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 <alev...@cloudscaling.com <mailto:alev...@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 <s...@dague.net <mailto:s...@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 [alev...@cloudscaling.com
                <mailto:alev...@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-requ...@lists.openstack.org?subject:unsubscribe
                
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
                
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
        <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
    <http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to