Hi,
As discussed in the last meeting, i had changed the POC for Quota Management in
Hierarchical Multitenancy setup. Please check the following links
Twiki Page -> https://wiki.openstack.org/wiki/POC_for_QuotaManagement#API_URLs
Code (diff) ->
https://github.com/vinodkumarboppanna/POC-For-Quo
Wow Yuriy, amazing and fast :-), benchmarks included ;-)
The daemon solution only adds 4.5ms, good work. I'll add some
comments in a while.
Recently I talked with another engineer in Red Hat (working
in ovirt/vdsm), and they have something like this daemon, and they
are using BaseMan
We're using a dedicated MongoDB instance for ceilometer and a distinct DB for
each of the Nova cells.
Tim
From: Nadya Privalova [mailto:nprival...@mirantis.com]
Sent: 20 March 2014 13:27
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer][QA
Team,
Here's what i see in the system so far.
Mentors:
ybudupi
blint
boris_42
coroner
cppcabrera
sriramhere
arnaudleg
greghaynes
hughsaunders
julim
ddutta (Organization Administrator)
dims (Organization Administrator)
Projects:
Cross-services Scheduler project. Artem Shepelev Artem Shepelev
Prop
Also, before undertaking large blueprints like this, I'd highly encourage
folks to look
at existing work in the community. The Neutron community has been working on
Group Based Policy since last fall. There was a design summit session in
Hong Kong
around this as well, and we've been meeting weekly
On Thu, Mar 20, 2014 at 5:21 AM, Kumar, Vinod (HP Networking) <
vinod.kum...@hp.com> wrote:
> Hi All,
>
>
>
> Me and my fellow friends (CCed) invite the community to review OpenStack
> Neutron Port Templates Network Policy blueprint submitted recently.
>
> Please review the same and feel free to
On 03/20/2014 01:27 PM, Nadya Privalova wrote:
> Tim, yep. If you use one db for Ceilometer and Nova then nova's
> performance may be affected.
If I understood it correctly the problem is not the higher load produced
directly by Ceilometer on the database. The problem is that the
Ceilometer comput
On 03/20/2014 08:36 AM, Mark McLoughlin wrote:
> On Thu, 2014-03-20 at 12:07 +0100, Thierry Carrez wrote:
>> Monty Taylor wrote:
>>> On 03/20/2014 01:30 AM, Radcliffe, Mark wrote:
The problem with AGPL is that the scope is very uncertain and the
determination of the consequences are very
- Original Message -
> Monty Taylor wrote:
> > On 03/20/2014 01:30 AM, Radcliffe, Mark wrote:
> >> The problem with AGPL is that the scope is very uncertain and the
> >> determination of the consequences are very fact intensive. I was the
> >> chair of the User Committee in developing the
On Tue, Mar 18, 2014 at 7:38 PM, Yuriy Taraday wrote:
> I'm aiming at ~100 new lines of code for daemon. Of course I'll use some
> batteries included with Python stdlib but they should be safe already.
> It should be rather easy to audit them.
>
Here's my take on this: https://review.openstack.o
On Thu, 2014-03-20 at 12:07 +0100, Thierry Carrez wrote:
> Monty Taylor wrote:
> > On 03/20/2014 01:30 AM, Radcliffe, Mark wrote:
> >> The problem with AGPL is that the scope is very uncertain and the
> >> determination of the consequences are very fact intensive. I was the
> >> chair of the User
On 20/03/14 09:09 +, Mark McLoughlin wrote:
On Wed, 2014-03-19 at 12:37 -0700, Devananda van der Veen wrote:
Let me start by saying that I want there to be a constructive discussion
around all this. I've done my best to keep my tone as non-snarky as I could
while still clearly stating my con
On 03/18/2014 07:19 PM, Davanum Srinivas wrote:
Dear Students,
Student application deadline is on Friday, March 21 [1]
Once you finish the application process on the Google GSoC site.
Please reply back to this thread to confirm that all the materials are
ready to review.
thanks,
dims
[1] http
Tim, yep. If you use one db for Ceilometer and Nova then nova's performance
may be affected. I've seen this issue.
Will start profiling ASAP.
On Thu, Mar 20, 2014 at 3:59 PM, Tim Bell wrote:
>
> +1 for performance analysis to understand what needs to be optimised.
> Metering should be light-wei
On Thu, 20 Mar 2014 11:51:26 +0100
Thierry Carrez wrote:
>
> I still think reverting before release is an option we should
> consider. My point is, yes we broke it back in October for people
> doing CD (and they might by now have gotten used to it), if we let
> this to release we'll then break it
+1 for performance analysis to understand what needs to be optimised. Metering
should be light-weight.
For those of us running in production, we don't have an option to turn
ceilometer off some of the time. That we are not able to run through the gate
tests hints that there are optimisations t
On Wed, 2014-03-19 at 12:37 -0700, Devananda van der Veen wrote:
> Let me start by saying that I want there to be a constructive discussion
> around all this. I've done my best to keep my tone as non-snarky as I could
> while still clearly stating my concerns. I've also spent a few hours
> reviewin
Hi,
As said here [1], please don't send review requests directly to the ML.
[1]
http://lists.openstack.org/pipermail/openstack-dev/2013-September/015264.html
2014-03-20 12:08 GMT+01:00 Kamat, Maruti Haridas :
> Hi All,
>
> Me and my fellow friends (CCed) invite the community to review OpenSt
Hello all,
I have been working on adding tests in Tempest for Marconi, for the last few
months.
While there are many amazing people to work with, the process has been more
difficult than I expected.
Couple of pain-points and suggestions to make the process easier for myself &
future contributo
On 03/20/2014 05:31 AM, Miguel Angel Ajo wrote:
On 03/19/2014 10:54 PM, Joe Gordon wrote:
On Wed, Mar 19, 2014 at 9:25 AM, Miguel Angel Ajo mailto:majop...@redhat.com>> wrote:
An advance on the changes that it's requiring to have a
py->c++ compiled rootwrap as a mitigation POC fo
Hi All,
I would like you to go through a blueprint I submitted recently and get early
comments from you, so that it covers all the use cases and anything else which
will improve the blueprint.
Link to Open Stack blueprint page
https://blueprints.launchpad.net/neutron/+spec/neutron-auditlogging
Sean, thank for analysis.
JFYI, I did some initial profiling, it's described here
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg19030.html.
On Thu, Mar 20, 2014 at 2:15 PM, Sean Dague wrote:
> On 03/20/2014 05:49 AM, Nadya Privalova wrote:
> > Hi all,
> > First of all, thank
Hi All,
Me and my fellow friends (CCed) invite the community to review OpenStack
Neutron Port Templates Framework blueprint submitted recently.
Please review the same and feel free to suggest, comment and ask questions.
Link to Open Stack blueprint page
https://blueprints.launchpad.net/neutron/+
Monty Taylor wrote:
> On 03/20/2014 01:30 AM, Radcliffe, Mark wrote:
>> The problem with AGPL is that the scope is very uncertain and the
>> determination of the consequences are very fact intensive. I was the
>> chair of the User Committee in developing the GPLv3 and I am therefor
>> quite famili
Christopher Yeoh wrote:
> The patch was merged in October (just after Icehouse opened) and so has
> been used in clouds that do CD for quite a while. After some discussion
> on IRC I think we'll end up having to leave this backwards incompatible
> change in there - given there are most likely users
Hi,
Re-architecting the schema might fix most of the performance issues of
resource_list.
And also, must do some work to improve the performance of meter-list.
Is the Gordon's blue print gonna cover the both aspects ?
https://blueprints.launchpad.net/ceilometer/+spec/big-data-sql
Samp
Hi All,
Me and my fellow friends (CCed) invite the community to review OpenStack
Neutron Port Templates Network Policy blueprint submitted recently.
Please review the same and feel free to suggest, comment and ask questions.
Link to Open Stack blueprint page
https://blueprints.launchpad.net/neut
On 03/20/2014 05:49 AM, Nadya Privalova wrote:
> Hi all,
> First of all, thanks for your suggestions!
>
> To summarize the discussions here:
> 1. We are not going to install Mongo (because "is's wrong" ?)
We are not going to install Mongo "not from base distribution", because
we don't do that for
Hi all,
First of all, thanks for your suggestions!
To summarize the discussions here:
1. We are not going to install Mongo (because "is's wrong" ?)
2. Idea about spawning several collectors is suspicious (btw there is a
patch that run several collectors: https://review.openstack.org/#/c/79962/.)
On 03/19/2014 10:54 PM, Joe Gordon wrote:
On Wed, Mar 19, 2014 at 9:25 AM, Miguel Angel Ajo mailto:majop...@redhat.com>> wrote:
An advance on the changes that it's requiring to have a
py->c++ compiled rootwrap as a mitigation POC for havana/icehouse.
https://github.com/mange
On 19/03/14 11:00 -0400, Doug Hellmann wrote:
On Wed, Mar 19, 2014 at 7:31 AM, Thierry Carrez wrote:
Kurt Griffiths wrote:
> Kudos to Balaji for working so hard on this. I really appreciate his
candid feedback on both frameworks.
Indeed, that analysis is very much appreciated.
Just out of curiosity: what is the purpose of project "warm"? From the wiki
page and the sample it looks pretty much like what Heat is doing.
And "warm" is almost "HOT" so could you imagine your use cases can just be
addressed by Heat using HOT templates?
Regards,
Thomas
sahid wrote on 18/03/201
On 03/20/2014 01:30 AM, Radcliffe, Mark wrote:
The problem with AGPL is that the scope is very uncertain and the
determination of the consequences are very fact intensive. I was the
chair of the User Committee in developing the GPLv3 and I am therefor
quite familiar with the legal issues. The i
On Wed, 19 Mar 2014, Sullivan, Jon Paul wrote:
> > From: James Slagle [mailto:james.sla...@gmail.com]
> > Sent: 18 March 2014 19:58
> > Subject: [openstack-dev] [TripleO] Alternating meeting time for more TZ
> > friendliness
> >
> > Our current meeting time is Tuesdays at 19:00 UTC. I think this
On Thu, 2014-03-20 at 01:28 +, Joshua Harlow wrote:
> Proxying from yahoo's open source director (since he wasn't initially
> subscribed to this list, afaik he now is) on his behalf.
>
> From Gil Yehuda (Yahoo’s Open Source director).
>
> I would urge you to avoid creating a dependency betwee
On Tue, 18 Mar 2014 19:52:27 +0100
"Koderer, Marc" wrote:
> > Am I missing something or are these schemas being added now just a
> > subset of what is being used for negative testing? Why can't we
> > either add the extra negative test info around the new test
> > validation patches and get the d
HI, all
cause of the Juno, the PCI discuss keen open, for group VS to
flavor/extra-information based solution. there is a use case, which
group based
solution can not supported well.
please considerate of this, and choose the flavor/extra-information
based solution.
Groups problem:
I: exposed
Hi Dims!
I have submitted my proposal to the Google GSoC site and I will upload it
to the OpenStack GSoC wiki soon.
Could you please review it for me?
Please inform me if anything else is needed.
Thank you,
Dániel Csubák (csuby)
2014-03-18 16:19 GMT+01:00 Davanum Srinivas :
> Dear Students,
>
Hi List,
I was looking at the etherpad and March 19 notes and have few Qs
1) How is the "DR middleware" (depicted in Ron's youtube video) different
than the "replication agent" (noted in the March 19 etherpad notes). Are
they same, if not, how/why are they different ?
2) Maybe a dumb Q.. but
101 - 139 of 139 matches
Mail list logo
