There where some questions regarding direction for this on the fuel meeting today. Can you elaborate on the status?
On Thu, Feb 12, 2015 at 12:01 PM, Andrew Woodward <xar...@gmail.com> wrote: > > > On Thu, Feb 12, 2015 at 3:59 AM, Tomasz Napierala <tnapier...@mirantis.com > > wrote: > >> >> > On 10 Feb 2015, at 23:02, Andrew Woodward <xar...@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 >> tnapier...@mirantis.com >> >> >> >> >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@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 > -- Andrew Mirantis Fuel community ambassador Ceph community
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev