Open Stack

On 05/02/2013 02:01 AM, Monty Taylor wrote:
> I do not believe that we're going to spend
> a good amount of energy on supporting arbitrary version upgrades such as
> essex->grizzly.

I'm not saying that we should spend an unreasonable amount of energy on
*any arbitrary* version upgrades. Essex -> grizzly is currently LTS ->
last current stable. I don't think it is unreasonable to support it.

Oh, and by the way, I have no choice. Wheezy has Essex. After this
week-end, Wheezy will be out (on the 5th, if everything goes as the
release team plans...), and I'll be uploading Grizzly to SID (instead of
Experimental). I will continue to receive some piuparts repports with
upgrades from Wheezy to SID. Such failure to upgrade are considered
(rightly) release critical in Debian. So, unless I decide to upload only
LTS versions of OpenStack (which can be a solution... not satisfying,
but still a solution), I'll be hitting the problem.

On 05/02/2013 02:37 AM, Morgan Fainberg wrote:
> Essex -> Grizzly is a big jump

>From the user's perspective, I don't agree. That's only 1 year ago.

On 05/02/2013 02:37 AM, Morgan Fainberg wrote:
> I think that the best plan of action for Essex -> Grizzly is
> documentation

This is absolutely *not* an option. I can't reply to the piuparts tests
bug reports that I receive that the problem is documented, and there
fore I should close the bug!!!

On 05/02/2013 02:47 AM, Sean Dague wrote:
> To support skip upgrades you need to get all the core teams to commit
> to Deprecate in N, remove in N+2, instead of Deprecate in N, remove
> in N+1.

That's not what I'm asking for. I'm asking that upgrade from the last
LTS to the current stable should always be possible. This would include
Essex -> Havana, but not Folsom -> Havana.

On 05/02/2013 02:47 AM, Sean Dague wrote:
> It would mean that grizzly would have still shipped with nova-volume.
> It would mean that nova-network would need to still ship in I, as
> would the bare-metal virt driver (just for some examples).

I'm not asking for that either. If we have moving parts, then user
should adapt, that part is fine in a documentation. We already have
already stuff like this:

Package: nova-volume
Depends: cinder-volume, cinder-api, cinder-scheduler

which is quite fine... As a package maintainer, I don't really need to
worry much about it anyway.

On 05/02/2013 03:53 AM, Russell Bryant wrote:
> The ship has long since sailed on the Essex -> Grizzly question, so
> there's not much use in debating that at this point.

The upstream author ship can sink, I still will be held as responsible
for the packages and their maintenance. The question is more: do you
wish to help me, or am I alone here?

On 05/02/2013 04:27 AM, Ryan Lane wrote:
> essex -> folsom and folsom -> grizzly schema changes will be the same
> forever. They never need to change. Just because we don't want to
> support essex -> grizzly upgrades, doesn't mean we need to actively
> remove things that will continue to work forever.

This is exactly my point as well. I don't think this is a high
maintenance thing that I'm asking for.

On 05/02/2013 04:27 AM, Ryan Lane wrote:
> Obviously people are going to have to change their config files and
> they may need to replace entire services, but we should have data
> migration paths going back forever. All we have to do for this is
> leave them alone.

Yes. And configuration files are still under the responsibility of the
users, even though it is nicer if package maintainer can provide smooth
upgrades (which should be doable with couples of sed -i at the correct
places, though documenting should be enough, contrary to db upgrades
which we *have* to support).

On 05/02/2013 05:31 AM, Johannes Erdfelt wrote:
> Right now that time frame is ~6 months because that is how often
> releases are made.

If we had PPA support in Debian, I wouldn't mind. Though we still don't,
therefore I'm stuck with having to support Debian users who do expect
rightly that things "just work" (tm). This includes Essex -> Grizzly
currently, and will include Essex -> Havana when it will be out. That's
how things are, I can't change them. If you continue to just reply to me
"but we only have a 6 months timeframe", that doesn't make the issue go
away. That just leaves me alone with it.

Cheers,

Thomas