Re: [openstack-dev] Proposed Logging Standards

Hi Cristian, The functionality already exists within Openstack (certainly it's there in Nova) it's just not very well documented (something I keep meaning to do!) Basically you need to add the following to your nova.conf file: log_config=/etc/nova/logging.conf And then create /etc/nova/logging

Re: [openstack-dev] [Keystone] - Cloud federation on top of the Apache

On 29.01.2014 17:06, Adam Young wrote: We had a team member looking into SAML, but I don't don't know if he made that distinction. Do you think he would be willing to give a helping hand and share his expertise? Any possibility to contact your colleague? Without ECP/http clients extensions i

Re: [openstack-dev] Fwd: [TripleO] mid-cycle meetup?

I would love to attend and March should work fine for me. -- Gregory Haynes g...@greghaynes.net On Mon, Jan 27, 2014, at 01:53 AM, James Polley wrote: I'd love to come, but at this stage I won't be able to travel before about March 3, which sounds like it's a few weeks later than most peo

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

There is an unexpected line break in the middle of the link, so I post it again: https://docs.google.com/document/d/1RfP7jRsw1mXMjd7in72ARjK0fTrsQv1bqolOri IQB2Y > -Message d'origine- > De : Khanh-Toan Tran [mailto:khanh-toan.t...@cloudwatt.com] > Envoyé : mercredi 29 janvier 2014 13:25 >

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

> > Tasks which we've identified need to be done: > > 1) Convert existing networks > 2) Convert existing port allocations > 3) Convert existing security groups > 4) Convert existing security rules > 5) Convert existing floating IP allocations > Additional tasks: 6) Create routers for each network

[openstack-dev] [Nova][Scheduler] Policy Based Scheduler needs review & approvals

Dear Stackers, Ice-house 3 deadline is approaching quickly and we still need reviews & approval for Policy Based Scheduler ! So I kindly ask for your attention for this blueprint. The purpose of this blueprint is to manage the scheduling process by the policy. With it admin can define scheduling

Re: [openstack-dev] [savanna] Choosing provisioning engine during cluster launch

I agree with Andrew. I see no value in letting users select how their cluster is provisioned, it will only make interface a little bit more complex. Dmitry 2014/1/30 Andrew Lazarev > Alexander, > > What is the purpose of exposing this to user side? Both engines must do > exactly the same thing

[openstack-dev] [Nova][Scheduler] Will the Scheuler use Nova Objects?

Hi, I have heard a couple of conflicting comments about the scheduler and nova objects that I would like to clear up. In one scheduler/gantt meeting, Gary Kotton offered to convert the scheduler to use Nova objects. In another I heard that with the creation of Gantt, the scheduler would avoid u

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

Applicable Blueprints: https://blueprints.launchpad.net/neutron/+spec/nova-to-quantum-upgrade https://blueprints.launchpad.net/nova/+spec/deprecate-nova-network https://blueprints.launchpad.net/neutron/+spec/nova-network-to-neutron-recipes Previous Discussions that relate: http://www.gossamer-thre

Re: [openstack-dev] Nova style cleanups with associated hacking check addition

On Wed, Jan 29, 2014 at 01:22:59PM -0500, Joe Gordon wrote: > On Tue, Jan 28, 2014 at 4:45 AM, John Garbutt wrote: > > On 27 January 2014 10:10, Daniel P. Berrange wrote: > >> On Fri, Jan 24, 2014 at 11:42:54AM -0500, Joe Gordon wrote: > >>> On Fri, Jan 24, 2014 at 7:24 AM, Daniel P. Berrange >

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

Hi Khanh-Toan, I only have one comment on your proposal : why are you proposing something new for overcommitments with aggregates while the AggregateCoreFilter [1] and AggregateRAMFilter [2]already exist, which AIUI provide same feature ? I'm also concerned about the scope of changes for schedul

Re: [openstack-dev] [nova][ceilometer] ceilometer unit tests broke because of a nova patch

I have posted a patch in the ceilometer to temporary solve the problem, https://review.openstack.org/#/c/70073/ Similar problem ,I think we should rewrite the test with faking the object layer instead of faking db layer. -Original Message- From: Joe Gordon [mailto:joe.gord...@gmail.com]

Re: [openstack-dev] [nova][ceilometer] ceilometer unit tests broke because of a nova patch

On Thu, Jan 30 2014, Joe Gordon wrote: Hi Joe, > While looking at gate failures trying to improve our classification > rate I stumbled across this: > > http://logs.openstack.org/50/67850/5/gate/gate-ceilometer-python26/8fd55b6/console.html > > It appears that ceilometer is pulling in the nova rep

[openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support

Hi all, I've seen some confusion regarding the homogenous hardware support as the first step for the tripleo UI. I think it's time to make sure we're all on the same page. Here's what I think is not controversial: 1. Build the UI and everything underneath to work with homogenous hardware in

Re: [openstack-dev] [Ceilometer]Cumulative metrics resetting

On Thu, Jan 30 2014, Adrian Turjak wrote: > example: > 10min pipeline interval, a reset/shutdown happens 7 mins after the last > poll. The data for those 7 mins is gone. Even terminating a VM will mean we > lose the data in that last interval. If the shutdown is down properly, the nova notifier p

[openstack-dev] [Neutron][LBaaS] LBaaS subteam meeting 30.01.2014 14-00 UTC

Hi neutrons, Let's keep our usual weekly meeting at #openstack-meeting at 14-00 UTC We'll discuss current status of main features on Icehouse agenda: - SSL - LB instance - L7 rules Meeting page: https://wiki.openstack.org/wiki/Network/LBaaS Thanks, Eugene.

Re: [openstack-dev] [Neutron][LBaaS] Securing RPC channel between the server and the agent

Hi Russel, Thank for your input. I'll look into that. Thanks, Eugene. On Mon, Jan 27, 2014 at 6:57 PM, Russell Bryant wrote: > On 01/27/2014 09:37 AM, Eugene Nikanorov wrote: > > Hi folks, > > > > As we are going to add ssl implementation to lbaas which would be based > > on well-known haprox

[openstack-dev] [Heat] About LaunchConfiguration and Autoscaling

Hi all, While talking to Zane yesterday, he raised an interesting question about whether or not we want to keep a LaunchConfiguration object for the native autoscaling resources. The LaunchConfiguration object basically holds properties to be able to fire new servers in a scaling group. In the

Re: [openstack-dev] [Heat] About LaunchConfiguration and Autoscaling

Hi Thomas, I haven't looked at the details of the autoscaling design for a while, but the first option looks more intuitive to me. It seems to cover the same content as LaunchConfiguration, but is it generic and therefore would provide for one common approach for all kinds of resources. Regards,

Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support

On 01/30/2014 11:26 AM, Tomas Sedovic wrote: 1.1 Treat similar hardware configuration as equal The way I understand it is this: we use a scheduler filter that wouldn't do a strict match on the hardware in Ironic. E.g. if our baremetal flavour said 16GB ram and 1TB disk, it would also match a nod

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

Hi Sylvain, 1) Some Filters such as AggregateCoreFilter, AggregateRAMFilter can change its parameters for aggregates. But what if admin wants to change for all hosts in an availability-zone? Does he have to rewrite all the parameters in all aggregates? Or should we create a new AvailabilityZoneC

Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support

On 01/30/2014 12:39 PM, Jiří Stránský wrote: On 01/30/2014 11:26 AM, Tomas Sedovic wrote: 1.1 Treat similar hardware configuration as equal The way I understand it is this: we use a scheduler filter that wouldn't do a strict match on the hardware in Ironic. E.g. if our baremetal flavour said 16

Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

Ian, I hope that you guys are in agreement on this. But take a look at the wiki: https://wiki.openstack.org/wiki/PCI_passthrough_SRIOV_support and see if it has any difference from your proposals. IMO, it's the critical piece of the proposal, and hasn't been specified in exact term yet. I'm no

Re: [openstack-dev] [Nova][Scheduler] Will the Scheuler use Nova Objects?

Hi, I started to do the work – https://review.openstack.org/#/c/65691/. From the comments on the review it did not seem the right way to go. So I gave up on it. Sorry to not have updated. I personally think that the scheduler should use objects, the reason for this is as follows: 1. One of th

Re: [openstack-dev] [Ceilometer]Cumulative metrics resetting

On 30/01/2014 23:31, Julien Danjou wrote: On the other hand, would it be possible to setup a notification based metric that updates cumulative metrics, or triggers a poll right before the reset/shutdown/suspension/terminate, so we have an entry right before it resets and don't lose any data? Th

Re: [openstack-dev] [Ceilometer]Cumulative metrics resetting

On Thu, Jan 30 2014, Adrian Turjak wrote: > Awesome! But where in the source are they? As the only two notification > plugins that seem to exist on the compute agent are for cpu and instance. Is > there meant to be one that handles network.outgoing/incoming updates on > those VM state changes? Th

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th

On 01/30/2014 01:42 AM, Irena Berezovsky wrote: > Please see inline > > > > *From:*Ian Wells [mailto:ijw.ubu...@cack.org.uk] > *Sent:* Thursday, January 30, 2014 1:17 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [nova][neutron] PCI pas

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

On Thu, Jan 30, 2014 at 2:08 PM, Michael Still wrote: > On Thu, Jan 30, 2014 at 2:29 PM, Christopher Yeoh > wrote: > > > So if nova-network doesn't go away this has implications for the V3 API > as > > it currently doesn't support > > nova-network. I'm not sure that we have time to add support f

Re: [openstack-dev] [Neutron] Assigning a floating IP to an internal network

Hi all, During the implementation of: https://blueprints.launchpad.net/neutron/+spec/floating-ip-extra-route Which suggest allowing assignment of floating IP to internal address not directly connected to the router, if there is a route configured on the router to the internal address. In: https:

Re: [openstack-dev] [Heat] About LaunchConfiguration and Autoscaling

Excerpts from Thomas Herve's message of 2014-01-30 03:01:38 -0800: > Hi all, > > While talking to Zane yesterday, he raised an interesting question about > whether or not we want to keep a LaunchConfiguration object for the native > autoscaling resources. > > The LaunchConfiguration object basi

Re: [openstack-dev] Proposed Logging Standards

Hi Matt, What about the rest of the components? Do they also have this capability? Thanks Cristian On 30/01/14 04:59, "Macdonald-Wallace, Matthew" wrote: >Hi Cristian, > >The functionality already exists within Openstack (certainly it's there >in Nova) it's just not very well documented (somet

Re: [openstack-dev] [Nova][Scheduler] Will the Scheuler use Nova Objects?

On 01/30/14 at 04:13am, Gary Kotton wrote: Hi, I started to do the work – https://review.openstack.org/#/c/65691/. From the comments on the review it did not seem the right way to go. So I gave up on it. Sorry to not have updated. I personally think that the scheduler should use objects, the r

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

On 01/30/2014 08:10 AM, Christopher Yeoh wrote: > On Thu, Jan 30, 2014 at 2:08 PM, Michael Still > wrote: > > On Thu, Jan 30, 2014 at 2:29 PM, Christopher Yeoh > wrote: > > > So if nova-network doesn't go away this has implications

Re: [openstack-dev] Proposed Logging Standards

No idea, I only really work on Nova, but as this is in Oslo I expect so! Matt > -Original Message- > From: Sanchez, Cristian A [mailto:cristian.a.sanc...@intel.com] > Sent: 30 January 2014 13:44 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-d

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

On 01/29/2014 05:24 PM, Kyle Mestery wrote: > > On Jan 29, 2014, at 12:04 PM, Russell Bryant wrote: > >> On 01/29/2014 12:45 PM, Daniel P. Berrange wrote: >>> I was thinking of an upgrade path more akin to what users got when we >>> removed the nova volume driver, in favour of cinder. >>> >>> h

Re: [openstack-dev] [Nova][Scheduler] Will the Scheuler use Nova Objects?

2014-01-30 Andrew Laski : > On 01/30/14 at 04:13am, Gary Kotton wrote: > >> Hi, >> I started to do the work - https://review.openstack.org/#/c/65691/. From >> the comments on the review it did not seem the right way to go. So I gave >> up on it. Sorry to not have updated. I personally think that t

Re: [openstack-dev] Proposed Logging Standards

For all projects that use oslo logging (which is currently everything except swift), this works. -Sean On 01/30/2014 09:07 AM, Macdonald-Wallace, Matthew wrote: > No idea, I only really work on Nova, but as this is in Oslo I expect so! > > Matt > >> -Original Message- >> From: S

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

On Fri, Jan 31, 2014 at 12:27 AM, Russell Bryant wrote: > On 01/30/2014 08:10 AM, Christopher Yeoh wrote: > > On Thu, Jan 30, 2014 at 2:08 PM, Michael Still > > wrote: > > > > On Thu, Jan 30, 2014 at 2:29 PM, Christopher Yeoh > > wrote

Re: [openstack-dev] [savanna] Choosing provisioning engine during cluster launch

i imagine this is something that can be useful in a development and testing environment, especially during the transition period from direct to heat. so having the ability is not unreasonable, but i wouldn't expose it to users via the dashboard (maybe not even directly in the cli) generally i

Re: [openstack-dev] Proposed Logging Standards

On 01/27/2014 11:03 AM, Macdonald-Wallace, Matthew wrote: >>> I've also noticed just now that we appear to be "re-inventing" some parts of >> the logging framework (openstack.common.log.WriteableLogger for example >> appears to be a "catchall" when we should just be handing off to the default >> lo

Re: [openstack-dev] [nova]Why not allow to create a vm directly with two VIF in the same network

Vishvananda Ishaya wrote: >In testing I have been unable to saturate a 10g link using a single VM. Even >with multiple streams, >the best I have been able to do (using virtio and vhost_net is about 7.8g. Can you share details about your hardware and vSwitch config (possibly off list if that isn

Re: [openstack-dev] Proposed Logging Standards

On 01/28/2014 06:28 PM, Scott Devoid wrote: > > A big part of my interest here is to make INFO a useful informational > level for operators. That means getting a bunch of messages out of it > that don't belong. > > > +1 to that! How should I open / tag bugs for this? I'm thinking ri

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

On 01/30/2014 09:13 AM, Christopher Yeoh wrote: > > On Fri, Jan 31, 2014 at 12:27 AM, Russell Bryant I can't say in any sort of confidence that I think nova-network will go > away in the foreseeable future. Yes, this has an unfortunate big impact > on our original plan for the v3 API

[openstack-dev] [climate] New date for closest team meeting

Hi, folks! We need to choose new date for our next weekly teem meeting due to some emergency - at least two our core members (Sylvain and Swann) and usually active meeting participants will be travelling to FOSDEM tomorrow 15:00 UTC. So they'll have no opportunity to participate. Have you any pre

Re: [openstack-dev] [climate] New date for closest team meeting

Le 30/01/2014 15:33, Dina Belova a écrit : Hi, folks! We need to choose new date for our next weekly teem meeting due to some emergency - at least two our core members (Sylvain and Swann) and usually active meeting participants will be travelling to FOSDEM tomorrow 15:00 UTC. So they'll have

Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support

On 1/30/14, 5:26 AM, Tomas Sedovic wrote: > Hi all, > > I've seen some confusion regarding the homogenous hardware support as > the first step for the tripleo UI. I think it's time to make sure we're > all on the same page. > > Here's what I think is not controversial: > > 1. Build the UI and ev

Re: [openstack-dev] [climate] New date for closest team meeting

I'm ok with Tuesday 1500 UTC. We may go to #openstack-meeting-3 if we'll need. I'm pretty sure it'll be free. Horizon folks have there meeting Tuesday 1600 UTC, but I'm sure 1 hour will be enough for us :) Folks, any other ideas? Cheers, Dina On Thu, Jan 30, 2014 at 6:42 PM, Sylvain Bauza wrote

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

On 01/30/14 at 09:31am, Russell Bryant wrote: On 01/30/2014 09:13 AM, Christopher Yeoh wrote: On Fri, Jan 31, 2014 at 12:27 AM, Russell Bryant Well, it depends. If the tasks API is going to purely be an add-on, then sure, I agree. If it's a fundamental shift to the existing API, including ch

Re: [openstack-dev] [climate] New date for closest team meeting

Hi, I won't be at office before Wednesday 5. No need to switch for me, Sylvain will take my voice. FYI, I'll continue the Belgium tour after Brussel : Gent for the http://cfgmgmtcamp.eu/ 2014-01-30 Dina Belova > I'm ok with Tuesday 1500 UTC. We may go to #openstack-meeting-3 if we'll > need

[openstack-dev] [nova] bp proposal: libvirt-resize-disk-down

Greetings, A blueprint is being discussed about the disk resize down feature of libvirt driver. https://blueprints.launchpad.net/nova/+spec/libvirt-resize-disk-down The current implementation does not handle disk resize down and just skips the step during a resize down of the instance. I'm r

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

Hi all, Excellent definition of the issue at hand. The recent blueprints of policy-based-scheduler and solver-scheduler indeed highlight a possible weakness in the current design, as despite their completely independent contributions (i.e. which filters to apply per request vs. how to compute a

Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support

On 30/01/14 15:53, Matt Wagner wrote: On 1/30/14, 5:26 AM, Tomas Sedovic wrote: Hi all, I've seen some confusion regarding the homogenous hardware support as the first step for the tripleo UI. I think it's time to make sure we're all on the same page. Here's what I think is not controversial:

Re: [openstack-dev] [nova][swift] Importing Launchpad Answers in Ask OpenStack

On Wed 29 Jan 2014 01:49:04 PM CET, Swapnil Kulkarni wrote: > Getting lauchpad bus in ask.openstack would really help people and > this looks really nice.(just saw some question-answers) I was not able > to search for questions though Yes, we know, search is disabled on staging. > and (answered

[openstack-dev] [TripleO] devtest thoughts

devtest, our TripleO setup, has been rapidly evolving. We've added a fair amount of configuration options for stuff like using actual baremetal, and (soon) HA deployments by default. Also, the scripts (which the docs are generated from) are being used for both CD and CI. This is all great progress

Re: [openstack-dev] [Heat] About LaunchConfiguration and Autoscaling

On 30/01/14 06:01, Thomas Herve wrote: Hi all, While talking to Zane yesterday, he raised an interesting question about whether or not we want to keep a LaunchConfiguration object for the native autoscaling resources. The LaunchConfiguration object basically holds properties to be able to fir

[openstack-dev] Speaking at PyCON US 2014 about OpenStack?

If you're going to talk about anything related to OpenStack at PyCON US/Canada this year, please let me know. We're collecting the list of talks related to the project. Cheers, stef -- Ask and answer questions on https://ask.openstack.org ___ OpenStac

Re: [openstack-dev] [nova] bp proposal: libvirt-resize-disk-down

On Thu, 2014-01-30 at 14:59 +, sahid wrote: > > The implementation will be separated in several commits: > + Move shared utility methods to a common module: > - virt.xenapi.vm_utils._get_partitions to virt.disk.utils.get_partitions > - virt.libvirt.utils.copy_image to virt.disk.utils

Re: [openstack-dev] [nova] bp proposal: libvirt-resize-disk-down

* sahid wrote: > Greetings, > > A blueprint is being discussed about the disk resize down feature of libvirt > driver. > https://blueprints.launchpad.net/nova/+spec/libvirt-resize-disk-down > > The current implementation does not handle disk resize down and just skips the > step during a re

Re: [openstack-dev] [savanna] Choosing provisioning engine during cluster launch

My mistake, it's already there. I missed the distinction between set on startup and set per cluster. Trev On Thu, 2014-01-30 at 10:50 -0500, Trevor McKay wrote: > +1 > > How about an undocumented config? > > Trev > > On Thu, 2014-01-30 at 09:24 -0500, Matthew Farrellee wrote: > > i imagine th

Re: [openstack-dev] [savanna] Choosing provisioning engine during cluster launch

+1 How about an undocumented config? Trev On Thu, 2014-01-30 at 09:24 -0500, Matthew Farrellee wrote: > i imagine this is something that can be useful in a development and > testing environment, especially during the transition period from direct > to heat. so having the ability is not unreaso

[openstack-dev] [Ironic] PXE driver deploy issues

Hi, I have been trying to use the PXE driver along with a unreleased power and vendor passthru driver from SeaMicro to provision a node in Ironic. Has anyone successfully used the PXE driver to get the deploy image onto the node and then actually completing the deployment? I have created a depl

Re: [openstack-dev] Speaking at PyCON US 2014 about OpenStack?

On 01/30/2014 08:42 AM, Stefano Maffulli wrote: > If you're going to talk about anything related to OpenStack at PyCON > US/Canada this year, please let me know. We're collecting the list of > talks related to the project. > > Cheers, > stef > Would it be possible to start an etherpad for this? I

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

> If necessary the tasks work could be done solely as an extension, but I > would really prefer to avoid that so I'll get this ball rolling quickly. I agree that doing it as a bolt-on to v3 would be significantly less favorable than making it an integrated feature of the API. IMHO, if a server cre

Re: [openstack-dev] [Nova][Scheduler] Will the Scheuler use Nova Objects?

> I'm of the opinion that the scheduler should use objects, for all the > reasons that Nova uses objects, but that they should not be Nova > objects. Ultimately what the scheduler needs is a concept of capacity, > allocations, and locality of resources. But the way those are modeled > doesn't nee

Re: [openstack-dev] Speaking at PyCON US 2014 about OpenStack?

On Thu, Jan 30, 2014 at 11:14 AM, Anita Kuno wrote: > On 01/30/2014 08:42 AM, Stefano Maffulli wrote: > > If you're going to talk about anything related to OpenStack at PyCON > > US/Canada this year, please let me know. We're collecting the list of > > talks related to the project. > > > > Cheers

Re: [openstack-dev] [Ironic] PXE driver deploy issues

Hi Rohan, I've successfully deployed an image using Ironic+Devstack, you might want to take a look at the guideline: https://etherpad.openstack.org/p/IronicDeployDevstack After calling /v1/nodes//states/provision, my Node > "provision_state" is stuck at "deploying" and i can also see that there i

Re: [openstack-dev] [Heat] About LaunchConfiguration and Autoscaling

I favor the second option for the same reasons as Zane described, but also don't think we need a LaunchConfiguration resource. How about just adding a attribute to the resources such that the engine knows is not meant to be handled in the usual way, and instead it is really a "template" (sorry for

Re: [openstack-dev] Speaking at PyCON US 2014 about OpenStack?

On 01/30/2014 09:51 AM, Doug Hellmann wrote: > On Thu, Jan 30, 2014 at 11:14 AM, Anita Kuno wrote: > >> On 01/30/2014 08:42 AM, Stefano Maffulli wrote: >>> If you're going to talk about anything related to OpenStack at PyCON >>> US/Canada this year, please let me know. We're collecting the list o

Re: [openstack-dev] [Heat] About LaunchConfiguration and Autoscaling

Excerpts from Zane Bitter's message of 2014-01-30 07:38:38 -0800: > On 30/01/14 06:01, Thomas Herve wrote: > > Hi all, > > > > While talking to Zane yesterday, he raised an interesting question about > > whether or not we want to keep a LaunchConfiguration object for the native > > autoscaling re

Re: [openstack-dev] OpenStack python clients libraries release process

Tiago Mello wrote: > Thanks for the answer! We are working on the > https://blueprints.launchpad.net/python-glanceclient/+spec/cross-service-request-id > and we were wondering what is the timing for getting a new version of > the client and bump the version in nova requirements.txt... In that case

Re: [openstack-dev] [nova][ceilometer] ceilometer unit tests broke because of a nova patch

It's also worth pointing out a related side effect of that choice... http://logs.openstack.org/14/68714/3/gate/gate-ceilometer-python27/dc7e987/console.html#_2014-01-30_15_57_30_413 > Uploads of branch tarballs are not stable and they're also not atomic. If your job tries to retrieve that tarbal

Re: [openstack-dev] [Heat] About LaunchConfiguration and Autoscaling

On Jan 30, 2014, at 12:09 PM, Clint Byrum wrote: > Excerpts from Zane Bitter's message of 2014-01-30 07:38:38 -0800: >> On 30/01/14 06:01, Thomas Herve wrote: >>> Hi all, >>> >>> While talking to Zane yesterday, he raised an interesting question about >>> whether or not we want to keep a Launc

Re: [openstack-dev] [nova]Why not allow to create a vm directly with two VIF in the same network

On Jan 30, 2014, at 6:26 AM, CARVER, PAUL wrote: > Vishvananda Ishaya wrote: > > >In testing I have been unable to saturate a 10g link using a single VM. Even > >with multiple streams, > >the best I have been able to do (using virtio and vhost_net is about 7.8g. > > Can you share details ab

Re: [openstack-dev] [oslo] VMware tools in oslo-incubator or straight to oslo.vmware

This library is highly specific to VMware drivers in OpenStack and not a generic VMware API client. As Doug mentioned, this library won't be useful outside OpenStack. Also, it has some dependencies on openstack.common code as well. Therefore it makes sense if we make this code as part of OSLO.

Re: [openstack-dev] Hierarchicical Multitenancy Discussion

Vish, Excellent idea to discuss this more widely. To your point about domains not being well understood and that most policy files being just "admin or not", the exception here is, of course, keystone itself - where we can use domains to support enable various levels of cloud/domain & project

Re: [openstack-dev] [Heat] About LaunchConfiguration and Autoscaling

The reuse case can be handled via using a nested Stack. The scaled_resource type property would allow that to happen in the first arrangement. I don't think you can specify a resource type/nested stack with a LaunchConfig which makes it much less preferable I think. So its less flexible and more

Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support

As far as nova-scheduler and Ironic go, I believe this is a solved problem. Steps are: - enroll hardware with proper specs (CPU, RAM, disk, etc) - create flavors based on hardware specs - scheduler filter matches requests exactly There are, I suspect, three areas where this would fall short today:

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

It is really good we are reviving the conversation we started during the last summit in Hongkong during one of the scheduler sessions called “Smart resource placement”. This is the document we used to discuss during the session. Probably you may have seen this before: https://docs.google.com/

Re: [openstack-dev] Proposed Logging Standards

Is there any technical reason of why Swift does not use oslo logging? If not, I can work on incorporating that to Swift. Thanks Cristian On 30/01/14 11:12, "Sean Dague" wrote: >For all projects that use oslo logging (which is currently everything >except swift), this works. > > -Sean > >

Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support

Wouldn't lying about the hardware specs when registering nodes be problematic for upgrades? Users would have to re-register their nodes. One reason why a custom filter feels attractive is that it provides us with a clear upgrade path: Icehouse * nodes are registered with correct attributes

Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2100 UTC is 1 PM Pacific. :-) Den 29/01/2014 17.01 skrev "Vishvananda Ishaya" : > I apologize for the confusion. The Wiki time of 2100 UTC is the correct > time (Noon Pacific time). We can move tne next meeting to a different > day/time that is more convienient for Europe. > > Vish > > > On Jan 29

Re: [openstack-dev] [climate] New date for closest team meeting

Hi, all! Only evening that I can spend out of gym is Friday. :( But, I think that everything will be okay if I skip 1 meeting. Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2014-01-30 Swann Croiset : > Hi, > > I won't be at office before Wednesday 5. > > No

Re: [openstack-dev] Hierarchicical Multitenancy Discussion

Thanks Soren, you are correct! Yay Timezones Vish On Jan 30, 2014, at 10:39 AM, Soren Hansen wrote: > 2100 UTC is 1 PM Pacific. :-) > > Den 29/01/2014 17.01 skrev "Vishvananda Ishaya" : > I apologize for the confusion. The Wiki time of 2100 UTC is the correct time > (Noon Pacific time). We ca

Re: [openstack-dev] [nova] bp proposal: libvirt-resize-disk-down

> For metering/usage purposes, does the old size of ephemeral disk > continue to be shown in usage records, or does the size of the disk in > the newly-selected instance type (flavor) get used? If the former, then > this would be an avenue for users to Get more disk space than they are > paying for

Re: [openstack-dev] Hierarchicical Multitenancy Discussion

That's why I love this site: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140130T2100 On Thu, Jan 30, 2014 at 1:46 PM, Vishvananda Ishaya wrote: > Thanks Soren, you are correct! Yay Timezones > > Vish > > On Jan 30, 2014, at 10:39 AM, Soren Hansen wrote: > > 2100 UTC is 1 PM Pacif

Re: [openstack-dev] [nova] bp proposal: libvirt-resize-disk-down

> In case it hasn't been considered yet, shrinking a filesystem can result > in terrible fragmentation. The block allocator in resize2fs does not do > a great job of handling this case. The result will be a very > non-optimal file layout and measurably worse performance, especially for > drives w

Re: [openstack-dev] [TripleO] devtest thoughts

On 2014-01-30 09:28, James Slagle wrote: devtest, our TripleO setup, has been rapidly evolving. We've added a fair amount of configuration options for stuff like using actual baremetal, and (soon) HA deployments by default. Also, the scripts (which the docs are generated from) are being used for

Re: [openstack-dev] [Heat] How to model resources in Heat

Zane Thanks for putting this together. This will guide us as we develop some resources in Heat. As chmouel said it would be great if this can be converted to blog article. thanks prasadv On Wed, Jan 29, 2014 at 11:09 PM, Chmouel Boudjnah wrote: > Zane Bitter writes: > > > As I said, figuring t

Re: [openstack-dev] [TripleO] devtest thoughts

Excerpts from Ben Nemec's message of 2014-01-30 11:08:44 -0800: > On 2014-01-30 09:28, James Slagle wrote: > > devtest, our TripleO setup, has been rapidly evolving. We've added a > > fair amount of configuration options for stuff like using actual > > baremetal, and (soon) HA deployments by defaul

Re: [openstack-dev] [TripleO] devtest thoughts

Excerpts from James Slagle's message of 2014-01-30 07:28:01 -0800: > devtest, our TripleO setup, has been rapidly evolving. We've added a > fair amount of configuration options for stuff like using actual > baremetal, and (soon) HA deployments by default. Also, the scripts > (which the docs are gen

[openstack-dev] [savanna] Alembic migrations and absence of DROP column in sqlite

I was playing with alembic migration and discovered that op.drop_column() doesn't work with sqlite. This is because sqlite doesn't support dropping a column (broken imho, but that's another discussion). Sqlite throws a syntax error. To make this work with sqlite, you have to copy the table to a

Re: [openstack-dev] [savanna] Alembic migrations and absence of DROP column in sqlite

On Thu, 2014-01-30 at 14:51 -0500, Trevor McKay wrote: > I was playing with alembic migration and discovered that > op.drop_column() doesn't work with sqlite. This is because sqlite > doesn't support dropping a column (broken imho, but that's another > discussion). Sqlite throws a syntax error. >

[openstack-dev] [savanna] team meeting minutes Jan 30

Thanks everyone who have joined Savanna meeting. Here are the logs from the meeting: Minutes: http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-01-30-18.05.html Log: http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-01-30-18.05.log.html Regards, Alexander Ignato

Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support

On 30 January 2014 23:26, Tomas Sedovic wrote: > Hi all, > > I've seen some confusion regarding the homogenous hardware support as the > first step for the tripleo UI. I think it's time to make sure we're all on > the same page. > > Here's what I think is not controversial: > > 1. Build the UI and

Re: [openstack-dev] Speaking at PyCON US 2014 about OpenStack?

Paul Kehrer and I are talking about the state of crypto in Python. The talk isn't specifically about OpenStack, but we will be talking about various OpenStack related issues including the Barbican service. Thanks, Jarret On 1/30/14, 11:05 AM, "Anita Kuno" wrote: >On 01/30/2014 09:51 AM, Dou

Re: [openstack-dev] [Heat] How to model resources in Heat

On Wed, Jan 29, 2014 at 5:03 PM, Zane Bitter wrote: > On 29/01/14 19:40, Jay Pipes wrote: > >> On Wed, 2014-01-29 at 18:55 -0500, Zane Bitter wrote: >> >>> I've noticed a few code reviews for new Heat resource types - >>> particularly Neutron resource types - where folks are struggling to find >>

[openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi, We made a lot of progress today. We agreed that: -- vnic_type will be a top level attribute as binding:vnic_type -- BPs: * Irena's https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type for binding:vnic_type * Bob to submit a BP for binding:profile in ML2. SRIOV input

Re: [openstack-dev] [TripleO] devtest thoughts

On 2014-01-30 13:32, Clint Byrum wrote: Excerpts from Ben Nemec's message of 2014-01-30 11:08:44 -0800: On 2014-01-30 09:28, James Slagle wrote: > devtest, our TripleO setup, has been rapidly evolving. We've added a > fair amount of configuration options for stuff like using actual > baremetal,

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Robert, Thank you very much for the summary. Please, see inline From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Thursday, January 30, 2014 10:45 PM To: Robert Kukura; Sandhya Dasu (sadasu); Irena Berezovsky; OpenStack Development Mailing List (not for usage questions); Brian Bowen (brbowen

Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support

- Original Message - > On 30 January 2014 23:26, Tomas Sedovic wrote: > > Hi all, > > > > I've seen some confusion regarding the homogenous hardware support as the > > first step for the tripleo UI. I think it's time to make sure we're all on > > the same page. > > > > Here's what I think

  1   2   >