<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 22 December 2015 at 19:29, Dan Prince <span dir="ltr"><<a href="mailto:dprince@redhat.com" target="_blank">dprince@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Tue, 2015-12-22 at 15:36 +0000, Dougal Matthews wrote:<br>
> Hi all,<br>
><br>
> This topic came up in the 2015-12-15 meeting[1], and again briefly<br>
> today.<br>
> After working with the code that came out of the deployment library<br>
> spec[2] 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-<br>
> 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<br>
> swift)<br>
> how do we handle the case where there is an error? For example, if<br>
> we are<br>
> uploading 10 files - what do we do if the 5th one fails for some<br>
> reason?<br>
> There is a patch to do a manual rollback[3], but I have concerns<br>
> about<br>
> doing this in Python. If Swift is completely inaccessible for a<br>
> short<br>
> period the rollback wont work either.<br>
><br>
> - When deploying to Heat, we need to download all the YAML files<br>
> from Swift.<br>
> This can take a couple of seconds. What happens if somebody starts<br>
> to<br>
> upload a new version of the plan in the middle? We could end up<br>
> trying to<br>
> deploy half old and half new files. We wouldn't have a consistent<br>
> view of<br>
> the database.<br>
><br>
> We had a few suggestions in the meeting:<br>
><br>
> - Add a locking mechanism. I would be concerned about deadlocks or<br>
> having to<br>
> lock for the full duration of a deploy.<br>
> - Store the files in a tarball (so we only deal with one file). I<br>
> think we<br>
> could still hit issues with multiple operations unless we<br>
> guarantee that<br>
> only one instance of the API is ever running.<br>
<br>
</div></div>I may be partial to trying out the above solutions because I was in the<br>
meeting. Before we write these off shouldn't we prototype them out<br>
first?<br></blockquote><div><br></div><div>Sure, I would be interested in seeing prototypes. I think the hardest <br>problem will be validating the prototypes and making sure they are flexible<br>enough going forward.<br><br></div><div>At the moment all the Swift interaction is in one storage backend[1], it<br></div><div>might be that the best way forward is to support multiple options and then<br></div><div>we can see over time which works best. However, the likely outcome would<br></div><div>be that the default is the one that wins regardless.<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Anyways, I feel like the title of this thread is a bit loaded. Swift<br>
may not be the best "database"... but if our goal is to use it for<br>
object storage while we design set of workflows to help us deploy<br>
things then I think it might fit in nicely.<br></blockquote><div><br></div><div>That's fair, the subject was probably a bit sensationalist. I actually intended<br></div><div>to change it to "store", but the difference is neither here nor there now.<br><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><font color="#888888">
Dan<br>
</font></span><span class=""><br>
><br>
> I think these could potentially be made to work, but at this point<br>
> 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>
> - Invest time in building something on Swift.<br>
> - Glance was transitioning to be a Artifact store. I don't know the<br>
> status of<br>
> this or if it would meet out needs.<br>
><br>
> Any input, ideas or suggestions would be great!<br>
><br>
> Thanks,<br>
> Dougal<br>
><br>
><br>
> [1]: <a href="http://eavesdrop.openstack.org/meetings/tripleo/2015/tripleo.201" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/meetings/tripleo/2015/tripleo.201</a><br>
> 5-12-15-14.03.log.html#l-89<br>
> [2]: <a href="https://specs.openstack.org/openstack/tripleo-specs/specs/mitaka" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/tripleo-specs/specs/mitaka</a><br>
> /tripleo-overcloud-deployment-library.html<br>
> [3]: <a href="https://review.openstack.org/#/c/257481/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/257481/</a><br>
</span>> _____________________________________________________________________<br>
<div class=""><div class="h5">> _____<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubs" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubs</a><br>
> cribe<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>
<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>
</div></div></blockquote></div><br></div></div>