Lloyd Dewolf wrote:
In my fantasies for the Grizzly release it would start something like:
A. Grizzly Summit
B. From the summit the Tech Committee PTL have community consensus
on the overarching goal for the release and the projects' goals.
Articulated online in user friendly manner.
On Mon, Jul 16, 2012 at 9:08 AM, Thierry Carrez thie...@openstack.org wrote:
Using the user committee setup, you don't really need to take
authority away from the PTL. You increase the influence of the users
on technical decisions. You just provide a clear and official mechanism
to represent
Jay Pipes on 16 July 2012 18:31 wrote:
On 07/16/2012 09:55 AM, David Kranz wrote:
Sure, although in this *particular* case the Cinder project is a
bit-for-bit copy of nova-volumes. In fact, the only thing really of
cause for concern are:
* Providing a migration script for the database
@lists.launchpad.net
Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Jay Pipes on 16 July 2012 18:31 wrote:
On 07/16/2012 09:55 AM, David Kranz wrote:
Sure, although in this *particular* case the Cinder project is a
bit-for-bit copy of nova-volumes. In fact, the only thing
] On Behalf Of
Thomas, Duncan
Sent: 17 July 2012 10:47
To: Jay Pipes; openstack@lists.launchpad.net
Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Jay Pipes on 16 July 2012 18:31 wrote:
On 07/16/2012 09:55 AM, David Kranz wrote:
Sure, although in this *particular
On 07/17/2012 05:47 AM, Thomas, Duncan wrote:
Jay Pipes on 16 July 2012 18:31 wrote:
On 07/16/2012 09:55 AM, David Kranz wrote:
Sure, although in this *particular* case the Cinder project is a
bit-for-bit copy of nova-volumes. In fact, the only thing really of
cause for concern are:
On 07/12/2012 05:40 PM, Vishvananda Ishaya wrote:
Excellent points. Let me make the following proposal:
1) Leave the code in nova-volume for now.
2) Document and test a clear migration path to cinder.
3) Take the working example upgrade to the operators list and ask them for
opinions.
4)
An excellent idea. I believe that if the below message had been sent in
April, the tenor of the discussion would have been much different. I
think a main source of angst around this was that there was no mention
at the Folsom summit of nova-volume being simply removed immediately,
except
I definitely agree with everything said here.
On Jul 16, 2012, at 8:55 AM, David Kranz wrote:
An excellent idea. I believe that if the below message had been sent in
April, the tenor of the discussion would have been much different. I think a
main source of angst around this was that there
David Kranz wrote:
Going forward, and this may be controversial, I think these kinds of
issues would be best addressed by following these measures:
1. Require each blueprint that involves an API change or significant
operational incompatibility to include a significant justification of
On 07/16/2012 09:55 AM, David Kranz wrote:
An excellent idea. I believe that if the below message had been sent in
April, the tenor of the discussion would have been much different. I
think a main source of angst around this was that there was no mention
at the Folsom summit of nova-volume
-bounces+sriram=sriramhere@lists.launchpad.net] On
Behalf Of Thierry Carrez
Sent: Monday, July 16, 2012 9:08 AM
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
David Kranz wrote:
Going forward, and this may be controversial, I think
Speaking of the User Committee as proposed in the draft governance docs, I
can
certainly see value in having the committee chair chosen by the board.
However, as
currently proposed, there is a convoluted process for appointing the
representatives
of the committee. Frankly, if you want to give a
Christopher B Ferris wrote:
Speaking of the User Committee as proposed in the draft governance docs,
I can
certainly see value in having the committee chair chosen by the board.
However, as
currently proposed, there is a convoluted process for appointing the
representatives
of the
Hi,
On Sat, Jul 14, 2012 at 1:51 PM, Andrew Clay Shafer
a...@parvuscaptus.comwrote:
I disagree with your last point, it is true if we look only into this
particular problem, but if you look into the whole ecosystem you'll realize
that the code removal of nova-volumes is not the only
Hi,
On Fri, Jul 13, 2012 at 9:20 PM, Andrew Clay Shafer
a...@parvuscaptus.comwrote:
[...]
In this particular case, I chose option 1 under the following assumptions
(which may be wrong):
- the api for the end user would not change
- the code for the service is essentially the same,
I disagree with your last point, it is true if we look only into this
particular problem, but if you look into the whole ecosystem you'll realize
that the code removal of nova-volumes is not the only change from essex to
folsom.. if we had deprecated all other changes, this particular one would
Apologies if this has already been proposed, but how about an option 3
(perhaps more accurately option 2.5):
We already have a process for maintaining code in one project and
occasionally copying it to another project. Namely, code is maintained
in openstack-common and then -- at appropriate
George Reese wrote:
How many years has it been? [...]
The answer to those questions is:
- 3
It's been 2 years, actually. Feels like 3 years, I know. We are still
maturing, obviously. But seeing the discussions we had at the last
design summit, I think that we are improving. We are now
Matt Joyce wrote:
To certain extent I agree with george's sentiment.
Recent example... we're changing tenants to projects in the keystone api.
Yes we maintain v2 api compatibility but there will be a cost to users
in the confusion of decisions like this. George is right to be calling
+1 to Vish's proposal
I'd go a step further and suggest adopt this model for such changes going
forward.
Chris
Sent from my iPad
On Jul 12, 2012, at 5:40 PM, Vishvananda Ishaya vishvana...@gmail.com
wrote:
On Jul 12, 2012, at 2:36 PM, David Mortman wrote:
On Thu, Jul 12, 2012 at 3:38
This is exactly the sort of interaction we need between the two perspectives of
the OpenStack community.
Thanks
Chris
Sent from my iPad
On Jul 12, 2012, at 11:20 PM, Joe Topjian joe.topj...@cybera.ca wrote:
Hello,
I'm not an OpenStack developer nor any type of developer. I am, however,
Sent from my iPad
On Jul 13, 2012, at 12:41 AM, Blake Yeager blake.yea...@gmail.com
wrote:
snip
I am excited to see such passion from the community but we need to make
sure that passion is directed in a constructive manner.
+1
Chris___
Mailing
-bounces+tim.reddin=hp@lists.launchpad.net] On Behalf Of
Shake Chen
Sent: 12 July 2012 01:31
To: Renuka Apte
Cc: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net)
Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
option 1.
On Thu, Jul 12, 2012
On 07/12/2012 03:54 PM, George Reese wrote:
This community needs offending.
This is your opinion and you're entitled to it but let me assure you
that *nobody* here wants to be offended by you. This community is made
of smart people that deserve respect: stop offending them, now.
Make your point
Because the community has done such a good job in the area of interoperability
and compatibility over the past few years that it thus deserves the benefit of
the doubt even though we have a thread previously showing blatant disregard for
such concerns?
No, this community has, by and large,
Disagreements and misunderstanding concerning etiquette and upgrading
Cassandra aside, this thread has three major themes: 1) the relative ease
or burden of upgrade paths 2) compatibility between versions and 3) what
OpenStack values when making decisions.
I believe the first two hinge on the
(openstack@lists.launchpad.net) (openstack@lists.launchpad.net)
Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
For me it's +1 to 1, but...
Here at Globo.com we're already deploying clouds based on openstack (not in
production yet, we have dev and lab), and it's really painful
On 07/12/2012 10:36 AM, Thomas, Duncan wrote:
We’ve got volumes in production, and while I’d be more comfortable with
option 2 for the reasons you list below, plus the fact that cinder is
fundamentally new code with totally new HA and reliability work needing
to be done (particularly for the
On Thu, Jul 12, 2012 at 9:28 AM, Jay Pipes jaypi...@gmail.com wrote:
On 07/12/2012 10:36 AM, Thomas, Duncan wrote:
We’ve got volumes in production, and while I’d be more comfortable with
option 2 for the reasons you list below, plus the fact that cinder is
fundamentally new code with totally
We currently have a large deployment that is based on nova-volume as it is
in trunk today, and just ripping it out will be quite painful. For us,
option #2 is the only suitable option.
We need a smooth migration path, and time to successfuly migrate to Cinder.
Since there is no clear migration
This community just doesn't give a rat's ass about compatibility, does it?
-George
On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote:
Hello Everyone,
Now that the PPB has decided to promote Cinder to core for the Folsom
release, we need to decide what happens to the existing Nova
We actually care a hell of a lot about compatibility. We also recognize there
are times when we have to sacrifice compatibility so we can move forward at a
reasonable pace.
If you think we are handling anything the wrong way, we would love to hear your
suggestions. If you just want to make
Well, I think overall OpenStack has done an absolute shit job of compatibility
and I had hoped (and made a huge point of this at the OpenStack conference)
Diablo - Essex would be the end of this compatibility bullshit.
But the attitudes in this thread and with respect to the whole Cinder
On 07/12/2012 12:32 PM, George Reese wrote:
This community just doesn't give a rat's ass about compatibility, does it?
a) Please don't be inappropriate on the mailing list
b) Vish sent the email below to the mailing list *precisely because* he
cares about compatibility. He wants to discuss the
This level of response is unnecessary.
That said, the perspectives which influenced the decision seemed somewhat
weighted to the development community. I could be wrong, but I did not see much
input from the operations community as to the impact.
Clearly, going forward, we want to be more
I certainly wasn't picking on Vish, but instead the entire community so eagerly
interested in option #1. You see, the OpenStack community has a perfect record
of making sure stuff like that ends up breaking everyone between upgrades.
So, if you take offense by my comments… err, well, I'm not at
You evidently have not had to live with the interoperability nightmare known as
OpenStack in the same way I have. Otherwise, you would find responses like
Brian's much more offensive.
-George
On Jul 12, 2012, at 1:48 PM, Christopher B Ferris wrote:
This level of response is unnecessary.
What exactly was so offensive about what I said? Communities like OpenStack are
built on top of people *doing* things, not *talking* about things. I'm just
asking you to contribute code or design help rather than slanderous commentary.
Brian Offensive Waldon
On Jul 12, 2012, at 11:59 AM,
So if Im not coding, I should shut up?
I think you answered your own question.
Sent from my iPhone
On Jul 12, 2012, at 14:10, Brian Waldon brian.wal...@rackspace.com wrote:
What exactly was so offensive about what I said? Communities like OpenStack
are built on top of people *doing* things,
Planning the development of the projects is valuable as well as contributing
code. If you review my last message, you'll see the words '... or design help',
which I intended to represent non-code contribution. You seem to have strong
opinions on how things should be done, but I don't see your
This ain't the first time I've had a run in with you where your response was
essentially if you don't like it, go code it.
And obviously you missed the entire constructive point in my response. It's
this:
The proposed options suck. It's too late to do anything about that as this ship
has
On Jul 12, 2012, at 11:48 AM, Christopher B Ferris wrote:
This level of response is unnecessary.
That said, the perspectives which influenced the decision seemed somewhat
weighted to the development community. I could be wrong, but I did not see
much input from the operations community
] [cinder] Nova-volume vs. Cinder in Folsom
Well, I think overall OpenStack has done an absolute shit job of compatibility
and I had hoped (and made a huge point of this at the OpenStack conference)
Diablo - Essex would be the end of this compatibility bullshit.
But the attitudes in this thread
To certain extent I agree with george's sentiment.
Recent example... we're changing tenants to projects in the keystone api.
Yes we maintain v2 api compatibility but there will be a cost to users in
the confusion of decisions like this. George is right to be calling for
openstack to grow up.
(openstack@lists.launchpad.net)
(openstack@lists.launchpad.net) openstack@lists.launchpad.net
Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Well, I think overall OpenStack has done an absolute shit job of
compatibility and I had hoped (and made a huge point
@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
You are mistaking me for caring about the answer to this question.
This ship has sailed. We are faced with two shitty choices as a result of
continued lack of concern by this community
: Thursday, July 12, 2012 10:14 AM
To: Brian Waldon brian.wal...@rackspace.com
Cc: Openstack (openstack@lists.launchpad.net)
(openstack@lists.launchpad.net) openstack@lists.launchpad.net
Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Well, I think overall OpenStack has
On Thu, Jul 12, 2012 at 1:14 PM, George Reese
george.re...@enstratus.com wrote:
So if Im not coding, I should shut up?
I think you answered your own question.
Sent from my iPhone
On Jul 12, 2012, at 14:10, Brian Waldon brian.wal...@rackspace.com wrote:
What exactly was so offensive about
+gabriel.hurley=nebula@lists.launchpad.net] On
Behalf Of George Reese
Sent: Thursday, July 12, 2012 12:15 PM
To: Brian Waldon
Cc: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net)
Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
So if Im not coding, I
George,
your opinion is best conveyed if it comes with a polite choice of words.
Please refrain from adding more of your references to excrements and
help the community make a decision.
/stef
On 07/12/2012 12:14 PM, George Reese wrote:
So if Im not coding, I should shut up?
I think you
On Thu, Jul 12, 2012 at 2:37 PM, George Reese george.re...@enstratus.comwrote:
This ain't the first time I've had a run in with you where your response
was essentially if you don't like it, go code it.
And obviously you missed the entire constructive point in my response.
It's this:
The
On 07/12/2012 12:37 PM, George Reese wrote:
It's too late to do anything about that as
this ship has sailed.
This is wrong. You and anybody that believes options #1 and #2 proposed
by Vish and John are sub-optimal still have time to make a proposal.
Please, take time to write it down.
Cheers,
On Thu, Jul 12, 2012 at 2:38 PM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
Agreed, I'm a developer, so I'm clearly biased towards what is easier for
developers. It will be a significant effort to have to maintain the
nova-volume code, so I want to be sure it is necessary. End users
On Jul 12, 2012, at 2:36 PM, David Mortman wrote:
On Thu, Jul 12, 2012 at 3:38 PM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
Two thoughts:
1) I think this is the wrong forum to poll operators on their
preferences in general
2) We don't yet even have a fully laid out set of
tl;dr: I vote for option 2 as it's the only reasonable path from a deployer's
point of view
With my deployer hat on, I think option 1 isn't really valid. It's completely
unfair to force deployers to use Cinder before they can upgrade to Folsom.
There are real deployments using nova-volumes,
@lists.launchpad.net)
Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Well, I think overall OpenStack has done an absolute shit job of
compatibility and I had hoped (and made a huge point of this at the
OpenStack conference) Diablo - Essex would be the end
On Thu, Jul 12, 2012 at 2:38 PM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
On Jul 12, 2012, at 11:48 AM, Christopher B Ferris wrote:
This level of response is unnecessary.
That said, the perspectives which influenced the decision seemed somewhat
weighted to the development community.
On Thu, Jul 12, 2012 at 2:56 PM, George Reese
george.re...@enstratus.com wrote:
I don't think Cinder should exist.
Sometimes you have to live with the technical debt because that's the best
way to preserve the investment your customers have made in your product.
Or if you're very smart, you
[launchpad is slow at delivering messages to the list. Please everybody
keep it in mind and slow down your replies too to give people the chance
to comment, too.]
On 07/12/2012 12:47 PM, Matt Joyce wrote:
Yes we maintain v2 api compatibility but there will be a cost to users
in the confusion of
On Jul 12, 2012, at 5:08 PM, John Postlethwait wrote:
So, in short, your entire purpose here is to troll everyone? Nice… : /
If you think that, you're likely part of the problem.
You obviously care. You keep responding… You have been asked numerous times
what we can do to NOT stick us
Excellent points. Let me make the following proposal:
1) Leave the code in nova-volume for now.
2) Document and test a clear migration path to cinder.
3) Take the working example upgrade to the operators list and ask them for
opinions.
4) Decide based on their feedback whether it is
On Jul 12, 2012, Christopher B Ferris wrote:
Clearly, going forward, we want to be more deliberate about changes
Funny how compatibility is always a popular going forward item.
Best -Federico
_
-- 'Problem' is a bleak word for challenge - Richard Fish
Hello,
I'm not an OpenStack developer nor any type of developer. I am, however,
heavily involved with operations for a few production OpenStack
environments. I understand the debate going on and wanted to add an
administrator's point of view.
For admins, OpenStack is not our job, but a tool we
stef...@openstack.org
Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net
07/12/2012 06:38 PM
To
openstack@lists.launchpad.net
cc
Subject
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
[launchpad is slow at delivering messages to the list. Please everybody
keep
+1 for Option 1.
On Wed, Jul 11, 2012 at 11:26 PM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
Hello Everyone,
Now that the PPB has decided to promote Cinder to core for the Folsom
release, we need to decide what happens to the existing Nova Volume
code. As far as I can see it there are
One vote for option 1.
Remove Volumes
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
+1 for option 1
On 7/11/12 8:26 AM, Vishvananda Ishaya vishvana...@gmail.com wrote:
Hello Everyone,
Now that the PPB has decided to promote Cinder to core for the Folsom
release, we need to decide what happens to the existing Nova Volume
code. As far as I can see it there are two basic
+1 for option 1
--
Mike Perez
DreamHost.com
On Wednesday, July 11, 2012 at 8:26 AM, Vishvananda Ishaya wrote:
Option 1 -- Remove Nova Volume
==
___
Mailing list: https://launchpad.net/~openstack
Post to :
I also vote for option 1, but the migration path really needs to be
solid and well documented.
-nld
On Wed, Jul 11, 2012 at 10:52 AM, Andrew Clay Shafer
a...@parvuscaptus.com wrote:
One vote for option 1.
Remove Volumes
___
Mailing list:
On Wed, 11 Jul 2012 08:26:56 -0700
Vishvananda Ishaya vishvana...@gmail.com wrote:
Hello Everyone,
Now that the PPB has decided to promote Cinder to core for the Folsom
release, we need to decide what happens to the existing Nova Volume
code. As far as I can see it there are two basic
+1 on 1
chuck
On Wed, 11 Jul 2012 08:26:56 -0700
Vishvananda Ishaya vishvana...@gmail.com wrote:
Hello Everyone,
Now that the PPB has decided to promote Cinder to core for the Folsom
release, we need to decide what happens to the existing Nova Volume
code. As far as I can see it there are
+1 for option 1. Bite the bullet now, rather than making it worse later.
-Paul
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help :
-Original Message-
From: openstack-bounces+gregory_althaus=dell@lists.launchpad.net
[mailto:openstack-bounces+gregory_althaus=dell@lists.launchpad.net] On
Behalf Of Vishvananda Ishaya
Sent: Wednesday, July 11, 2012 10:27 AM
To: Openstack (openstack@lists.launchpad.net)
Before we completely pile on option 1, can we get devstack changed to
run this way? I think the amount of pain / ease that transition is for
users and the OpenStack CI team will greatly inform this decision, and
give us some good data points on how tough this is for people to convert.
+1 for option 1
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
+1 option one.
On Wed, Jul 11, 2012 at 11:55 AM, Paul McMillan paul.mcmil...@nebula.comwrote:
+1 for option 1. Bite the bullet now, rather than making it worse later.
-Paul
__**_
Mailing list:
+1 for 1
On 11/07/12 8:26 AM, Vishvananda Ishaya vishvana...@gmail.com wrote:
Hello Everyone,
Now that the PPB has decided to promote Cinder to core for the Folsom
release, we need to decide what happens to the existing Nova Volume
code. As far as I can see it there are two basic strategies.
+1 to option 1, rip the band-aid off quickly :-)
-Doug
-Original Message-
From: openstack-bounces+gregory_althaus=dell@lists.launchpad.net
[mailto:openstack-bounces+gregory_althaus=dell.com@lists.launchpad.
net] On Behalf Of Vishvananda Ishaya
Sent: Wednesday, July 11, 2012
On 07/11/2012 09:22 AM, Narayan Desai wrote:
I also vote for option 1, but the migration path really needs to be
solid and well documented.
-nld
I feel the same. I think documented and tested migration paths are of
utmost importance here. Unlike the Keystone - Keystone Light
migration,
All,
Just wanted to note that either decision means a revision and addition
of documentation - to me, one option does not create more doc need
than the other. Removal or deprecation, both require documentation.
Anne
On Wed, Jul 11, 2012 at 11:22 AM, Narayan Desai narayan.de...@gmail.com wrote:
Vish,
How would the Nova migration from Essex to Folsom take place ? I'm wondering
how we can validate Folsom without risking an existing Essex installation
via some sort of clone/migrate operation.
What is your assessment of the risk that Cinder is less stable than Nova
volume ?
Option 1
On Wed, Jul 11, 2012 at 11:38 AM, Sean Dague sda...@linux.vnet.ibm.com wrote:
Before we completely pile on option 1, can we get devstack changed to run
this way? I think the amount of pain / ease that transition is for users and
the OpenStack CI team will greatly inform this decision, and give
For me it's +1 to 1, but...
Here at Globo.com we're already deploying clouds based on openstack (not in
production yet, we have dev and lab), and it's really painful when
openstack just forces us to change, I mean, sysadmins are not that happy,
so I think it's more polite if we warn them in
On Wed, Jul 11, 2012 at 1:49 PM, Adam Gandelman ad...@canonical.com wrote:
On 07/11/2012 09:22 AM, Narayan Desai wrote:
I also vote for option 1, but the migration path really needs to be
solid and well documented.
-nld
I feel the same. I think documented and tested migration paths are
+1
Chris
Sent from my iPad
On Jul 11, 2012, at 3:02 PM, Sean Dague sda...@linux.vnet.ibm.com
wrote:
Before we completely pile on option 1, can we get devstack changed to
run this way? I think the amount of pain / ease that transition is for
users and the OpenStack CI team will greatly
Just to be clear, I was +1 ing Sean's point that we should get sme
experience behind this before pulling the plug.
Chris
Sent from my iPad
On Jul 11, 2012, at 3:02 PM, Sean Dague sda...@linux.vnet.ibm.com
wrote:
Before we completely pile on option 1, can we get devstack changed to
run this
I'm normally very much in favor of stable APIs and slow deprecation, but in
this case I'm far more concerned about having to support two completely
independent codebases. If we pursue option 2 I think the language there needs
to be even stronger and we'd have to say that nova-volume is
@lists.launchpad.net)
Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
For me it's +1 to 1, but...
Here at Globo.com we're already deploying clouds based on openstack (not in
production yet, we have dev and lab), and it's really painful when openstack
just forces us
]
*Sent:* Wednesday, July 11, 2012 12:56 PM
*To:* Renuka Apte
*Cc:* Vishvananda Ishaya; Openstack (openstack@lists.launchpad.net) (
openstack@lists.launchpad.net)
*Subject:* Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in
Folsom
** **
For me it's +1 to 1, but...
Here
90 matches
Mail list logo
