Hi all,
Jclouds put out a stack trace when I tried "Get server details" of API v2 by
jclouds.
I looked into a response body of the API, and found that a value of "image" was
an empty string as follows.
I think the value of "image" should be an empty dictionary like "Get server
details" of API v
Can you link to the etherpad you mentioned?
In the mean time, apologies for another analogy in
advance. :-)
If I give you an API to sort a list, I'm free to implement it however I
want as long as I return a sorted list. However, there is no way me to know
based on a call to this API that you migh
On 8 August 2014 02:06, Michael Still wrote:
> 1: I think that ultimately should live in infra as part of check, but
> I'd be ok with it starting as a third party if that delivers us
> something faster. I'd be happy enough to donate resources to get that
> going if we decide to go with this plan.
Hi,
This is to discuss Bug #1231298 - https://bugs.launchpad.net/cinder/+bug/1231298
Bug description : When one creates a volume from a snapshot or another volume,
the size argument is calculated automatically. In the case of an image it needs
to be specified though, for something larger than t
On 8 August 2014 10:52, Yuriy Taraday wrote:
> I don't dislike rebases because I sometimes use a bit longer version of it.
> I would be glad to avoid them because they destroy history that can help me
> later.
rebase doesn't destroy any history. gc destroys history.
See git reflog - you can rec
On Thu, Aug 07, 2014 at 03:56:04AM -0700, Jay Pipes wrote:
> On 08/07/2014 02:12 AM, Kashyap Chamarthy wrote:
[. . .]
> >
> >Excellent sugestion. I've wondered multiple times that if we could
> >dedicate a good chunk (or whole) of a specific release for heads down
> >bug fixing/stabilization. As
Did this ever go anywhere?
http://lists.openstack.org/pipermail/openstack-dev/2014-January/024315.html
Looking at what is needed to get backup working in OpenStack, and this
seems the most recent reference.
___
OpenStack-dev mailing list
OpenStack-dev@l
Getting a massive amount of information from data storage to be displayed is
where most of the activity happens in OpenStack. The two activities of reading
data and writing (creating, updating and deleting) data are fundamentally
different.
The optimization for these two opposite database activ
Hi, all
if I have more than one ironic conductor, so does each conductor should has
their own PXE server and DHCP namespace or they just share one centralized
pxe server or dhcp server ? if they share one centralized pxe and dhcp
server, so how does they support HA?
___
It seems to me that the tension here is that there are groups who
would really like to use features in newer libvirts that we don't CI
on in the gate. Is it naive to think that a possible solution here is
to do the following:
- revert the libvirt version_cap flag
- instead implement a third part
On Thu, Aug 7, 2014 at 11:20 PM, Russell Bryant wrote:
> On 08/07/2014 09:07 AM, Sean Dague wrote:> I think the difference is
> slot selection would just be Nova drivers. I
>> think there is an assumption in the old system that everyone in Nova
>> core wants to prioritize the blueprints. I think t
On Fri, Aug 8, 2014 at 3:03 AM, Chris Friesen
wrote:
> On 08/07/2014 04:52 PM, Yuriy Taraday wrote:
>
> I hope you don't think that this thread was about rebases vs merges.
>> It's about keeping track of your changes without impact on review process.
>>
>
> But if you rebase, what is stopping yo
On 08/07/2014 04:52 PM, Yuriy Taraday wrote:
I hope you don't think that this thread was about rebases vs merges.
It's about keeping track of your changes without impact on review process.
But if you rebase, what is stopping you from keeping whatever private
history you want and then rebase t
On 07/08/14 13:22, Tomas Sedovic wrote:
Hi all,
I have a ResourceGroup which wraps a custom resource defined in another
template:
servers:
type: OS::Heat::ResourceGroup
properties:
count: 10
resource_def:
type: my_custom_server
properti
On Thu, Aug 7, 2014 at 7:36 PM, Ben Nemec wrote:
> On 08/06/2014 05:35 PM, Yuriy Taraday wrote:
> > On Wed, Aug 6, 2014 at 11:00 PM, Ben Nemec
> wrote:
> >> You keep mentioning detached HEAD and reflog. I have never had to deal
> >> with either when doing a rebase, so I think there's a disconne
Hi all,
At the recent Ironic mid-cycle meetup, we got the first version of the
ironic-python-agent (IPA) driver merged. There are a few reviews we need merged
(and their dependencies) across a few other projects in order to begin testing
it automatically. We would like to eventually gate IPA a
On Thu, Aug 7, 2014 at 10:28 AM, Chris Friesen
wrote:
> On 08/06/2014 05:41 PM, Zane Bitter wrote:
>
>> On 06/08/14 18:12, Yuriy Taraday wrote:
>>>
>>> Well, as per Git author, that's how you should do with not-CVS. You have
>>> cheap merges - use them instead of erasing parts of history.
>>>
>>
> On 08/07/2014 01:41 PM, Eoghan Glynn wrote:
> > My point was simply that we don't have direct control over the
> > contributors' activities
>
> This is not correct and I've seen it repeated too often to let it go
> uncorrected: we (the OpenStack project as a whole) have a lot of control
> over
On Thu, Aug 7, 2014 at 12:54 PM, Kevin L. Mitchell <
kevin.mitch...@rackspace.com> wrote:
> On Thu, 2014-08-07 at 17:46 +0100, Matthew Booth wrote:
> > > In any case, the operative point is that CONF. must
> > always be
> > > evaluated inside run-time code, never at module load time.
> >
> > ...un
On 08/07/2014 01:41 PM, Eoghan Glynn wrote:
> My point was simply that we don't have direct control over the
> contributors' activities
This is not correct and I've seen it repeated too often to let it go
uncorrected: we (the OpenStack project as a whole) have a lot of control
over contributors to
> Dear All,
>
> Let me use my first post to this list to introduce Cyclops and initiate a
> discussion towards possibility of this platform as a future incubated
> project in OpenStack.
>
> We at Zurich university of Applied Sciences have a python project in open
> source (Apache 2 Licensing)
Thierry Carrez wrote on 08/07/2014 06:23:56 AM:
> From: Thierry Carrez
> To: openstack-dev@lists.openstack.org
> Date: 08/07/2014 06:25 AM
> Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy
> and the way forward
>
> Armando M. wrote:
> > This thread is moving so fast I can't
On Thu, Aug 7, 2014 at 12:08 PM, Kevin Benton wrote:
> >I mean't 'side stepping' why GBP allows for the comment you made
> previous, "With the latter, a mapping driver could determine that
> communication between these two hosts can be prevented by using an ACL on a
> router or a switch, which do
That I understand it!
Thanks for the clarification.
Edgar
From: Ryan Moats mailto:rmo...@us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, August 7, 2014 at 2:45 PM
To: "OpenStack Development Mailing L
Edgar Magana wrote on 08/07/2014 04:37:39 PM:
> From: Edgar Magana
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Date: 08/07/2014 04:40 PM
> Subject: Re: [openstack-dev] [Neutron][policy] Group Based Policy -
Renaming
>
> Ryan,
>
> COPS implies a common protocol to
Thanks for sharing this Sumit.
Again, my apologies for not attending the meeting, I just I couldn’t.
It seems you had a good discussion about the naming and I do respect the
decision.
Cheers,
Edgar
On 8/7/14, 2:32 PM, "Sumit Naiksatam" wrote:
>Ryan, point well taken. I am paraphrasing the di
Ryan,
COPS implies a common protocol to communicate with PEPs, which implies the same
communication mechanism basically.
So, you are implying that "endpoints" in GBP will use "different" protocol to
communicate with "decisions" entities?
It that is the case.. Well it sounds very complex for a s
Ryan, point well taken. I am paraphrasing the discussion from today's
GBP sub team meeting on the options considered and the eventual
proposal for "policy-point" and "policy-group":
18:36:50 so regarding the endpoint terminology
18:36:53 any suggestions?
18:36:56 ivar-lazzaro: If you are expre
Edgar-
I can't speak for anyone else, but in my mind at least (and having been
involved in the work that led up to 3198),
the members of the groups being discussed here are not PEPs. As 3198
states, being a PEP implies running COPS
and I don't see that as necessary for membership in GBP groups.
Hi Carol, thanks for the summary presentation. I listened in to the board
meeting for this portion. More below.
On Wed, Aug 6, 2014 at 4:55 PM, Barrett, Carol L
wrote:
> I want to provide the community an update on the Win The Enterprise work
> group that came together in a BoF session in Atla
LGTM. Plenty of things I could add to your list, but they're all
post-import. :-)
-Ben
On 08/07/2014 01:58 PM, Yuriy Taraday wrote:
> Hello, oslo cores.
>
> I've finished polishing up oslo.concurrency repo at [0] - please take a
> look at it. I used my new version of graduate.sh [1] to generate
hi Sahara folks,
This serves as a detailed status update for the Swift trust authentication
spec[1], and to bring up concerns about integration for the Juno cycle.
So far I have pushed a few reviews that start to lay the groundwork for the
infrastructure needed to complete this blueprint. I hav
I am sorry that I could not attend the GBP meeting.
Is there any reason why the IEFT standard is not considered?
http://tools.ietf.org/html/rfc3198
I would like to understand the argument why we are creating new names instead
of using the standard ones.
Edgar
From: Ronak Shah mailto:ronak.malav
Can you include the definition/description of what each is here as well? I
think there was a description in the 100+ thread of doom, but I don't want
to go back there :)
On Thu, Aug 7, 2014 at 3:17 PM, Ronak Shah
wrote:
> Hi,
> Following a very interesting and vocal thread on GBP for last coup
> > If we try to limit the number of WIP slots, then surely aspiring
> > contributors will simply work around that restriction by preparing
> > the code they're interested in on their own private branches, or
> > in their github forks?
> >
> > OK, some pragmatic contributors will adjust their prio
Hi,
Following a very interesting and vocal thread on GBP for last couple of
days and the GBP meeting today, GBP sub-team proposes following name
changes to the resource.
policy-point for endpoint
policy-group for endpointgroup (epg)
Please reply if you feel that it is not ok with reason and sugg
Personally, I prefer IRC for general meeting stuff, with separate
breakouts to voice for topics that warrant it.
Doug
On 8/7/14, 2:28 AM, "Stephen Balukoff" wrote:
>Hi Brandon,
>
>
>I don't think we've set a specific date to make the transition to IRC
>meetings. Is there a particular urgency a
On Thu, Aug 7, 2014 at 10:58 PM, Yuriy Taraday wrote:
> Hello, oslo cores.
>
> I've finished polishing up oslo.concurrency repo at [0] - please take a
> look at it. I used my new version of graduate.sh [1] to generate it, so
> history looks a bit different from what you might be used to.
>
> I've
Those are definitely other big reasons, and probably the reason it is
planned to move to IRC in the future, no matter what. I was just
wondering how soon, if soon at all.
On Thu, 2014-08-07 at 12:35 -0700, Stefano Maffulli wrote:
> On Thu 07 Aug 2014 12:12:26 PM PDT, Brandon Logan wrote:
> > It's
On Thu 07 Aug 2014 12:12:26 PM PDT, Brandon Logan wrote:
> It's just my own preference. Others like webex/hangouts because it can
> be easier to talk about topics than in IRC, but with this many people
> and the latency delays, it can become quite cumbersome. Plus, it makes
> it easier for meetin
On 08/07/2014 02:09 PM, Dean Troyer wrote:
> I want to nominate Ian Wienand (IRC: ianw) to the DevStack core team.
> Ian has been a consistent contributor and reviewer for some time now.
> He also manages the Red Hat CI that runs tests on Fedora, RHEL and
> CentOS so those platforms have been a p
On Aug 6, 2014, at 5:10 PM, Michael Still wrote:
> On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez wrote:
>
>> We seem to be unable to address some key issues in the software we
>> produce, and part of it is due to strategic contributors (and core
>> reviewers) being overwhelmed just trying to
It's just my own preference. Others like webex/hangouts because it can
be easier to talk about topics than in IRC, but with this many people
and the latency delays, it can become quite cumbersome. Plus, it makes
it easier for meeting notes. I'll deal with it while the majority
really prefer it.
>I mean't 'side stepping' why GBP allows for the comment you made previous,
"With the latter, a mapping driver could determine that communication
between these two hosts can be prevented by using an ACL on a router or a
switch, which doesn't violate the user's intent and buys a performance
improvem
On Aug 7, 2014, at 12:39 PM, Kevin L. Mitchell
wrote:
> On Thu, 2014-08-07 at 17:27 +0100, Matthew Booth wrote:
>> On 07/08/14 16:27, Kevin L. Mitchell wrote:
>>> On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote:
A (the?) solution is to register_opts() in foo before importing any
>>>
Hello, oslo cores.
I've finished polishing up oslo.concurrency repo at [0] - please take a
look at it. I used my new version of graduate.sh [1] to generate it, so
history looks a bit different from what you might be used to.
I've made as little changes as possible, so there're still some steps le
On 08/07/2014 12:32 PM, Eoghan Glynn wrote:
If we try to limit the number of WIP slots, then surely aspiring
contributors will simply work around that restriction by preparing
the code they're interested in on their own private branches, or
in their github forks?
OK, some pragmatic contributors
Hey sahara folks,
I'm going to push 2014.1.2 tag to stable/icehouse branch next week,
so, please, propose backports before the weekend and ping us to
backport some sensitive fixes.
Thanks you!
--
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Softwar
Thanks everyone who have joined Sahara meeting.
Here are the logs from the meeting:
http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-08-07-18.02.html
http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-08-07-18.02.log.html
--
Sincerely yours,
Sergey Lukjanov
Sahara Te
> Multidisciplinary training rules! As an architect with field experience
> building roads, sidewalks, roofs, city planning (and training in lean
> manufacturing and services) I think I can have a say ;)
>
> > You're not really introducing a successful Kanban here, you're just
> > clarifying tha
On Tue, Aug 5, 2014 at 9:03 AM, Thierry Carrez
wrote:
> Hi everyone,
>
> With the incredible growth of OpenStack, our development community is
> facing complex challenges. How we handle those might determine the
> ultimate success or failure of OpenStack.
>
> With this cycle we hit new limits in
I want to nominate Ian Wienand (IRC: ianw) to the DevStack core team. Ian
has been a consistent contributor and reviewer for some time now. He also
manages the Red Hat CI that runs tests on Fedora, RHEL and CentOS so those
platforms have been a particular point of interest for him. Ian has also
Hey,
I agree with Dmitry that this spec has a huge scope. If you resubmitted one
with only the power interface, that could be considered for an exception.
A few specific reasons:
1) Auto-enrollment -- should probably be held off at the moment
- This is something that was talked about extensive
On Thu, Aug 7, 2014 at 9:54 AM, Kevin Benton wrote:
> You said you had no idea what group based policy was buying us so I tried
> to illustrate what the difference between declarative and imperative
> network configuration looks like. That's the major selling point of GBP so
> I'm not sure how th
On Thu, 2014-08-07 at 17:41 +0100, Matthew Booth wrote:
> ... or arg is an object which defines __nonzero__(), or defines
> __getattr__() and then explodes because of the unexpected lookup of a
> __nonzero__ attribute. Or it's False (no quotes when printed by the
> debugger), but has a unicode type
On Thu, 2014-08-07 at 17:46 +0100, Matthew Booth wrote:
> > In any case, the operative point is that CONF. must
> always be
> > evaluated inside run-time code, never at module load time.
>
> ...unless you call register_opts() safely, which is what I'm
> proposing.
No, calling register_opts() at a
On Thu, 2014-08-07 at 17:44 +0100, Matthew Booth wrote:
> These are tricky, case-by-case workarounds to a general problem which
> can be solved by simply calling register_opts() in a place where it's
> guaranteed to be safe.
No, THE CODE IS WRONG. It is evaluating a configuration value at
_modul
On 08/07/2014 01:49 AM, Thierry Carrez wrote:
> As an ex factory IT manager, I feel compelled to comment on that :)
Multidisciplinary training rules! As an architect with field experience
building roads, sidewalks, roofs, city planning (and training in lean
manufacturing and services) I think I ca
Indeed, thanks much Eugene for taking on this critical activity.
Please let me know if I can help in any way as well.
On Thu, Aug 7, 2014 at 7:39 AM, Kyle Mestery wrote:
> On Thu, Aug 7, 2014 at 9:31 AM, Eugene Nikanorov
> wrote:
>> Hi neutron folks,
>>
>> Today should have been 'Bug squashing d
Hi all,
I have a ResourceGroup which wraps a custom resource defined in another
template:
servers:
type: OS::Heat::ResourceGroup
properties:
count: 10
resource_def:
type: my_custom_server
properties:
prop_1: "..."
prop_2:
I will be around today. I can help on bug triaging.. Catch me on IRC
(emagana)
Thank for coordinating this Eugene!
Edgar
On 8/7/14, 9:19 AM, "Akihiro Motoki" wrote:
>Thanks Eugene for initiating Neutron bug squashing day!
>I would like to focus on bug triaging and checking bug status rather
>t
On Thu, Aug 7, 2014 at 9:02 AM, John Griffith
wrote:
>
>
>
> On Thu, Aug 7, 2014 at 6:20 AM, Sean Dague wrote:
>
>> On 08/07/2014 07:58 AM, Angus Salkeld wrote:
>> > On Wed, 2014-08-06 at 15:48 -0600, John Griffith wrote:
>> >> I have to agree with Duncan here. I also don't know if I fully
>> >
On August 7, 2014 at 8:36:16 AM, Matt Wagner (matt.wag...@redhat.com) wrote:
On 07/08/14 14:17 +0200, Dmitry Tantsur wrote:
>2. We'll need to speed up spec reviews, because we're adding one more
>blocker on the way to the code being merged :) Maybe it's no longer a
>problem actually, we're doi
You said you had no idea what group based policy was buying us so I tried
to illustrate what the difference between declarative and imperative
network configuration looks like. That's the major selling point of GBP so
I'm not sure how that's 'side stepping' any points. It removes the need for
the u
On 07/08/14 17:39, Kevin L. Mitchell wrote:
> On Thu, 2014-08-07 at 17:27 +0100, Matthew Booth wrote:
>> On 07/08/14 16:27, Kevin L. Mitchell wrote:
>>> On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote:
A (the?) solution is to register_opts() in foo before importing any
modules whic
On 07/08/14 17:34, Dan Smith wrote:
>> That's different behaviour, because you can no longer pass arg=None. The
>> fix isn't to change the behaviour of the code.
>
> So use a sentinel...
That would also be a change to the behaviour of the code, because you
can no longer pass in the sentinel.
The
On 07/08/14 17:11, Kevin L. Mitchell wrote:
> On Thu, 2014-08-07 at 10:55 -0500, Matt Riedemann wrote:
>>
>> On 8/7/2014 10:27 AM, Kevin L. Mitchell wrote:
>>> On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote:
A (the?) solution is to register_opts() in foo before importing any
modul
On Thu, 2014-08-07 at 17:27 +0100, Matthew Booth wrote:
> On 07/08/14 16:27, Kevin L. Mitchell wrote:
> > On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote:
> >> A (the?) solution is to register_opts() in foo before importing any
> >> modules which might also use oslo.config.
> >
> > Actually
> That's different behaviour, because you can no longer pass arg=None. The
> fix isn't to change the behaviour of the code.
So use a sentinel...
--Dan
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@l
On 07/08/14 16:27, Kevin L. Mitchell wrote:
> On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote:
>> A (the?) solution is to register_opts() in foo before importing any
>> modules which might also use oslo.config.
>
> Actually, I disagree. The real problem here is the definition of
> bar_func
Thanks Eugene for initiating Neutron bug squashing day!
I would like to focus on bug triaging and checking bug status rather
than fixing bugs.
There seem be many bugs which are not valid anymore.
Thanks,
Akihiro
On Thu, Aug 7, 2014 at 11:31 PM, Eugene Nikanorov
wrote:
> Hi neutron folks,
>
> Tod
On Thu, 2014-08-07 at 10:55 -0500, Matt Riedemann wrote:
>
> On 8/7/2014 10:27 AM, Kevin L. Mitchell wrote:
> > On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote:
> >> A (the?) solution is to register_opts() in foo before importing any
> >> modules which might also use oslo.config.
> >
> > Ac
On 7 August 2014 16:39, John Griffith wrote:
> On Thu, Aug 7, 2014 at 9:28 AM, Eric Harney wrote:
>> On 08/07/2014 09:55 AM, John Griffith wrote:
>> > There are three things that have just crushed productivity and
>> > motivation
>> > in Cinder this release (IMO):
>> > 1. Overwhelming number of d
On 08/07/2014 03:20 PM, Russell Bryant wrote:
> On 08/07/2014 09:07 AM, Sean Dague wrote:> I think the difference is
> slot selection would just be Nova drivers. I
>> think there is an assumption in the old system that everyone in Nova
>> core wants to prioritize the blueprints. I think there are a
On 8/7/2014 10:27 AM, Kevin L. Mitchell wrote:
On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote:
A (the?) solution is to register_opts() in foo before importing any
modules which might also use oslo.config.
Actually, I disagree. The real problem here is the definition of
bar_func().
Thanks Armando,
The fix for the bug you pointed out was the reason of the failure we've
been seeing.
The follow-up patch merged and I've removed the wip status from the patch
for the full job [1]
Salvatore
[1] https://review.openstack.org/#/c/88289/
On 7 August 2014 16:50, Armando M. wrote:
On Thu, Aug 7, 2014 at 9:28 AM, Eric Harney wrote:
> On 08/07/2014 09:55 AM, John Griffith wrote:
> > Seems everybody that's been around a while has noticed "issues" this
> > release and have talked about it, thanks Thierry for putting it together
> so
> > well and kicking off the ML thread here
On 08/06/2014 05:35 PM, Yuriy Taraday wrote:
> Oh, looks like we got a bit of a race condition in messages. I hope you
> don't mind.
>
>
> On Wed, Aug 6, 2014 at 11:00 PM, Ben Nemec wrote:
>
>> On 08/06/2014 01:42 PM, Yuriy Taraday wrote:
>>> On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec
>> wrote:
On 07/08/14 14:17 +0200, Dmitry Tantsur wrote:
2. We'll need to speed up spec reviews, because we're adding one more
blocker on the way to the code being merged :) Maybe it's no longer a
problem actually, we're doing it faster now.
I'm not sure if this will actually delay stuff getting merged.
On 08/07/2014 09:55 AM, John Griffith wrote:
> Seems everybody that's been around a while has noticed "issues" this
> release and have talked about it, thanks Thierry for putting it together so
> well and kicking off the ML thread here.
>
> I'd agree with everything that you stated, I've also flo
On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote:
> A (the?) solution is to register_opts() in foo before importing any
> modules which might also use oslo.config.
Actually, I disagree. The real problem here is the definition of
bar_func(). The default value of the parameter "arg" will lik
On 07/08/14 12:15, Matthew Booth wrote:
> I'm sure this is well known, but I recently encountered this problem for
> the second time.
>
> ---
> foo:
> import oslo.config as cfg
>
> import bar
>
> CONF = cfg.CONF
> CONF.register_opts('foo_opt')
>
> ---
> bar:
> import oslo.config as cfg
>
> CON
On 08/07/2014 01:32 PM, Jan Provaznik wrote:
Hi,
by default we don't set nameserver when setting up neutron subnet used
by overcloud nodes, then nameserver points to the machine where
undercloud's dnsmasq is running.
I wonder if we should not change *default* devtest setup to allow dns
resolving
Hi Kevin,
I feel as your latest response is completely side stepping the points we
have been trying to get to in the last series of emails. At the end of the
day I don't believe we are changing the laws of networking (or perhaps we
are?). Thus I think it's important to actually get down to the ne
Hi, are you on IRC? :)
Endre
2014-08-07 12:01 GMT+02:00 Piyush Harsh :
> Dear All,
>
> Let me use my first post to this list to introduce Cyclops and initiate a
> discussion towards possibility of this platform as a future incubated
> project in OpenStack.
>
> We at Zurich university of Applied
On Thu, Aug 7, 2014 at 6:20 AM, Sean Dague wrote:
> On 08/07/2014 07:58 AM, Angus Salkeld wrote:
> > On Wed, 2014-08-06 at 15:48 -0600, John Griffith wrote:
> >> I have to agree with Duncan here. I also don't know if I fully
> >> understand the limit in options. Stress test seems like it
> >> c
Hi Salvatore,
I did notice the issue and I flagged this bug report:
https://bugs.launchpad.net/nova/+bug/1352141
I'll follow up.
Cheers,
Armando
On 7 August 2014 01:34, Salvatore Orlando wrote:
> I had to put the patch back on WIP because yesterday a bug causing a 100%
> failure rate slippe
On Thu, Aug 7, 2014 at 9:31 AM, Eugene Nikanorov
wrote:
> Hi neutron folks,
>
> Today should have been 'Bug squashing day' where we go over existing bugs
> filed for the project and triage/prioritize/comment on them.
>
> I've created an etherpad with (hopefully) full list of neutron bugs:
> https:
On 7/18/2014 2:55 AM, Daniel P. Berrange wrote:
On Thu, Jul 17, 2014 at 12:13:13PM -0700, Johannes Erdfelt wrote:
On Thu, Jul 17, 2014, Russell Bryant wrote:
On 07/17/2014 02:31 PM, Johannes Erdfelt wrote:
It kind of helps. It's still implicit in that you need to look at what
features are e
On 07/08/14 11:11, Timur Sufiev wrote:
Thanks,
now it is clear that this requirement can be safely dropped.
As I said, it's required during build time, if you execute the tests
during build.
It's not a runtime dependency; the page you were referring to is from
the build system.
Matthias
__
Hi neutron folks,
Today should have been 'Bug squashing day' where we go over existing bugs
filed for the project and triage/prioritize/comment on them.
I've created an etherpad with (hopefully) full list of neutron bugs:
https://etherpad.openstack.org/p/neutron-bug-squashing-day-2014-08-07
I wa
Oops, thanks
On 2014年08月07日 22:08, Ben Nemec wrote:
Unfortunately this is a known issue. We're working on a fix:
https://bugs.launchpad.net/oslo/+bug/1327946
On 08/07/2014 03:57 AM, Alex Xu wrote:
When I startup nova-network, it stuck at trying get lock for ebtables.
@utils.synchronized('ebt
Unfortunately this is a known issue. We're working on a fix:
https://bugs.launchpad.net/oslo/+bug/1327946
On 08/07/2014 03:57 AM, Alex Xu wrote:
> When I startup nova-network, it stuck at trying get lock for ebtables.
>
> @utils.synchronized('ebtables', external=True)
> def ensure_ebtables_rules
On Thu, Aug 7, 2014 at 7:33 AM, Anne Gentle wrote:
>
>
>
> On Thu, Aug 7, 2014 at 8:20 AM, Russell Bryant wrote:
>
>> On 08/07/2014 09:07 AM, Sean Dague wrote:> I think the difference is
>> slot selection would just be Nova drivers. I
>> > think there is an assumption in the old system that ever
On Thu, Aug 7, 2014 at 8:20 AM, Russell Bryant wrote:
> On 08/07/2014 09:07 AM, Sean Dague wrote:> I think the difference is
> slot selection would just be Nova drivers. I
> > think there is an assumption in the old system that everyone in Nova
> > core wants to prioritize the blueprints. I think
On 08/06/2014 11:51 AM, Eoghan Glynn wrote:
>
>
>> Hi everyone,
>>
>> With the incredible growth of OpenStack, our development community is
>> facing complex challenges. How we handle those might determine the
>> ultimate success or failure of OpenStack.
>>
>> With this cycle we hit new limits in
On 08/07/2014 09:07 AM, Sean Dague wrote:> I think the difference is
slot selection would just be Nova drivers. I
> think there is an assumption in the old system that everyone in Nova
> core wants to prioritize the blueprints. I think there are a bunch of
> folks in Nova core that are happy having
On 08/07/2014 08:54 AM, Russell Bryant wrote:
> On 08/07/2014 04:49 AM, Thierry Carrez wrote:
>> Stefano Maffulli wrote:
>>> On Wed 06 Aug 2014 02:10:23 PM PDT, Michael Still wrote:
- we rate limit the total number of blueprints under code review at
any one time to a fixed number of "slo
On 08/07/2014 04:49 AM, Thierry Carrez wrote:
> Stefano Maffulli wrote:
>> On Wed 06 Aug 2014 02:10:23 PM PDT, Michael Still wrote:
>>> - we rate limit the total number of blueprints under code review at
>>> any one time to a fixed number of "slots". I secretly prefer the term
>>> "runway", so I a
On 6 August 2014 18:54, Jay Pipes wrote:
> So, Liyi Meng has an interesting patch up for Nova:
>
> https://review.openstack.org/#/c/104876
>
> 1) We should just deprecate both the options, with a note in the option help
> text that these options are not used when volume size is not 0, and that the
1 - 100 of 133 matches
Mail list logo
