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-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
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.
__________________________________________________________________________
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
