<div dir="ltr">There where some questions regarding direction for this on the fuel meeting today. Can you elaborate on the status?</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 12, 2015 at 12:01 PM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Feb 12, 2015 at 3:59 AM, Tomasz Napierala <span dir="ltr"><<a href="mailto:tnapierala@mirantis.com" target="_blank">tnapierala@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
> On 10 Feb 2015, at 23:02, Andrew Woodward <<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>> wrote:<br>
><br>
> previously we used squid in 3.0 and before. The main problem is that the deployment would proceeded even if not all the packages where cached or even available on the remote. This often lead to broken deployments that where hard to debug and a waste of alot of time. This _MUST_ be resolved or we will re-introduce this horrible work flow that we had placed all the packages on the system for to begin with.<br>
<br>
</span>Anyway we need to ensure our QA is run against fresh mirror, that would prevent a lot of problems. We also think about how situation in the field can differ from our labs and QA infra - there might be differences indeed.<br>
<span><br>
> I think we need to add a requirements that we need to be able to:<br>
> a) pre-populate the cacher<br>
> b) we need to not start the deployment until we either have every package in the chache (eiew) or at least know every package is reachable currently (or allow the user to select either as a deployment criteria)<br>
<br>
</span>This sounds for me like creating local mirror ;) We don’t want to do this.<br>
We are thinking about mirror verification tool, it was mentioned by eifferent guys already. Do you really think we should prepopulate cache?</blockquote><div><br></div></span><div>by pre-populate, I mean that we need to start some form of task that can be started to create a repo/mirror of the packages we know we need for the installation. The source of where this would be built from could be an ISO, or equally any other mirror site. The user should be able to use this as a base population for the packages. If the mirror is incomplete this should be OK also as long as the user is told that their nodes will attempt to get the remaining packages from the internet. The task should be able to be run at any time, and if desired the user would be able to make the deployment require it to finish first.</div><div><br></div><div>so yes, we need both a repo/mirror like now, with a passthrough that might use a squid proxy to help with multiple access. Keep in mind that the squid proxy would have to work with the virtual router for nodes bp [1]</div><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> I hink first node deployment will fetch a lot of packages, and other nodes will be easier. Once we have prototype, we will see some number.<span><br></span></blockquote><div><br></div></span><div>The first OS install will fetch packages, then later the fist of each roll will fetch different packages, it's possible we could get all the way to compute and fail there because we cant get a package. I can personally promise that without something else this will have problems with this the same as we did before with 3.0 (I could run two squid layers one in my host and one on my fuel vm and still have problems (usually cache misses)). When this occurs the result is terrible, hard for not fuel people to realize, and you will end up restarting the whole deployment. the user experience (UX) from this is horrible. We need the tools to prevent this from occurring at all.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
Regards,<br>
--<br>
Tomasz 'Zen' Napierala<br>
Sr. OpenStack Engineer<br>
<a href="mailto:tnapierala@mirantis.com" target="_blank">tnapierala@mirantis.com</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</span><div><div>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><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></div></blockquote></span></div><div class="gmail_extra"><br></div>[1] <a href="https://blueprints.launchpad.net/fuel/+spec/virtual-router-for-env-nodes" target="_blank">https://blueprints.launchpad.net/fuel/+spec/virtual-router-for-env-nodes</a><span class=""><br><br clear="all"><div><br></div>-- <br><div>Andrew<br>Mirantis<br>Fuel community ambassador <br>Ceph community</div>
</span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Andrew<br>Mirantis<br>Fuel community ambassador <br>Ceph community</div>
</div>