Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-02-05 Thread Vishvananda Ishaya

On Feb 3, 2015, at 6:19 AM, Sean Dague s...@dague.net wrote:

 On 02/03/2015 08:57 AM, Thierry Carrez wrote:
 Jesse Pretorius wrote:
 I think that perhaps something that shouldn't be lost site of is that
 the users using the EC2 API are using it as-is. The only commitment that
 needs to be made is to maintain the functionality that's already there,
 rather than attempt to keep it up to scratch with newer functionality
 that's come into EC2.
 
 The stackforge project can perhaps be the incubator for the development
 of a full replacement which is more up-to-date and interacts more like a
 translator. Once it's matured enough that the users want to use it
 instead of the old EC2 API in-tree, then perhaps deprecation is the
 right option.
 
 Between now and then, I must say that I agree with Sean - perhaps the
 best strategy would be to make it clear somehow that the EC2 API isn't a
 fully tested or up-to-date API.
 
 Right, there are several dimensions in the issue we are discussing.
 
 - I completely agree we should communicate clearly the status of the
 in-tree EC2 API to our users.
 
 - Deprecation is a mechanism by which we communicate to our users that
 they need to evolve their current usage of OpenStack. It should not be
 used lightly, and it should be a reliable announcement. In the past we
 deprecated things based on a promised replacement plan that never
 happened, and we had to un-deprecate. I would very much prefer if we
 didn't do that ever again, because it's training users to ignore our
 deprecation announcements. That is what I meant in my earlier email. We
 /can/ deprecate, but only when we are 99.9% sure we will follow up on that.
 
 - The supposed 35% of our users are actually more 44% of the user
 survey respondents replying yes when asked if they ever used the EC2
 API in their deployment of OpenStack. Given that it's far from being up
 to date or from behaving fully like the current Amazon EC2 API, it's
 fair to say that those users are probably more interested in keeping the
 current OpenStack EC2 API support as-is, than they are interested in a
 new project that will actually make it better and/or different.
 
 All of which is fair, however there is actually no such thing as
 keeping support as-is. The EC2 API is the equivalent of parts of Nova
 + Neutron + Cinder + Keystone + Swift. However the whole thing is
 implemented in Nova. Nova, for instances, has a terrible s3 object store
 in tree to make any of this work (so that the EC2 API doesn't actually
 depend on Swift). As the projects drift away and change their semantics,
 and bump their APIs keeping the same support is real work, that's not
 getting done.

This is a bit unfair. This code path is only used for ec2_register_image
which I think is almost completely unused even by ec2 these days. Also,
it can use any s3 object store (for example swift with swift3 in front).

Vish

 
 It will become different over time regardless, the real question is if
 it gets different worse or different better.
 
 - Given legal uncertainty about closed APIs it might make *legal* sense
 to remove it from Nova or at least mark it deprecated and freeze it
 until that removal can happen. Projects in Stackforge are, by
 definition, not OpenStack projects, and therefore do not carry the same
 risk.
 
 
 
 -- 
 Sean Dague
 http://dague.net
 
 __
 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


Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-02-03 Thread Thierry Carrez
Jesse Pretorius wrote:
 I think that perhaps something that shouldn't be lost site of is that
 the users using the EC2 API are using it as-is. The only commitment that
 needs to be made is to maintain the functionality that's already there,
 rather than attempt to keep it up to scratch with newer functionality
 that's come into EC2.
 
 The stackforge project can perhaps be the incubator for the development
 of a full replacement which is more up-to-date and interacts more like a
 translator. Once it's matured enough that the users want to use it
 instead of the old EC2 API in-tree, then perhaps deprecation is the
 right option.
 
 Between now and then, I must say that I agree with Sean - perhaps the
 best strategy would be to make it clear somehow that the EC2 API isn't a
 fully tested or up-to-date API.

Right, there are several dimensions in the issue we are discussing.

- I completely agree we should communicate clearly the status of the
in-tree EC2 API to our users.

- Deprecation is a mechanism by which we communicate to our users that
they need to evolve their current usage of OpenStack. It should not be
used lightly, and it should be a reliable announcement. In the past we
deprecated things based on a promised replacement plan that never
happened, and we had to un-deprecate. I would very much prefer if we
didn't do that ever again, because it's training users to ignore our
deprecation announcements. That is what I meant in my earlier email. We
/can/ deprecate, but only when we are 99.9% sure we will follow up on that.

- The supposed 35% of our users are actually more 44% of the user
survey respondents replying yes when asked if they ever used the EC2
API in their deployment of OpenStack. Given that it's far from being up
to date or from behaving fully like the current Amazon EC2 API, it's
fair to say that those users are probably more interested in keeping the
current OpenStack EC2 API support as-is, than they are interested in a
new project that will actually make it better and/or different.

- Given legal uncertainty about closed APIs it might make *legal* sense
to remove it from Nova or at least mark it deprecated and freeze it
until that removal can happen. Projects in Stackforge are, by
definition, not OpenStack projects, and therefore do not carry the same
risk.

-- 
Thierry Carrez (ttx)

__
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


Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-02-03 Thread Sean Dague
On 02/03/2015 08:57 AM, Thierry Carrez wrote:
 Jesse Pretorius wrote:
 I think that perhaps something that shouldn't be lost site of is that
 the users using the EC2 API are using it as-is. The only commitment that
 needs to be made is to maintain the functionality that's already there,
 rather than attempt to keep it up to scratch with newer functionality
 that's come into EC2.

 The stackforge project can perhaps be the incubator for the development
 of a full replacement which is more up-to-date and interacts more like a
 translator. Once it's matured enough that the users want to use it
 instead of the old EC2 API in-tree, then perhaps deprecation is the
 right option.

 Between now and then, I must say that I agree with Sean - perhaps the
 best strategy would be to make it clear somehow that the EC2 API isn't a
 fully tested or up-to-date API.
 
 Right, there are several dimensions in the issue we are discussing.
 
 - I completely agree we should communicate clearly the status of the
 in-tree EC2 API to our users.
 
 - Deprecation is a mechanism by which we communicate to our users that
 they need to evolve their current usage of OpenStack. It should not be
 used lightly, and it should be a reliable announcement. In the past we
 deprecated things based on a promised replacement plan that never
 happened, and we had to un-deprecate. I would very much prefer if we
 didn't do that ever again, because it's training users to ignore our
 deprecation announcements. That is what I meant in my earlier email. We
 /can/ deprecate, but only when we are 99.9% sure we will follow up on that.
 
 - The supposed 35% of our users are actually more 44% of the user
 survey respondents replying yes when asked if they ever used the EC2
 API in their deployment of OpenStack. Given that it's far from being up
 to date or from behaving fully like the current Amazon EC2 API, it's
 fair to say that those users are probably more interested in keeping the
 current OpenStack EC2 API support as-is, than they are interested in a
 new project that will actually make it better and/or different.

All of which is fair, however there is actually no such thing as
keeping support as-is. The EC2 API is the equivalent of parts of Nova
+ Neutron + Cinder + Keystone + Swift. However the whole thing is
implemented in Nova. Nova, for instances, has a terrible s3 object store
in tree to make any of this work (so that the EC2 API doesn't actually
depend on Swift). As the projects drift away and change their semantics,
and bump their APIs keeping the same support is real work, that's not
getting done.

It will become different over time regardless, the real question is if
it gets different worse or different better.

 - Given legal uncertainty about closed APIs it might make *legal* sense
 to remove it from Nova or at least mark it deprecated and freeze it
 until that removal can happen. Projects in Stackforge are, by
 definition, not OpenStack projects, and therefore do not carry the same
 risk.
 


-- 
Sean Dague
http://dague.net

__
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


Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-02-02 Thread Jesse Pretorius
On 2 February 2015 at 16:29, Sean Dague s...@dague.net wrote:

 It's really easy to say someone should do this, but the problem is
 that none of the core team is interested, neither is anyone else. Most
 of the people that once were interested have left being active in
 OpenStack.

 EC2 compatibility does not appear to be part of the long term strategy
 for the project, hasn't been in a while (looking at the level of
 maintenance here). Ok, we should signal that so that new and existing
 users that believe that is a core supported feature realize it's not.

 The fact that there is some plan to exist out of tree is a bonus,
 however the fact that this is not a first class feature in Nova really
 does need to be signaled. It hasn't been.

 Maybe deprecation is the wrong tool for that, and marking EC2 as
 experimental and non supported in the log message is more appropriate.


I think that perhaps something that shouldn't be lost site of is that the
users using the EC2 API are using it as-is. The only commitment that needs
to be made is to maintain the functionality that's already there, rather
than attempt to keep it up to scratch with newer functionality that's come
into EC2.

The stackforge project can perhaps be the incubator for the development of
a full replacement which is more up-to-date and interacts more like a
translator. Once it's matured enough that the users want to use it instead
of the old EC2 API in-tree, then perhaps deprecation is the right option.

Between now and then, I must say that I agree with Sean - perhaps the best
strategy would be to make it clear somehow that the EC2 API isn't a fully
tested or up-to-date API.
__
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


Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-02-02 Thread Daniel P. Berrange
On Fri, Jan 30, 2015 at 04:38:44PM -0600, Matt Riedemann wrote:
 
 
 On 1/30/2015 3:16 PM, Soren Hansen wrote:
 As I've said a couple of times in the past, I think the
 architecturally sound approach is to keep this inside Nova.
 
 The two main reasons are:
   * Having multiple frontend API's keeps us honest in terms of
 separation between the different layers in Nova.
   * Having the EC2 API inside Nova ensures the internal data model is
 rich enough to feed the EC2 API. If some field's only use is to
 enable the EC2 API and the EC2 API is a separate component, it's not
 hard to imagine it being deprecated as well.
 
 I fear that deprecation is a one way street and I would like to ask
 one more chance to resucitate it in its current home.
 
 I could be open to a discussion about putting it into a separate
 repository, but having it functionally remain in its current place, if
 that's somehow easier to swallow.
 
 
 Soren Hansen | http://linux2go.dk/
 Ubuntu Developer | http://www.ubuntu.com/
 OpenStack Developer  | http://www.openstack.org/
 
 
 2015-01-28 20:56 GMT+01:00 Sean Dague s...@dague.net:
 The following review for Kilo deprecates the EC2 API in Nova -
 https://review.openstack.org/#/c/150929/
 
 There are a number of reasons for this. The EC2 API has been slowly
 rotting in the Nova tree, never was highly tested, implements a
 substantially older version of what AWS has, and currently can't work
 with any recent releases of the boto library (due to implementing
 extremely old version of auth). This has given the misunderstanding that
 it's a first class supported feature in OpenStack, which it hasn't been
 in quite sometime. Deprecating honestly communicates where we stand.
 
 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.
 
 Comments are welcomed, but we've attempted to get more people engaged to
 address these issues over the last 18 months, and never really had
 anyone step up. Without some real maintainers of this code in Nova (and
 tests somewhere in the community) it's really no longer viable.
 
  -Sean
 
 --
 Sean Dague
 http://dague.net
 
 
 __
 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
 
 
 Deprecation isn't a one-way street really, nova-network was deprecated for a
 couple of releases and then undeprecated and opened up again for feature
 development (at least for a short while until the migration to neutron is
 sorted out and implemented).

Nova-network was prematurely deprecated as the alternative was not fully
ready. That's a prime example of why we should not be deprecating EC2
right now either.

Deprecation is a mechanism by which you inform users that they should
stop using the current functionality and switch to $NEW-THING as the
replacement. In the case of nova-network they could not switch because
neutron did not offer feature parity at the time we were asking them
to switch (nor did it have an upgrade path for that matter). Likewise
in the case of the EC2 API, the alternative is not ready for users to
actually switch to at a production quality level.

What we actually trying to tell users is that we think the out of tree
EC2 implementation is the long term strategic direction of the EC2
support with Nova, and that the current in tree impl is not being actively
developed. That's a sensible thing to tell our users, but deprecation is
the wrong mechanism for this. It is a task best suited for release notes.
Keep deprecation available as a mechanism for telling users that the time
has come for them to actively switch their deployments to the new impl.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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


Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-02-02 Thread Thierry Carrez
Daniel P. Berrange wrote:
 On Fri, Jan 30, 2015 at 04:38:44PM -0600, Matt Riedemann wrote:

 Deprecation isn't a one-way street really, nova-network was deprecated for a
 couple of releases and then undeprecated and opened up again for feature
 development (at least for a short while until the migration to neutron is
 sorted out and implemented).
 
 Nova-network was prematurely deprecated as the alternative was not fully
 ready. That's a prime example of why we should not be deprecating EC2
 right now either.
 
 Deprecation is a mechanism by which you inform users that they should
 stop using the current functionality and switch to $NEW-THING as the
 replacement. In the case of nova-network they could not switch because
 neutron did not offer feature parity at the time we were asking them
 to switch (nor did it have an upgrade path for that matter). Likewise
 in the case of the EC2 API, the alternative is not ready for users to
 actually switch to at a production quality level.
 
 What we actually trying to tell users is that we think the out of tree
 EC2 implementation is the long term strategic direction of the EC2
 support with Nova, and that the current in tree impl is not being actively
 developed. That's a sensible thing to tell our users, but deprecation is
 the wrong mechanism for this. It is a task best suited for release notes.
 Keep deprecation available as a mechanism for telling users that the time
 has come for them to actively switch their deployments to the new impl.

I'm with Daniel on that one. We shouldn't deprecate until we are 100%
sure that the replacement is up to the task and that strategy is solid.

Today, we are just figuring out the strategy between the mainline EC2
support and the separated EC2 support repository, and we have some
promised resources to work on the issue. We have been there before (a
few times), and if we had deprecated the EC2 support on that promise
back then, we would have put ourselves in an odd corner. Today is not
really the best moment to deprecate. Announcing the proposed strategy,
however, is good information to send to our users.

-- 
Thierry Carrez (ttx)

__
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


Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-02-02 Thread Dan Smith
 I'm with Daniel on that one. We shouldn't deprecate until we are 100%
 sure that the replacement is up to the task and that strategy is solid.

My problem with this is: If there wasn't a stackforge project, what
would we do? Nova's in-tree EC2 support has been rotting for years now,
and despite several rallies for developers, no real progress has been
made to rescue it. I don't think that it's reasonable to say that if
there wasn't a stackforge project we'd just have to suck it up and
magically produce the developers to work on EC2; it's clear that's not
going to happen.

Thus, it seems to me that we need to communicate that our EC2 support is
going away. Hopefully the stackforge project will be at a point to
support users that want to keep the functionality. However, the fate of
our in-tree support seems clear regardless of how that turns out.

--Dan



signature.asc
Description: OpenPGP digital signature
__
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


Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-02-02 Thread Sean Dague
On 02/02/2015 10:55 AM, Daniel P. Berrange wrote:
 On Mon, Feb 02, 2015 at 07:44:24AM -0800, Dan Smith wrote:
 I'm with Daniel on that one. We shouldn't deprecate until we are 100%
 sure that the replacement is up to the task and that strategy is solid.

 My problem with this is: If there wasn't a stackforge project, what
 would we do? Nova's in-tree EC2 support has been rotting for years now,
 and despite several rallies for developers, no real progress has been
 made to rescue it. I don't think that it's reasonable to say that if
 there wasn't a stackforge project we'd just have to suck it up and
 magically produce the developers to work on EC2; it's clear that's not
 going to happen.
 
 I think that is exactly what we'd would have todo. We exist as a project
 to serve the needs of our users and it seems pretty clear from the survey
 results that users are deploying the EC2 impl in significant numbers,
 so to just remove it would essentially be ignoring what our users want
 from the project. If we're saying it is reasonable to ignore what our
 users want, then this project is frankly doomed.
 
 Thus, it seems to me that we need to communicate that our EC2 support is
 going away. Hopefully the stackforge project will be at a point to
 support users that want to keep the functionality. However, the fate of
 our in-tree support seems clear regardless of how that turns out.
 
 If the external EC2 support doesn't work out for whatever reason, then
 I don't think the fate of the in-tree support is at all clear. I think
 it would have a very strong case for continuing to exist.

It's really easy to say someone should do this, but the problem is
that none of the core team is interested, neither is anyone else. Most
of the people that once were interested have left being active in OpenStack.

EC2 compatibility does not appear to be part of the long term strategy
for the project, hasn't been in a while (looking at the level of
maintenance here). Ok, we should signal that so that new and existing
users that believe that is a core supported feature realize it's not.

The fact that there is some plan to exist out of tree is a bonus,
however the fact that this is not a first class feature in Nova really
does need to be signaled. It hasn't been.

Maybe deprecation is the wrong tool for that, and marking EC2 as
experimental and non supported in the log message is more appropriate.

-Sean

-- 
Sean Dague
http://dague.net

__
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


Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-02-02 Thread Daniel P. Berrange
On Mon, Feb 02, 2015 at 07:44:24AM -0800, Dan Smith wrote:
  I'm with Daniel on that one. We shouldn't deprecate until we are 100%
  sure that the replacement is up to the task and that strategy is solid.
 
 My problem with this is: If there wasn't a stackforge project, what
 would we do? Nova's in-tree EC2 support has been rotting for years now,
 and despite several rallies for developers, no real progress has been
 made to rescue it. I don't think that it's reasonable to say that if
 there wasn't a stackforge project we'd just have to suck it up and
 magically produce the developers to work on EC2; it's clear that's not
 going to happen.

I think that is exactly what we'd would have todo. We exist as a project
to serve the needs of our users and it seems pretty clear from the survey
results that users are deploying the EC2 impl in significant numbers,
so to just remove it would essentially be ignoring what our users want
from the project. If we're saying it is reasonable to ignore what our
users want, then this project is frankly doomed.

 Thus, it seems to me that we need to communicate that our EC2 support is
 going away. Hopefully the stackforge project will be at a point to
 support users that want to keep the functionality. However, the fate of
 our in-tree support seems clear regardless of how that turns out.

If the external EC2 support doesn't work out for whatever reason, then
I don't think the fate of the in-tree support is at all clear. I think
it would have a very strong case for continuing to exist.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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


Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-01-31 Thread Alexandre Levine

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


Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-01-31 Thread M Ranga Swami Reddy
I could see the real issue here is the maintainers for EC2 API code.
If this is the case - create a sub-group with core members in it, who
will be responsible to maintain this code like other projects.

On Sat, Jan 31, 2015 at 2:54 PM, Alexandre Levine
alev...@cloudscaling.com wrote:
 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

__
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


Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-01-30 Thread Matt Riedemann



On 1/30/2015 3:16 PM, Soren Hansen wrote:

As I've said a couple of times in the past, I think the
architecturally sound approach is to keep this inside Nova.

The two main reasons are:
  * Having multiple frontend API's keeps us honest in terms of
separation between the different layers in Nova.
  * Having the EC2 API inside Nova ensures the internal data model is
rich enough to feed the EC2 API. If some field's only use is to
enable the EC2 API and the EC2 API is a separate component, it's not
hard to imagine it being deprecated as well.

I fear that deprecation is a one way street and I would like to ask
one more chance to resucitate it in its current home.

I could be open to a discussion about putting it into a separate
repository, but having it functionally remain in its current place, if
that's somehow easier to swallow.


Soren Hansen | http://linux2go.dk/
Ubuntu Developer | http://www.ubuntu.com/
OpenStack Developer  | http://www.openstack.org/


2015-01-28 20:56 GMT+01:00 Sean Dague s...@dague.net:

The following review for Kilo deprecates the EC2 API in Nova -
https://review.openstack.org/#/c/150929/

There are a number of reasons for this. The EC2 API has been slowly
rotting in the Nova tree, never was highly tested, implements a
substantially older version of what AWS has, and currently can't work
with any recent releases of the boto library (due to implementing
extremely old version of auth). This has given the misunderstanding that
it's a first class supported feature in OpenStack, which it hasn't been
in quite sometime. Deprecating honestly communicates where we stand.

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.

Comments are welcomed, but we've attempted to get more people engaged to
address these issues over the last 18 months, and never really had
anyone step up. Without some real maintainers of this code in Nova (and
tests somewhere in the community) it's really no longer viable.

 -Sean

--
Sean Dague
http://dague.net


__
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



Deprecation isn't a one-way street really, nova-network was deprecated 
for a couple of releases and then undeprecated and opened up again for 
feature development (at least for a short while until the migration to 
neutron is sorted out and implemented).


--

Thanks,

Matt Riedemann


__
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


Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-01-30 Thread Soren Hansen
As I've said a couple of times in the past, I think the
architecturally sound approach is to keep this inside Nova.

The two main reasons are:
 * Having multiple frontend API's keeps us honest in terms of
separation between the different layers in Nova.
 * Having the EC2 API inside Nova ensures the internal data model is
rich enough to feed the EC2 API. If some field's only use is to
enable the EC2 API and the EC2 API is a separate component, it's not
hard to imagine it being deprecated as well.

I fear that deprecation is a one way street and I would like to ask
one more chance to resucitate it in its current home.

I could be open to a discussion about putting it into a separate
repository, but having it functionally remain in its current place, if
that's somehow easier to swallow.


Soren Hansen | http://linux2go.dk/
Ubuntu Developer | http://www.ubuntu.com/
OpenStack Developer  | http://www.openstack.org/


2015-01-28 20:56 GMT+01:00 Sean Dague s...@dague.net:
 The following review for Kilo deprecates the EC2 API in Nova -
 https://review.openstack.org/#/c/150929/

 There are a number of reasons for this. The EC2 API has been slowly
 rotting in the Nova tree, never was highly tested, implements a
 substantially older version of what AWS has, and currently can't work
 with any recent releases of the boto library (due to implementing
 extremely old version of auth). This has given the misunderstanding that
 it's a first class supported feature in OpenStack, which it hasn't been
 in quite sometime. Deprecating honestly communicates where we stand.

 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.

 Comments are welcomed, but we've attempted to get more people engaged to
 address these issues over the last 18 months, and never really had
 anyone step up. Without some real maintainers of this code in Nova (and
 tests somewhere in the community) it's really no longer viable.

 -Sean

 --
 Sean Dague
 http://dague.net


 __
 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


Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-01-30 Thread Matt Riedemann



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.


--

Thanks,

Matt Riedemann


__
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


Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-01-29 Thread Alexandre Levine

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


Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-01-28 Thread Joe Gordon
On Wed, Jan 28, 2015 at 11:56 AM, Sean Dague s...@dague.net wrote:

 The following review for Kilo deprecates the EC2 API in Nova -
 https://review.openstack.org/#/c/150929/

 There are a number of reasons for this. The EC2 API has been slowly
 rotting in the Nova tree, never was highly tested, implements a
 substantially older version of what AWS has, and currently can't work
 with any recent releases of the boto library (due to implementing
 extremely old version of auth). This has given the misunderstanding that
 it's a first class supported feature in OpenStack, which it hasn't been
 in quite sometime. Deprecating honestly communicates where we stand.

 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.


FYI:
http://lists.openstack.org/pipermail/openstack-dev/2015-January/055041.html



 Comments are welcomed, but we've attempted to get more people engaged to
 address these issues over the last 18 months, and never really had
 anyone step up. Without some real maintainers of this code in Nova (and
 tests somewhere in the community) it's really no longer viable.

 -Sean

 --
 Sean Dague
 http://dague.net


 __
 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


Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

2015-01-28 Thread Thomas Goirand
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