Sure, I can see both ways.
It's not easy to find a perfect solution, especially in opensource with such a
diverse community. How do other projects handle this? I would think the kernel
would have a similar issue, or hadoop or other diverse and large opensource
projects.
Sent from my really
On Wed, Aug 28, 2013 at 4:18 AM, Sam Alba sam.a...@gmail.com wrote:
Hi all,
We've been working hard during the last couple of weeks with some
people. Brian Waldon helped a lot designing the Glance integration and
driver testing. Dean Troyer helped a lot on bringing Docker support in
So - calling for votes for Derek to become a TripleO core reviewer!
+1
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Wed, Aug 28, 2013 at 12:45:26PM +1000, Michael Still wrote:
[Concerns over review wait times in the nova project]
I think that we're also seeing the fact that nova-core's are also
developers. nova-core members have the same feature freeze deadline,
and that means that to a certain extent
On Wed, Aug 28, 2013 at 03:43:21AM +, Joshua Harlow wrote:
Why not a rotation though, I could see it beneficial to say have a
group of active developers code for say a release then those
developers rotate to a reviewer position only (and rotate again for
every release). This allows for a
Hi,
Whilst reviewing the code I think that I have stumbled on an issue (I hope that
I am mistaken). The change set (https://review.openstack.org/#/c/35749/)
expects pci stats to be returned from the host. There are a number of issues
here that I have concern with an would like to know what the
On Wed, Aug 28, 2013 at 06:00:50PM +1000, Michael Still wrote:
On Wed, Aug 28, 2013 at 4:18 AM, Sam Alba sam.a...@gmail.com wrote:
Hi all,
We've been working hard during the last couple of weeks with some
people. Brian Waldon helped a lot designing the Glance integration and
driver
Hi folks,
We'll be have the Savanna team meeting as usual in #openstack-meeting-alt
channel.
Agenda:
https://wiki.openstack.org/wiki/Meetings/SavannaAgenda#Agenda_for_August.2C_29
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Savanna+Meetingiso=20130829T18
Sincerely yours,
Sergey
The Ceilometer project team holds a meeting in #openstack-meeting, see
https://wiki.openstack.org/wiki/Meetings/MeteringAgenda for more details.
Next meeting is on Wed Aug 28 at 2100 UTC
Please add your name with the agenda item, so we know who to call on during
the meeting.
* Review Havana-3
On 28 August 2013 21:13, Daniel P. Berrange berra...@redhat.com wrote:
On Wed, Aug 28, 2013 at 03:43:21AM +, Joshua Harlow wrote:
For a big project like nova the workload could be spread out more
like that.
I don't think any kind of rotation system like that is really
practical. Core
On Wed, Aug 28, 2013 at 10:29:23PM +1200, Robert Collins wrote:
On 28 August 2013 21:13, Daniel P. Berrange berra...@redhat.com wrote:
On Wed, Aug 28, 2013 at 03:43:21AM +, Joshua Harlow wrote:
For a big project like nova the workload could be spread out more
like that.
I don't
On 28 August 2013 22:39, Daniel P. Berrange berra...@redhat.com wrote:
No, IIUC, Joshua was suggesting that core team members spend one cycle
doing reviews only, with no coding, and then reverse for the next cycle.
That is just far too coarse/crude. Core team members need to be free to
The Rickshaw library is in the Master. Building of the reusable charts
on top of it is in the progress.
On 08/27/2013 02:51 PM, Chmouel Boudjnah wrote:
Julien Danjou jul...@danjou.info writes:
It sounds like a good plan to pick Rickshaw. Better building on top of
it, contributing back to it,
Hi,
We see a need for enhancing Swift to support a federation of swift clusters
such that a set of clusters can work as a unified namespace and allow
control over placement between the clusters. This requires multiple
extensions to swift.
To promote community inputs and work in this area, I
It seems that the main concern was that the overridden scheduler
properties are taken from the flavor, and not from the aggregate. In fact,
there was a consensus that this is not optimal.
I think that we can still make some progress in Havana towards
per-aggregate overrides, generalizing on
tl;dr at the end... I can ramble on a bit.
I agree with Daniel.
I'm not a core reviewer, but I'm trying to think like one. Over the last few
weeks I've divested myself of almost all coding tasks, instead trying to
increase the size of the community that is actively contributing to my area of
Robert Collins wrote:
So I'd like to throw two ideas into the mix.
Firstly, consider having a rota - ideally 24x5 but that will need some
more geographical coverage I suspect for many projects - of folk who
spend a dedicated time period only reviewing.
We have been doing that in the past
On Aug 28, 2013 9:42 AM, Shawn Hartsock hartso...@vmware.com wrote:
tl;dr at the end... I can ramble on a bit.
I agree with Daniel.
I'm not a core reviewer, but I'm trying to think like one. Over the last
few weeks I've divested myself of almost all coding tasks, instead trying
to increase
On 08/28/2013 05:18 AM, Daniel P. Berrange wrote:
On Wed, Aug 28, 2013 at 06:00:50PM +1000, Michael Still wrote:
On Wed, Aug 28, 2013 at 4:18 AM, Sam Alba sam.a...@gmail.com wrote:
Hi all,
We've been working hard during the last couple of weeks with some
people. Brian Waldon helped a lot
On Tue, Aug 27, 2013 at 12:30 PM, Jay Pipes jaypi...@gmail.com wrote:
On 08/27/2013 04:32 AM, Boris Pavlovic wrote:
Jay,
I should probably share to you about our work around DB.
Migrations should be run only in production and only for production
backends (e.g. psql and mysql)
In tests we
On 08/28/2013 10:58 AM, Thierry Carrez wrote:
Robert Collins wrote:
So I'd like to throw two ideas into the mix.
Firstly, consider having a rota - ideally 24x5 but that will need some
more geographical coverage I suspect for many projects - of folk who
spend a dedicated time period only
Hi,
I am not sure that there is a good solution. I guess that we all need to
'vasbyt' (that is Afrikaans for bite the bullet) and wait for the code posted
to be reviewed. In Neutron when we were heading towards the end of a cycle and
there were a ton of BP's being added the PTL would ensure
On Tue, Aug 27 2013, Thierry Carrez wrote:
Daniel P. Berrange wrote:
Is openstack looking to have a strong presence at FOSDEM 2014 ? I didn't
make it to FOSDEM this year, but IIUC, there were quite a few openstack
contributors talks in 2013.
Yes, we are aiming for a devroom again at FOSDEM
+1
On Tue, Aug 27, 2013 at 5:25 PM, Robert Collins
robe...@robertcollins.netwrote:
http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt
http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt
- Derek is reviewing fairly regularly and has got a sense of the
culture
On 08/27/2013 03:52 PM, Matt Riedemann wrote:
This change:
_https://review.openstack.org/#/c/43298/_
Is attempting to fix a bug where a tempest test fails when nova-manage
--version is different from nova-manage version when using a RHEL 6
installation rather than devstack.
Pavel points out
On 08/28/2013 05:10 AM, Daniel P. Berrange wrote:
IOW we should
prioritize review of work whose authors submitted earlier to encourage
good practice with early submission.
+1.
Can we reconfigure Gerrit to show oldest first rather than newest first
by default?
(next-review does this.
On 08/28/2013 10:31 AM, Gary Kotton wrote:
Hi,
I am not sure that there is a good solution. I guess that we all need to
'vasbyt' (that is Afrikaans for bite the bullet) and wait for the code posted
to be reviewed. In Neutron when we were heading towards the end of a cycle and
there were a ton
Shrinking that rotation granularity would be reasonable to. Rotate once every 2
weeks or some other time period still seems useful to me.
Sent from my really tiny device...
On Aug 28, 2013, at 3:43 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Wed, Aug 28, 2013 at 10:29:23PM +1200,
Thanks a lot everyone for the nice feedback. I am going to work hard
to get all those new comments addressed to be able to re-submit a new
patchset today or tomorrow (the later).
On Wed, Aug 28, 2013 at 7:02 AM, Russell Bryant rbry...@redhat.com wrote:
On 08/28/2013 05:18 AM, Daniel P. Berrange
Shawn,
If each little group had at least one active Nova core member, i think it
would speed things up way faster IMHO.
-- dims
On Wed, Aug 28, 2013 at 9:40 AM, Shawn Hartsock hartso...@vmware.comwrote:
tl;dr at the end... I can ramble on a bit.
I agree with Daniel.
I'm not a core
On 08/28/2013 10:31 AM, Gary Kotton wrote:
Hi,
I am not sure that there is a good solution. I guess that we all need to
'vasbyt' (that is Afrikaans for bite the bullet) and wait for the code posted
to be reviewed. In Neutron when we were heading towards the end of a cycle and
there were a ton
On 08/28/2013 12:25 PM, Davanum Srinivas wrote:
If each little group had at least one active Nova core member, i think
it would speed things up way faster IMHO.
Agreed, in theory. However, we should not add someone just for the sake
of having someone on the team from a certain area. They
+1000 Russell
-- dims
On Wed, Aug 28, 2013 at 1:06 PM, Russell Bryant rbry...@redhat.com wrote:
On 08/28/2013 12:25 PM, Davanum Srinivas wrote:
If each little group had at least one active Nova core member, i think
it would speed things up way faster IMHO.
Agreed, in theory. However,
The downside of doing version discovery in the client is that it adds
a third round trip... though the client can cache the support versions
I guess.
On 18 August 2013 00:14, Joshua Harlow harlo...@yahoo-inc.com wrote:
+3
Sent from my really tiny device...
On Aug 17, 2013, at 8:33 AM, Dolph
On Wed, Aug 28, 2013, Russell Bryant rbry...@redhat.com wrote:
On 08/28/2013 12:25 PM, Davanum Srinivas wrote:
If each little group had at least one active Nova core member, i think
it would speed things up way faster IMHO.
Agreed, in theory. However, we should not add someone just for
Gary
Firstly, thanks for your review very much.
The pci_stats is calculated in the resource tracker in the compute
node and is also saved in compute_node, I think currently the scheduler depends
on the information provided by the compute_node table so this method should fit
On Aug 26, 2013, at 6:14 PM, Maru Newby ma...@redhat.com wrote:
On Aug 26, 2013, at 4:06 PM, Edgar Magana emag...@plumgrid.com wrote:
Hi Developers,
Let me explain my point of view on this topic and please share your thoughts
in order to merge this new feature ASAP.
My
So I recently ran into a fun config issue in trying to configure Nova to work
w/ Ceilometer using Puppet:
https://bugs.launchpad.net/puppet-ceilometer/+bug/1217867
Today, what you need to do to make Nova work with ceilometer is add this to
your nova.conf file:
On Thu, Aug 22, 2013 at 12:29 PM, Kurt Griffiths
kurt.griffi...@rackspace.com wrote:
What was wrong with qpid, rabbitmq, activemq, zeromq, ${your favorite
queue here} that required marconi?
That's a good question. The features supported by AMQP brokers, ZMQ, and
Marconi certainly do
On Wed, Aug 28, 2013 at 9:12 AM, Alex Glikson glik...@il.ibm.com wrote:
It seems that the main concern was that the overridden scheduler
properties are taken from the flavor, and not from the aggregate. In fact,
there was a consensus that this is not optimal.
I think that we can still make
As an outsider to OOO, but a Keystone core, let me endorse Derek's work
on provioning in general. He is an outstanding developer.
On 08/28/2013 10:31 AM, James Slagle wrote:
+1
On Tue, Aug 27, 2013 at 5:25 PM, Robert Collins
robe...@robertcollins.net mailto:robe...@robertcollins.net
On Wed, Aug 28, 2013 at 12:18 PM, Duncan Thomas duncan.tho...@gmail.comwrote:
The downside of doing version discovery in the client is that it adds
a third round trip... though the client can cache the support versions
I guess.
That's only for the Identity version discovery. Add more round
On 08/28/2013 01:22 PM, Johannes Erdfelt wrote:
On Wed, Aug 28, 2013, Russell Bryant rbry...@redhat.com wrote:
On 08/28/2013 12:25 PM, Davanum Srinivas wrote:
If each little group had at least one active Nova core member, i think
it would speed things up way faster IMHO.
Agreed, in theory.
While these are useful steps in isolation, I'm hesitant to just say go for
it! because I see this as a problem that OpenStack as a whole needs to solve.
Your implementation here is a good proof-of-concept that's likely worth vetting
and then emulating elsewhere.
However looking at it a
If you look at the code in the post()[1] method of the base workflow view
you'll note that a response to a successful workflow POST is always a
redirect[2] (caveat for when it's specifically adding data back to a field,
which isn't relevant here).
The reason for this is that in general when
Salvatore,
Two problems have been found that were caused by calling empty_chain and
then failing to restore some rule in the chain that was just emptied. The
first problem found was mine in my fix to this bug.
https://bugs.launchpad.net/neutron/+bug/1209011
I filed a bug on the second
Why can't something like this be done with just different filters, see
such as for AggregateRamFilter?
Well, first, at the moment each of these filters today duplicate the code
that handles aggregate-based overrides. So, it would make sense to have it
in one place anyway. Second, why
On Wed, Aug 28, 2013 at 3:55 PM, Alex Glikson glik...@il.ibm.com wrote:
Why can't something like this be done with just different filters, see
such as for AggregateRamFilter*?*
Well, first, at the moment each of these filters today duplicate the code
that handles aggregate-based overrides.
All,
We've known for a while now that some duplication of work happened with
respect to adding multiple worker processes to the neutron-server. There
were a few mistakes made which led to three patches being done
independently of each other.
Can we settle on one and accept it?
I have changed
Joe Gordon joe.gord...@gmail.com wrote on 28/08/2013 11:04:45 PM:
Well, first, at the moment each of these filters today duplicate the
code that handles aggregate-based overrides. So, it would make sense
to have it in one place anyway. Second, why duplicating all the
filters if this can be
On Wed, Aug 28, 2013 at 4:34 PM, Alex Glikson glik...@il.ibm.com wrote:
Joe Gordon joe.gord...@gmail.com wrote on 28/08/2013 11:04:45 PM:
Well, first, at the moment each of these filters today duplicate the
code that handles aggregate-based overrides. So, it would make sense
to have it in
That said, If there is potential value in offering both, it seems like it
should
be under the control of the deployer not the user. In other words the deployer
should be able to set the default network type and enforce whether setting the
type is exposed to the user at all.
+1
From my
On 08/27/2013 04:46 PM, Sergey Lukjanov wrote:
Hi folks,
migration of all Savanna sub projects to pbr has been completed.
Please, inform us and/or create bugs for all packaging-related issues.
Thanks.
Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.
Thanks for pushing
Hello Stackers,
We would like to introduce a new project Raksha, a Data Protection As a Service
(DPaaS) for OpenStack Cloud.
Raksha's primary goal is to provide a comprehensive Data Protection for
OpenStack by leveraging Nova, Swift, Glance and Cinder. Raksha has following
key features:
1.
Hi all,
The [state-management] project team holds a weekly meeting in
#openstack-meeting on thursdays, 2000 UTC. The next meeting is tomorrow,
2013-08-29!!!
As usual, everyone is welcome :-)
Link: https://wiki.openstack.org/wiki/Meetings/StateManagement
Taskflow:
+1
On Thu, Aug 29, 2013 at 6:12 AM, Murali Balcha murali.bal...@triliodata.com
wrote:
Hello Stackers,
We would like to introduce a new project Raksha, a Data Protection As a
Service (DPaaS) for OpenStack Cloud.
Raksha’s primary goal is to provide a comprehensive Data Protection for
Hi Murali, welcome to the OpenStack community. Some comments inline...
On 08/28/2013 06:12 PM, Murali Balcha wrote:
Hello Stackers,
We would like to introduce a new project Raksha, a Data Protection As a
Service (DPaaS) for OpenStack Cloud.
Raksha’s primary goal is to provide a comprehensive
Hi stackers!
Sorry for the stupid question, but why does nova.network.neutronv2.get_client()
[1] drop auth_token for admin? Is it really necessary to make another check for
username/password when trying to get a list of ports or floating IPs?..
When keystone is configured with LDAP backed
Hi Murali, welcome to the OpenStack community. Some comments inline...
Hi Jay,
Thanks for your comments. I have been involved with OpenStack since Diablo time
frame, but mostly monitoring the traffic. Always great to be part of the
community.
My comments are inline.
On 08/28/2013 06:12
For admin, we must use admin token. In general, the token from API context
is not of role admin.
I think the BP can help
https://blueprints.launchpad.net/keystone/+spec/reuse-token
On Thu, Aug 29, 2013 at 8:12 AM, Roman Verchikov rverchi...@mirantis.comwrote:
Hi stackers!
Sorry for the
Ha! My team totally ran into the same issue. I was hoping that Padraig's
crudini would make my dreams come true but I don't think it's handling
multi-string options.
https://github.com/pixelb/crudini
So +1 to getting rid of those.
Thanks,
MATT RIEDEMANN
Advisory Software Engineer
Cloud
Dear Stackers,
I came across a proposed talk related to OpenStack on OpenStack/ OpenStack
as a Service. Couldn't recollect if there were two different talks or the
same. I am interested in learning more - could the speakers ping me offline
please?
--
Thanks,
-Sriram
Dan,
I saw you abandoned the patch because:
Using Sqlalchemy 0.8.2 or downgrading to 0.7.10 seems to fix this issue.
Given the glance requirement on SQLAlchemy:
https://github.com/openstack/glance/blob/master/requirements.txt#L9
Why were you at those levels to begin with?
Thanks,
MATT
[/me grabs popcorn and pulls up a chair to watch...]
On Wed, Aug 28, 2013 at 7:40 PM, Matt Riedemann mrie...@us.ibm.com wrote:
Ha! My team totally ran into the same issue. I was hoping that Padraig's
crudini would make my dreams come true but I don't think it's handling
multi-string
On Wed, Aug 28, 2013 at 7:22 PM, Yongsheng Gong gong...@unitedstack.comwrote:
For admin, we must use admin token. In general, the token from API
context is not of role admin.
So... because the authenticated user making the API request *may not* have
admin access, you're dropping that
Hi,
I am trying to back port the HDP scaling implementation to the 0.2 branch and
have run into a number of differences. At this point I am trying to figure out
whether what I am observing is intended or symptoms of a bug.
For a case in which I am adding one instance to an existing node
On Wed, Aug 28, 2013 at 5:22 PM, Yongsheng Gong gong...@unitedstack.comwrote:
For admin, we must use admin token. In general, the token from API
context is not of role admin.
If this functionality is supposed to be allowed to non-admin users,
wouldn't it be easier to provide access to it to
so we're in the process of selling Ceilometer to product teams so that
they'll adopt it and we'll get more funding :). one item that comes up
from product teams is 'what will Ceilometer be able to do and where does
the product takeover and add value?'
the first question is, Ceilometer
On Wed, 28 Aug 2013 09:58:48 -0400
Joe Gordon joe.gord...@gmail.com wrote:
On a related note, I really like when the developer adds a gerrit
comment saying why the revision, that makes my life as a reviewer
easier.
+1 - I try to remember to do this and from a reviewer point of view this
is
Hi,
When compared to Nova URL implementations, It is observed that the Neutron
URL support cannot be used for more than TWO levels.
Applications which want to add as PLUG-IN may be restricted with this.
We want to add support for changes required for supporting more than TWO
Levels of URL by
On Wed, 28 Aug 2013 15:56:33 +
Joshua Harlow harlo...@yahoo-inc.com wrote:
Shrinking that rotation granularity would be reasonable to. Rotate
once every 2 weeks or some other time period still seems useful to me.
I wonder if the quality of reviewing would drop if someone was doing it
all
On Wed, Aug 28, 2013 at 9:12 AM, Sam Alba sam.a...@gmail.com wrote:
Thanks a lot everyone for the nice feedback. I am going to work hard
to get all those new comments addressed to be able to re-submit a new
patchset today or tomorrow (the later).
On Wed, Aug 28, 2013 at 7:02 AM, Russell
72 matches
Mail list logo
