Open Stack

Matt,

Ideally (when we remove all the workarounds), the code should be 
dependent only on public APIs and oslo, but for the first few releases 
when some additional functionality is exposed in Nova for us to remove 
workarounds we might be dependent on particular releases - or if it's 
done via extensions or versioning and we can see what we're dealing with 
we also can be independent in terms of releases.

Best regards,
   Alex Levine
On 1/31/15 1:37 AM, Matt Riedemann wrote:
>
>
> On 1/29/2015 5:52 AM, Alexandre Levine wrote:
>> Thomas,
>>
>> I'm the lead of the team working on it.
>> The project is in a release-candidate state and the EC2 (non-VPC) part
>> is just being finished, so there are no tags or branches yet. Also we
>> were not sure about what should we do with it since we were told that
>> it'll have a chance of going as a part of nova eventually. So we've
>> created a spec and blueprint and only now the discussion has started.
>> Whatever the decisions we're ready to follow. If the first thing to get
>> it closer to customers is to create a package (now it can be only
>> installed from sources obviously) and a tag is required for it, then
>> that's what we should do.
>>
>> So bottom line - we're not sure ourselves what the best way to move. Do
>> we put a tag (in what format? 1.0? m1? 2015.1.rc1?)? Or do we create a
>> branch?
>> My thinking now is to just put a tag - something like 1.0.rc1.
>> What do you think?
>>
>> Best regards,
>>    Alex Levine
>>
>> On 1/29/15 2:13 AM, Thomas Goirand wrote:
>>> On 01/28/2015 08:56 PM, Sean Dague wrote:
>>>> There is a new stackforge project which is getting some activity now -
>>>> https://github.com/stackforge/ec2-api. The intent and hope is that is
>>>> the path forward for the portion of the community that wants this
>>>> feature, and that efforts will be focused there.
>>> I'd be happy to provide a Debian package for this, however, there's not
>>> even a single git tag there. That's not so nice for tracking issues.
>>> Who's working on it?
>>>
>>> Also, is this supposed to be branch-less? Or will it follow
>>> juno/kilo/l... ?
>>>
>>> Cheers,
>>>
>>> Thomas Goirand (zigo)
>>>
>>>
>>> __________________________________________________________________________ 
>>>
>>>
>>> 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
>>
>>
>> __________________________________________________________________________ 
>>
>> 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
>>
>
> How dependent is this code on current nova master?  For example, is 
> there a rebase or something that happens or things in nova on master 
> that change which affect this repo and it has to adjust, like what 
> happens with the nova-docker driver repo in stackforge?
>
> If so, then I'd think it more closely aligns with the openstack 
> release schedule and tagging/branching scheme, at least until it's 
> completely independent.
>