openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #07638
Re: Remove Zones code - FFE
See comments inline.
> -----Original Message-----
> From: Mark Washenberger [mailto:mark.washenberger@xxxxxxxxxxxxx]
> Sent: 15 February 2012 15:51
> To: Gabe Westmaas
> Cc: Armando Migliaccio; Jay Pipes; openstack@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack] Remove Zones code - FFE
>
> "Gabe Westmaas" <gabe.westmaas@xxxxxxxxxxxxx> said:
>
> > I think both these approaches are valid, and speaks to the fact that
> > there isn't really a relationship between the two concepts.
>
>
> Absolutely. An availability zone is about partitioning user instance
> infrastructure and exposing that partitioning scheme to the api user for
> reliability purposes. What we're talking about with "zones" is partitioning
> the nova *control* infrastructure (nova-api, nova-compute, database, rabbit,
> etc) in a way that enables scale. And we most likely do not expose these
> scale-partitioning details to the api user.
I think you touched the crucial point here: what is exposed to the user and what not. Reading:
http://wiki.openstack.org/MultiClusterZones#Design
one would think that zones is a concept exposed to end users. You're saying otherwise; Is it just my misunderstanding or the wiki page is out of sync with the latest developments? If zones are not going to be exposed to the users, what will? Just availability zones?
> The two concepts seem wholly
> independent to me, which is one reason why I think we should ditch the term
> "zone".
>
>
> "Gabe Westmaas" <gabe.westmaas@xxxxxxxxxxxxx> said:
>
> >
> >
> > On 2/15/12 9:48 AM, "Armando Migliaccio"
> > <Armando.Migliaccio@xxxxxxxxxxxxx> wrote:
> >
> >>I am a bit lost...what has size got to do with relationship?
> >>
> >>> -----Original Message-----
> >>> From: Jay Pipes [mailto:jaypipes@xxxxxxxxx]
> >>> Sent: 15 February 2012 14:36
> >>> To: Gabe Westmaas
> >>> Cc: Armando Migliaccio; Martin Paulo; openstack@xxxxxxxxxxxxxxxxxxx
> >>> Subject: Re: [Openstack] Remove Zones code - FFE
> >>>
> >>> On 02/15/2012 09:13 AM, Gabe Westmaas wrote:
> >>> > I think this thing we call zones is fundamentally different from
> >>> > an
> >>> Availability Zone or a Host Aggregate. An Availability Zone is
> >>> about redundancy, a Host Aggregate is about capabilities, and a Zone
> >>> is about infrastructure performance.
> >>>
> >>> That is an awesome way of describing the differences.
> >>>
> >>> >I could easily imagine an Availability Zone larger than a Zone,
> >>>and vice versa, thus I want to be cautious about talking about the
> >>>relationships between them.
> >>>
> >>> Very true.
> >>
> >>I would disagree with this, maybe if you could elaborate a bit more...
> >>
> >>To me an availability zone is a partition of the infrastructure that
> >>can fail as a whole. I increase the reliability of my cloud app by
> >>deploying across multiple availability zones. To this aim, I would
> >>keep an availability zone as small as possible. A zone is for load
> >>balancing on a large (geographical) scale. I can scale my cloud app
> >>horizontally by deploying it in multiple zones.
> >>
> >>This way of arranging a cloud app would imply the following options:
> >>
> >>a) zones contains availability zones
> >>b) zones and availability zones are arranged in a grid
> >>
> >>but to me a) is way easier to understand.
> >
> > I think it all depends on scale. Some very large nova deployments may
> > have an availability zone at the datacenter level, but for
> > infrastructure performance reasons, need to split that up into
> > multiple zones. A datacenter could be considered an availability zone
> > depending on your application - you want to be redundant even if the
> datacenter goes down.
> >
> > Much smaller deployments may consider a single switch to the bound on
> > an availability zone, and probably don't need to even consider what we
> > call zones until they get to several of those switches.
> >
> > I think both these approaches are valid, and speaks to the fact that
> > there isn't really a relationship between the two concepts. It may
> > mean that we need more options when defining availability zones, but
> > that's for another thread!
> >
> > Gabe
> >
> >>
> >>>
> >>> >And I think host aggregates are way too powerful an idea to keep
> >>>inside either of those boxes as well.
> >>>
> >>> Perhaps, yes.
> >>>
> >>> > In the new implementation we don't have entire openstack
> >>> > deployments
> >>>- we
> >>> have parts of an openstack deployment. Hypervisors, DB, and the
> >>>queuing service are all that are the new Zones. Words that make the
> >>>most sense to me are words that talk about that split rather than
> >>>words that talk about location or aggregation.
> >>>
> >>> Eventually, though, even the hypervisor wouldn't be unique in a
> >>>Zone, right?
> >>> HostAggregates would take over the role of exposing virtualization
> >>>capacity and abilities... so really, a Zone is just the partition of
> >>>DB and MQ that services a segment of HostAggregates?
> >>>
> >>> > Slice, section, segment, sector, division, partition - something
> >>>along those
> >>> lines.
> >>>
> >>> Slice is overloaded from Slicehost...
> >>>
> >>> Partition is fairly overloaded from filesystem and database
> >>>terminology...
> >>>
> >>> Segment has network connotations...
> >>>
> >>> Sector has disk/drive connotations...
> >>>
> >>> Perhaps division is the only one left out of the above that seems to
> >>>fit the bill? :)
> >>>
> >>> -jay
> >>>
> >>> > Gabe
> >>> >
> >>> > -----Original Message-----
> >>> > From:
> >>> > openstack-bounces+gabe.westmaas=rackspace.com@xxxxxxxxxxxxxxxxxxx
> >>> > [mailto:openstack-bounces+gabe.westmaas=rackspace.com@lists.launchpad.
> >>> > net] On Behalf Of Armando Migliaccio
> >>> > Sent: Wednesday, February 15, 2012 6:36 AM
> >>> > To: Martin Paulo; Jay Pipes
> >>> > Cc: openstack@xxxxxxxxxxxxxxxxxxx
> >>> > Subject: Re: [Openstack] Remove Zones code - FFE
> >>> >
> >>> > -1 for ServerGroup because in the OSAPI terminology Server is a
> >>> > guest
> >>> instance rather than a physical host.
> >>> >
> >>> > I assume that the relationship between zone and availability zone
> >>>will still
> >>> exist (and I remind you that host-aggregates have been coming along
> >>>to). So you have:
> >>> >
> >>> > ??<--> Availability Zones<--> Host Aggregates
> >>> >
> >>> > How about ?? == Deployment [Slice | Area | or Section]
> >>> >
> >>> > I know that Region may not be liked by some people, but that is
> >>> > good
> >>>too.
> >>> >
> >>> > Armando
> >>> >
> >>> >> -----Original Message-----
> >>> >> From:
> >>> >> openstack-bounces+armando.migliaccio=eu.citrix.com@lists.launchpa
> >>> >> openstack-bounces+d.ne
> >>> >> openstack-bounces+t
> >>> >> [mailto:openstack-
> >>> >> bounces+armando.migliaccio=eu.citrix.com@xxxxxxxxxxxxxxxxxxx] On
> >>> >> bounces+Behalf Of
> >>> >> Martin Paulo
> >>> >> Sent: 14 February 2012 23:34
> >>> >> To: Jay Pipes
> >>> >> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> >>> >> Subject: Re: [Openstack] Remove Zones code - FFE
> >>> >>
> >>> >> ServerGroup gets my vote at the moment: it's a term that has an
> >>> >> overloaded meaning (as far as I know)
> >>> >>
> >>> >> Martin
> >>> >>
> >>> >> On 15 February 2012 06:25, Jay Pipes<jaypipes@xxxxxxxxx> wrote:
> >>> >>> -1 on shard b/c of database terminology. -1 on cluster because
> >>> >>> of HPC and database terminology.
> >>> >>>
> >>> >>> Zone was originally used because it is general -- referring to
> >>> >>> merely a collection of hosts or other zones and not having a
> >>> >>> geographic connotation like Region does.
> >>> >>>
> >>> >>> Other possibilities:
> >>> >>>
> >>> >>> * Container (not recommended, as it is overloaded with Solaris
> >>> >>> or Linux container virtualization)
> >>> >>> * ServerGroup
> >>> >>> * HostGroup
> >>> >>> * Group
> >>> >>> * Collection
> >>> >>>
> >>> >>> If Zone isn't used, I suppose I would prefer ServerGroup
> >>> >>>
> >>> >>> -jay
> >>> >>>
> >>> >>>
> >>> >>> On 02/13/2012 08:45 PM, Yun Mao wrote:
> >>> >>>>
> >>> >>>> agreed..
> >>> >>>>
> >>> >>>> -1 on shard, +1 on cluster
> >>> >>>>
> >>> >>>> Yun
> >>> >>>>
> >>> >>>> On Mon, Feb 13, 2012 at 7:59 PM, Martin
> >>> >>>> Paulo<martin.paulo@xxxxxxxxx>
> >>> >>>> wrote:
> >>> >>>>>
> >>> >>>>> Please not 'shards'
> >>> >>>>> Sharding as a concept is so intertwined with databases IMHO
> >>> >>>>> that it will serve to confuse even more. Why not 'cluster'?
> >>> >>>>>
> >>> >>>>> Martin
> >>> >>>>>
> >>> >>>>> On 13 February 2012 09:50, Chris
> >>> >>>>> Behrens<cbehrens@xxxxxxxxxxxx>
> >>> wrote:
> >>> >>>>>>
> >>> >>>>>> Sorry, I'm late. Really getting down to the wire here. :)
> >>> >>>>>>
> >>> >>>>>> I've thrown up a version here:
> >>> >>>>>> https://review.openstack.org/#change,4062
> >>> >>>>>>
> >>> >>>>>> I've not functionally tested it yet, but there's really good test
> >>> >>>>>> coverage for the zones service itself. I also have added a
> >>> >>>>>> test_compute_zones which tests that all of the compute tests
> >>> >>>>>> pass while using the new ComputeZonesAPI class.
> >>> >>>>>>
> >>> >>>>>> There's a couple bugs I note in the review and then I think
> >>> >>>>>> I'm missing pushing some instance updates to the top in libvirt
> code.
> >>> >>>>>> And missing an update for instance deletes in the compute
> >>>manager.
> >>> >>>>>> Going to hit those up today and finish this off.
> >>> >>>>>>
> >>> >>>>>> One other comment: It's been suggested we not call this
> >>> >>>>>> stuff
> >>>'Zones'
> >>> >>>>>> anymore. It gets confused with availability zones and so forth.
> >>> >>>>>> Since this is really a way to shard nova, it has been
> >>> >>>>>> suggested to call
> >>> >> this 'Shards'.
> >>> >>>>>> :) Not sure I dig that name completely, although it makes
> >>>sense.
> >>> >>>>>> Thoughts?
> >>> >>>>>>
> >>> >>>>>> - Chris
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote:
> >>> >>>>>>
> >>> >>>>>>> Awesome Chrisssss !!!
> >>> >>>>>>>
> >>> >>>>>>> Lean
> >>> >>>>>>>
> >>> >>>>>>> On Thu, Feb 9, 2012 at 3:26 PM, Alejandro
> >>> >>>>>>> Comisario<alejandro.comisario@xxxxxxxxxxxxxxxx> wrote:
> >>> >>>>>>> Niceee !!
> >>> >>>>>>>
> >>> >>>>>>> Alejandro.
> >>> >>>>>>>
> >>> >>>>>>> On 02/09/2012 02:02 PM, Chris Behrens wrote:
> >>> >>>>>>>>
> >>> >>>>>>>> I should be pushing something up by end of day... Even if
> >>> >>>>>>>> it's not granted an FFE, I'll have a need to keep my branch
> >>> >>>>>>>> updated and working, so I should at least always have a
> >>> >>>>>>>> branch pushed up to a github account somewhere until F1
> >>> >>>>>>>> opens up. So, I guess worst case... there'll be a branch
> >>> >>>>>>>> somewhere for you to play with. :)
> >>> >>>>>>>>
> >>> >>>>>>>> - Chris
> >>> >>>>>>>>
> >>> >>>>>>>>
> >>> >>>>>>>> On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote:
> >>> >>>>>>>>
> >>> >>>>>>>>
> >>> >>>>>>>>> Just raising another deployment waiting on this new Zone
> >>> >>>>>>>>> implementation - we currently have 2000 cores sitting idle
> >>> >>>>>>>>> in another datacentre that we can use "better" if this is done.
> >>> >>>>>>>>>
> >>> >>>>>>>>> How can we help? ;)
> >>> >>>>>>>>>
> >>> >>>>>>>>> Regards,
> >>> >>>>>>>>>
> >>> >>>>>>>>> Tom
> >>> >>>>>>>>>
> >>> >>>>>>>>> On 02/08/2012 07:30 PM, Ziad Sawalha wrote:
> >>> >>>>>>>>>
> >>> >>>>>>>>>> We were working on providing the necessary functionality
> >>> >>>>>>>>>> in Keystone but stopped when we heard of the alternative
> >>>solution.
> >>> >>>>>>>>>> We could resume the conversation about what is needed on
> >>> >>>>>>>>>> the Keystone side and implement if needed.
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> Z
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> From: Sandy Walsh<
> >>> >>>>>>>>>> sandy.walsh@xxxxxxxxxxxxx
> >>> >>>>>>>>>> <mailto:sandy.walsh@xxxxxxxxxxxxx>
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>> Date: Thu, 2 Feb 2012 01:49:58 +0000
> >>> >>>>>>>>>> To: Joshua McKenty<
> >>> >>>>>>>>>> joshua@xxxxxxxxxxxxxxx
> >>> >>>>>>>>>> <mailto:joshua@xxxxxxxxxxxxxxx>
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>> , Vishvananda Ishaya
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> <
> >>> >>>>>>>>>> vishvananda@xxxxxxxxx<mailto:vishvananda@xxxxxxxxx>
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>> Cc: "
> >>> >>>>>>>>>> openstack@xxxxxxxxxxxxxxxxxxx
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> <mailto:openstack@xxxxxxxxxxxxxxxxxxx>"<openstack@lists.l
> >>> >>>>>>>>>> aunc hp ad.net<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>> Subject: Re: [Openstack] Remove Zones code - FFE
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> Understood, timing is everything. I'll let Chris talk
> >>> >>>>>>>>>> about expected timing for the replacement. From a
> >>> >>>>>>>>>> deployers side, nothing would really change, just some
> >>> >>>>>>>>>> configuration options ... but a replacement should be
> available.
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> I'm sure we could get it working pretty easily. The
> >>> >>>>>>>>>> Keystone integration was the biggest pita.
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> I can keep this branch fresh with trunk for when we're
> >>> >>>>>>>>>> ready to pull the trigger.
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> -S
> >>> >>>>>>>>>>
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> ---------------------------------------------------------
> >>> >>>>>>>>>> ----
> >>> >>>>>>>>>> --
> >>> >>>>>>>>>> ---------
> >>> >>>>>>>>>> *From:* Joshua McKenty [
> >>> >>>>>>>>>> joshua@xxxxxxxxxxxxxxx
> >>> >>>>>>>>>> <mailto:joshua@xxxxxxxxxxxxxxx> ]
> >>> >>>>>>>>>> *Sent:* Wednesday, February 01, 2012 4:45 PM
> >>> >>>>>>>>>> *To:* Vishvananda Ishaya
> >>> >>>>>>>>>> *Cc:* Sandy Walsh;
> >>> >>>>>>>>>> openstack@xxxxxxxxxxxxxxxxxxx
> >>> >>>>>>>>>> <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> *Subject:* Re: [Openstack] Remove Zones code - FFE
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> +1 to Vish's points. I know there are some folks coming
> >>> >>>>>>>>>> +online in
> >>> >>>>>>>>>> the
> >>> >>>>>>>>>> Folsom timeline that can help out with the new stuff, but
> >>> >>>>>>>>>> this feels a bit like going backwards.
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> --
> >>> >>>>>>>>>> Joshua McKenty, CEO
> >>> >>>>>>>>>> Piston Cloud Computing, Inc.
> >>> >>>>>>>>>> w: (650) 24-CLOUD
> >>> >>>>>>>>>> m: (650) 283-6846
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> http://www.pistoncloud.com
> >>> >>>>>>>>>>
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> "Oh, Westley, we'll never survive!"
> >>> >>>>>>>>>> "Nonsense. You're only saying that because no one ever has."
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda
> >>> >>>>>>>>>> Ishaya
> >>> >>>>>>>>>> wrote:
> >>> >>>>>>>>>>
> >>> >>>>>>>>>>
> >>> >>>>>>>>>>> I am all for pulling this out, but I'm a bit concerned
> >>> >>>>>>>>>>> with the fact that we have nothing to replace it with.
> >>> >>>>>>>>>>> There are some groups still trying to use it.
> >>> >>>>>>>>>>> MercadoLibre is trying to use it for example. I know you
> >>> >>>>>>>>>>> guys are trying to replace this with something better,
> >>> >>>>>>>>>>> but it would be nice not to break people for 7+ months
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>> So I guess I have some questions:
> >>> >>>>>>>>>>> 1.a) is the current implementation completely broken?
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>> 1.b) if yes, is it fixable
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>> 2) If we do remove this, what can we tell people that
> >>> >>>>>>>>>>> need something like zones between now and the Folsom release?
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>> Vish
> >>> >>>>>>>>>>> On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote:
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>>> As part of the new (and optional) Zones code coming
> >>> >>>>>>>>>>>> down the pipe, part of this is to remove the old Zones
> >>>implementation.
> >>> >>>>>>>>>>>>
> >>> >>>>>>>>>>>> More info in the merge prop:
> >>> >>>>>>>>>>>>
> >>> >>>>>>>>>>>> https://review.openstack.org/#change,3629
> >>> >>>>>>>>>>>>
> >>> >>>>>>>>>>>>
> >>> >>>>>>>>>>>> So, can I? can I? Huh?
> >>> >>>>>>>>>>>> _______________________________________________
> >>> >>>>>>>>>>>> Mailing list:
> >>> >>>>>>>>>>>> https://launchpad.net/~openstack
> >>> >>>>>>>>>>>>
> >>> >>>>>>>>>>>> Post to :
> >>> >>>>>>>>>>>> openstack@xxxxxxxxxxxxxxxxxxx
> >>> >>>>>>>>>>>> <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
> >>> >>>>>>>>>>>>
> >>> >>>>>>>>>>>> Unsubscribe :
> >>> >>>>>>>>>>>> https://launchpad.net/~openstack
> >>> >>>>>>>>>>>>
> >>> >>>>>>>>>>>> More help :
> >>> >>>>>>>>>>>> https://help.launchpad.net/ListHelp
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>> _______________________________________________
> >>> >>>>>>>>>>> Mailing list:
> >>> >>>>>>>>>>> https://launchpad.net/~openstack
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>> Post to :
> >>> >>>>>>>>>>> openstack@xxxxxxxxxxxxxxxxxxx
> >>> >>>>>>>>>>> <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>> Unsubscribe :
> >>> >>>>>>>>>>> https://launchpad.net/~openstack
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>> More help :
> >>> >>>>>>>>>>> https://help.launchpad.net/ListHelp
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> _______________________________________________ Mailing list:
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> https://launchpad.net/~openstack Post to :
> >>> >>>>>>>>>> openstack@xxxxxxxxxxxxxxxxxxx
> >>> >>>>>>>>>> <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
> >>> >>>>>>>>>> Unsubscribe :
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> https://launchpad.net/~openstack
> >>> >>>>>>>>>> More help :
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> https://help.launchpad.net/ListHelp
> >>> >>>>>>>>>>
> >>> >>>>>>>>>>
> >>> >>>>>>>>>>
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> _______________________________________________
> >>> >>>>>>>>>> Mailing list:
> >>> >>>>>>>>>> https://launchpad.net/~openstack
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> Post to :
> >>> >>>>>>>>>> openstack@xxxxxxxxxxxxxxxxxxx
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> Unsubscribe :
> >>> >>>>>>>>>> https://launchpad.net/~openstack
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> More help :
> >>> >>>>>>>>>> https://help.launchpad.net/ListHelp
> >>> >>>>>>>>>
> >>> >>>>>>>>> _______________________________________________
> >>> >>>>>>>>> Mailing list:
> >>> >>>>>>>>> https://launchpad.net/~openstack
> >>> >>>>>>>>>
> >>> >>>>>>>>> Post to :
> >>> >>>>>>>>> openstack@xxxxxxxxxxxxxxxxxxx
> >>> >>>>>>>>>
> >>> >>>>>>>>> Unsubscribe :
> >>> >>>>>>>>> https://launchpad.net/~openstack
> >>> >>>>>>>>>
> >>> >>>>>>>>> More help :
> >>> >>>>>>>>> https://help.launchpad.net/ListHelp
> >>> >>>>>>>>
> >>> >>>>>>>> _______________________________________________
> >>> >>>>>>>> Mailing list:
> >>> >>>>>>>> https://launchpad.net/~openstack
> >>> >>>>>>>>
> >>> >>>>>>>> Post to :
> >>> >>>>>>>> openstack@xxxxxxxxxxxxxxxxxxx
> >>> >>>>>>>>
> >>> >>>>>>>> Unsubscribe :
> >>> >>>>>>>> https://launchpad.net/~openstack
> >>> >>>>>>>>
> >>> >>>>>>>> More help :
> >>> >>>>>>>> https://help.launchpad.net/ListHelp
> >>> >>>>>>>
> >>> >>>>>>>
> >>> >>>>>>> _______________________________________________
> >>> >>>>>>> Mailing list: https://launchpad.net/~openstack Post to :
> >>> >>>>>>> openstack@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> >>> >>>>>>> https://launchpad.net/~openstack More help :
> >>> >>>>>>> https://help.launchpad.net/ListHelp
> >>> >>>>>>>
> >>> >>>>>>>
> >>> >>>>>>> _______________________________________________
> >>> >>>>>>> Mailing list: https://launchpad.net/~openstack Post to :
> >>> >>>>>>> openstack@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> >>> >>>>>>> https://launchpad.net/~openstack More help :
> >>> >>>>>>> https://help.launchpad.net/ListHelp
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> _______________________________________________
> >>> >>>>>> Mailing list: https://launchpad.net/~openstack Post to :
> >>> >>>>>> openstack@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> >>> >>>>>> https://launchpad.net/~openstack More help :
> >>> >>>>>> https://help.launchpad.net/ListHelp
> >>> >>>>>
> >>> >>>>>
> >>> >>>>>
> >>> >>>>>
> >>> >>>>> --
> >>> >>>>> ==============================================================
> >>> >>>>> ====
> >>> >>>>>
> >>> >>>>> Martin Paulo, BSc.
> >>> >>>>> Software Developer
> >>> >>>>>
> >>> >>>>> Tel : +61-3-9434 2508 (Home) Tel : 04 205 20339
> >>> >>>>> (Mobile)
> >>> >>>>> Site: http://www.thepaulofamily.net
> >>> >>>>>
> >>> >>>>> "Nobody goes there any more. It's too crowded" - Yogi Berra.
> >>> >>>>>
> >>> >>>>> _______________________________________________
> >>> >>>>> Mailing list: https://launchpad.net/~openstack Post to :
> >>> >>>>> openstack@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> >>> >>>>> https://launchpad.net/~openstack More help :
> >>> >>>>> https://help.launchpad.net/ListHelp
> >>> >>>>
> >>> >>>>
> >>> >>>> _______________________________________________
> >>> >>>> Mailing list: https://launchpad.net/~openstack Post to :
> >>> >>>> openstack@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> >>> >>>> https://launchpad.net/~openstack More help :
> >>> >>>> https://help.launchpad.net/ListHelp
> >>> >>>
> >>> >>>
> >>> >>> _______________________________________________
> >>> >>> Mailing list: https://launchpad.net/~openstack Post to :
> >>> >>> openstack@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> >>> >>> https://launchpad.net/~openstack More help :
> >>> >>> https://help.launchpad.net/ListHelp
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> =================================================================
> >>> >> =
> >>> >>
> >>> >> Martin Paulo, BSc.
> >>> >> Software Developer
> >>> >>
> >>> >> Tel : +61-3-9434 2508 (Home)
> >>> >> Tel : 04 205 20339 (Mobile)
> >>> >> Site: http://www.thepaulofamily.net
> >>> >>
> >>> >> "Nobody goes there any more. It's too crowded" - Yogi Berra.
> >>> >>
> >>> >> _______________________________________________
> >>> >> Mailing list: https://launchpad.net/~openstack
> >>> >> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> >>> >> Unsubscribe : https://launchpad.net/~openstack
> >>> >> More help : https://help.launchpad.net/ListHelp
> >>> >
> >>> > _______________________________________________
> >>> > Mailing list: https://launchpad.net/~openstack
> >>> > Post to : openstack@xxxxxxxxxxxxxxxxxxx
> >>> > Unsubscribe : https://launchpad.net/~openstack
> >>> > More help : https://help.launchpad.net/ListHelp
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
> >
>
Follow ups
References
