Re: [openstack-dev] [OpenStack][InstanceGroup] metadetails and metadata in instance_group.py

Le 11/08/2014 18:03, Gary Kotton a écrit : On 8/11/14, 6:06 PM, "Dan Smith" wrote: As the person who -2'd the review, I'm thankful you raised this issue on the ML, Jay. Much appreciated. The "metadetails" term isn't being invented in this patch, of course. I originally complained about the

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Hi Nikola, Le 12/08/2014 12:21, Nikola Đipanov a écrit : Hey Nova-istas, While I was hacking on [1] I was considering how to approach the fact that we now need to track one more thing (NUMA node utilization) in our resources. I went with - "I'll add it to compute nodes table" thinking it's a fu

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

(sorry for reposting, missed 2 links...) Hi Nikola, Le 12/08/2014 12:21, Nikola Đipanov a écrit : Hey Nova-istas, While I was hacking on [1] I was considering how to approach the fact that we now need to track one more thing (NUMA node utilization) in our resources. I went with - "I'll add it

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Le 12/08/2014 18:54, Nikola Đipanov a écrit : On 08/12/2014 04:49 PM, Sylvain Bauza wrote: (sorry for reposting, missed 2 links...) Hi Nikola, Le 12/08/2014 12:21, Nikola Đipanov a écrit : Hey Nova-istas, While I was hacking on [1] I was considering how to approach the fact that we now

Re: [openstack-dev] Openstack Capacity Planning

Le 13/08/2014 03:48, Fei Long Wang a écrit : Hi Adam, Please refer this https://wiki.openstack.org/wiki/Blazar. Hope it's helpful. Cheers. On 13/08/14 12:54, Adam Lawson wrote: Something was presented at a meeting recently which had me curious: what sort of capacity planning tools/capabilit

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Le 12/08/2014 22:06, Sylvain Bauza a écrit : Le 12/08/2014 18:54, Nikola Đipanov a écrit : On 08/12/2014 04:49 PM, Sylvain Bauza wrote: (sorry for reposting, missed 2 links...) Hi Nikola, Le 12/08/2014 12:21, Nikola Đipanov a écrit : Hey Nova-istas, While I was hacking on [1] I was

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Le 13/08/2014 12:21, Sylvain Bauza a écrit : Le 12/08/2014 22:06, Sylvain Bauza a écrit : Le 12/08/2014 18:54, Nikola Đipanov a écrit : On 08/12/2014 04:49 PM, Sylvain Bauza wrote: (sorry for reposting, missed 2 links...) Hi Nikola, Le 12/08/2014 12:21, Nikola Đipanov a écrit : Hey Nova

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Le 13/08/2014 18:40, Brian Elliott a écrit : On Aug 12, 2014, at 5:21 AM, Nikola Đipanov wrote: Hey Nova-istas, While I was hacking on [1] I was considering how to approach the fact that we now need to track one more thing (NUMA node utilization) in our resources. I went with - "I'll add it

Re: [openstack-dev] Is there a way to let nova schedule plugin fetch glance image metadata

Mmm... I can understand that you perhaps need an external scheduler for your own purposes, but I think you can't expect your plugin merged upstream for two reasons : - during Icehouse, there was an effort for not having the scheduler proxying to the compute nodes - Call for scheduler needs to go th

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Sylvain [1] https://review.openstack.org/#/c/113936/ [2] https://review.openstack.org/#/c/89893 > Thanks, > Michael > > On Thu, Aug 14, 2014 at 3:40 AM, Sylvain Bauza wrote: > > > > Le 13/08/2014 18:40, Brian Elliott a écrit : > > > >> On Aug 12, 2014, at

Re: [openstack-dev] [nova][core] Expectations of core reviewers

Le 14 août 2014 21:56, "Joe Gordon" a écrit : > > > > > On Thu, Aug 14, 2014 at 1:47 AM, Daniel P. Berrange wrote: >> >> On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote: >> > On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith wrote: >> > >> I'm not questioning the value of f2f - I'm questi

Re: [openstack-dev] [nova] Review priorities as we approach juno-3

Le 14 août 2014 22:02, "Michael Still" a écrit : > > Hi. > > We're rapidly approaching j-3, so I want to remind people of the > current reviews that are high priority. The definition of high > priority I am using here is blueprints that are marked high priority > in launchpad that have outstanding

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Le 15 août 2014 08:16, "Nikola Đipanov" a écrit : > > On 08/14/2014 10:25 PM, Sylvain Bauza wrote: > > Hi mikal, > > > > Le 14 août 2014 01:49, "Michael Still" > <mailto:mi...@stillhq.com>> a écrit : > >> > >> So, there&#

Re: [openstack-dev] [nova][core] Expectations of core reviewers

Le 18 août 2014 14:36, "Salvatore Orlando" a écrit : > > As the conversation has drifted away from a discussion pertaining the nova core team, I have some comments inline as well. > > > On 18 August 2014 12:18, Thierry Carrez wrote: >> >> Doug Hellmann wrote: >> > On Aug 13, 2014, at 4:42 PM, Rus

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Le 15/08/2014 15:35, Andrew Laski a écrit : On 08/14/2014 03:21 AM, Nikola Đipanov wrote: On 08/13/2014 06:05 PM, Sylvain Bauza wrote: Le 13/08/2014 12:21, Sylvain Bauza a écrit : Le 12/08/2014 22:06, Sylvain Bauza a écrit : Le 12/08/2014 18:54, Nikola Đipanov a écrit : On 08/12/2014 04

[openstack-dev] [Nova] Scheduler split wrt Extensible Resource Tracking

Hi, As it was also stated in http://www.stillhq.com/openstack/juno/12.html, we expect to finish the prerequisites for Scheduler split by Juno. That requires to merge two blueprints, one with the spec validated but patches still under review [1] and one with the spec still subject to debat

Re: [openstack-dev] [Nova] Scheduler split wrt Extensible Resource Tracking

Le 19/08/2014 14:51, Sylvain Bauza a écrit : Hi, As it was also stated in http://www.stillhq.com/openstack/juno/12.html, we expect to finish the prerequisites for Scheduler split by Juno. That requires to merge two blueprints, one with the spec validated but patches still under review

Re: [openstack-dev] [Nova] Scheduler split wrt Extensible Resource Tracking

Tracking On 08/19/2014 06:39 PM, Sylvain Bauza wrote: On the other hand, ERT discussion is decoupled from the scheduler split discussion and will be delayed until Extensible Resource Tracker owner (Paul Murray) is back from vacation. In the mean time, we're considering new patches usin

Re: [openstack-dev] [nova] Prioritizing review of potentially "approvable" patches

Le 21/08/2014 13:57, Daniel P. Berrange a écrit : Tagged with '[nova]' but this might be relevant data / idea for other teams too. With my code contributor hat on, one of the things that I find most the frustrating about Nova code review process is that a patch can get a +2 vote from one core t

Re: [openstack-dev] [nova] Is the BP approval process broken?

Sorry folks, I just had a new daughter since Thursday so I'm on PTO until Monday, so thanks to the people who discussed about the blueprint I created and how we can avoid the problem raised by Don for Kilo. Answers inline. Le 29/08/2014 19:42, John Garbutt a écrit : I think this is now more

Re: [openstack-dev] znc as a service (was Re: [nova] Is the BP approval process broken?)

Le 03/09/2014 14:38, Kuvaja, Erno a écrit : Another well working option that can be easily used: 1) get a Linux system with internet connection (local box, VM in a cloud, whatever floats your boat) 2) install irssi and screen 3) run irssi in a screen Now you can login (local console, ssh, teln

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

Le 04/09/2014 15:36, Gary Kotton a écrit : Hi, I do not think that Nova is in a death spiral. I just think that the current way of working at the moment is strangling the project. I do not understand why we need to split drivers out of the core project. Why not have the ability to provide Œcore

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

Le 04/09/2014 17:00, Solly Ross a écrit : My only question is about the need to separate out each virt driver into a separate project, wouldn't you accomplish a lot of the benefit by creating a single virt project that includes all of the drivers? I don't think there's particularly a *point*

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

Le 04/09/2014 17:57, Daniel P. Berrange a écrit : On Thu, Sep 04, 2014 at 03:49:26PM +, Dugger, Donald D wrote: Actually, I think Sylvain's point is even stronger as I don't think splitting the virt drivers out of Nova is a complete fix. It may solve the review latency for the virt driver

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

Le 05/09/2014 01:26, Jay Pipes a écrit : On 09/04/2014 10:33 AM, Dugger, Donald D wrote: Basically +1 with what Daniel is saying (note that, as mentioned, a side effect of our effort to split out the scheduler will help but not solve this problem). The difference between Dan's proposal and th

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

Le 05/09/2014 01:22, Michael Still a écrit : On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange wrote: [Heavy snipping because of length] The radical (?) solution to the nova core team bottleneck is thus to follow this lead and split the nova virt drivers out into separate projects and deleg

Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno

Le 05/09/2014 13:05, Nikola Đipanov a écrit : On 09/04/2014 10:25 PM, Solly Ross wrote: Anyway, I think it would be useful to have some sort of page where people could say "I'm an SME in X, ask me for reviews" and then patch submitters could go and say, "oh, I need an someone to review my patc

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

Le 05/09/2014 14:48, Jay Pipes a écrit : On 09/05/2014 02:59 AM, Sylvain Bauza wrote: Le 05/09/2014 01:26, Jay Pipes a écrit : On 09/04/2014 10:33 AM, Dugger, Donald D wrote: Basically +1 with what Daniel is saying (note that, as mentioned, a side effect of our effort to split out the

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

Le 05/09/2014 12:48, Sean Dague a écrit : On 09/05/2014 03:02 AM, Sylvain Bauza wrote: Le 05/09/2014 01:22, Michael Still a écrit : On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange wrote: [Heavy snipping because of length] The radical (?) solution to the nova core team bottleneck is

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

Le 05/09/2014 15:11, Jay Pipes a écrit : On 09/05/2014 08:58 AM, Sylvain Bauza wrote: Le 05/09/2014 14:48, Jay Pipes a écrit : On 09/05/2014 02:59 AM, Sylvain Bauza wrote: Le 05/09/2014 01:26, Jay Pipes a écrit : On 09/04/2014 10:33 AM, Dugger, Donald D wrote: Basically +1 with what Daniel

Re: [openstack-dev] [nova] [gantt] Scheduler cleanup - what did we agree to

Hi Don, Adding [nova] in the subject too, because we could miss some people here. Le 08/09/2014 07:24, Dugger, Donald D a écrit : As I mentioned in a prior email I think that, although we’re in agreement on what needs to be done before splitting out the scheduler into the Gantt project, I b

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

Le 08/09/2014 18:06, Steven Dake a écrit : On 09/05/2014 06:10 AM, Sylvain Bauza wrote: Le 05/09/2014 12:48, Sean Dague a écrit : On 09/05/2014 03:02 AM, Sylvain Bauza wrote: Le 05/09/2014 01:22, Michael Still a écrit : On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange wrote: [Heavy

Re: [openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers

Le 10/09/2014 10:44, Daniel P. Berrange a écrit : On Tue, Sep 09, 2014 at 05:14:43PM -0700, Stefano Maffulli wrote: To me, this means you don't really want a sin bin where you dump drivers and tell them not to come out until they're fit to be reviewed by the core; You want a trusted driver comm

Re: [openstack-dev] [nova] Server Groups - remove VM from group?

Le 11/09/2014 01:10, Joe Cropper a écrit : Agreed - I’ll draft up a formal proposal in the next week or two and we can focus the discussion there. Thanks for the feedback - this provides a good framework for implementation considerations. Count me on it, I'm interested in discussing the nex

Re: [openstack-dev] [gantt] Cancel the IRC meeting this week?

Le 15/09/2014 20:20, Dugger, Donald D a écrit : I’d like to propose that we defer the meeting this week and reconvene next Tues, 9/23. I don’t think there’s much new to talk about right now and we’re waiting for a write up on the claims process. I’d like to get that write up when it’s read

Re: [openstack-dev] [blazar]: proposal for a new lease type

Le 18/09/2014 15:27, Lisa a écrit : Hi all, my name is Lisa Zangrando and I work at the Italian National Institute for Nuclear Physics (INFN). In particular I am leading a team which is addressing the issue concerning the efficiency in the resource usage in OpenStack. Currently OpenStack all

[openstack-dev] [Climate] How we agree to determine that an user has admin rights ?

Hi, When reviewing https://review.openstack.org/#/c/54539/, it appeared to me that we need to make consensus on the way to know that a request is having admin creds. Currently, for implementing policies check in Climate, I'm looking at context.roles dict, which contains the unicode string 'adm

Re: [openstack-dev] [Climate] How we agree to determine that an user has admin rights ?

Le 20/11/2013 11:18, Julien Danjou a écrit : It depends on how fine grained you want your ACL to be, Then, that's policy matter to let you know if you can trust the user or not. I'm digging into http://adam.younglogic.com/2013/11/policy-enforcement-in-openstack/,great value for knowing how m

Re: [openstack-dev] [Climate] How we agree to determine that an user has admin rights ?

Hi Yuriy, Le 20/11/2013 11:56, Yuriy Taraday a écrit : Looking at implementations in Keystone and Nova, I found the only use for is_admin but it is essential. Whenever in code you need to run a piece of code with admin privileges, you can create a new context with is_admin=True keeping all

Re: [openstack-dev] [Climate] How we agree to determine that an user has admin rights ?

x27;s commit to have is_admin param to use. On Wed, Nov 20, 2013 at 3:21 PM, Sylvain Bauza <mailto:sylvain.ba...@bull.net>> wrote: Hi Yuriy, Le 20/11/2013 11:56, Yuriy Taraday a écrit : Looking at implementations in Keystone and Nova, I found the only use for is_a

Re: [openstack-dev] [Climate] How we agree to determine that an user has admin rights ?

Hi Yuriy, Dolph et al. I'm implementing a climate.policy.check_is_admin(ctx) which will look at policy.json entry 'context_is_admin' for knowing which roles do have elevated rights for Climate. This check must be called when creating a context for knowing if we can allow extra rights. The is

Re: [openstack-dev] [Climate] How we agree to determine that an user has admin rights ?

Le 21/11/2013 10:04, Yuriy Taraday a écrit : On Thu, Nov 21, 2013 at 12:37 PM, Sylvain Bauza mailto:sylvain.ba...@bull.net>> wrote: Hi Yuriy, Dolph et al. I'm implementing a climate.policy.check_is_admin(ctx) which will look at policy.json entry 'context_is_ad

[openstack-dev] [All] [Climate]Where should we define Exceptions ?

Hi, Declaring Exceptions in Openstack projects is quite straightforward and identical for most of the projects : all of them are defined in a global exception.py module called each time a specific exception must be handled. I recently received a -1 for that, so I would like to come back to th

Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

> > De : Robert Collins [robe...@robertcollins.net] > Date d'envoi : jeudi 21 novembre 2013 21:58 > À : OpenStack Development Mailing List > Objet : [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest > proposal for an external scheduler in our l

Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

As said earlier, I also would love to join the team, triggering a few blueprints or so. By the way, I'm currently reviewing the Scheduler code. Do you began to design the API queries or do you need help for that ? -Sylvain Le 25/11/2013 08:24, Haefliger, Juerg a écrit : Hi Robert, I see

[openstack-dev] [Climate] Today's meeting minutes

Hi, You can find our today's meeting minutes here : http://eavesdrop.openstack.org/meetings/climate/2013/climate.2013-11-25-09.59.html Thanks, -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin

Re: [openstack-dev] Gate broken right now

Indeed, Climate is also impacted. Is there a bug already open or shall I create one ? -Sylvain Le 26/11/2013 10:46, Chmouel Boudjnah a écrit : On Tue, Nov 26, 2013 at 9:52 AM, Flavio Percoco > wrote: This seems to be the issue you're talking about, is it?

Re: [openstack-dev] Gate broken right now

http://zuul.openstack.org/rechecks is not mentioning it by the way. Le 26/11/2013 11:32, Sylvain Bauza a écrit : Indeed, Climate is also impacted. Is there a bug already open or shall I create one ? -Sylvain Le 26/11/2013 10:46, Chmouel Boudjnah a écrit : On Tue, Nov 26, 2013 at 9:52 AM

Re: [openstack-dev] Gate broken right now

Created https://bugs.launchpad.net/openstack-ci/+bug/1255041 Le 26/11/2013 11:34, Sylvain Bauza a écrit : http://zuul.openstack.org/rechecks is not mentioning it by the way. Le 26/11/2013 11:32, Sylvain Bauza a écrit : Indeed, Climate is also impacted. Is there a bug already open or shall I

Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

Le 28/11/2013 17:04, Chris Friesen a écrit : On 11/28/2013 09:50 AM, Gary Kotton wrote: One option worth thinking about is to introduce a new scheduling driver to nova - this driver will interface with the external scheduler. This will let us define the scheduling API, model etc, without being

Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

Le 02/12/2013 18:12, Russell Bryant a écrit : On 12/02/2013 10:59 AM, Gary Kotton wrote: I think that this is certainly different. It is something that we we want and need a user facing API. Examples: - aggregates - per host scheduling - instance groups Etc. That is just taking the nova

Re: [openstack-dev] [openstack-tc] Incubation Request for Barbican

Hi Jarret, 2013/12/2 Jarret Raim > > > >It's also pretty easy for a stackforge project to opt-in to the global > >requirements sync job now too. > > Are there some docs on how to do this somewhere? I added a task for us to > complete the work as part of the incubation request here: > https://wik

Re: [openstack-dev] Tool for detecting commonly misspelled words

Great tool ! Just discovered that openstack.common.rpc does have typos, another good reason to migrate to oslo.messaging.rpc :-) -Sylvain 2013/12/3 Joe Gordon > HI all, > > Recently I have seen a few patches fixing a few typos. I would like to > point out a really nifty tool to detect commonl

Re: [openstack-dev] [openstack-tc] [barbican] Curious about oslo.messaging (from Incubation Request for Barbican)

Le 04/12/2013 06:01, John Wood a écrit : I was curious if there is an OpenStack project that would be a good example to follow as we convert Barbican over to oslo messaging. I've been examining existing OpenStack projects such as Ceilometer and Keystone to see how they are utilizing oslo messa

Re: [openstack-dev] [policy] Let's make topics mandatory for openstack-dev

Le 05/12/2013 11:03, Matthew Booth a écrit : On Thu, 2013-12-05 at 11:35 +0200, Roman Prykhodchenko wrote: Hi folks, Open Stack community grows continuously bringing more people and so new initiatives and new projects. This growing amount of people, initiatives and projects causes increasing th

[openstack-dev] [climate] IRC meeting reschedule exceptionnally today

Hi Dina, Forwarding your request to openstack-dev@ as everyone needs to be aware of that. Which time do you propose for meeting us today ? On my side, I'll be travelling tomorrow and the day after, I'll be out of office with limited access, so we need to sync up today. I can propose 2000 UTC

Re: [openstack-dev] [climate] IRC meeting reschedule exceptionnally today

aging blueprints for 0.1. Some are good, some need to be discussed, IMHO. For example, not having policies in Climate sounds a showstopper to me. -Sylvain Le 09/12/2013 10:38, Dina Belova a écrit : I think it's ok, but not more than a half of hour On Monday, December 9, 2013, Sylvain B

[openstack-dev] [climate] IRC meeting exceptionnally today 2000 UTC

else > really completed and their support doesn't blocks main functionality. It'll > be great to have them in 0.1, but I think that it's a nice to have for 0.1. > > Thanks. > > > On Mon, Dec 9, 2013 at 1:46 PM, Dina Belova wrote: > >> Ok, we'll disc

[openstack-dev] [Climate] Minutes from today meeting

Huge thanks for our Russian peers who did exceptional efforts for joining us exceptionnally today at 2000 UTC (midnight their time), I owe you a beer :-) You can find our weekly meeting minutes on http://eavesdrop.openstack.org/meetings/climate/2013/climate.2013-12-09-20.01.html Thanks, -Sylvain

Re: [openstack-dev] Unified Guest Agent proposal

Why the notifications couldn't be handled by Marconi ? That would be up to Marconi's team to handle security issues while it is part of their mission statement to deliver a messaging service in between VMs. Le 12 déc. 2013 22:09, "Fox, Kevin M" a écrit : > Yeah, I think the extra nic is unnecess

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

While I agree with most of what Thierry said, I need clarifications though, on what a Program is, and what is the key point where an idea should get its own Program instead of being headed by an already existing Program. For example, take Barbican which is providing extra features to Keystone, or

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

rry Carrez > Sylvain Bauza wrote: > > While I agree with most of what Thierry said, I need clarifications > > though, on what a Program is, > > A "team" is a group of people working on a given mission. They can be > freely created. They apply to become an &q

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

Apologies for the miss, I just double-checked and Nova does have its own mission statement : http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml Thanks, -Sylvain 2013/12/13 Sylvain Bauza > Thanks Thierry. > > AFAIK, Compute ("Nova") is not

Re: [openstack-dev] Unified Guest Agent proposal

nses from queue B. > > http is then used all the way through the process, which should make > things easy to implement and scale. > > Thanks, > Kevin > > > From: Sylvain Bauza [sylvain.ba...@gmail.com] > Sent: Thursday, Decemb

Re: [openstack-dev] [Nova][TripleO] Nested resources

Hi Kevin, 2013/12/2 Fox, Kevin M > Hi all, > > I just want to run a crazy idea up the flag pole. TripleO has the concept > of an under and over cloud. In starting to experiment with Docker, I see a > pattern start to emerge. > > * As a User, I may want to allocate a BareMetal node so that it i

Re: [openstack-dev] [Nova][TripleO] Nested resources

2013/12/9 Clint Byrum > Excerpts from Fox, Kevin M's message of 2013-12-09 09:34:06 -0800: > > I'm thinking more generic: > > > > The cloud provider will provide one or more "suballocating" images. The > one Triple O uses to take a bare metal node and make vm's available would > be the obvious on

Re: [openstack-dev] [climate] Weekly meeting accidental moving to Tuesday, 10:00 UTC

Le 16/12/2013 10:41, Dina Belova a écrit : Hello! Guys, I have no opportunity to hold our IRC meeting today. I propose to move it tomorrow, the same time. Please let me know if you are OK with that. Thank you! +2 to this. No regular meetings planned on Tuesdays 1000UTC as per https://wik

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

Le 17/12/2013 14:59, Thierry Carrez a écrit : Mark McLoughlin wrote: On Tue, 2013-12-17 at 13:44 +0100, Thierry Carrez wrote: Mark McLoughlin wrote: How about if we had an "emerging projects" page where the TC feedback on each project would be listed? That would give visibility to our feedbac

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

Le 18/12/2013 11:25, Thierry Carrez a écrit : Sylvain Bauza wrote: Well, correct me if I'm wrong, but Stackforge is already the place for promising projects ? If so, why creating a wikipage for listing them ? Not really. Any project can be in stackforge. It doesn't have to be promi

Re: [openstack-dev] Diversity as a requirement for incubation

Le 18/12/2013 11:40, Thierry Carrez a écrit : I guess there are 3 options: 1. Require diversity for incubation, but find ways to bless or recommend projects pre-incubation so that this diversity can actually be achieved 2. Do not require diversity for incubation, but require it for graduation,

Re: [openstack-dev] Diversity as a requirement for incubation

Le 18/12/2013 16:37, Steven Dake a écrit : In the early days of incubation requests, I got the distinct impression managers at companies believed that actually getting a project incubated in OpenStack was not possible, even though it was sparsely documented as an option. Maybe things are dif

[openstack-dev] [Climate] Next two weekly meetings cancelled ?

Hi team, I won't be able to attend the next two weekly meetings (23Dec and 30Dec), I would like to postpone our meetings till 6th January 2014. Any objections to this ? -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http:/

Re: [openstack-dev] [Climate] Next two weekly meetings cancelled ?

Le 19/12/2013 13:54, Sergey Lukjanov a écrit : yup, agreed. Additionally, I'd like to start a discussion about new meeting time that'd be more US-folks friendly. Luckily, we do have Internet now : http://

Re: [openstack-dev] [Climate] Next two weekly meetings cancelled ?

Le 19/12/2013 13:57, Dina Belova a écrit : I have Christmas holidays till 12th January... So I don't really know I if I will be available 6th Jan. Oh ok. Who else are still on vacation these times ? We can do our next meeting on 12th Jan, but I'm concerned with the delivery of Climate 0.1 wh

[openstack-dev] [Climate] PTL Candidacy

Hi, I hereby would like to announce my candidacy for the Climate (Reservations) PTL. A brief history about me : I'm playing with Software Engineering and Operations since more than 10 years, with a special focus on Openstack since the Essex release. I promoted Openstack in my previous compan

Re: [openstack-dev] [Climate] Next two weekly meetings cancelled ?

when I don't do my BJJ classes. Or we can move to 1900-2000UTC. it looks fine for me. Or move to early Europe morning. *__* Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2013/12/19 Sylvain Bauza <mailto:sylvain.ba...@bull.net>> Le 19/12/2

Re: [openstack-dev] [Climate] Next two weekly meetings cancelled ?

1500 UTC On Fri, Dec 20, 2013 at 1:26 PM, Sylvain Bauza mailto:sylvain.ba...@bull.net>> wrote: Well, 2000UTC means midnight for you, guys. Not really safe for family concerns :-) Maybe you were meaning 2000 local time, so 1600 UTC ?

Re: [openstack-dev] [climate] PTL electinos: voting

Hi. I know that's pretty late for asking but could we consider having a quorum for voting ? As the election is running during vacations for most of the team, my concern is to make sure there are enough voters. Thanks, Sylvain Le 25 déc. 2013 11:08, "Sergey Lukjanov" a écrit : > Hi, > > voting f

Re: [openstack-dev] [climate] PTL electinos: voting

hat someone will not be available for this period? > > Currently, we have 70% participation (poll have been started 18h ago). > > > On Thu, Dec 26, 2013 at 2:27 AM, Sylvain Bauza wrote: > >> Hi. I know that's pretty late for asking but could we consider having a >&

Re: [openstack-dev] [Openstack] Quota delegation tool (for nova) ?

Hi Ulrich, I already discussed with Tim during last Swiss meetup at CERN about how Climate could maybe help you on your use cases. There are still many things to discuss and a demo to run out so we could see if it match your needs. Basically, Climate is a new Stackforge project planning to impleme

Re: [openstack-dev] [climate] PTL elections: final results

Kudos to Dina for the PTL position. 3 vs. 5 with 80% participation means it's a good thing for Climate : this is not a Stackforge project pushed by only one sponsor and having a benevolent dictator, but rather a mix of various experiences and subprojects with people having various ideas. Now, let'

[openstack-dev] [Climate] Reminder: Meeting today at 1500 UTC

Hi folks, Please keep in mind that our weekly meeting changed its timeslot from Mondays to Fridays 1500 UTC. #openstack-meeting should be available at this time, booking it. -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http

Re: [openstack-dev] [gantt[ Patches to sync gantt up to the current nova tree

I think we should still review the patches in case of any merging issues with Gantt code. If the volume of reviews is high, then we have to increase the number of reviewers. I was part of the discussions for an external scheduler, I will dedicate some time for +1... Afaik, the current weekly meet

Re: [openstack-dev] [keystoneclient] old keystone-client package on pypi

Le 27/12/2013 10:24, Nikolay Starodubtsev a écrit : Hi all, Guys, I want to say that keystoneclient package on pypi is too old. For example it hadn't Client func in keystoneclient/client.py. May be someone can help me with this? Speaking of python-keystoneclient, the latest release is 0.4.

Re: [openstack-dev] [keystoneclient] old keystone-client package on pypi

Le 13/01/2014 13:49, Thierry Carrez a écrit : Sylvain Bauza wrote: Le 27/12/2013 10:24, Nikolay Starodubtsev a écrit : Hi all, Guys, I want to say that keystoneclient package on pypi is too old. For example it hadn't Client func in keystoneclient/client.py. May be someone can help me with

Re: [openstack-dev] [climate][cafe] Climate and Café teams meeting

I can propose anytime at 0600 UTC, I can make efforts for waking up earlier :-) I can yet understand that other EU people couldn't attend the call, so I will aggregate and feedback all the topics for my French peers. -Sylvain 2014/1/13 Nikolay Starodubtsev > Hi, all! > Guys, both our teams (C

Re: [openstack-dev] [keystoneclient] old keystone-client package on pypi

Le 13/01/2014 15:00, Dolph Mathews a écrit : Ooh, I meant to get this done last week as I agree that keystoneclient needed to see a new release, but it totally slipped my mind. python-keystoneclient 0.4.2 is now available on pypi! https://pypi.python.org/pypi/python-keystoneclient/0.4.2 What'

Re: [openstack-dev] [climate][cafe] Climate and Cafe teams meeting

;> >>> >>> Subject: Re: [openstack-dev] [climate][cafe] Climate and Caf? teams >>> >>> meeting >>> >>> Message-ID: >>> >>> < >>> cacsco2zx6wezkznbeu5040fuef91ddx27oa6nn

Re: [openstack-dev] [climate][cafe] Climate and Cafe teams meeting

One more thing, we can meet up on #openstack-climate (logging available), or we can take a room in #openstack-meeting for starting a formal meeting and get minutes. Both are convenient for me, but with a preference for #openstack-climate. -Sylvain 2014/1/14 Sylvain Bauza > OK for me too,

[openstack-dev] [Climate] 0.1 status meeting

Hi team, As agreed during our last meeting, we need to discuss on the progression before code freeze next Tuesday. I could propose tomorrow Wed 15 1000 UTC on #openstack-climate. +1/-1 to this, please. -Sylvain ___ OpenStack-dev mailing list OpenSt

Re: [openstack-dev] [gantt] Sync up patches

Thanks Don for raising the point, I was about to send an email after finishing up to review. To me, it appears I have to give -1 when either : 1. Change is related to API documentation or WSGI framework. AIUI, Gantt will be plugged to Nova thanks to its RPC interface, it makes no sense to ship any

Re: [openstack-dev] a "common" client library

Hi Doug, Count me in. Climate is currently working on delivering its first python-climateclient but it would be great if we could leverage any olso lib for this. -Sylvain 2014/1/15 Doug Hellmann > Several people have mentioned to me that they are interested in, or > actively working on, code

Re: [openstack-dev] [gantt] Sync up patches

Le 16/01/2014 17:18, Vishvananda Ishaya a écrit : On Jan 16, 2014, at 6:46 AM, Joe Gordon > wrote: On Wed, Jan 15, 2014 at 1:29 PM, Dugger, Donald D mailto:donald.d.dug...@intel.com>> wrote: My thought was to try and get some parallel effort going, do t

Re: [openstack-dev] Next steps for Whole Host allocation / Pclouds

Le 20/01/2014 16:57, Jay Pipes a écrit : On Mon, Jan 20, 2014 at 10:18 AM, Day, Phil > wrote: HI Folks, The original (and fairly simple) driver behind whole-host-allocation (https://wiki.openstack.org/wiki/WholeHostAllocation) was to enable users to

Re: [openstack-dev] Next steps for Whole Host allocation / Pclouds

Hi Jay, Le 20/01/2014 17:34, Jay Pipes a écrit : On Mon, Jan 20, 2014 at 11:18 AM, Sylvain Bauza mailto:sylvain.ba...@bull.net>> wrote: Jay, please be aware of the existence of Climate, which is a Stackforge project for managing dedicated resources (like AWS reserved ins

Re: [openstack-dev] Next steps for Whole Host allocation / Pclouds

2014/1/20 Jay Pipes > > > But I believe that the two concerns can be tackled separately. > > Indeed. I fully agree with the fact isolation can be provided by Nova, and Climate would by the way happy to leverage it for providing capacity planning on top of it. By the way, I'm personnally convicted

Re: [openstack-dev] Climate - Was: Next steps for Whole Host allocation / Pclouds

Hi Phil, Le 21/01/2014 13:13, Day, Phil a écrit : Hi Phil and Jay, Phil, maybe you remember I discussed with you about the possibility of using pclouds with Climate, but we finally ended up using Nova aggregates and a dedicated filter. That works pretty fine. We don't use instance_properties

Re: [openstack-dev] Next steps for Whole Host allocation / Pclouds

Le 21/01/2014 12:57, Day, Phil a écrit : So, I actually don't think the two concepts (reservations and "isolated instances") are competing ideas. Isolated instances are actually not reserved. They are simply instances that have a condition placed on their assignment to a particular compute node t

Re: [openstack-dev] Next steps for Whole Host allocation / Pclouds

Le 21/01/2014 15:28, Day, Phil a écrit : I think there is clear water between this and the existing aggregate based isolation. I also think this is a different use case from reservations. It's *mostly* like a new scheduler hint, but because it has billing impacts I think it needs to be more

Re: [openstack-dev] [gantt] How to include nova modules in unit tests

Hi Don, Look at how Climate is doing this [1]. The idea is to pull the master tarball as an eggfile. That works fine, the only issues we have is when we register opts to CONF where we could get DuplicateOpt if we try to register opt with same name when importing. -Sylvain [1] : https://github.c

  1   2   3   4   5   6   7   >