cloud-init-dev team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

lots of comments...
Thanks for all the work here, we need to try to do things more iteratively. I know we're still bringing this all up, but there is just so much here that its almost impossible to review.

General:
 * please lets try to do smaller merge proposals, doing one set of things
   at a time.
 * full chart of enabled/disabled at: http://goo.gl/q78sY8
   this is a private url, not suitable for a commit message
   possibly we just move this into doc in cloud-init?
 * where is the upstream bug that prevents 2.2 from working correctly?

 * i think we can live without 'alias: t'.
 * apparently we should be using dnf rather than yum in any recent RH distro
 * "switch to using images.linuxcontainers.org from using ubuntu daily images"
    why ?? we really need to be testing Ubuntu images, not linuxcontainers.org
    I like using them for other distros where we have nothing else, but
    ubuntu should test primarily on ubuntu images.

 * system_ready_script can be simplified by being a command, passed
   directly to 'execute'.
     system_ready_script: ['test', '-e', '/run/cloud-init/result.json']
   that saves writing the file and executing it on the other side, and
   also then assuming 'bash'.
 * "Pass $HOME through in tox citest envs for lxc client use"
   message doesn't make sense. where are we using the lxc client? just
   for developer debug ?
 * "Disable centos66 test"
   why ?

tox.ini:
 * multiple citest_* are fine for now, but i really do not want them
   going forward.


Easily droppable commits / things that can be done separartely:
- "Use LOG.warning instead of deprectated LOG.warn"
   why? This is just not necessary in this merge proposal.
- "Change behavior of upgrade in setup_image"

tests/cloud_tests/bddeb.py
 * 7cd4a3b5 source_archive: can we either
   a.) just assume the deb-src lines are present
   b.) hueristically grab one... i'd like to not use us.archive.com if
       the image is otherwise using archive.ubuntu.com as that will
       avoid any proxy in the path.  this is kind of tough actually..

 * creating the tarball..
   I think what we want to do here is:
     a.) make-tarball on "this side"
     b.) modify bddeb to be able to just create a debian/ dir
         either
         i.) have it create the orig tarball and a debian.tar.gz into a 
             provided (empty) output dir.
         ii.) have it just create the debian.tar.gz and we create the tarball
              example of doing that http://paste.ubuntu.com/23870964/
     c.) move the tarball and debian dir over, extract tarball, extract debian/
     d.) mk-build-deps --install .... debian/control
     e.) dpkg-buildpackage

   doing this should mean we do  not have to 'install additional build deps'
   but rather just have mk-build-deps do the right thing.

 * when building with dpkg-buildpackage or debuild, good to
   allow setting DEB_BUILD_OPTIONS=nocheck (which will not run pep8 and
   nosetests)

 * i think we can drop 'git' due to above, 'tar' is essential so you
   do not have to declare it.  
   lets do the install of devscripts and equivs with --no-install-recommends
   and also eatmydata everywhere

 * i think the above path means we do not depend on deb-src lines.


-- 
https://code.launchpad.net/~wesley-wiedenmeier/cloud-init/+git/cloud-init/+merge/308218
Your team cloud init development team is requested to review the proposed merge of ~wesley-wiedenmeier/cloud-init:integration-testing into cloud-init:master.