On Sat, 2012-02-18 at 19:36 +, Ed Leafe wrote:
> I still prefer 'cell'. The parallel to single celled / multi-cellular
> life forms makes sense, and there is really no overloading of the word
> in the world of computers.
I'll point out the concept of AFS cells. That said, +1 for "cell"…
--
K
On Sun, Feb 19, 2012 at 8:57 PM, Ed Leafe wrote:
> On Feb 19, 2012, at 12:53 PM, Mark Washenberger wrote:
>
> > For this reason, whatever name we choose I would hope we prefix it with
> "compute-" (i.e. compute-zone or compute-cell) so that we aren't letting
> language trick us out of some of our
Vishvananda Ishaya wrote:
> +1 to cell.
+1 to cell. Short, clean and relatively not overloaded. Someone has to
decide, and that someone is actually Vish :)
[ and I didn't see any good opposition to "cell" yet among all the
bikeshedding ]
--
Thierry Carrez (ttx)
Release Manager, OpenStack
_
On Feb 19, 2012, at 12:53 PM, Mark Washenberger wrote:
> For this reason, whatever name we choose I would hope we prefix it with
> "compute-" (i.e. compute-zone or compute-cell) so that we aren't letting
> language trick us out of some of our better implementation options, such as
> allowing de
overloaded...
>
> Tim
>
>> -Original Message-
>> From: openstack-bounces+tim.bell=cern...@lists.launchpad.net
>> [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf
>> Of Mark Washenberger
>> Sent: 19 February 2012 19:54
>> To: ope
@lists.launchpad.net
Subject: Re: [Openstack] Remove Zones code - FFE
+1 to cell.
On Feb 18, 2012 9:41 AM, "Dean Troyer"
mailto:dtro...@gmail.com>> wrote:
> On Feb 17, 2012, at 9:06 AM, Ed Leafe wrote:
>> The term "zone" was adopted at a time when we weren't
++ to you Mark. Excellent suggestion on compute-cell.
-jay
On 02/19/2012 01:53 PM, Mark Washenberger wrote:
Remember that for many deployments, the entire system will be a single
"zone", so
whatever term is used should make sense in a singular sense. That rules out
names
such as 'slic
ad.net
> [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf
> Of Mark Washenberger
> Sent: 19 February 2012 19:54
> To: openstack@lists.launchpad.net
> Subject: Re: [Openstack] Remove Zones code - FFE
>
> > Remember that for many deployments, the entire sys
> Remember that for many deployments, the entire system will be a single
> "zone", so
> whatever term is used should make sense in a singular sense. That rules out
> names
> such as 'slice' or 'fragment'.
I think this is a slightly outdated concept of zones.
The key to scalability in nova
On 02/18/2012 03:22 PM, Chris Behrens wrote:
On Feb 18, 2012, at 11:36 AM, Ed Leafe wrote:
I still prefer 'cell'. The parallel to single celled / multi-cellular
life forms makes sense, and there is really no overloading of the word in the
world of computers.
I like 'cell' too. It m
+1 for cell
Sent from my iPhone
On Feb 18, 2012, at 14:32, "Vishvananda Ishaya"
mailto:vishvana...@gmail.com>> wrote:
+1 to cell.
On Feb 18, 2012 9:41 AM, "Dean Troyer"
mailto:dtro...@gmail.com>> wrote:
> On Feb 17, 2012, at 9:06 AM, Ed Leafe wrote:
>> The term "zone" was adopted at a
Clump?
-B
On Feb 18, 2012, at 12:24 PM, Vishvananda Ishaya wrote:
> +1 to cell.
>
> On Feb 18, 2012 9:41 AM, "Dean Troyer" wrote:
> > On Feb 17, 2012, at 9:06 AM, Ed Leafe wrote:
> >> The term "zone" was adopted at a time when we weren't really
> >> focusing on mimicking the AWS Availabi
+1 to cell.
On Feb 18, 2012 9:41 AM, "Dean Troyer" wrote:
> > On Feb 17, 2012, at 9:06 AM, Ed Leafe wrote:
> >> The term "zone" was adopted at a time when we weren't really
> >> focusing on mimicking the AWS Availability Zone concept, and in
> >> hindsight, it was a poor choice. So we shoul
On Feb 18, 2012, at 11:36 AM, Ed Leafe wrote:
> I still prefer 'cell'. The parallel to single celled / multi-cellular
> life forms makes sense, and there is really no overloading of the word in the
> world of computers.
I like 'cell' too. It makes sense.
But "'cell' reminds me too much
On Feb 18, 2012, at 1:08 PM, Nathanael Burton wrote:
> Sectors remind me too much of disks.
Agreed.
> How about? Layers, Slices, Fragments, Knots...
Remember that for many deployments, the entire system will be a single
"zone", so whatever term is used should make sense in a si
> On Feb 17, 2012, at 9:06 AM, Ed Leafe wrote:
>> The term "zone" was adopted at a time when we weren't really
>> focusing on mimicking the AWS Availability Zone concept, and in
>> hindsight, it was a poor choice. So we should learn from that mistake
>> and make sure we don't choose a replace
On Feb 18, 2012, at 11:08 AM, Nathanael Burton wrote:
> Sectors remind me too much of disks.
Right.. I mentioned it because I would think it'd be rather difficult to
confuse 'Nova sectors' with sectors on a disk.
>
> How about? Layers, Slices, Fragments, Knots...
Of those, I'd probably pref
Sectors remind me too much of disks.
How about? Layers, Slices, Fragments, Knots...
On Feb 18, 2012 1:57 PM, "Chris Behrens" wrote:
> Sector?
>
>
> On Feb 17, 2012, at 9:06 AM, Ed Leafe wrote:
>
> > On Feb 15, 2012, at 10:07 AM, Armando Migliaccio wrote:
> >
> >> I think you touched the crucial
Sector?
On Feb 17, 2012, at 9:06 AM, Ed Leafe wrote:
> On Feb 15, 2012, at 10:07 AM, Armando Migliaccio wrote:
>
>> 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
On Feb 15, 2012, at 10:07 AM, Armando Migliaccio wrote:
> 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
> ot
See comments inline.
> -Original Message-
> From: Mark Washenberger [mailto:mark.washenber...@rackspace.com]
> Sent: 15 February 2012 15:51
> To: Gabe Westmaas
> Cc: Armando Migliaccio; Jay Pipes; openstack@lists.launchpad.net
> Subject: Re: [Openstack] Remove Zones co
size got to do with relationship?
>>
>>> -Original Message-
>>> From: Jay Pipes [mailto:jaypi...@gmail.com]
>>> Sent: 15 February 2012 14:36
>>> To: Gabe Westmaas
>>> Cc: Armando Migliaccio; Martin Paulo; openstack@lists.launchpad.net
>&g
c: Armando Migliaccio; Martin Paulo; openstack@lists.launchpad.net
>> 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
t
> > [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@lists.launchpad.net
> > Subject: Re: [Openstack] Re
ts.launchpad.net] On
Behalf Of Armando Migliaccio
Sent: Wednesday, February 15, 2012 6:36 AM
To: Martin Paulo; Jay Pipes
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Remove Zones code - FFE
-1 for ServerGroup because in the OSAPI terminology Server is a guest instance
rather than a p
Paulo; Jay Pipes
Cc: openstack@lists.launchpad.net
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 r
gt; [mailto:openstack-
> bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of
> Martin Paulo
> Sent: 14 February 2012 23:34
> To: Jay Pipes
> Cc: openstack@lists.launchpad.net
> Subject: Re: [Openstack] Remove Zones code - FFE
>
> ServerGroup gets m
On Feb 14, 2012, at 6:28 PM, Kevin L. Mitchell wrote:
> On Wed, 2012-02-15 at 00:00 +, Monsyne Dragon wrote:
>>> Other possibilities:
>>>
>>> * Container (not recommended, as it is overloaded with Solaris or Linux
>>> container virtualization)
>>> * ServerGroup
>>> * HostGroup
>>> * Group
>>
On Wed, 2012-02-15 at 00:00 +, Monsyne Dragon wrote:
> On Feb 14, 2012, at 1:25 PM, Jay Pipes 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
> >
On Wed, 2012-02-15 at 00:00 +, Monsyne Dragon wrote:
> > Other possibilities:
> >
> > * Container (not recommended, as it is overloaded with Solaris or Linux
> > container virtualization)
> > * ServerGroup
> > * HostGroup
> > * Group
> > * Collection
>
> - Set
> - Cell
> - Huddle
> - Constel
is 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? ;)
>>>>>&
gt;> Z
>>>>>>>>
>>>>>>>> From: Sandy Walsh<
>>>>>>>> sandy.wa...@rackspace.com
>>>>>>>> <mailto:sandy.wa...@rackspace.com>
>>>>>>>>>
>>>>>>>&g
t;>>>>>>
>>>>>>>
>>>>>>>> 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&
dle in
>>>>>>>another datacentre that we can use "better" if this is done.
>>>>>>>
>>>>>>> How can we help? ;)
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>
--
*From:* Joshua McKenty [
jos...@pistoncloud.com
<mailto:jos...@pistoncloud.com>
]
*Sent:* Wednesday, February 01, 2012 4:45 PM
*To:* Vishvananda Ishaya
*Cc:* Sandy Walsh;
openstack@lists.launchpad.net
<mailto:openstack@lists.l
te:
>>>>>
>>>>>> 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 a
; >>>>> 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 i
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.
>>>>&
sts.launchpad.net; Chris Behrens
> Subject: Re: [Openstack] Remove Zones code - FFE
>
> 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 the
=rackspace@lists.launchpad.net] on behalf of
Chris Behrens [cbehr...@codestud.com]
Sent: Sunday, February 12, 2012 6:50 PM
To: Leandro Reox
Cc: openstack@lists.launchpad.net; Chris Behrens
Subject: Re: [Openstack] Remove Zones code - FFE
Sorry, I'm late. Really getting down to the wire
;>> conversation about what is needed on the Keystone side and implement if
>>>> needed.
>>>>
>>>> Z
>>>>
>>>> From: Sandy Walsh <
>>>> sandy.wa...@rackspace.com
>>>> <mailto:sandy.wa...@rackspace.com>
>&
gt; mailto:vishvana...@gmail.com> >
> Cc: "openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>
> "
> mailto:openstack@lists.launchpad.net>
> >
> Subject: Re: [Openstack] Remove Zones code - FFE
>
> Understood, timing is everything.
;openstack@lists.launchpad.net
<mailto:openstack@lists.launchpad.net>"mailto:openstack@lists.launchpad.net>>
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,
os...@pistoncloud.com>>, Vishvananda Ishaya
>> mailto:vishvana...@gmail.com>>
>> Cc: "openstack@lists.launchpad.net
>> <mailto:openstack@lists.launchpad.net>" > <mailto:openstack@lists.launchpad.net>>
>> Subject: Re: [Openstack] Remove Zo
+
To: Joshua McKenty mailto:jos...@pistoncloud.com>>, Vishvananda Ishaya
mailto:vishvana...@gmail.com>>
Cc: "openstack@lists.launchpad.net
<mailto:openstack@lists.launchpad.net>" mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] Remove Zones code - FFE
Thu, 2 Feb 2012 01:49:58 +
To: Joshua McKenty mailto:jos...@pistoncloud.com>>,
Vishvananda Ishaya mailto:vishvana...@gmail.com>>
Cc: "openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>"
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openst
Thierry et. al.
Responses inline.
On 02/02/2012 06:03 AM, Thierry Carrez wrote:
Chris Behrens wrote:
Well, I can actually say with confidence that the replacement would be stable
by essex release. In fact, I expect the first commit to be a completely
working solution that solves a number of
Chris Behrens wrote:
>
> Well, I can actually say with confidence that the replacement would be stable
> by essex release. In fact, I expect the first commit to be a completely
> working solution that solves a number of problems with the original
> implementation. I don't think there's any is
Well, I can actually say with confidence that the replacement would be stable
by essex release. In fact, I expect the first commit to be a completely
working solution that solves a number of problems with the original
implementation. I don't think there's any issue getting something committed
I talked with chris a bit offline, and I'm a little concerned that we will be
pushing too hard to try and get this into a working state by Essex. I think
even if we to slam it in we will be faced with bugs that will make the essex
version potentially as broken as the current zones code is. It i
alsh; openstack@lists.launchpad.net
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.
Sounds pretty good Vish.
Since we are mostly deployers, and the ones who are gonna try the new
code from day zero, whats good for Sandy, its good for us.
Alejandro.
On 02/01/2012 06:57 PM, Vishvananda Ishaya wrote:
Thanks for the feedback. It is good to get input from one of the
largest open
Thanks for the feedback. It is good to get input from one of the largest
openstack installs! So it sounds like the existing code is pretty broken. Based
on this feedback I would like to propose the following:
1) cut out zones code
(meaning merge the existing branch)
2) grant an FFe for the ne
Hi guys.
Its true that we are trying to make multizones work, actually we did,
but we get into an instance were listing all vms from the parent zone (
where is has to go thru all the child zones ) is buggy ( if not
impossible by now ).
So, if there is a new zone architecture that actually works
+1
On Feb 1, 2012 4:13 PM, "Vishvananda Ishaya" wrote:
> I would prefer that if it can be done super-super fast. :)
>
> Vish
>
> On Feb 1, 2012, at 1:04 PM, Chris Behrens wrote:
>
> > I wonder if we can use some of the architecture of the new code and move
> the current implementation to that mod
I would prefer that if it can be done super-super fast. :)
Vish
On Feb 1, 2012, at 1:04 PM, Chris Behrens wrote:
> I wonder if we can use some of the architecture of the new code and move the
> current implementation to that model. It'd preserve the existing
> functionality, set us up for the
I wonder if we can use some of the architecture of the new code and move the
current implementation to that model. It'd preserve the existing
functionality, set us up for the new implementation, and fits in with 'cleanup'
for E4, etc.
On Feb 1, 2012, at 2: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
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://launchp
59 matches
Mail list logo
