Clark Boylan <cboy...@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 _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
