Open Stack

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 
> <alevine at cloudscaling.com <mailto:alevine at cloudscaling.com>> 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 <sean at dague.net <mailto:sean at dague.net>> 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 [alevine at cloudscaling.com
>                 <mailto:alevine at cloudscaling.com>]
>                 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:
>                 OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>                 <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>                 __________________________________________________________________________
>                 OpenStack Development Mailing List (not for usage
>                 questions)
>                 Unsubscribe:
>                 OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>                 <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>         __________________________________________________________________________
>         OpenStack Development Mailing List (not for usage questions)
>         Unsubscribe:
>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150305/335cb993/attachment.html>