cloud-init-dev team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

On Thu, 17 May 2012, jvlcek wrote:

> Hey Scott,
>
<snip>
I'm sorry, but I don't think the message got through to the list, its not
viewable in the archive, and I don't see it in the moderator view either.

> Ultimately I'd like to get his fedora specific patches  and my patches merged
> into the upstream cloud-init bzr trunk.

I think I had just about everything from Garret merged back into 0.6.3.

> Can I simply move forward with pushing the changes to the cloud-init bzr
> development trunk?

The right thing to:
 *  get your changes into a local bzr branch:
    # init a repo, and checkout trunk (init repo is to share bzr info
    # across multiple checkouts, its different that git).
    bzr init-repo cloud-init
    bzr branch lp:cloud-init trunk.dist
    bzr branch trunk.dist local-dev-fedora
 * commit your changes
    bzr commit
 * push to launchpad to a personal branch:
    bzr push lp:~joev-n/cloud-init/fedora-changes
 * propose that for a merge into lp:cloud-init via web browser
    # open the branch in launchpad, it will be at:
    # https://code.launchpad.net/<YOUR_USERNAME>/<PROJECT>/<BRANCH_NAME>
    # for example:
    # https://code.launchpad.net/~joev-n/cloud-init/fedora-changes
    click 'propose for merging'
    select 'lp:cloud-init' as the target branch

I'll review the changes and push.
>
> My Immediate Goal:
> ------------------
>
>    Get input from cloud-init devel for how best to add cloud back
>    end support to cloud-init
>
> My Ultimate Goal:
> -----------------
>
>    Add my support for RHEVm and vSphere to cloud-init for
>    instances launched using DeltaCloud
>    (http://deltacloud.apache.org/)
>
>    DeltaCloud injects user data for instances launched to
>    RHEVm or vSphere via a floppy device hook and a CD device.

The NoCloud Datasource does something very similar, so that might be a
good reference.  We might even want to merge it in there, to avoid
multiple different data sources mounting and un-mounting devices (for
speed reasons).

> A code Patch:
> -------------
>
>    Attached is a patch for modifications I made to cloud-init for
>    a proof of concept/prototype for accessing user data for RHEVm
>    and vSphere.
>
>    I started with the Fedora archive version:
>    http://pkgs.fedoraproject.org/gitweb/?p=cloud-init.git
>
>    I then modified cloudinit/DataSourceEc2.py to access user data
>    for RHEVm and vSphere.
>
>    The testing I have done so far consists of passing a very simple
>    shell script as the user data.
>
>    The patch consists of 4 files:
>
>     Makefile.fedora and cloud-init-multi-cloud.spec
>       Ignore these two files. I use them to generate an rpm for testing.

I'm not opposed to keeping these around, ideally not in the top dir, if
they're useful.

>     cloud-init-fedora.cfg
>       Modified to address ec2-user to root user and tags bug
>
>     cloudinit/DataSourceEc2.py
>       - added some supporting routines
>       - Modified get_data() to support ec2, rhevm and vspher
>       - Moved existing EC2 specific get_data() logic to user_data_ec2()
>       - Added user_data_rhevm()
>       - Added user_data_vsphere()
>
> What I hope to do next.
> -----------------------
>
>    With the simple proof of concept working I want to get some input
>    from cloud-init developement on how best to proceed.
>
>    In addition to the code changes to cloudinit/DataSourceEc2.py I
>    have also modify cloud-init-fedora.cfg (cloud.cfg) to enable
>    root user instead of ec2-user since ec2-user is not available
>    on RHEVm and vSphere. I have also had to remove tags:
>    cloud_config_modules and cloud_final_modules from cloud-init-fedora.cfg
>    to workaround what seems to be a bug I am investigating.
>
>    I am "not" looking for a code review yet. I am interested in
>    discovering if the idea of adding rhevm and vsphere user data
>    support to cloudinit/DataSourceEc2.py is acceptable.

Well, I'm fine with adding support for a rhevm/vsphere data source, for
sure.  I took just a quick glance, and here are the comments I have right
now:
 * Generally, I think you'll be better to look at the DataSourceNoCloud or
   DataSourceConfigDrive as starting points.  Both of these actually mount
   media and look for files files there.  Very similar to what it looks
   like you're doing in your changes.
 * _run_cmd is very much like util.subp.  I'm not convinced that util.subp
   is the most wonderful interface in the world, but ideally we don't add
   yet another way to invoke subprocesses.
 * I'd really rather avoid dependency on 'facter' at the moment.  That is
   primarily just because of the language selection of facter (ruby) and
   the lack of ruby in Ubuntu cloud images.  It shouldn't be too hard to
   add support for determining the few things you're using from it.

> My questions:
> ------------
>
>    - Is adding rhevm and vsphere user data support to
>      cloudinit/DataSourceEc2.py is acceptable.
>
>    - Should cloudinit/DataSourceEc2.py remain unchanged an a
>      new the support for other cloud back ends be added in to
>      new files:
>
>      e.g.:
>      cloudinit/DataSourceRHEVm.py
>      cloudinit/DataSourcevSphere.py

I think we can probably make the changes clean enough to fit into
DataSourceNoCloud, but if not, we can just make DataSourceSOMETHING that
describes both of these 2 things, as they look very similar.

>    - Should additional cloud back end support be added to
>      cloudinit/DataSourceEc2.py and perhaps renamed it to
>      cloudinit/DataSourceCloud.py
>
>    - Would it be better to create and user a cloud-init-user instead
>      of using ec2-user and/or the root user?

Well, others have asked to have cloud-init be able to create a local user
if it did not exist.  I think that'd be the best solution.  Cloud-init
would just add a local user, but as you've discovered, using 'user' as
'root' should work, right?

>    - Can I  push a polished version of this upstream and/or
>      into the Fedora archive version? Can I get push privilege
>      for adding a patch to the Fedora archive version?

I'm not really aware of how Fedora archive permissions work.  I'm sure
Garret can answer that.

>    - Any other suggestions?

Sysvinit scripts are what you'll need for RH.  I'd love to have ones
that worked for RHEV and SLES.

> Thank you in advance for the help/feedback.

Sorry I missed this before.

>
> Joe VLcek
>
>
>
>