Re: [openstack-dev] problems in pypi.openstack.org

On 2013-07-20 10:02:34 +0800 (+0800), Gareth wrote: [...] > xattr can't be installed correctly. [...] > BTW, Swift and Glance are influenced. One of xattr's dependencies was cached in a broken state, but should be resolved as of the past couple hours. -- Jeremy Stanley __

[openstack-dev] pip requirements externally host (evil evil stab stab stab)

Hey guys! PyPI is moving towards the world of getting people to stop hosting stuff via external links. It's been bad for us in the past and one of the reasons for the existence of our mirror. pip 1.4 has an option to disallow following external links, and in 1.5 it's going to be the default behavi

Re: [openstack-dev] [Neutron] lbaas installation guide

By the way, I'm wondering if lbaas has a separate doc somewhere else? From: Anne Gentle [mailto:a...@openstack.org] Sent: Friday, July 19, 2013 6:33 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Neutron] lbaas installation guide Thanks for bringing it to the attention of the

Re: [openstack-dev] [Neutron] lbaas installation guide

Thanks Anne! From: Anne Gentle [mailto:a...@openstack.org] Sent: Friday, July 19, 2013 6:33 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Neutron] lbaas installation guide Thanks for bringing it to the attention of the list -- I've logged this doc bug. https://bugs.launchpa

Re: [openstack-dev] [nova] generate_sample.sh

Looks like it's complaining because you changed nova.conf.sample. Based on the readme: https://github.com/openstack/nova/tree/master/tools/conf Did you running ./tools/conf/analyze_opts.py? I'm assuming you need to run the tools and if there are issues you have to resolve them before pushin

[openstack-dev] problems in pypi.openstack.org

Hi https://jenkins.openstack.org/job/gate-glance-python27/4896/console xattr can't be installed correctly. And in http://pypi.openstack.org/openstack/xattr/ the xattr-0.7.1 was just updated several hours ago. Are any problems in it? BTW, Swift and Glance are influenced.

Re: [openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.

On Jul 19, 2013, at 6:01 PM, Aaron Rosen wrote: > > On Fri, Jul 19, 2013 at 3:37 PM, Ian Wells wrote: > > [arosen] - sure, in this case though then we'll have to add even more > > queries between nova-compute and quantum as nova-compute will need to query > > quantum for ports matching the devic

[openstack-dev] [Neutron] lbaas installation guide

Thanks for bringing it to the attention of the list -- I've logged this doc bug. https://bugs.launchpad.net/openstack-manuals/+bug/1203230 Hopefully a Neutron team member can pick it up and investigate. Anne On Fri, Jul 19, 2013 at 7:35 PM, Qing He wrote: > In the network installation guide(

[openstack-dev] [nova] generate_sample.sh

Hi, I have run into a problem with pep8 for https://review.openstack.org/#/c/37539/. The issue is that have run the script in the subject and the pep8 fails. Any ideas? Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://

Re: [openstack-dev] [Netron] lbaas installation guide

In the network installation guide( http://docs.openstack.org/grizzly/openstack-network/admin/content/install_ubuntu.html ) there is a sentence “quantum-lbaas-agent, etc (see below for more information about individual services agents).” in the pluggin installation section. However, lbaas is nev

Re: [openstack-dev] A simple way to improve nova scheduler

On Fri, Jul 19, 2013 at 3:13 PM, Sandy Walsh wrote: > > > On 07/19/2013 05:36 PM, Boris Pavlovic wrote: > > Sandy, > > > > I don't think that we have such problems here. > > Because scheduler doesn't pool compute_nodes. > > The situation is another compute_nodes notify scheduler about their > > st

Re: [openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.

On Fri, Jul 19, 2013 at 3:37 PM, Ian Wells wrote: > > [arosen] - sure, in this case though then we'll have to add even more > > queries between nova-compute and quantum as nova-compute will need to > query > > quantum for ports matching the device_id to see if the port was already > > created and

Re: [openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.

> [arosen] - sure, in this case though then we'll have to add even more > queries between nova-compute and quantum as nova-compute will need to query > quantum for ports matching the device_id to see if the port was already > created and if not try to create them. The cleanup job doesn't look like

Re: [openstack-dev] Moving task flow to conductor - concern about scale

I remember trying to make this argument myself about a month or 2 ago. I agree with the thought & splitting up "principle", just unsure of the timing. Taskflow (the library) I am hoping can become a useful library for making these complicates less complex. WIP of course :) Honestly I think it's

Re: [openstack-dev] [Nova] New DB column or new DB table?

The "lazy load" is , with lazy load, for example, the framework don't need fetch the PCI information if no PCI filter specified. The discussion on 'http://markmail.org/message/gxoqi6coscd2lhwo#query:+page:1+mid:7ksr6byyrpcgkqjv+state:results' gives a lot of information. --jyh From: Boris

Re: [openstack-dev] Moving task flow to conductor - concern about scale

This seems to me to be a good example where a library "problem" is leaking into the openstack architecture right? That is IMHO a bad path to go down. I like to think of a world where this isn't a problem and design the correct solution there instead and fix the eventlet problem instead. Other la

Re: [openstack-dev] A simple way to improve nova scheduler

On 07/19/2013 05:36 PM, Boris Pavlovic wrote: > Sandy, > > I don't think that we have such problems here. > Because scheduler doesn't pool compute_nodes. > The situation is another compute_nodes notify scheduler about their > state. (instead of updating their state in DB) > > So for example if

Re: [openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.

On Fri, Jul 19, 2013 at 8:47 AM, Kyle Mestery (kmestery) wrote: > On Jul 18, 2013, at 5:16 PM, Aaron Rosen wrote: > > > > Hi, > > > > I wanted to raise another design failure of why creating the port on > nova-compute is bad. Previously, we have encountered this bug ( > https://bugs.launchpad.ne

Re: [openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.

On Jul 19, 2013, at 1:58 PM, Aaron Rosen wrote: > > > > > On Fri, Jul 19, 2013 at 8:47 AM, Kyle Mestery (kmestery) > wrote: > On Jul 18, 2013, at 5:16 PM, Aaron Rosen wrote: > > > > Hi, > > > > I wanted to raise another design failure of why creating the port on > > nova-compute is bad. Pr

Re: [openstack-dev] [keystone] sqlite doesn't support migrations

Along these lines, OpenStack is now maintaining sqlachemy-migrate, and we have our first patch up for better SQLite support, taken from nova, https://review.openstack.org/#/c/37656/ Do we want to go the direction of explicitly not supporting sqllite and not running migrations with it, like keyston

Re: [openstack-dev] A simple way to improve nova scheduler

On 07/19/2013 04:25 PM, Brian Schott wrote: > I think Soren suggested this way back in Cactus to use MQ for compute > node state rather than database and it was a good idea then. The problem with that approach was the number of queues went exponential as soon as you went beyond simple flavors.

Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options.

On Fri, Jul 19, 2013 at 1:55 AM, Samuel Bercovici wrote: > Hi, > > ** ** > > I have completely missed this discussion as it does not have > quantum/Neutron in the subject (modify it now) > > I think that the security group is the right place to control this. > > I think that this migh

[openstack-dev] [Netron] Allow OVS default veth MTU to be configured.

Neutron Core Reviewers, Could you please review the following bug fix? I have refactored the test code. https://review.openstack.org/#/c/27937/ Thanks, -Jun ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cg

Re: [openstack-dev] [Nova] New DB column or new DB table?

Jiang, I would like to reduce "magic" 1) We are using already RPC (because all compute nodes update are done in DB via conductor (which means RPC call). So count of RPC calls and size of msg will be the same. 2) There is no lazy load when you have to fetch all data about all compute nodes on eve

Re: [openstack-dev] Change in openstack/neutron[master]: Add method to get iptables traffic counters

Hi Sylvain, Sorry for the slow reply, I'll have to look closer next week, but I did have some comments. 1. This isn't something a tenant should be able to do, so should be admin-only, correct? 2. I think it would be useful for an admin to be able to add metering rules for all tenants with a sing

[openstack-dev] Savanna 0.2 release details and screencast

Hello everyone! As you remember, we had 0.2 release this week and I’m really happy to do one more announcement today. We've prepared blog post for you with all new features appeared in our release. The most beautiful thing is that my colleague, Dmitry Mescheryakov made an awesome screencast wit

Re: [openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.

On Fri, Jul 19, 2013 at 1:11 PM, Kyle Mestery (kmestery) wrote: > On Jul 19, 2013, at 1:58 PM, Aaron Rosen wrote: > > > > > > > > > > On Fri, Jul 19, 2013 at 8:47 AM, Kyle Mestery (kmestery) < > kmest...@cisco.com> wrote: > > On Jul 18, 2013, at 5:16 PM, Aaron Rosen wrote: > > > > > > Hi, > > >

Re: [openstack-dev] A simple way to improve nova scheduler

Sandy, Hm I don't know that algorithm. But our approach doesn't have exponential exchange. I don't think that in 10k nodes cloud we will have a problems with 150 RPC call/sec. Even in 100k we will have only 1.5k RPC call/sec. More then (compute nodes update their state in DB through conductor whic

Re: [openstack-dev] Moving task flow to conductor - concern about scale

On Fri, Jul 19, 2013 at 4:36 PM, Joshua Harlow wrote: > This seems to me to be a good example where a library "problem" is leaking > into the openstack architecture right? That is IMHO a bad path to go down. > > I like to think of a world where this isn't a problem and design the correct > solut

Re: [openstack-dev] A simple way to improve nova scheduler

Sandy, I don't think that we have such problems here. Because scheduler doesn't pool compute_nodes. The situation is another compute_nodes notify scheduler about their state. (instead of updating their state in DB) So for example if scheduler send request to compute_node, compute_node is able to

Re: [openstack-dev] [keystone] sqlite doesn't support migrations

Hi all, We are working around adding support for sqlite into Alembic. And we will switch to Alembic in I cycle in whole OpenStack I hope. So don't touch sqlite. Joe Gordon, No we would like to merge it. Because at this moment we are able to run unit test in Nova only against SQLite. So it has cr

Re: [openstack-dev] Cinder Driver Base Requirements

Great idea, Mike. Should we have a section that describes the minimum docs for a driver? On Thu, Jul 18, 2013 at 12:20 AM, thingee wrote: > To avoid having a grid of what features are available by which drivers and > which releases, the Cinder team has met and agreed on 2013-04-24 that we > wou

[openstack-dev] [neutron] [ml2] [devstack] ML2 devstack changes for tunneling

I've pushed out a review [1] to enable support for setting additional ML2 options when running with devstack. Since H2, ML2 has now added support for both GRE and VXLAN tunnels, and the patch below allows for this configuration when running with devstack. Feedback from folks on the Neutron ML2 s

Re: [openstack-dev] Moving task flow to conductor - concern about scale

On 19 July 2013 22:55, Day, Phil wrote: > Hi Josh, > > My idea's really pretty simple - make "DB proxy" and "Task workflow" separate > services, and allow people to co-locate them if they want to. +1, for all the reasons discussed in this thread. I was weirded out when I saw non-DB-proxy work be

Re: [openstack-dev] [nova] volume affinity filter for nova scheduler

On Fri, Jul 12, 2013 at 1:57 AM, Robert Collins wrote: > On 11 July 2013 02:39, Russell Bryant wrote: > > >> We'll probably need something like this for Ironic with persistent > >> volumes on machines - yes its a rare case, but when it matters, it > >> matters a great deal. > > > > I believe you,

Re: [openstack-dev] A simple way to improve nova scheduler

On 07/19/2013 05:01 PM, Boris Pavlovic wrote: > Sandy, > > Hm I don't know that algorithm. But our approach doesn't have > exponential exchange. > I don't think that in 10k nodes cloud we will have a problems with 150 > RPC call/sec. Even in 100k we will have only 1.5k RPC call/sec. > More then

Re: [openstack-dev] Moving task flow to conductor - concern about scale

> Nova-conductor is the gateway to the database for nova-compute > processes. So permitting a single nova-conductor process would > effectively serialize all database queries during instance creation, > deletion, periodic instance refreshes, etc. FWIW, I don't think anyone is suggesting a single

Re: [openstack-dev] [Nova] New DB column or new DB table?

Hi all, We have to much different branches about scheduler (so I have to repeat here also). I am against to add some extra tables that will be joined to compute_nodes table on each scheduler request (or adding large text columns). Because it make our non scalable scheduler even less scalable. Al

Re: [openstack-dev] [Nova] New DB column or new DB table?

Boris I think you in fact covered two topic, one is if use db or rpc for communication. This has been discussed a lot. But I didn't find the conclusion. From the discussion, seems the key thing is the fan out messages. I'd suggest you to bring this to scheduler sub meeting. http://eaves

Re: [openstack-dev] A simple way to improve nova scheduler

I think Soren suggested this way back in Cactus to use MQ for compute node state rather than database and it was a good idea then. On Jul 19, 2013, at 10:52 AM, Boris Pavlovic wrote: > Hi all, > > > In Mirantis Alexey Ovtchinnikov and me are working on nova scheduler > improvements. > > A

Re: [openstack-dev] A vision for Keystone

Adam, Your essay below is outstanding! Any chance part of it could be included within the keystone project documentation? I think having it in the project and at folks fingertips would really help folks that are trying to get up to speed with keystone! Thanks again for writing this up! --B

Re: [openstack-dev] [Nova] New DB column or new DB table?

> IIUC, Ceilometer is currently a downstream consumer of data from > Nova, but no functionality in Nova is a consumer of data from > Ceilometer. This is good split from a security separation point of > view, since the security of Nova is self-contained in this > architecture. > > If Nova schedular

Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling

On 07/19/2013 12:30 PM, Sean Dague wrote: > On 07/19/2013 10:37 AM, Murray, Paul (HP Cloud Services) wrote: >> If we agree that "something like capabilities" should go through Nova, >> what do you suggest should be done with the change that sparked this >> debate: https://review.openstack.org/#/c

[openstack-dev] Host evacuation

Would it be an idea to make the host evacuation to use the scheduler to pick where the VMs are supposed to address the note http://sebastien-han.fr/blog/2013/07/19/openstack-instance-evacuation-goes-to-host/? ___ OpenStack-dev mailing list OpenStack-dev@l

Re: [openstack-dev] [Heat] Long-term, how do we make heat image/flavor name agnostic?

Gabriel, On Jul 18, 2013, at 5:18 PM, Gabriel Hurley wrote: > Generally spot-on with what Adrian said, but I have one question from that > email: > >> Mappings is one of the high level concepts in CFN that I think can be >> completely eliminated with auto-discovery. > > What do you mean by th

Re: [openstack-dev] Moving task flow to conductor - concern about scale

On Fri, Jul 19, 2013 at 10:15 AM, Dan Smith wrote: > > > So rather than asking "what doesn't work / might not work in the > > future" I think the question should be "aside from them both being > > things that could be described as a conductor - what's the > > architectural reason for wanting to ha

Re: [openstack-dev] [Keystone] Reviewers wanted: Delegated Auth a la Oauth

Hi David, I don't want to derail anything, as there are still open issues in your note; but it's worth mentioning that the session fixation attack issue you mentioned was in OAuth1.0, it was addressed in OAuth1.0a. Thanks, _ Steve Martinelli | A4-317

Re: [openstack-dev] [Nova] New DB column or new DB table?

On Thu, Jul 18, 2013 at 07:05:10AM -0400, Sean Dague wrote: > On 07/17/2013 10:54 PM, Lu, Lianhao wrote: > >Hi fellows, > > > >Currently we're implementing the BP > >https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling. > >The main idea is to have an extensible plugin framewor

[openstack-dev] A simple way to improve nova scheduler

Hi all, In Mirantis Alexey Ovtchinnikov and me are working on nova scheduler improvements. As far as we can see the problem, now scheduler has two major issues: 1) Scalability. Factors that contribute to bad scalability are these: *) Each compute node every periodic task interval (60 sec by

Re: [openstack-dev] Reminder: Oslo project meeting

On Tue, 2013-07-16 at 22:11 +0100, Mark McLoughlin wrote: > Hi > > We're having an IRC meeting on Friday to sync up again on the messaging > work going on: > > https://wiki.openstack.org/wiki/Meetings/Oslo > https://etherpad.openstack.org/HavanaOsloMessaging > > Feel free to add other topics

Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling

I think that current approach of Scheduler is not scalable and not flexible. if we add key/value this will make our scheduler flexible but with tons of hacks and less scalable. We will get a tons of problems even on small 1k nodes cloud. We found another approach (just remove DB) this will so

Re: [openstack-dev] Moving task flow to conductor - concern about scale

> -Original Message- > From: Dan Smith [mailto:d...@danplanet.com] > Sent: 19 July 2013 15:15 > To: OpenStack Development Mailing List > Cc: Day, Phil > Subject: Re: [openstack-dev] Moving task flow to conductor - concern about > scale > > > There's nothing I've seen so far that causes me

Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options.

Adding the original people conversing on this subject to this mail. Regards, -Sam. On Jul 19, 2013, at 11:57 AM, "Samuel Bercovici" mailto:samu...@radware.com>> wrote: Hi, I have completely missed this discussion as it does not have quantum/Neutron in the subject (modify it now)

Re: [openstack-dev] Moving task flow to conductor - concern about scale

On Jul 19, 2013 9:57 AM, "Day, Phil" wrote: > > > -Original Message- > > From: Dan Smith [mailto:d...@danplanet.com] > > Sent: 19 July 2013 15:15 > > To: OpenStack Development Mailing List > > Cc: Day, Phil > > Subject: Re: [openstack-dev] Moving task flow to conductor - concern about > >

[openstack-dev] [Infra] Channel logging enabled

Hi everyone, The #openstack-infra channel has been increasing in traffic and attention these past several months (hooray!). It finally became clear to us that discussions happening there were often of interest to the wider project and that we should start logging the channel. Today we added the e

Re: [openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.

On Jul 18, 2013, at 5:16 PM, Aaron Rosen wrote: > > Hi, > > I wanted to raise another design failure of why creating the port on > nova-compute is bad. Previously, we have encountered this bug > (https://bugs.launchpad.net/neutron/+bug/1160442). What was causing the issue > was that when nov

Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling

On 07/19/2013 10:37 AM, Murray, Paul (HP Cloud Services) wrote: If we agree that "something like capabilities" should go through Nova, what do you suggest should be done with the change that sparked this debate: https://review.openstack.org/#/c/35760/ I would be happy to use it or a modified v

Re: [openstack-dev] Moving task flow to conductor - concern about scale

> I had assumed that some of the task management state would exist > in memory. Is it all going to exist in the database? Well, our state is tracked in the database now, so.. yeah. There's a desire, of course, to make the state transitions as idempotent/restartable as possible, which may mean driv

Re: [openstack-dev] Moving task flow to conductor - concern about scale

On Fri, Jul 19, 2013 at 11:06 AM, Dan Smith wrote: > FWIW, I don't think anyone is suggesting a single conductor, and > especially not a single database proxy. This is a critical detail that I missed. Re-reading Phil's original email, I see you're debating the ratio of nova-conductor DB proxies t

Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling

If we agree that "something like capabilities" should go through Nova, what do you suggest should be done with the change that sparked this debate: https://review.openstack.org/#/c/35760/ I would be happy to use it or a modified version. Paul. -Original Message- From: Sean Dague [mail

Re: [openstack-dev] Moving task flow to conductor - concern about scale

> There's nothing I've seen so far that causes me alarm, but then > again we're in the very early stages and haven't moved anything > really complex. The migrations (live, cold, and resize) are moving there now. These are some of the more complex stateful operations I would expect conductor to ma

Re: [openstack-dev] KMIP client for volume encryption key management

I'm not sure that I agree with this direction. In our investigation, KMIP is a problematic protocol for several reasons: * We haven't found an implementation of KMIP for Python. (Let us know if there is one!) * Support for KMIP by HSM vendors is limited. * We haven't found software i

Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling

On 07/19/2013 08:30 AM, Andrew Laski wrote: On 07/19/13 at 12:08pm, Murray, Paul (HP Cloud Services) wrote: Hi Sean, Do you think the existing static allocators should be migrated to going through ceilometer - or do you see that as different? Ignoring backward compatibility. It makes sense to

Re: [openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.

> I wanted to raise another design failure of why creating the port on > nova-compute is bad. Previously, we have encountered this bug > (https://bugs.launchpad.net/neutron/+bug/1160442). What was causing the > issue was that when nova-compute calls into quantum to create the port; > quantum create

Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling

On 07/19/2013 09:47 AM, Day, Phil wrote: >> -Original Message- >> From: Sean Dague [mailto:s...@dague.net] >> Sent: 19 July 2013 12:04 >> To: OpenStack Development Mailing List >> Subject: Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics >> collector for scheduling (was: Ne

Re: [openstack-dev] [Nova] New DB column or new DB table?

On 07/19/2013 09:43 AM, Sandy Walsh wrote: > > > On 07/18/2013 11:12 PM, Lu, Lianhao wrote: >> Sean Dague wrote on 2013-07-18: >>> On 07/17/2013 10:54 PM, Lu, Lianhao wrote: Hi fellows, Currently we're implementing the BP https://blueprints.launchpad.net/nova/+spec/utilizat

Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling (was: New DB column or new DB table?)

> -Original Message- > From: Sean Dague [mailto:s...@dague.net] > Sent: 19 July 2013 12:04 > To: OpenStack Development Mailing List > Subject: Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics > collector for scheduling (was: New DB column or new DB table?) > > On 07/19/2013

Re: [openstack-dev] [Nova] New DB column or new DB table?

On 07/18/2013 11:12 PM, Lu, Lianhao wrote: > Sean Dague wrote on 2013-07-18: >> On 07/17/2013 10:54 PM, Lu, Lianhao wrote: >>> Hi fellows, >>> >>> Currently we're implementing the BP >>> https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling. >>> The main idea is to have >> an

Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling (was: New DB column or new DB table?)

On 07/19/13 at 07:04am, Sean Dague wrote: On 07/19/2013 06:18 AM, Day, Phil wrote: Ceilometer is a great project for taking metrics available in Nova and other systems and making them available for use by Operations, Billing, Monitoring, etc - and clearly we should try and avoid having multipl

Re: [openstack-dev] Opinions needed: Changing method signature in RPC callback ...

On 07/18/2013 05:56 PM, Eric Windisch wrote: > > > These callback methods are part of the Kombu driver (and maybe part of > > Qpid), but are NOT part of the RPC abstraction. These are private > > methods. They can be broken for external consumers of these methods, > > because the

Re: [openstack-dev] headsup - transient test failures on py26 ' cannot import name OrderedDict'

Hi guys, Both 0.0.16 and 0.0.17 seem to have a broken tests counter. It shows that 2 times more tests have been run than I actually have. Thanks, Roman On Thu, Jul 18, 2013 at 2:29 AM, David Ripton wrote: > On 07/17/2013 04:54 PM, Robert Collins wrote: > >> On 18 July 2013 08:48, Chris Jones

Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling (was: New DB column or new DB table?)

On 07/19/13 at 12:08pm, Murray, Paul (HP Cloud Services) wrote: Hi Sean, Do you think the existing static allocators should be migrated to going through ceilometer - or do you see that as different? Ignoring backward compatibility. It makes sense to keep some things in Nova, in order to handl

Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling (was: New DB column or new DB table?)

Hi Sean, Do you think the existing static allocators should be migrated to going through ceilometer - or do you see that as different? Ignoring backward compatibility. The reason I ask is I want to extend the static allocators to include a couple more. These plugins are the way I would have don

Re: [openstack-dev] [Keystone] Reviewers wanted: Delegated Auth a la Oauth

On 19/07/2013 07:10, Steve Martinelli wrote: Hi David, This email is long overdue. 1. I don't recall ever stating that we were going to use OAuth 1.0a over 2.0, or vice versa. I've checked _https://etherpad.openstack.org/havana-saml-oauth-scim_and _https://etherpad.openstack.org/havana-extern

Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling (was: New DB column or new DB table?)

On 07/19/2013 06:18 AM, Day, Phil wrote: Ceilometer is a great project for taking metrics available in Nova and other systems and making them available for use by Operations, Billing, Monitoring, etc - and clearly we should try and avoid having multiple collectors of the same data. But making

Re: [openstack-dev] Moving task flow to conductor - concern about scale

Hi Josh, My idea's really pretty simple - make "DB proxy" and "Task workflow" separate services, and allow people to co-locate them if they want to. Cheers. Phil > -Original Message- > From: Joshua Harlow [mailto:harlo...@yahoo-inc.com] > Sent: 17 July 2013 14:57 > To: OpenStack Develop

Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduler (was: New DB column or new DB table?)

On 07/18/2013 10:12 PM, Lu, Lianhao wrote: Using ceilometer as the source of those metrics was discussed in the nova-scheduler subgroup meeting. (see #topic extending data in host state in the following link). http://eavesdrop.openstack.org/meetings/scheduler/2013/scheduler.2013-04-30-15.04.log.h

Re: [openstack-dev] Moving task flow to conductor - concern about scale

> -Original Message- > From: Dan Smith [mailto:d...@danplanet.com] > Sent: 16 July 2013 14:51 > To: OpenStack Development Mailing List > Cc: Day, Phil > Subject: Re: [openstack-dev] Moving task flow to conductor - concern about > scale > > > In the original context of using Conductor as a

Re: [openstack-dev] [Openstack] [cinder] Proposal for Ollie Leahy to join cinder-core

+1 Just to add to the context - keep in mind that within HP (and I assume other large organisations such as IBM but can't speak directly from them) there are now many separate divisions working with Openstack (Public Cloud, Private Cloud Products, Labs, Consulting, etc), each bringing different

Re: [openstack-dev] [Quantum][LBaaS] Feedback needed: Healthmonitor workflow.

Hi, First want to mention that currently health monitor is not a pure DB object: upon creation the request is also send to device/driver. Another thing is that there is no delete_health_monitor in driver API (delete_pool_health_monitor only deletes the association) which is weird because potentiall

Re: [openstack-dev] [Nova] New DB column or new DB table?

Ceilometer is a great project for taking metrics available in Nova and other systems and making them available for use by Operations, Billing, Monitoring, etc - and clearly we should try and avoid having multiple collectors of the same data. But making the Nova scheduler dependent on Ceilometer

Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options.

Hi, I have completely missed this discussion as it does not have quantum/Neutron in the subject (modify it now) I think that the security group is the right place to control this. I think that this might be only allowed to admins. Let me explain what we need which is more than just disable spoof

Re: [openstack-dev] [Horizon] Navigation UX Enhancements - Collecting Issues

Hi Jeff, thanks for contribution. As long as there is no more input in gathering issues, I'll try to wrap all the problems up in BP's whiteboard and we can start designing proposals. Best -- Jarda On 2013/09/07 16:09, Walls, Jeffrey Joel (HP Converged Cloud - Cloud OS) wrote: One issue I