Open Stack

On Tue, Dec 20, 2016, at 10:19 AM, James E. Blair wrote:

snip

> 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:

This appears to currently be called "meta".

>             foo: bar
>           labels:
>             - name: small-ubuntu-trusty
>               ram: 2g
>             - name: large-ubuntu-trusty
>               ram: 8g
>   
>   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.

I am not sure this is necessarily the case. You could make diskimages
that rely on cloud-init or glean to configure your users rather than
bake the key data in. (I seem to recall that at least one group wanted
that at one time, was it lifeless?) And if that was the case they could
certainly differ by provider or image or flavor even. Though I think we
would also need to add a public key field per image so that the nova
boot can be told what public key to provide via metadata.
 
> Does this sound like a reasonable path forward?

Yup, I think this makes sense and avoids duplicate image data. One other
similarish use case that I don't think this addresses that we should
consider is the one we had in hpcloud and what we do in osic-cloud1
currently. Basically chunk up a provider in several different ways to
affect distribution of nodes based on attributes within that provider. I
don't have any great ideas for how that might look right now, but wonder
if that might also solve the flavor problem. Probably something to think
about before we commit to this.

Clark