Open Stack

On Thu, Feb 12, 2015 at 3:59 AM, Tomasz Napierala <tnapierala at mirantis.com>
wrote:

>
> > On 10 Feb 2015, at 23:02, Andrew Woodward <xarses at gmail.com> wrote:
> >
> > 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.
>
> 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.
>
> > I think we need to add a requirements that we need to be able to:
> > a) pre-populate the cacher
> > 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)
>
> This sounds for me like creating local mirror ;) We don’t want to do this.
> We are thinking about mirror verification tool, it was mentioned by
> eifferent guys already. Do you really think we should prepopulate cache?


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.

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]


> 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.
>

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.


> Regards,
> --
> Tomasz 'Zen' Napierala
> Sr. OpenStack Engineer
> tnapierala at mirantis.com
>
>
>
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

[1] https://blueprints.launchpad.net/fuel/+spec/virtual-router-for-env-nodes


-- 
Andrew
Mirantis
Fuel community ambassador
Ceph community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150212/aad34870/attachment.html>