<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Christopher,<br>
<br>
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?<br>
<br>
<br>
Best regards,<br>
Alex Levine<br>
<br>
<div class="moz-cite-prefix">On 3/5/15 2:53 AM, Christopher Yeoh
wrote:<br>
</div>
<blockquote
cite="mid:CANCY3efGa7MRxk0U7BX7AYL1wFAQfYEnyq5Z-iN4KyKGMxhqkA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Mar 4, 2015 at 9:51 PM,
Alexandre Levine <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:alevine@cloudscaling.com" target="_blank">alevine@cloudscaling.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Christopher,<br>
<br>
Does this<span class=""><br>
<br>
"So the plan for assignment of microversion api numbers
is the same as<br>
what we currently do for db migration changes - take the
next one<br>
knowing that you may need to rebase if someone else
merges before you"<br>
<br>
</span>
mean that I should put 2.2 in my review for now instead of
2.4?<br>
<br>
</blockquote>
<div><br>
</div>
<div>I don't think that'd be worth it because in this case
as its the first microversion we've already decided to
merge <a moz-do-not-send="true"
href="https://review.openstack.org/140313">https://review.openstack.org/140313</a><br>
</div>
<div>first and you'll need to rebase to at least 2.3. I
think the reason I recommended 2.4 to you was that <a
moz-do-not-send="true"
href="https://review.openstack.org/128940">https://review.openstack.org/128940</a>
was the other patch identified as<br>
</div>
<div>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<br>
</div>
<div>issues thoughso if your patch is ready when 140313
merges you might end up with 2.3.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
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.<br>
<br>
</blockquote>
<div><br>
<br>
</div>
<div>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.. <br>
</div>
<div> <br>
</div>
<div>It someone has experience from db migrations that they
think would work well, please let us know!<br>
</div>
<div><br>
</div>
<div>Regards,<br>
<br>
</div>
<div>Chris<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
Best regards,<br>
Alex Levine
<div class="">
<div class="h5"><br>
<br>
On 3/4/15 11:44 AM, Christopher Yeoh wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
On Tue, 03 Mar 2015 10:28:34 -0500<br>
Sean Dague <<a moz-do-not-send="true"
href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
On 03/03/2015 10:24 AM, Claudiu Belu wrote:<br>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
Hello.<br>
<br>
I've talked with Christopher Yeoh yesterday and
I've asked him<br>
about the microversions and when will they be
able to merge. He<br>
said that for now, this commit had to get in
before any other<br>
microversions: <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/159767/"
target="_blank">https://review.openstack.org/#/c/159767/</a><br>
<br>
He also said that he'll double check everything,
and if everything<br>
is fine, the first microversions should be
getting in soon after.<br>
<br>
Best regards,<br>
<br>
Claudiu Belu<br>
</blockquote>
I just merged that one this morning, so hopefully
we can dislodge.<br>
</blockquote>
<br>
So just before we merged the the keypairs
microversion change someone<br>
enabled response schema tests which showed some
further problems. They<br>
have now all been fixed but <a
moz-do-not-send="true"
href="https://review.openstack.org/#/c/161112/"
target="_blank">https://review.openstack.org/#/c/161112/</a><br>
which needs just one more +2. After that the first
api change which uses<br>
microversions <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/140313/"
target="_blank">https://review.openstack.org/#/c/140313/</a>
can merge (has<br>
3 +2's just needs the v2.1 fix first.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
________________________________________<br>
From: Alexandre Levine [<a
moz-do-not-send="true"
href="mailto:alevine@cloudscaling.com"
target="_blank">alevine@cloudscaling.com</a>]<br>
Sent: Tuesday, March 03, 2015 4:22 PM<br>
To: OpenStack Development Mailing List (not for
usage questions)<br>
Subject: Re: [openstack-dev] [nova] what's the
merge plan for<br>
current proposed microversions?<br>
<br>
Bump.<br>
<br>
I'd really appreciate some answers to the
question Sean asked. I<br>
still have the 2.4 in my review (the very one
Sean mentioned) but<br>
it seems that it might not be the case.<br>
<br>
Best regards,<br>
Alex Levine<br>
<br>
On 3/2/15 2:30 PM, Sean Dague wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
This change for the additional attributes for
ec2 looks like it's<br>
basically ready to go, except it has the wrong
microversion on it<br>
(as they anticipated the other changes landing
ahead of them) -<br>
<a moz-do-not-send="true"
href="https://review.openstack.org/#/c/155853"
target="_blank">https://review.openstack.org/#/c/155853</a><br>
<br>
What's the plan for merging the outstanding
microversions? I<br>
believe we're all conceptually approved on all
them, and it's an<br>
important part of actually moving forward on
the new API. It seems<br>
like we're in a bit of a holding pattern on
all of them right now,<br>
and I'd like to make sure we start merging
them this week so that<br>
they have breathing space before the freeze.<br>
<br>
</blockquote>
</blockquote>
</blockquote>
So the plan for assignment of microversion api
numbers is the same as<br>
what we currently do for db migration changes - take
the next one<br>
knowing that you may need to rebase if someone else
merges before you.<br>
Other suggestions welcome but will have to follow
the requirement that<br>
they always merge in version order.<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
-Sean<br>
<br>
</blockquote>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for
usage questions)<br>
Unsubscribe:<br>
<a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for
usage questions)<br>
Unsubscribe:<br>
<a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
<br>
</blockquote>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>