<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 22 December 2015 at 16:56, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Dougal Matthews's message of 2015-12-22 07:36:02 -0800:<br>
<span class="">> Hi all,<br>
><br>
> This topic came up in the 2015-12-15 meeting[1], and again briefly today.<br>
> After working with the code that came out of the deployment library spec[2]<br>
> I<br>
> had some concerns with how we are storing the templates.<br>
><br>
> Simply put, when we are dealing with 100+ files from tripleo-heat-templates<br>
> how can we ensure consistency in Swift without any atomicity or<br>
> transactions.<br>
> I think this is best explained with a couple of examples.<br>
><br>
>  - When we create a new deployment plan (upload all the templates to swift)<br>
>    how do we handle the case where there is an error? For example, if we are<br>
>    uploading 10 files - what do we do if the 5th one fails for some reason?<br>
>    There is a patch to do a manual rollback[3], but I have concerns about<br>
>    doing this in Python. If Swift is completely inaccessible for a short<br>
>    period the rollback wont work either.<br>
><br>
<br>
</span>You could create a unique swift container, upload things to that, and<br>
then update a pointer in a well-known location to point at that container<br>
for the new plan only after you've verified it is available. This is a<br>
primitive form of Read-copy-update.<br>
<span class=""><br>
>  - When deploying to Heat, we need to download all the YAML files from<br>
> Swift.<br>
>    This can take a couple of seconds. What happens if somebody starts to<br>
>    upload a new version of the plan in the middle? We could end up trying to<br>
>    deploy half old and half new files. We wouldn't have a consistent view of<br>
>    the database.<br>
><br>
<br>
</span>Perhaps you should land a change in Heat to allow templates to be directly<br>
downloaded by the engine from swift without needing to be uploaded. In<br>
the past allowing URLs to be downloaded unfettered was disabled because<br>
we don't want Heat to be a DoS engine, but swift would be in-cloud and<br>
could be restricted to the stack owner.<br>
<span class=""><br>
> We had a few suggestions in the meeting:<br>
><br>
>  - Add a locking mechanism. I would be concerned about deadlocks or having<br>
> to<br>
>    lock for the full duration of a deploy.<br>
<br>
</span>Deadlocks only happen when competing interests lock _two_ things in<br>
different order. Have one thing to lock, and you don't have to worry<br>
about this.<br></blockquote><div><br></div><div>Good point. Sorry, I am getting my terminology confused. I can't think what the<br></div><div>word is, but I was worried about stale locks getting lost and locking everything up.<br></div><div>Where would we store the lock? On the machine running the API maybe?<br></div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>  - Store the files in a tarball (so we only deal with one file). I think we<br>
>    could still hit issues with multiple operations unless we guarantee that<br>
>    only one instance of the API is ever running.<br>
><br>
> I think these could potentially be made to work, but at this point are we<br>
> using the best tool for the job?<br>
><br>
> For alternatives, I see a can think of a couple of options:<br>
><br>
> - Use a database, like we did for Tuskar and most OpenStack API's do.<br>
<br>
</span>It's worth noting that many OpenStack API's/daemons are using the<br>
database + MQ to provide consistency in a distributed fashion, and many<br>
have identified that this doesn't scale particularly well, and looking<br>
at tooz to help bring in DLM's. In fact, a spec recently landed around<br>
this:<br>
<br>
<a href="http://specs.openstack.org/openstack/openstack-specs/specs/chronicles-of-a-dlm.html" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/openstack-specs/specs/chronicles-of-a-dlm.html</a><br>
<br>
So if you are only using the DB for consistency, you might want to just<br>
use tooz+swift.<br></blockquote><div><br></div><div>Interesting! I hadn't come across this and I'll look into it. Thanks.<br><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> - Invest time in building something on Swift.<br>
> - Glance was transitioning to be a Artifact store. I don't know the status<br>
> of<br>
>   this or if it would meet out needs.<br>
<br>
</span>I'd say the artifact store is more about exposing options to users, and<br>
less about providing primitives for an API.<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>