Open Stack

On Tue, Dec 20, 2016 at 10:19:26AM -0800, James E. Blair wrote:
> Hi,
> 
> I've been working on reconciling a confusing part of the Nodepool config
> file: the mapping between labels, provider images, and diskimages.
> 
> Broadly speaking the three constructs are:
> 
> diskimages: the file(s) that DIB produces
> provider images: a disk image uploaded to a provider, combined with
>   flavor information
> labels: a set of nodes created from provider images
> 
> I think the biggest problem is that provider images are combining two
> concepts which should be distinct: uploaded diskimages and flavors used
> for launching nodes.  They hold at least one piece of data for each of
> these functions: the image metadata (which is used at upload time) and
> the flavor (used at node creation time), which makes it impossible to
> disentangle them without a change.
> 
> Adding to the confusion is simply the use of the word 'images' in
> provider images, as it's a little unclear what an image is in this
> context (a single diskimage?  one of may images uploaded to the cloud?
> an artificial construct combining the two?)
> 
> The literal way to reconcile the current configuration syntax would be to
> upload the same diskimage to a provider multiple times, each as a
> different provider image (with its own set of metadata).  That seems
> very wasteful.
> 
> Because we did not include support for that (nor should we have, I
> think), we needed to take at least one step in the direction of
> correcting this situation when making the new zookeeper builders.  To
> that end, we merged this change:
> 
>   https://review.openstack.org/396749
> 
> which removed the diskimage parameter from the provider image stanza.
> This made an implicit 1:1 connection between the provider images and
> diskimages, based on their having the same name.  That means that we
> know which metadata to use when uploading a diskimage to a provider.
> However, it also means that there is now not a way to specify more than
> one flavor with the same image.  That is not a feature we use currently
> (especially since the allocator does not take flavor size into acconut)
> but it is one we want to have in the future.
> 
> I don't see a way to support both of these features (single upload and
> multiple flavors) without a change to the configuration.  I propose that
> we keep 396749 in place, and iterate forward.
> 
> I think we should change the provider images section to separate out the
> parts pertaining to diskimages and those pertaining to flavors.
> Something like:
> 
>   labels:
>     - name: small-ubuntu-trusty
>       ready-script: configure_mirror.sh
>       min-ready: 1
>   
>   providers:
>     - name: cloud
>       diskimages:
>         - name: ubuntu-trusty
>           metadata:
>             foo: bar
>           labels:
>             - name: small-ubuntu-trusty
>               ram: 2g
>             - name: large-ubuntu-trusty
>               ram: 8g
>   
What are you visioning for the image-type key? I only bring it up since we've
dropped 'images' here.

>   diskimages:
>     - name: ubuntu-trusty
>       private-key: /home/nodepool/.ssh/id_rsa
>       elements: ...
> 
> That also lets us remove the 'providers' section from each label
> definition.  That is used to indicate which providers should be used to
> create nodes of each label, but by associating labels with provider
> copies of diskimages, it is simple to add or remove those label entries
> (which would not affect the diskimage entry, whose addition/removal
> would cause image uploads or deletions).  I also moved the 'private-key'
> attribute to the diskimage section, since that should not differ by
> provider.
> 
++ to providers removal.

On the fence about private-key moving to diskimages.  But, understand why, in
our nodepool.yaml we have 74 entries for it; all the same. In the use case I am
thinking of, where using nodepool-builder just to build images, there wouldn't
be need for a private-key. We'd only use that after uploading.

> Does this sound like a reasonable path forward?
> 
> Thanks,
> 
> Jim
> 
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra