On Feb 3, 2015, at 6:19 AM, Sean Dague 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 t
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,
>> r
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 new
On 2 February 2015 at 16:29, Sean Dague 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 doe
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 th
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?
> 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 despit
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 t
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 fronten
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
wrote:
> Matt,
>
> Ideally (when we remove al
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 e
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
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
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
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 p
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
On Wed, Jan 28, 2015 at 11:56 AM, Sean Dague 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
17 matches
Mail list logo
