Christopher,
If I'm not mistaken about what you mean I understand the point with the
small changes, but what's wrong with already approved, tested and ready
changes to be added as one version? Alternatively you risk getting
rather quickly to high version numbers like 2.25, 2.37.... It'll lead to
a zoo of folders in jsons and docs and lots of functions and test
classes with version-specific names and decorators in the code, all of
them with ever increasing numbers. I mean it is a trade-off - quantity
of versions against sizes of changes. So maybe the mid-path is good
enough? Say, all trailing changes existing now at the moment to be
packed into one microversion? I understand there are 3 of them and all
of them are ready and waiting, aren't they?
Best regards,
Alex Levine
On 3/5/15 2:53 AM, Christopher Yeoh wrote:
On Wed, Mar 4, 2015 at 9:51 PM, Alexandre Levine
<[email protected] <mailto:[email protected]>> wrote:
Christopher,
Does this
"So the plan for assignment of microversion api numbers is the same as
what we currently do for db migration changes - take the next one
knowing that you may need to rebase if someone else merges before you"
mean that I should put 2.2 in my review for now instead of 2.4?
I don't think that'd be worth it because in this case as its the first
microversion we've already decided to merge
https://review.openstack.org/140313
first and you'll need to rebase to at least 2.3. I think the reason I
recommended 2.4 to you was that https://review.openstack.org/128940
was the other patch identified as
a possible good candidate for being the first microversion but in the
end wasn't selected so it ended up with 2.3. From a quick look at
128940 I think it might have spec approval
issues thoughso if your patch is ready when 140313 merges you might
end up with 2.3.
Other suggestion would be to pack several simultaneously incoming
changes into one microversion. Maybe spawn them once a week, or
once a couple of weeks, or even with longer period, depending on
the amount of incoming changes. For example, wouldn't it be
convenient for clients to acquire all of the accumulated changes
in one microversion (2.2 as I understand) without needing to
understand which one came with what number? To clarify, I'm
suggesting to pass reviews for all of the hanging API changes
against 2.2 version.
So I think its probably better to keep the number of changes small per
microversion. Though I have also suggested in the past that very minor
changes in the same such as formatting etc be fixed if we're making
api chnges in the same area anyway and clients will be forced to
modify what they do regardless. However bundling a lot of api changes
in one microversion will for CD we'd need them to be enabled all at
once meaning we'd either need to merge them into one patch or have an
additional patch which just enables say 2.2 once all the dependent
patches are merged. This increases the probability that one delayed
patch will delay a bunch of others whereas now whoever is ready the
first will merge first..
It someone has experience from db migrations that they think would
work well, please let us know!
Regards,
Chris
Best regards,
Alex Levine
On 3/4/15 11:44 AM, Christopher Yeoh wrote:
On Tue, 03 Mar 2015 10:28:34 -0500
Sean Dague <[email protected] <mailto:[email protected]>> wrote:
On 03/03/2015 10:24 AM, Claudiu Belu wrote:
Hello.
I've talked with Christopher Yeoh yesterday and I've
asked him
about the microversions and when will they be able to
merge. He
said that for now, this commit had to get in before
any other
microversions: https://review.openstack.org/#/c/159767/
He also said that he'll double check everything, and
if everything
is fine, the first microversions should be getting in
soon after.
Best regards,
Claudiu Belu
I just merged that one this morning, so hopefully we can
dislodge.
So just before we merged the the keypairs microversion change
someone
enabled response schema tests which showed some further
problems. They
have now all been fixed but
https://review.openstack.org/#/c/161112/
which needs just one more +2. After that the first api change
which uses
microversions https://review.openstack.org/#/c/140313/ can
merge (has
3 +2's just needs the v2.1 fix first.
________________________________________
From: Alexandre Levine [[email protected]
<mailto:[email protected]>]
Sent: Tuesday, March 03, 2015 4:22 PM
To: OpenStack Development Mailing List (not for usage
questions)
Subject: Re: [openstack-dev] [nova] what's the merge
plan for
current proposed microversions?
Bump.
I'd really appreciate some answers to the question
Sean asked. I
still have the 2.4 in my review (the very one Sean
mentioned) but
it seems that it might not be the case.
Best regards,
Alex Levine
On 3/2/15 2:30 PM, Sean Dague wrote:
This change for the additional attributes for ec2
looks like it's
basically ready to go, except it has the wrong
microversion on it
(as they anticipated the other changes landing
ahead of them) -
https://review.openstack.org/#/c/155853
What's the plan for merging the outstanding
microversions? I
believe we're all conceptually approved on all
them, and it's an
important part of actually moving forward on the
new API. It seems
like we're in a bit of a holding pattern on all of
them right now,
and I'd like to make sure we start merging them
this week so that
they have breathing space before the freeze.
So the plan for assignment of microversion api numbers is the
same as
what we currently do for db migration changes - take the next one
knowing that you may need to rebase if someone else merges
before you.
Other suggestions welcome but will have to follow the
requirement that
they always merge in version order.
-Sean
__________________________________________________________________________
OpenStack Development Mailing List (not for usage
questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage
questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
