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
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
On Tue, Aug 5, 2014 at 9:03 AM, Thierry Carrez thie...@openstack.org
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
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 that there
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
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
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
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
On Aug 7, 2014, at 12:39 PM, Kevin L. Mitchell kevin.mitch...@rackspace.com
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
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
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.
On Aug 6, 2014, at 5:10 PM, Michael Still mi...@stillhq.com wrote:
On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez thie...@openstack.org 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)
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
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 meeting
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, Aug 7, 2014 at 10:58 PM, Yuriy Taraday yorik@gmail.com 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
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 sbaluk...@bluebox.net wrote:
Hi Brandon,
I don't think we've set a specific date to make the transition to IRC
meetings. Is there a
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
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 priorities to
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 ronak.malav.s...@gmail.com
wrote:
Hi,
Following a very interesting and vocal
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
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
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 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 carol.l.barr...@intel.com
wrote:
I want to provide the community an update on the Win The Enterprise work
group that came together
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.
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 SumitNaiksatam_ so regarding the endpoint terminology
18:36:53 SumitNaiksatam_ any suggestions?
18:36:56
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 simple
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 sumitnaiksa...@gmail.com wrote:
Ryan, point well taken. I
Edgar Magana edgar.mag...@workday.com wrote on 08/07/2014 04:37:39 PM:
From: Edgar Magana edgar.mag...@workday.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 08/07/2014 04:40 PM
Subject: Re: [openstack-dev] [Neutron][policy]
That I understand it!
Thanks for the clarification.
Edgar
From: Ryan Moats rmo...@us.ibm.commailto:rmo...@us.ibm.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, August 7, 2014 at
On Thu, Aug 7, 2014 at 12:08 PM, Kevin Benton blak...@gmail.com 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
Thierry Carrez thie...@openstack.org wrote on 08/07/2014 06:23:56 AM:
From: Thierry Carrez thie...@openstack.org
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
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) that
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
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.attribute must
always be
evaluated inside run-time code, never at module load time.
...unless
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 10:28 AM, Chris Friesen chris.frie...@windriver.com
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
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
On Thu, Aug 7, 2014 at 7:36 PM, Ben Nemec openst...@nemebean.com wrote:
On 08/06/2014 05:35 PM, Yuriy Taraday wrote:
On Wed, Aug 6, 2014 at 11:00 PM, Ben Nemec openst...@nemebean.com
wrote:
You keep mentioning detached HEAD and reflog. I have never had to deal
with either when doing a
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
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
On Fri, Aug 8, 2014 at 3:03 AM, Chris Friesen chris.frie...@windriver.com
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,
On Thu, Aug 7, 2014 at 11:20 PM, Russell Bryant rbry...@redhat.com 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
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
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?
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
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
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 it has
On 8 August 2014 10:52, Yuriy Taraday yorik@gmail.com 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
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
On 8 August 2014 02:06, Michael Still mi...@stillhq.com 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
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
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 v3.
What
Hi,
Is it possible to send a patch for review (i.e. A) on gerrit based on
multiple commit under the review (i.e. B and C)?
Based on the wiki page to add dependency these command should be used:
A-B, A-C (no dependency between B and C)
#fetch change under review and check out branch based on that
Hi,
Recently I have noticed the api-paste. ini file in heat has some very
long lines (over the popular 80c).
Wondering if there's recommended length limitation on it?
Sometime, users have to read the file and change the configuration
value, so I think it should be kept readable.
On 08/08/2014 12:12 AM, Stefano Maffulli wrote:
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
Dear Eoghan,
Thanks for your comments. Although you are correct that rating, charging,
and billing policies are commercially sensitive to the operators, still if
an operator has an openstack installation, I do not see why the stack could
not offer a service that supports ways for the operator to
On Thu, Aug 7, 2014 at 8:09 PM, Dean Troyer dtro...@gmail.com wrote:
Please respond in the usual manner, +1 or concerns.
+1, I would be happy to see Ian joining the team.
Chmouel
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
just an update: the Neutron Ryu CI is getting stable now.
please let me know if you noticed any problems. thank you.
YAMAMOTO Takashi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
Hi Nader,
Le 08/08/2014 09:23, Nader Lahouti a écrit :
Hi,
Is it possible to send a patch for review (i.e. A) on gerrit based on
multiple commit under the review (i.e. B and C)?
Based on the wiki page to add dependency these command should be used:
A-B, A-C (no dependency between B and C)
On Thu, Jul 31, 2014 at 1:43 AM, YAMAMOTO Takashi
yamam...@valinux.co.jp wrote:
On Wed, Jul 30, 2014 at 12:17 PM, YAMAMOTO Takashi
yamam...@valinux.co.jp wrote:
hi,
what's the right procedure to deprecate a plugin? we (ryu team) are
considering deprecating ryu plugin, in favor of ofagent.
Dear Andre,
I have not been an active user or IRC, but I have just now started using
it, I use the handle PH7_0 on irc://rajaniemi.freenode.net ... Tell me the
time and date and we can discuss more on cyclops.
Cheers,
Piyush.
___
Dr. Piyush Harsh, Ph.D.
i made 4 vm 1 controller, 1 network and 2 compute and i want 1 compute to
run as a storage so plz help how can i do such ?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Thu, Aug 07, 2014 at 12:01:04PM +0200, Piyush Harsh wrote:
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
Eoghan Glynn wrote:
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
On 08/08/2014 11:37 AM, Thierry Carrez wrote:
Personally I think we just need to get better at communicating the
downstream expectations, so that if we create waste, it's clearly
upstream fault rather than downstream. Currently it's the lack of
communication that makes developers produce more
On 07/08/14 18:54, Kevin L. Mitchell wrote:
On Thu, 2014-08-07 at 17:46 +0100, Matthew Booth wrote:
In any case, the operative point is that CONF.attribute must
always be
evaluated inside run-time code, never at module load time.
...unless you call register_opts() safely, which is what I'm
On 07/08/14 19:02, Kevin L. Mitchell wrote:
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
Hi,
On Tuesday, August 05, 2014 8:57 PM, Ihar Hrachyshka wrote:
Thanks. To facilitate quicker backport, you may also propose the patch
for review yourself. It may take time before stable maintainers or
other interested parties get to the bug and do cherry-pick.
I did cherry-pick for
On 08/08/2014 01:05 PM, Chmouel Boudjnah wrote:
On Thu, Aug 7, 2014 at 8:09 PM, Dean Troyer dtro...@gmail.com
mailto:dtro...@gmail.com wrote:
Please respond in the usual manner, +1 or concerns.
+1, I would be happy to see Ian joining the team.
+1
Chmouel
Hi,
Is there any way to proceed ahead the following topic?
Best Regards,
Hisashi Osanai
On Friday, August 01, 2014 7:32 PM, Hisashi Osanai wrote:
I would like to follow this discussion so I picked up points.
- There are two way to collect info from swift, one is pollster and
the other
- Original Message -
From: Thierry Carrez thie...@openstack.org
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Sent: Wednesday, August 6, 2014 4:00:35 PM
Subject: [openstack-dev] Which program for Rally
1. Rally as an essential QA tool
Performance testing (and
On 08/08/14 11:04, Matthew Booth wrote:
On 07/08/14 18:54, Kevin L. Mitchell wrote:
On Thu, 2014-08-07 at 17:46 +0100, Matthew Booth wrote:
In any case, the operative point is that CONF.attribute must
always be
evaluated inside run-time code, never at module load time.
...unless you call
Per yesterday's IRC meeting, I have updated the debug data I had collected
in the github issue @
https://github.com/csabahenk/cirros/issues/9
It has data for both :
32bit nfs client accessing 64bit cirros nfs server
64bit nfs client accessing 64bit cirros nfs server
thanx,
deepak
On Fri, 8 Aug 2014, Osanai, Hisashi wrote:
Is there any way to proceed ahead the following topic?
There are three active reviews that are somewhat related to this topic:
Use a FakeRequest object to test middleware:
https://review.openstack.org/#/c/110302/
Publish samples on other threads:
On 08/06/2014 07:54 PM, Jay Pipes wrote:
I bring this up on the mailing list because I think Liyi's patch offers
an interesting future direction to the way that we think about our retry
approach in Nova. Instead of having hard-coded or configurable interval
times, I think Liyi's approach of
Hi,
We have been struggling to get a decorator working for proposed new RBAC
functionality in ceilometer-api. We're hitting a problem where GET request
query parameters are mucked up by our decorator. Here's an example call:
curl -H X-Auth-Token:$TOKEN
On 08/07/2014 07:57 AM, Mathieu Gagné wrote:
On 2014-08-06 7:58 PM, Robert Collins wrote:
I'm astounded by this proposal - it doesn't remove the garbage
collection complexity at all - it transfers it from our code - Nova -
onto end users. So rather than one tested and consolidated
On 08/07/2014 08:06 PM, Michael Still wrote:
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
Trinath:
In looking at your FWaaS review [1], I noticed the site you are using
for log storage is being blacklisted again, at least by Cisco WSA
appliances. Thus, I cannot see the logs for it. Did you change the
location of your log storage again? Is anyone else seeing this issue?
Thanks,
Kyle
Sorry, wrong BP review link below. Here is the correct one:
https://review.openstack.org/#/c/112127/3. Please disregard the wiki link.
From: Pendergrass, Eric
Sent: Friday, August 08, 2014 6:50 AM
To: openstack-dev@lists.openstack.org
Cc: Giannetti, Fabio
Subject: [Ceilometer] Question on
Hi Li,
How are you going to make this separation transparent? I mean,
generally, in a function code, you can't know in advance if the
transaction will be read-only or it will contain an
INSERT/UPDATE/DELETE statement. On the other hand, as a developer, you
could analyze the DB queries that can be
Wrong link again, this is embarrassing :(
https://review.openstack.org/#/c/112137/3
From: Pendergrass, Eric
Sent: Friday, August 08, 2014 7:15 AM
To: openstack-dev@lists.openstack.org
Subject: RE: [Ceilometer] Question on decorators in Ceilometer pecan framework
Sorry, wrong BP review link
This thread couldn't help but make me wonder what kind of problems people
hit developing on the linux kernel.
I discovered this pretty incredible article which seemed to have enough
relevant information in it to post it, but also give me the hopes that
Openstack and it's contributors are
On Aug 8, 2014, at 12:03 AM, Li Ma skywalker.n...@gmail.com wrote:
So, I'd like to propose a transparent read/write separation method
for oslo.db that every project may happily takes advantage of it
without any code modification.
A single transaction begins, which is to emit a series of
It looks like maybe WSME or Pecan is inspecting the method signature. Have you
tried to change the order of the decorators?
On Aug 8, 2014, at 9:16, Pendergrass, Eric eric.pendergr...@hp.com wrote:
Wrong link again, this is embarrassing L
https://review.openstack.org/#/c/112137/3
From:
On 08/08/2014 01:46 AM, Luke Gorrie wrote:
On 8 August 2014 02:06, Michael Still mi...@stillhq.com
mailto:mi...@stillhq.com 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
On Fri, 8 Aug 2014, Nikola Đipanov wrote:
To me the runway approach seems like yet another set of arbitrary hoops
that we will put in place so that we don't have to tell people that we
don't have bandwidth/willingness to review and help their contribution in.
I pretty much agree with this. As
On 8 August 2014 15:27, Russell Bryant rbry...@redhat.com wrote:
It sounds like what you're working on is a separate thing.
Roger. Just wanted to check if our work could have some broader utility,
but as you say we do have a specific use case in mind.
Cheers!
-Luke
I've been looking at the implications of applying oslo.config in Swift, and I
have a question about the best pattern for registering options.
Looking at how keystone uses oslo.config, the pattern seems to be to have all
options declared and registered 'up-front' in a single place
On Thu, Aug 7, 2014 at 1:26 PM, Joe Gordon joe.gord...@gmail.com wrote:
On Tue, Aug 5, 2014 at 9:03 AM, Thierry Carrez thie...@openstack.org
wrote:
Hi everyone,
With the incredible growth of OpenStack, our development community is
facing complex challenges. How we handle those might
On Fri, Aug 8, 2014 at 4:06 AM, Thierry Carrez thie...@openstack.org wrote:
Michael Still wrote:
[...] I think an implied side effect of
the runway system is that nova-drivers would -2 blueprint reviews
which were not occupying a slot.
(If we start doing more -2's I think we will need to
On Fri, Aug 8, 2014 at 12:36 AM, Ganapathy, Sandhya
sandhya.ganapa...@hp.com wrote:
This is to discuss Bug #1231298 –
https://bugs.launchpad.net/cinder/+bug/1231298
...
Conclusion reached with this bug is that, we need to modify cinder client
in order to accept optional size parameter (as
On 08/08/2014 05:06 AM, Thierry Carrez wrote:
Michael Still wrote:
[...] I think an implied side effect of
the runway system is that nova-drivers would -2 blueprint reviews
which were not occupying a slot.
(If we start doing more -2's I think we will need to explore how to
not block on
+1
From: chandankumar
chandankumar.093...@gmail.commailto:chandankumar.093...@gmail.com
Reply-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, August 8, 2014 at 2:14 PM
To: OpenStack List
Does it make sense to move all advanced extension out of ML2, like security
group, qos...? Then we can just talk about advanced service itself, without
bothering basic neutron object (network/subnet/port)
Traditionally, SG is applied in CN, and FWaas is applied in NN (bound to L3
agent),
On Wed, Aug 6, 2014 at 5:30 AM, Thierry Carrez thie...@openstack.org
wrote:
Hi everyone,
At the TC meeting yesterday we discussed Rally program request and
incubation request. We quickly dismissed the incubation request, as
Rally appears to be able to live happily on top of OpenStack and
This came up while reviewing the fix for bug 1327406 [1]. Basically the
os-networks API behaves differently depending on your backing network
manager in nova-network.
We run Tempest in the gate with the FlatDHCPManager, which has the bug;
if you try to list networks as a non-admin user it
Thanks Matt for bringing this up/
There is a tiny start in flight here [0] - if you plan to work on providing
full testing coverage for the n-net api you may want to create a spec with
a link to an etherpad to help track / split the work.
andrea
[0] https://review.openstack.org/#/c/107552/21
On 8/8/2014 9:50 AM, Andrea Frittoli wrote:
Thanks Matt for bringing this up/
There is a tiny start in flight here [0] - if you plan to work on
providing full testing coverage for the n-net api you may want to create
a spec with a link to an etherpad to help track / split the work.
andrea
1 - 100 of 118978 matches
Mail list logo
