Open Stack

D+ here too.  seems unanimous.  (a bad mark at school but here a good 
thing!)

this captures the single biggest thing i think most of us care about:  
composition / more flexible re-use.
and does it in a manageable incremental way.

in the interest of separating issues, these are two other areas which 
are mostly independent but i think
also very important:

* intuitive DSL -- something easier to write and easier to read. two 
offenders which it seems not hard to
fix are long type names eg "OS::Nova::Server" (for which could introduce 
supertypes/aliases eg "server"?),
and embedded scripts/mappings (which a bundle could alleviate eg ZIP as 
per Thomas's suggestion)

* modelling relationships -- if we can support typed relationships 
between components (resources)
then we have a leg-up both for auto-wiring and for acting on wait 
conditions at a finer granularity.  this
makes the descriptions smaller and more portable, makes deployment 
faster, and allows more use cases.
(i've experimented with modelling this as requirements and fulfillments, 
which seems parsimonious and
natural, but that's part of what we need to figure out!)
     as an example, here are two use cases i believe we would struggle 
with (people would have to roll
their own co-ordination; but please correct me if i'm wrong):
** some of the hadoop distros need to know the ip's of a quorum of 
servers in order to seed the
config for those servers; and
** some databases require special connectors installed at the client 
(e.g. install php_mysql at the
wordpress node iff the database is mysql -- a conclusion from TOSCA is 
that if this logic lives in a
relationship/requirement type PhpDatabaseRequirement then we can reuse 
it, as opposed to
baking in java+php+ruby+etc support into all database resources, or 
mysql+db2+oracle+etc
support into all appserver resources)  [hope this is clear, please ping 
me if not]

but we need to iterate on these and meanwhile we need to make progress!  so:

+1 to the small focussed separate blueprints Zane proposes

--a


On 26/04/2013 11:17, Zane Bitter wrote:
> On 25/04/13 23:06, Randall Burt wrote:
>> (D) and a half (I'm more of a "OMG puppies!" man, myself). Clear, 
>> focused, and actionable. I really like this and think there's tons of 
>> value beyond just implementing an OpenStack native template language. 
>> Hopefully we can wrangle the different efforts around the native 
>> template language by next weeks meeting.
>>
>> In any case, Zane, do you think it would be a good idea to submit 
>> your action items as separate blueprints or include them under the 
>> Native DSL one? In either case, this sounds like an excellent 
>> proposal to me, and I'd totally throw my name in to help implement it.
>
> Thanks Randall. I think there's some advantage in separate blueprints: 
> we can keep them small, track the dependencies between them, and keep 
> a handle on what is happening even if we farm out the work to 
> different people.[1] Plus I see most of these as things that add value 
> in themselves, not just as intermediate steps towards the larger goal 
> (both of which are obviously important).
>
> cheers,
> Zane.
>
> [1] and by "we" I mean Steve H, to whom the task has fallen to have to 
> report this kind of stuff every week at the OpenStack project meeting. 
> Thanks Steve!
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev