[OpenStack-Infra] Nodepool config file structure

James E. Blair corvus at inaugust.com
Tue Dec 20 18:54:30 UTC 2016


Clark Boylan <cboylan at sapwetik.org> writes:

> This appears to currently be called "meta".

Let's change it while we're at it.  :)

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

How about we do both then?  Private-key in diskimages section to supply
a default value, and also overridable in provider-diskimages?

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

Yeah, I don't think this addresses that problem.  I suspect a real
solution to it would look a lot different than what we have now.  I'm
open to suggestions.

-Jim



More information about the OpenStack-Infra mailing list