Open Stack

Doug, thanks for the clarification re migration time.

I'm absolutely agree with point about need to keep API backward compat.

On Sat, May 31, 2014 at 1:04 AM, Doug Hellmann
<doug.hellmann at dreamhost.com> wrote:
> No matter what version number we use, we will have to be careful about
> API changes. We cannot have 2 versions of the same library installed
> at the same time, so in order for devstack to work (and therefore the
> gate), we will have to make all changes backwards-compatible and
> support older APIs until our projects have migrated to the new APIs.
>
> This is *exactly* why we have the Oslo incubator. It gives us a place
> to work out stable APIs in a way that does not restrict when and how
> updates can be made. since the syncs can be handled by projects at
> their own pace.
>
> Doug
>
> On Fri, May 30, 2014 at 11:37 AM, Roman Podoliaka
> <rpodolyaka at mirantis.com> wrote:
>> Hi Sergey,
>>
>> tl;dr
>>
>> I'd like to be a ready to use version, but not 1.0.0.
>>
>> So it's a good question and I'd like to hear more input on this from all.
>>
>> If we start from 1.0.0, this will mean that we'll be very limited in
>> terms of changes to public API we can make without bumping the MAJOR
>> part of the version number. I don't expect the number of those changes
>> to be big, but I also don't want us to happen in a situation when we
>> have oslo.db 3.0.0 in a few months (if we follow semver
>> pragmatically).
>>
>> Perhaps, we should stick to 0.MINOR.PATCH versioning for now (as e.g.
>> SQLAlchemy and TripleO projects do)? These won't be alphas, but rather
>> ready to use versions. And we would still have a bit more 'freedom' to
>> do small API changes bumping the MINOR part of the version number (we
>> could also do intermediate releases deprecating some stuff, so we
>> don't break people projects every time we make some API change).
>>
>> Thanks,
>> Roman
>>
>> On Fri, May 30, 2014 at 6:06 PM, Sergey Lukjanov <slukjanov at mirantis.com> wrote:
>>> Hey Roman,
>>>
>>> will it be the alpha version that should not be used by other projects
>>> or it'll be ready to use?
>>>
>>> Thanks.
>>>
>>> On Fri, May 30, 2014 at 6:36 PM, Roman Podoliaka
>>> <rpodolyaka at mirantis.com> wrote:
>>>> Hi Matt,
>>>>
>>>> We're waiting for a few important fixes to be merged (usage of
>>>> oslo.config, eventlet tpool support). Once those are merged, we'll cut
>>>> the initial release.
>>>>
>>>> Thanks,
>>>> Roman
>>>>
>>>> On Fri, May 30, 2014 at 5:19 PM, Matt Riedemann
>>>> <mriedem at linux.vnet.ibm.com> wrote:
>>>>>
>>>>>
>>>>> On 4/25/2014 7:46 AM, Doug Hellmann wrote:
>>>>>>
>>>>>> On Fri, Apr 25, 2014 at 8:33 AM, Matt Riedemann
>>>>>> <mriedem at linux.vnet.ibm.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 4/18/2014 1:18 PM, Doug Hellmann wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Nice work, Victor!
>>>>>>>>
>>>>>>>> I left a few comments on the commits that were made after the original
>>>>>>>> history was exported from the incubator. There were a couple of small
>>>>>>>> things to address before importing the library, and a couple that can
>>>>>>>> wait until we have the normal code review system. I'd say just add new
>>>>>>>> commits to fix the issues, rather than trying to amend the existing
>>>>>>>> commits.
>>>>>>>>
>>>>>>>> We haven't really discussed how to communicate when we agree the new
>>>>>>>> repository is ready to be imported, but it seems reasonable to use the
>>>>>>>> patch in openstack-infra/config that will be used to do the import:
>>>>>>>> https://review.openstack.org/#/c/78955/
>>>>>>>>
>>>>>>>> Doug
>>>>>>>>
>>>>>>>> On Fri, Apr 18, 2014 at 10:28 AM, Victor Sergeyev
>>>>>>>> <vsergeyev at mirantis.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hello all,
>>>>>>>>>
>>>>>>>>> During Icehouse release cycle our team has been working on splitting of
>>>>>>>>> openstack common db code into a separate library blueprint [1]. At the
>>>>>>>>> moment the issues, mentioned in this bp and [2] are solved and we are
>>>>>>>>> moving
>>>>>>>>> forward to graduation of oslo.db. You can find the new oslo.db code at
>>>>>>>>> [3]
>>>>>>>>>
>>>>>>>>> So, before moving forward, I want to ask Oslo team to review oslo.db
>>>>>>>>> repository [3] and especially the commit, that allows the unit tests to
>>>>>>>>> pass
>>>>>>>>> [4].
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Victor
>>>>>>>>>
>>>>>>>>> [1] https://blueprints.launchpad.net/oslo/+spec/oslo-db-lib
>>>>>>>>> [2] https://wiki.openstack.org/wiki/Oslo/GraduationStatus#oslo.db
>>>>>>>>> [3] https://github.com/malor/oslo.db
>>>>>>>>> [4]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://github.com/malor/oslo.db/commit/276f7570d7af4a7a62d0e1ffb4edf904cfbf0600
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OpenStack-dev mailing list
>>>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> OpenStack-dev mailing list
>>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>>
>>>>>>>
>>>>>>> I'm probably just late to the party, but simple question: why is it in
>>>>>>> the
>>>>>>> malor group in github rather than the openstack group, like
>>>>>>> oslo.messaging
>>>>>>> and oslo.rootwrap?  Is that temporary or will it be moved at some point?
>>>>>>
>>>>>>
>>>>>> This is the copy of the code being prepared to import into a new
>>>>>> oslo.db repository. It's easier to set up that temporary hosting on
>>>>>> github. The repo has been approved to be imported, and after that
>>>>>> happens it will be hosted on our git server like all of the other oslo
>>>>>> libraries.
>>>>>>
>>>>>> Doug
>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Matt Riedemann
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OpenStack-dev mailing list
>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>
>>>>> Are there any status updates on where we are with this [1]?  I see that
>>>>> oslo.db is in git.openstack.org now [2].  There is a super-alpha dev package
>>>>> on pypi [3], are we waiting for an official release?
>>>>>
>>>>> I'd like to start moving nova over to using oslo.db or at least get an idea
>>>>> for how much work it's going to be.  I don't imagine it's going to be that
>>>>> difficult since I think a lot of the oslo.db code originated in nova.
>>>>>
>>>>> [1] https://review.openstack.org/#/c/91407/
>>>>> [2] http://git.openstack.org/cgit/openstack/oslo.db/
>>>>> [3] https://pypi.python.org/pypi/oslo.db/0.0.1.dev15.g7efbf12
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Matt Riedemann
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> --
>>> Sincerely yours,
>>> Sergey Lukjanov
>>> Sahara Technical Lead
>>> (OpenStack Data Processing)
>>> Principal Software Engineer
>>> Mirantis Inc.
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.