openstack team mailing list archive

[Andrew Clay Shafer <acs@xxxxxxxxxxxxxxxx>]

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
> not be painful at all.
>

I'm not sure what you are disagreeing with or advocating.

We should expect code to change between releases, no?

As this thread demonstrated, we collectively have done a poor job of
communicating and managing those changes.

It is precisely because I expect more changes that I state that option 2 is
postponing risks, not lowering them.

I'm not saying you are wrong, or that my assumptions are correct, but I
don't understand what you disagree with.


>
>>
>> [...]
>> On the question of compatibility, my assumption is this a non-issue for
>> the moment.
>>
>
> I believe it wouldn't be an issue if people were not using OpenStack, but
> we are..
>

I thought it was clear from the context of the thread and my email that
compatibility in this case is in reference to the consumers of the API and
not to the differences for managing deployments.



>
> On the question of an upgrade path and the relative ease of deployment, my
>> assumption is this is no worse than any of the other upgrades.
>>
>
> It doesn't really mean a good thing, since I don't think that the others
> upgrades were good, based on what I heard and experienced with sysadmins
> from my team...
>

I totally agree that it's not a good thing.

Do we believe that keeping nova-volumes will make it painless?


> [...]
>> In specific, I think getting more information from operators and users is
>> generally good. Ultimately, if OpenStack cannot be operated and utilized,
>> the mission will fail.
>>
>
> I agree! (finally :P)
> I also think that it's our responsibility (as developers) to ask for input
> from operators, it's not because they are not complaining that things are
> going smoothly. We should ask for every one we know who's working with
> OpenStack and do our best to get feedback.
>

Definitely!

There are also different sets of unstated assumptions about what OpenStack
is or should be that have to be resolved or we are going to keep running
into these type of situations.

Those definitely create the situation we are facing, but they aren't unique
to Cinder/Volumes, so I will start another thread.