> On 30/01/14 12:20, Randall Burt wrote: > > On Jan 30, 2014, at 12:09 PM, Clint Byrum<cl...@fewbar.com> > > wrote: > > >> >I would hope we would solve that at a deeper level, rather than making > >> >resources for the things we think will need re-use. I think nested stacks > >> >allow this level of re-use already anyway. Software config just allows > >> >sub-resource composition. > > Agreed. Codifying re-use inside specific resource types is a game of > > catch-up I don't think we can win in the end. > > Thomas started this discussion talking about resources, but IMHO it's > mostly really about the scaling API. It just happens that we're > implementing the resources first and they need to match what we > eventually decide the API should look like.
Not talking about the API was completely intentional. I believe that we should offer the best resource interface possible, regardless of the underlying API. > So we're creating a new API. That doesn't happen very often. It's > absolutely appropriate to consider whether we want two classes of > resources in that API to have a 1:1 or 1:Many relationship, regardless > of how many fancy transclusion things we have in the templates. For a > start because one of the main reasons to create an API is so people can > access it without templates. Fair enough. To give my opinion, I think we're overstating how useful it'd be to reuse launch configurations. The real reusability is at software config level, not so much about what flavor you want to use when starting an instance. Also, we already have provider templates to be able to embed resources and their properties. Finally, if we go back to the API, it's one less thing to manage and simplify the model. The group becomes the bag containing scaling properties and resource definition. -- Thomas _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
