Open Stack

On 28/10/13 04:23, Lakshminaraya Renganarayana wrote:
> Sorry, Re-posting this with [Heat] in the subject line, because many of
> us have filters based on [Heat] in the subject line.
>
> Hello,
>
> A few us at IBM studied Steve Baker's proposal on HOT Software
> Configuration. Overall the proposed constructs and syntax are great --
> we really like the clean syntax and concise specification of components.
> We would like to propose a few minor extensions that help with better
> expression of dependencies among components and resources, and in-turn
> enable cross-vm coordination. We have captured our thoughts on this on
> the following Wiki page
> _
> __https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response_
>
> We would like to discuss these further ... please post your comments and
> suggestions.

Thanks for posting this! It seems to me like there may be one basic idea 
behind many of the differences between this and Steve's proposal. I'm 
going to try to explain the dichotomy, and let me know if I haven't 
understood correctly, but if I have then this is probably the first 
question we want to answer. (Note that some of the suggestions are 
definitely applicable regardless.)

So basically, the two options I see are:

1) Configurations represent entire software 'packages'; outputs are 
provided asynchronously as they become available and dependent packages 
can synchronise on them. Basically like WaitConditions now. (Steve B.)
2) Configurations represent individual steps in the deployment of a 
package; outputs are provided at the end of each configuration and 
dependent packages are synchronised purely on the graph of configs. 
(Lakshmi et. al.)

(I wrote this before seeing Georgy's comments, but I believe he has 
picked up on the same thing.)

I'm on the fence here. I lean toward the latter for 
implementation-related reasons, though the former seems like it would 
probably be tidier for users. I think getting a concrete idea of how 
outputs would be signalled within the config management system in the 
former system would allow us to compare it better to the latter system 
(which is described to a moderate level of detail already on this wiki 
page).


As brief feedback on these suggestions:
E1: Probably +1 for inputs, but tentative -1 for attributes. I'm not 
sure we can check anything useful with that other than internal 
consistency of the template. I'd like to see some more detail about how 
inputs/outputs would be exposed in the configuration management systems 
- or, more specifically, how the user can extend this to arbitrary 
configuration management systems.

E2: +1 for Opt1
     -1 for Opt2 (mixing namespaces is bad)
     -1 for Opt3

E3: Sounds like a real issue (also, the solution for E2 has to take this 
into account too); not sure about the implementation. In this method 
(i.e. option (2) above) shouldn't we be building the dependency graph in 
Heat rather than running through them sequentially as specified by the 
user? In that case, we should use a dictionary not a list:

   app_server:
     type: OS::Nova::Server
     properties:
       components:
         install_user_profile:
           definition: InstallWasProfile
           params:
             user_id
         install_admin_profile:
           definition: InstallWasProfile
           params:
             admin_id

E4: +1

E5: +1 but a question on where this is specified. In the component 
definition itself, or in the particular invocation of it on a server? 
Seems like it would have to be the latter.

cheers,
Zane.