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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
