Open Stack

Zane, thanks very much for the detailed feedback. I have added my comments
inline.

Zane Bitter <zbitter at redhat.com> wrote on 10/29/2013 08:46:21 AM:
...
> 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.

The explicit specification of the attributes (or outputs) is aimed
primarily
at providing a name for the output so that they can be referred to in
component
invocations and also by software config providers (Chef or Puppet, etc.) to
access them. The use of the attributes to check or validate is only a
secondary
aim and this could just be a consistency check with name matching. If we
had
more information such as types, constraints, about these attributes
(similar to inputs of a template) we can validate more. But this is not
the primary goal.

>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.

The way inputs/outputs are exposed in a CM system
would depend on its conventions. In our use with Chef, we expose these
inputs and outputs as a Chef's node attributes, i.e., via the node[][]
hash. I could imagine a similar scheme for Puppet. For a shell type of
CM provider the inputs/outputs can be exposed as Shell environment
variables. To avoid name conflicts, these inputs/outputs can be prefixed
by a namespace, say Heat.


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

Agreed -- we also prefer Opt1!

>
> E3: Sounds like a real issue (also, the solution for E2 has to take this
> into account too); not sure about the implementation.

Yes, agreed -- E2 has to understand which output from which invocation of
a component is being used or referred to. With invocation_id's it should
be possible to uniquely identify the component invocation.


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

I missed this implication of using a list! You are right, it should be
a dictionary and Heat would be building the dependence graph.


> 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.

Good point. I think it could be specified on both places. It definitely
could be specified on a particular invocation. I am not fully sure on this,
but one can also imagine cases where a cross-component
dependency is true for all invocations of a component, and hence might
be specified as a part of the component definition as a dependency between
two component types.

Thanks,
LN


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131030/5b87b960/attachment.html>