<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css">body {word-wrap: break-word; background-color:#ffffff;}</style>
</head>
<body>
<div style="font-family: sans-serif; font-size: 16px">There are ways to handle revision control for a zip. For example, you can simply expand it, and check in the folder, and then re-zip it when you are ready to move it somewhere. This way you can see changes
to the individual files. <br>
<br>
Another way is to simply reference a repo folder directly, so the need for the zip is completely eliminated for setups that have network access to the repo. The zip file can be used in those cases where there is not a suitable network present.<br>
<br>
--<br>
Adrian</div>
<br>
<br>
-----Original message-----<br>
<blockquote style="; border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">
<div style="font-family: sans-serif; font-size: 14px"><b>From: </b>Zane Bitter <zbitter@redhat.com><b><br>
To: </b>Alex Heneveld <alex.heneveld@cloudsoftcorp.com><b><br>
Cc: </b>OpenStack Development Mailing List <openstack-dev@lists.openstack.org><b><br>
Sent: </b>Mon, Apr 29, 2013 18:42:34 GMT+00:00<b><br>
Subject: </b>Re: [openstack-dev] [Heat] A concrete proposal for Heat Providers<br>
<br>
</div>
<div>
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
<div><font size="2"><span style="font-size:10pt;">
<div class="PlainText">On 26/04/13 13:24, Alex Heneveld wrote:<br>
><br>
> D+ here too. seems unanimous. (a bad mark at school but here a good<br>
> thing!)<br>
><br>
> this captures the single biggest thing i think most of us care about:<br>
> composition / more flexible re-use.<br>
> and does it in a manageable incremental way.<br>
><br>
> in the interest of separating issues, these are two other areas which<br>
> are mostly independent but i think<br>
> also very important:<br>
><br>
> * intuitive DSL -- something easier to write and easier to read. two<br>
> offenders which it seems not hard to<br>
> fix are long type names eg "OS::Nova::Server" (for which could introduce<br>
> supertypes/aliases eg "server"?),<br>
<br>
Aliases are easy to implement, and it's also easy to make a translation <br>
tool to reverse them, so if this would move the needle on adoption then <br>
it sounds like a good thing. Presumably we'd want to wait until we have <br>
native resource types for everything implemented, since there's no point <br>
aliasing to AWS resource types.<br>
<br>
> and embedded scripts/mappings (which a bundle could alleviate eg ZIP as<br>
> per Thomas's suggestion)<br>
<br>
Yeah, the embedded script markup is horrible at the moment - it's <br>
basically write-only code. There are a number of ideas being kicked <br>
around in these two blueprints:<br>
<br>
<a href="https://blueprints.launchpad.net/heat/+spec/bash-environment-function" target="_BLANK">https://blueprints.launchpad.net/heat/+spec/bash-environment-function</a><br>
<a href="https://blueprints.launchpad.net/heat/+spec/template-string-function" target="_BLANK">https://blueprints.launchpad.net/heat/+spec/template-string-function</a><br>
<br>
And I think that the YAML format plus whichever of those we end up <br>
implementing will go a long way towards making the scripts actually <br>
readable again.<br>
<br>
I understand the appeal of the zip archive - you can mix different file <br>
formats easily - but the downside is that the template becomes basically <br>
a black box and you can't e.g. check in to version control and do diffs.<br>
<br>
Not that things are perfect at the moment - nested stacks already make <br>
it difficult to guarantee that you can e.g. launch an identical stack <br>
again at a later date, unless you have a lot of very disciplined <br>
practices around how you use them. Provider stacks would make that even <br>
worse. I'm not sure yet what the best answer is.<br>
<br>
Maybe we should just scrap our API and replace it with a Git repo that <br>
updates your stack every time you do git push. I'm only half joking.<br>
<br>
><br>
> * modelling relationships -- if we can support typed relationships<br>
> between components (resources)<br>
> then we have a leg-up both for auto-wiring and for acting on wait<br>
> conditions at a finer granularity. this<br>
> makes the descriptions smaller and more portable, makes deployment<br>
> faster, and allows more use cases.<br>
> (i've experimented with modelling this as requirements and fulfillments,<br>
> which seems parsimonious and<br>
> natural, but that's part of what we need to figure out!)<br>
<br>
I'm still trying to get my head around this part, and in particular to <br>
what extent it overlaps with existing configuration management tools <br>
(i.e. Puppet/Chef). Concrete use cases are definitely the most helpful <br>
thing for trying to figure that out though, so thanks!<br>
<br>
> as an example, here are two use cases i believe we would struggle<br>
> with (people would have to roll<br>
> their own co-ordination; but please correct me if i'm wrong):<br>
> ** some of the hadoop distros need to know the ip's of a quorum of<br>
> servers in order to seed the<br>
> config for those servers; and<br>
<br>
As Steve said, it seems like this might be possible even now. It would <br>
be interesting to dig into this a bit deeper and either confirm that or <br>
refine our understanding of the problem.<br>
<br>
> ** some databases require special connectors installed at the client<br>
> (e.g. install php_mysql at the<br>
> wordpress node iff the database is mysql -- a conclusion from TOSCA is<br>
> that if this logic lives in a<br>
> relationship/requirement type PhpDatabaseRequirement then we can reuse<br>
> it, as opposed to<br>
> baking in java+php+ruby+etc support into all database resources, or<br>
> mysql+db2+oracle+etc<br>
> support into all appserver resources) [hope this is clear, please ping<br>
> me if not]<br>
<br>
This makes sense, but it seems to me pretty independent of the <br>
underlying infrastructure. Can you make a case for why this kind of <br>
thing should be baked in to OpenStack, rather than using tools like <br>
Puppet and Chef?<br>
<br>
I'm going to take a stab at it... say that different cloud providers <br>
offer different DBaaS services, perhaps some based on MySQL and others <br>
on... I don't know... something different. Then, in order to spin up <br>
your stack on any cloud you have to configure your app to talk to the <br>
right DBaaS, and you don't want to modify your template for each one.<br>
<br>
Am I close? It sounds interesting, but also doesn't seem like a high <br>
priority (not as high a priority as getting actually a DBaaS into <br>
OpenStack, for example).<br>
<br>
><br>
> but we need to iterate on these and meanwhile we need to make progress!<br>
> so:<br>
><br>
> +1 to the small focussed separate blueprints Zane proposes<br>
<br>
Cool, thanks for the input, it's very helpful.<br>
<br>
cheers,<br>
Zane.<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_BLANK">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</span></font></div>
</div>
</blockquote>
</body>
</html>