Open Stack

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.