Open Stack

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 <xarses at gmail.com> wrote:

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



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