[openstack-dev] [TripleO] Tuskar CLI after architecture changes

Ladislav Smola lsmola at redhat.com
Mon Jan 6 09:32:21 UTC 2014

On 12/20/2013 05:51 PM, Clint Byrum wrote:
> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Thanks for pointing that out, we should discuss it with Heat guys.

More information about the OpenStack-dev mailing list