Excerpts from Ladislav Smola's message of 2013-12-20 05:48:40 -0800: > On 12/20/2013 02:37 PM, Imre Farkas wrote: > > On 12/20/2013 12:25 PM, Ladislav Smola wrote: > >> 2. Heat stack create, update > >> This is locked in the process of the operation, so nobody can mess with > >> it while it is updating or creating. > >> Once we will pack all operations that are now aside in this, we should > >> be alright. And that should be doable in I. > >> So we should push towards this, rather then building some temporary > >> locking solution in Tuskar-API. > > > > It's not the issue of locking, but the goal of Tuskar with the > > Provision button is not only a single stack creation. After Heat's job > > is done, the overcloud needs to be properly configured: Keystone needs > > to be initialized, the services need to be registered, etc. I don't > > think Horizon wants to add a background worker to handle such operations. > > > > Yes, that is a valid point. I hope we will be able to pack it all to > Heat Template in I. This could be the way > https://blueprints.launchpad.net/heat/+spec/hot-software-config > > Seems like the consensus is: It belongs to Heat. We are just not able to > do it that way now. > > So there is a question, whether we should try to solve it in Tuskar-API > temporarily. Or rather focus on the Heat. >
Interestingly enough, what Imre has just mentioned isn't necessarily covered by hot-software-config. That blueprint is specifically about configuring machines, but not API's. I think we actually need multi-cloud to support what Imre is talking about. These are API operations that need to follow the entire stack bring-up, but happen in a different cloud (the new one). Assuming single servers instead of loadbalancers and stuff for simplicity: resources: keystone: type: OS::Nova::Server glance: type: OS::Nova::Server nova: type: OS::Nova::Server cloud-setup: type: OS::Heat::Stack properties: cloud-endpoint: str_join [ 'https://', get_attribute [ 'keystone', 'first_ip' ], ':35357/' ] cloud-credentials: get_parameter ['something'] template: keystone-catalog: type: OS::Keystone::Catalog properties: endpoints: - type: Compute publicUrl: str_join [ 'https://', get_attribute [ 'nova', 'first_ip' ], ':8447/' ] - type: Image publicUrl: str_join [ 'https://', get_attribute [ 'glance', 'first_ip' ], ':12345/' ] What I mean is, you want the Heat stack to be done not when the hardware is up, but when the API's have been orchestrated. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev