Davanum,
Now that the picture with the both EC2 API solutions has cleared up a
bit, I can say yes, we'll be adding the tempest tests and doing devstack
integration.
Best regards,
Alex Levine
On 1/31/15 2:21 AM, Davanum Srinivas wrote:
Alexandre, Randy,
Are there plans afoot to add suppor
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
Hi
This discussion came up at the cinder mid-cycle last week too, specifically
in the context of 'Can we change the details text in an existing error, or
is that an unacceptable API change'.
I have to second security / operational concerns about exposing too much
granularity of failure in these e
On 01/31/2015 05:24 AM, Duncan Thomas wrote:
> Hi
>
> This discussion came up at the cinder mid-cycle last week too,
> specifically in the context of 'Can we change the details text in an
> existing error, or is that an unacceptable API change'.
>
> I have to second security / operational concern
"Kevin L. Mitchell" writes:
> On Fri, 2015-01-30 at 22:33 +, Everett Toews wrote:
>> It was suggested that the API WG use the openstack-specs [1] and/or
>> the api-wg [2] repo to publish its guidelines. We’ve already arrived
>> at the consensus that we should only use 1 repo [3]. So the purpo
Sean Dague writes:
> On 01/31/2015 05:24 AM, Duncan Thomas wrote:
>> What I would rather not see is leakage of information when something
>> internal to the cloud goes wrong, that the tenant can do nothing
>> against. We certainly shouldn't be leaking internal implementation
>> details like vendo
Alex,
Very cool. thanks.
-- dims
On Sat, Jan 31, 2015 at 1:04 AM, Alexandre Levine
wrote:
> Davanum,
>
> Now that the picture with the both EC2 API solutions has cleared up a bit, I
> can say yes, we'll be adding the tempest tests and doing devstack
> integration.
>
> Best regards,
> Alex Lev
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
* Why: We got a bit in the review queue. K-2 [1] cut is set to February 5th.
* When: February 2nd at 2:00 UTC [2] to February 5th at 2:00 UTC [3]
or sooner if we finish!
* Where: #openstack-cinder on freenode IRC. There will also be a
posted google hangout link in channel and etherpad [4] since t
* Blueprint/Spec approval deadline - February 15th
* Code freeze for all features - March 10th
After blueprint/spec approval deadline date has passed, you may
request exception by:
1) Email the Openstack Dev mailing list with "[cinder] Request Spec
Freeze Exception" in the subject.
2) The spec is
For those that have been following this escapade I wrote up the
following, hopefully it's useful to someone ;)
https://github.com/harlowja/pippin#how-it-works
Example(s) of actual runs are also @
https://github.com/harlowja/pippin/tree/master/examples
^ Does not include the full output files
Huge +1 from me!
Congratulations Elizabeth!
On Fri, Jan 30, 2015 at 12:20 PM, James E. Blair
wrote:
> Hi,
>
> The Infrastructure program has a unique three-tier team structure:
> contributors (that's all of us!), core members (people with +2 ability
> on infra projects in Gerrit) and root membe
Question, looks like this spec was abandoned , hard to tell if it is being
addressed elsewhere? Good idea that received a -2 then ultimately abandoned
sure to juno freeze I think.
https://blueprints.launchpad.net/nova/+spec/nova-ephemeral-cinder
13 matches
Mail list logo
