[openstack-dev] [Nova][VMware] Deploy from vCenter template

I don't think these patches are conflicting. I will continue to work on this patch. https://review.openstack.org/#/c/34903/ Thanks! Best Regards --- Hi Arnaud, It's really good to know th

Re: [openstack-dev] [oslo][nova] oslo common.service vs. screen and devstack

Excerpts from Sean Dague's message of 2013-12-19 16:33:12 -0800: > So a few people had been reporting recently that unstack no longer stops > nova processes, which I only got around to looking at today. It turns > out the new common.service stack from oslo takes SIGHUP and treats it as > a restart.

[openstack-dev] Add no HPET option for resolving windows vm time drifting

Hi all, When we tested windows guest OS, the time drift case was occured. It meant the clock of windows mv gredually lost a few seconds per minute. It occured especailly the CPUs are working hard. For syncing between Hypervisor and windows vm, we need to other option into libvirt template. I subm

Re: [openstack-dev] [swift] Blocking issue with ring rebalancing

On Thu, Dec 19, 2013 at 8:22 PM, Nikolay Markov wrote: > > I created a bug on launchpad regarding this: > https://bugs.launchpad.net/swift/+bug/1262166 > > Could anybody please participate in discussion on how to overcome it? > Hello. I know you've decided to dig a bit deeper on IRC, but I've mad

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

I'm on holidays till 9th January. And I don't think I'll have an internet access all the time on holidays. p.s. By the way, I'll prefer Friday's evenings as new meeting time if it is available - it only one day when I don't do my BJJ classes. Or we can move to 1900-2000UTC. it looks fine for me. Or

Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Yes, Alan, you got me. Providing power/temperature to scheduler, set threshold or different weight, then the scheduler can boot VM on the most suitable node. Thanks --fengqian From: Alan Kavanagh [mailto:alan.kavan...@ericsson.com] Sent: Friday, December 20, 2013 11:58 AM To: OpenStack Developm

Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Cheers Gao It definitely makes sense to collect additional metrics such as power and temperature, and make that available for selective decisions you would want to take. However, I am just wondering if you could realistically feed those metrics as variables for scheduling, this is the main part

Re: [openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints

Ian, thanks for asking! I replied in the other thread. It works for me! On Fri, Dec 20, 2013 at 8:23 AM, Ian Wells wrote: > Xuhan, check the other thread - would 1500UTC suit? > > > On 19 December 2013 01:09, Xuhan Peng wrote: > >> Shixiong and guys, >> >> The sub team meeting is too early fo

[openstack-dev] [Nova]I want to add a hypervisor driver for Nova in icehouse

Hi all, I'm planing to commit a new hypervisor Driver for Huawei-FusionCompute in Icehouse. And I've already submitted a bp & wiki to OpenStack. BP: https://blueprints.launchpad.net/nova/+spec/driver-for-huawei-fusioncompute Wiki: https://wiki.openstack.org/wiki/FusionCompute Now I'm not sure w

Re: [openstack-dev] [Neutron][IPv6] Meeting time - change to 1300 UTC or 1500 UTC?

15UTC is 23PM in China, not ideal, but I am OK with that :-) On Fri, Dec 20, 2013 at 8:20 AM, Ian Wells wrote: > I'm easy. > > > On 20 December 2013 00:47, Randy Tuttle wrote: > >> Any of those times suit me. >> >> Sent from my iPhone >> >> On Dec 19, 2013, at 5:12 PM, "Collins, Sean" < >> sea

Re: [openstack-dev] [neutron] [third-party-testing] Reminder: Meeting tomorrow

Salvatore, Agreed that a visible job-log should be a requirement, otherwise who knows what was actually run. -Shiv From: Salvatore Orlando [mailto:sorla...@nicira.com] Sent: Thursday, December 19, 2013 4:50 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [opens

Re: [openstack-dev] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter- namespace

Keep in mind that this approach is a direct departure from the IPv4 world. Note that I'm not wholly against that, however there's something to keep in mind. Any kind of stack-agnostic interactions in Neutron will have to become stack aware or have a translator to tell if they need to interact

Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Hi, Devananda, Thanks for your reply. I totally agree with your thought, nova-compute could gathering such information locally. And I think IPMI, using in-band connection, might be more suitable to be used to collect these sensor data. At the beginning, I thought it would better to put all IPMI p

Re: [openstack-dev] [trove] datastore migration issues

I second Rob and Greg- we need to not allow the instance table to have nulls for the datastore version ID. I can't imagine that as Trove grows and evolves, that edge case is something we'll always remember to code and test for, so let's cauterize things now by no longer allowing it at all. The

Re: [openstack-dev] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter- namespace

Interesting. So you're suggesting we provision a single namespace (per network, rather than subnet?) proactively, and use it for both routing and DHCP. Not unreasonable. Also workable for v4, I think? -- Ian. On 20 December 2013 02:31, Shixiong Shang wrote: > Hi, Ian: > > The use case brough

[openstack-dev] [keystone] role of Domain in VPC definition

Hi, We had some internal discussions on role of Domain and VPCs. I would like to expand and understand community thinking of Keystone domain and VPCs. Is VPC equivalent to Keystone Domain? If so, as a public cloud provider - I create a Keystone domain and give it to an organization which wants

Re: [openstack-dev] [Nova] Default ephemeral filesystem

>From my some testing I did a couple of months ago, we decided to move to XFS to avoid the issue I was poking around with after my file system inadvertently filled and > found that in ex3/4 all of the inodes in the file system have to be zeroed > prior to mkfs completing (unless the kernel is abov

Re: [openstack-dev] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter- namespace

Hi, Randy: Thanks a bunch for pointing it out! Yup, you are absolutely right. What I wanted to say is why not put qg-, qr-, and ns- interfaces in the single namespace. I typed it on my small keyboard on iPhone. Sorry for the confusion. :( Shixiong On Dec 19, 2013, at 8:44 PM, Randy Tuttle

Re: [openstack-dev] [Openstack] Today - Doc Bug Day

Reminder: Doc Bug Day is today. On 13/12/13 08:16, Tom Fifield wrote: > Reminder: Friday next week - Doc Bug Day. > > Current number of doc bugs: 505 > > On 22/11/13 11:27, Tom Fifield wrote: >> All, >> >> This month, docs reaches 500 bugs, making it the 2nd-largest project by >> bug count in al

Re: [openstack-dev] [Nova][VMware] Deploy from vCenter template

Hi Arnaud, It's really good to know that your team are proposing the vcenter driver with OVA+glance datastore backend support. Thanks for sharing the information. OVA would be a good choice which will benefit users by avoiding only use flat image limited from current driver. But in my opin

Re: [openstack-dev] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter- namespace

Shixiong, I know you must have a typo in the 3rd paragraph. I think maybe you mean to include the ns- interface in that list. So why not have qg- qr- and ns- interfaces in the same namespace. Am I right? Rnady On Thu, Dec 19, 2013 at 8:31 PM, Shixiong Shang < sparkofwisdom.cl...@gmail.com> wrot

Re: [openstack-dev] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter- namespace

Hi, Ian: The use case brought by Comcast team today during the ipv6 sub-team meeting actually proved the point I made here, instead of against it. If I didn’t explain it clearly in my previous email, here it is. I was questioning the design with two namespaces and I believe we can use a SINGLE

Re: [openstack-dev] [neutron][qa] test_network_basic_ops and the "FloatingIPChecker" control point

Before starting this post I confess I did not read with the required level of attention all this thread, so I apologise for any repetition. I just wanted to point out that floating IPs in neutron are created asynchronously when using the l3 agent, and I think this is clear to everybody. So when th

Re: [openstack-dev] additional core review criteria - recent Jenkins pass - otherwise you break the gates

Jim and I have been talking about both of these ideas for months. We aren't lacking clever solutions to make this better. However they are lacking implementors. Volunteers welcomed. Until such time, this is completely solvable problem by people taking and extra 5 seconds before approving a patc

Re: [openstack-dev] additional core review criteria - recent Jenkins pass - otherwise you break the gates

On Thu, Dec 19 2013, Sean Dague wrote: > So please look for recent passes before +Aing anything. What about making that automatic? Same question for patchset that stays that for a month, finally got approved and fails right away because they cannot be merged. It would be cool to notify the submi

Re: [openstack-dev] Horizon and Tuskar-UI codebase merge

Another +1 for separate repos. Horizon's core focus should remain on the integrated projects, but we also need to prepare better for when incubated projects graduate, so their inclusion is less disruptive. I also like Gabriel's suggestion of a non-gating CI job to catch any integration issues betw

Re: [openstack-dev] additional core review criteria - recent Jenkins pass - otherwise you break the gates

On Thu, Dec 19, 2013 at 5:41 PM, Sean Dague wrote: > https://review.openstack.org/#/c/51793/ Just curious, what about the possibility of automating this? In other words, run through idle patches any time the gate volume gets below a certain threshold. If you come across a patch that hasn't been

Re: [openstack-dev] [neutron] [third-party-testing] Reminder: Meeting tomorrow

Hi, I'm sorry I could not make it to meeting. However, I can see clearly see the progress being made from gerrit! One thing which might be worth mentioning is that some of the new jobs are already voting. However, in some cases the logs are either not accessible, and in other cases the job seem t

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

On 19 December 2013 15:15, John Garbutt wrote: > > Note, I don't see the person who boots the server ever seeing the > pci-flavor, only understanding the server flavor. > > [IrenaB] I am not sure that elaborating PCI device request into server > flavor is the right approach for the PCI pass-thro

[openstack-dev] additional core review criteria - recent Jenkins pass - otherwise you break the gates

https://review.openstack.org/#/c/51793/ is a good instance of a behavior I've seen a lot of recently, where someone approves a patch that last ran CI on it a month ago (the last Jenkins pass on this patch was Nov 19th). If you come across a patch like that, as a core reviewer, please "recheck no b

[openstack-dev] [oslo][nova] oslo common.service vs. screen and devstack

So a few people had been reporting recently that unstack no longer stops nova processes, which I only got around to looking at today. It turns out the new common.service stack from oslo takes SIGHUP and treats it as a restart. Which isn't wrong, but is new, and is incompatible with screen (the way

Re: [openstack-dev] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter- namespace

Per the discussions this evening, we did identify a reason why you might need a dhcp namespace for v6 - because networks don't actually have to have routers. It's clear you need an agent in the router namespace for RAs and another one in the DHCP namespace for when the network's not connected to a

Re: [openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints

Xuhan, check the other thread - would 1500UTC suit? On 19 December 2013 01:09, Xuhan Peng wrote: > Shixiong and guys, > > The sub team meeting is too early for china IBM folks to join although we > would like to participate the discussion very much. Any chance to rotate > the time so we can com

Re: [openstack-dev] [Neutron][IPv6] Meeting time - change to 1300 UTC or 1500 UTC?

I'm easy. On 20 December 2013 00:47, Randy Tuttle wrote: > Any of those times suit me. > > Sent from my iPhone > > On Dec 19, 2013, at 5:12 PM, "Collins, Sean" < > sean_colli...@cable.comcast.com> wrote: > > > Thoughts? I know we have people who are not able to attend at our > > current time. >

[openstack-dev] [keystone] External authentication plugins

We've got to figure out what external authentication plugins we're going to provide in Keystone. This is something that you'd think wouldn't be complicated, but somehow it's gotten that way. Since we've made mistakes in the past, let's try to be careful this time and come up with what plugins are

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

Anita, Fawad and Myself will be also attending. BTW. Fawad will require an invitation letter for visa. He will email you directly with that request. Thanks, Edgar On Wed, Dec 18, 2013 at 1:17 PM, Anita Kuno wrote: > Okay time for a recap. > > What: Neutron Tempest code sprint > Where: Montr

Re: [openstack-dev] [Neutron][IPv6] Meeting time - change to 1300 UTC or 1500 UTC?

Any of those times suit me. Sent from my iPhone On Dec 19, 2013, at 5:12 PM, "Collins, Sean" wrote: > Thoughts? I know we have people who are not able to attend at our > current time. > > -- > Sean M. Collins > ___ > OpenStack-dev mailing list > O

[openstack-dev] [Ceilometer][Oslo] Consuming Notifications in Batches

Hi Folks, The Rackspace-HP team has been putting a lot of effort into performance testing event collection in the ceilometer storage drivers[0]. Based on some results of this testing, we would like to support batch consumption of notifications, as it will greatly improve insertion performance. Bat

Re: [openstack-dev] [Neutron][IPv6] Meeting time - change to 1300 UTC or 1500 UTC?

I cannot do 13:00UTC, but 14:00 or 15:00 UTC should work for me. > On Dec 19, 2013, at 5:12 PM, "Collins, Sean" > wrote: > > Thoughts? I know we have people who are not able to attend at our > current time. > > -- > Sean M. Collins > ___ > OpenSta

Re: [openstack-dev] [TripleO] Tuskar CLI after architecture changes

On 12/19/2013 04:55 AM, Radomir Dopieralski wrote: On 14/12/13 16:51, Jay Pipes wrote: [snip] Instead of focusing on locking issues -- which I agree are very important in the virtualized side of things where resources are "thinner" -- I believe that in the bare-metal world, a more useful focus

[openstack-dev] [Neutron][IPv6] Meeting time - change to 1300 UTC or 1500 UTC?

Thoughts? I know we have people who are not able to attend at our current time. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Agenda for today's meeting

Minutes from the meeting: http://eavesdrop.openstack.org/meetings/neutron_ipv6/2013/neutron_ipv6.2013-12-19-21.00.html -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listin

Re: [openstack-dev] [bugs] definition of triaged

On 16 December 2013 23:56, Thierry Carrez wrote: > Robert Collins wrote: >> https://wiki.openstack.org/wiki/BugTriage is a 10 step process: thats >> not something we can sensible do over coffee in the morning. > > Totally agree with that. The idea of those 10 steps was not meant as > something you

Re: [openstack-dev] [Nova] Default ephemeral filesystem

On 12/19/2013 03:21 PM, Robert Collins wrote: > The default ephemeral filesystem in Nova is ext3 (for Linux). However > ext3 is IMNSHO a pretty poor choice given ext4's existence. I can > totally accept that other fs's like xfs might be contentious - but is > there any reason not to make ext4 the d

[openstack-dev] [Nova] Default ephemeral filesystem

The default ephemeral filesystem in Nova is ext3 (for Linux). However ext3 is IMNSHO a pretty poor choice given ext4's existence. I can totally accept that other fs's like xfs might be contentious - but is there any reason not to make ext4 the default? I'm not aware of any distro that doesn't have

Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

On Wed, Dec 18, 2013 at 7:16 PM, Gao, Fengqian wrote: > Hi, Devananda, > > I agree with you that new features should be towards Ironic. > > As you asked why use Ironic instead of lm-sensors, actually I just want to > use IPMI instead of lm-sensors. I think it is reasonable to put the IPMI > part

Re: [openstack-dev] Incubation Request for Barbican

On Thu, Dec 12, 2013 at 4:48 PM, Morgan Fainberg wrote: > On December 12, 2013 at 14:32:36, Dolph Mathews > (dolph.math...@gmail.com) > wrote: > > > On Thu, Dec 12, 2013 at 2:58 PM, Adam Young wrote: > >> On 12/04/2013 08:58 AM, Jarret Raim wrote: >> >> While I am all for adding a new program,

Re: [openstack-dev] Adding DB migration items to the common review checklist

On 2013-12-18 22:08, Jay Pipes wrote: On 12/18/2013 02:14 PM, Brant Knudson wrote: Matt - Could a test be added that goes through the models and checks these things? Other projects could use this too. Here's an example of a test that checks if the tables are all InnoDB: http://git.openstack.or

Re: [openstack-dev] Incubation Request for Barbican

On Thu, Dec 19, 2013 at 4:14 AM, Sean Dague wrote: > On 12/19/2013 12:10 AM, Mike Perez wrote: > > On Tue, Dec 17, 2013 at 1:59 PM, Mike Perez > > wrote: > > > I reviewed the TC meeting notes, and my question still stands. > > > > It seems the committee is touching on

Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent

When the OpenStack project was started in 2010, we conceived of two languages that would be considered to have first class status: Python, and C++. The idea is that Python would be used for the API services, and that C++ would be used in special cases where Python was not a good fit, such as for

Re: [openstack-dev] [Climate] PTL Candidacy

Confirmed. https://wiki.openstack.org/wiki/Climate/PTL_Elections_Icehouse#Candidates On Thu, Dec 19, 2013 at 8:39 PM, Sylvain Bauza wrote: > Hi, > > I hereby would like to announce my candidacy for the Climate > (Reservations) PTL. > > A brief history about me : I'm playing with Software Engin

[openstack-dev] [State-Management] Agenda for today meeting at 2000 UTC

Hi all, The [state-management] project team holds a weekly meeting in #openstack-meeting on thursdays, 2000 UTC. The next meeting is today, 2013-12-19!!! As usual, everyone is welcome :-) Link: https://wiki.openstack.org/wiki/Meetings/StateManagement Taskflow: https://wiki.openstack.org/Ta

Re: [openstack-dev] [heat] Nomination for heat-core

On Thu, Dec 19, 2013 at 03:21:46PM +1300, Steve Baker wrote: > I would like to nominate Bartosz Górski to be a heat-core reviewer. His > reviews to date have been valuable and his other contributions to the > project have shown a sound understanding of how heat works. > > Here is his review histor

Re: [openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints

I will surely be there this afternoon, Sean! Look forward to it! On Dec 19, 2013, at 12:22 PM, Collins, Sean wrote: > Perfect! Will you be at the IRC meeting to discuss these? I've added > them to the agenda in the hopes that we can discuss > > -- > Sean M. Collins > _

Re: [openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints

Perfect! Will you be at the IRC meeting to discuss these? I've added them to the agenda in the hopes that we can discuss -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listi

Re: [openstack-dev] Horizon and Tuskar-UI codebase merge

On 12/19/2013 05:32 PM, Jordan O'Mara wrote: > > - Original Message - >> So basically this is our first proposal what we send out: >> http://lists.openstack.org/pipermail/openstack-dev/2013-December/022196.html >> >> After Horizon meetings, several e-mails and also couple of other >> discus

Re: [openstack-dev] Horizon and Tuskar-UI codebase merge

+1 to this! - Original Message - > So after a lot of consideration, my opinion is the two code bases should stay > in separate repos under the Horizon Program, for a few reasons: > -Adding a large chunk of code for an incubated project is likely going to > cause the Horizon delivery some g

Re: [openstack-dev] [Ceilometer] Nomination of Sandy Walsh to core team

On Mon, Dec 09 2013, Herndon, John Luke wrote: Hi John, > I¹m not 100% sure what the process is around electing an individual to the > core team (i.e., can a non-core person nominate someone?). However, I > believe the ceilometer core team could use a member who is more active in > the developmen

[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] [Heat] [Trove] [Savanna] [Oslo] Unified Agents - what is the actual problem?

Tim, IMHO network-based and hypervisor-based agents definitely can co-exist. What I wanted to say is that the problem of enabling communication between guest and cloud service is not relevant for hypervisor-based agents. They simply don't need network access into a VM. Dmitry 2013/12/19 Tim Sim

Re: [openstack-dev] Horizon and Tuskar-UI codebase merge

- Original Message - > So basically this is our first proposal what we send out: > http://lists.openstack.org/pipermail/openstack-dev/2013-December/022196.html > > After Horizon meetings, several e-mails and also couple of other > discussions of people who are for/against codebase merge,

Re: [openstack-dev] Horizon and Tuskar-UI codebase merge

So after a lot of consideration, my opinion is the two code bases should stay in separate repos under the Horizon Program, for a few reasons: -Adding a large chunk of code for an incubated project is likely going to cause the Horizon delivery some grief due to dependencies and packaging issues at

Re: [openstack-dev] Horizon and Tuskar-UI codebase merge

So basically this is our first proposal what we send out: http://lists.openstack.org/pipermail/openstack-dev/2013-December/022196.html After Horizon meetings, several e-mails and also couple of other discussions of people who are for/against codebase merge, it looks that in the end upstream le

[openstack-dev] [swift] Blocking issue with ring rebalancing

Hi, Our team run into some serious trouble with performance of 'swift-ring-builder rebalance' after some recent changes. On our environment it takes about 8 minutes, and this and it is not the maximum. This is really blocker for us. This issue is reproducible on Ubuntu 12.04 + Python 2.7. The fun

Re: [openstack-dev] Incubation Request for Barbican

Excerpts from Sean Dague's message of 2013-12-19 04:14:51 -0800: > On 12/19/2013 12:10 AM, Mike Perez wrote: > > On Tue, Dec 17, 2013 at 1:59 PM, Mike Perez > > wrote: > > > I reviewed the TC meeting notes, and my question still stands. > > > > It seems the committee is

Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

Ah, I think I've responded too fast, sorry. meter-list provides a list of various measurements that are being done per resource. sample-list provides a list of samples per every meter: ceilometer sample-list --meter cpu_util -q resource_id=vm_uuid These samples can be aggregated over a period of

Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

On Thu, Dec 19, 2013 at 08:02:16AM -0800, Gary Kotton wrote: > > > On 12/19/13 5:50 PM, "Daniel P. Berrange" wrote: > > >On Tue, Dec 17, 2013 at 04:28:30AM -0800, Gary Kotton wrote: > >> Hi, > >> Following the discussion yesterday I have updated the wiki - please see > >> > >>https://urldefens

Re: [openstack-dev] [Heat] [Trove] [Savanna] [Oslo] Unified Agents - what is the actual problem?

>> I agree that enabling communication between guest and cloud service is a >> common problem for most agent designs. The only exception is agent based on >> hypervisor provided transport. But as far as I understand many people are >> interested in network-based agent, so indeed we can start a t

Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

On 12/19/13 6:07 PM, "Daniel P. Berrange" wrote: >On Thu, Dec 19, 2013 at 08:02:16AM -0800, Gary Kotton wrote: >> >> >> On 12/19/13 5:50 PM, "Daniel P. Berrange" wrote: >> >> >On Tue, Dec 17, 2013 at 04:28:30AM -0800, Gary Kotton wrote: >> >> Hi, >> >> Following the discussion yesterday I h

Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

On 12/19/13 5:50 PM, "Daniel P. Berrange" wrote: >On Tue, Dec 17, 2013 at 04:28:30AM -0800, Gary Kotton wrote: >> Hi, >> Following the discussion yesterday I have updated the wiki - please see >> >>https://urldefense.proofpoint.com/v1/url?u=https://wiki.openstack.org/wik >>i/Nova_VM_Diagnostic

Re: [openstack-dev] [Horizon] Support for Django 1.6

On 2013-12-19 23:45:09 +0800 (+0800), Thomas Goirand wrote: > Sid has Django 1.6. Is it planned to add support for it? I currently > don't know what to do with the Horizon package, as it's currently > broken... :( You probably want to follow https://blueprints.launchpad.net/horizon/+spec/django-1p

Re: [openstack-dev] [trove] datastore migration issues

I think that we need to be good citizens and at least add dummy data. Because it is impossible to know who all is using this, the list you have is probably complete. But Trove has been available for quite some time and all these users will not be listening on this thread. Basically anytime you have

Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent

2013/12/19 Fox, Kevin M > How about a different approach then... OpenStack has thus far been very > successful providing an API and plugins for dealing with things that cloud > providers need to be able to switch out to suit their needs. > > There seems to be two different parts to the unified ag

Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

On Tue, Dec 17, 2013 at 04:28:30AM -0800, Gary Kotton wrote: > Hi, > Following the discussion yesterday I have updated the wiki - please see > https://wiki.openstack.org/wiki/Nova_VM_Diagnostics. The proposal is > backwards compatible and will hopefully provide us with the tools to be > able to tro

[openstack-dev] [Horizon] Support for Django 1.6

Hi, Sid has Django 1.6. Is it planned to add support for it? I currently don't know what to do with the Horizon package, as it's currently broken... :( Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/c

Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

On Thursday, December 19, 2013 8:49:13 AM, Vladik Romanovsky wrote: Or ceilometer meter-list -q resource_id='vm_uuid' - Original Message - From: "Daniel P. Berrange" To: "John Garbutt" Cc: "OpenStack Development Mailing List (not for usage questions)" Sent: Thursday, 19 December,

Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

On Thu, Dec 19, 2013 at 03:47:30PM +0100, Vladik Romanovsky wrote: > I think it was: > > ceilometer sample-list -m cpu_util -q 'resource_id=vm_uuid' Hmm, a standard devstack deployment of ceilometer doesn't seem to record any performance stats at all - just shows me the static configuration param

Re: [openstack-dev] [trove] datastore migration issues

We did consider doing that, but decided it wasn't really any different from the other options as it required the deployer to know to alter that data. That would require the fewest code changes, though. It was also my understanding that mysql variants were a possibility as well (percona and mar

Re: [openstack-dev] [neutron][qa] test_network_basic_ops and the "FloatingIPChecker" control point

My 2 cents: In the test the floating IP is created via neutron API and later checked via nova API. So the test is relying here (or trying to verify?) the network cache refresh mechanism in nova. This is something that we should test, but in a test dedicated to this. The primary objective of tes

Re: [openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints

On Wed, Dec 18, 2013 at 10:29:35PM -0500, Shixiong Shang wrote: > It is up to Sean to make the call, but I would love to see IBM team in the > meeting. Agreed - If we can find a time that works for USA, Europe and China that would be great. How good/bad is 1500 UTC? I don't trust my math :)

Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

On 4 December 2013 17:10, Russell Bryant wrote: > I think option 3 makes the most sense here (pending anyone saying we > should run away screaming from mox3 for some reason). It's actually > what I had been assuming since this thread a while back. > > This means that we don't need to *require* th

Re: [openstack-dev] [neutron][qa] test_network_basic_ops and the "FloatingIPChecker" control point

Hi, Yair Fried wrote: I would also like to point out that, since Brent used compute.build_timeout as the timeout value ***It takes more time to update FLIP in nova DB, than for a VM to build*** Yair Agreed. I think that's an extremely important highlight of this discussion. Propagation of t

Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

Or ceilometer meter-list -q resource_id='vm_uuid' - Original Message - > From: "Daniel P. Berrange" > To: "John Garbutt" > Cc: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Thursday, 19 December, 2013 9:34:02 AM > Subject: Re: [openstack-dev] [nova] VM diagn

Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

I think it was: ceilometer sample-list -m cpu_util -q 'resource_id=vm_uuid' Vladik - Original Message - > From: "Daniel P. Berrange" > To: "John Garbutt" > Cc: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Thursday, 19 December, 2013 9:34:02 AM > Subject: R

[openstack-dev] [Neutron][IPv6] Agenda for today's meeting

Hi, Agenda for today's meeting is pretty light - if you have something you'd like to discuss please add it to the wiki page https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_Dec_19_2013 I would also ask that when we conduct the meeting - we stick to the agenda that has bee

Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

On Thu, Dec 19, 2013 at 02:27:40PM +, John Garbutt wrote: > On 16 December 2013 15:50, Daniel P. Berrange wrote: > > On Mon, Dec 16, 2013 at 03:37:39PM +, John Garbutt wrote: > >> On 16 December 2013 15:25, Daniel P. Berrange wrote: > >> > On Mon, Dec 16, 2013 at 06:58:24AM -0800, Gary Ko

Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

On 16 December 2013 15:50, Daniel P. Berrange wrote: > On Mon, Dec 16, 2013 at 03:37:39PM +, John Garbutt wrote: >> On 16 December 2013 15:25, Daniel P. Berrange wrote: >> > On Mon, Dec 16, 2013 at 06:58:24AM -0800, Gary Kotton wrote: >> >> I'd like to propose the following for the V3 API (we

Re: [openstack-dev] [Nova][Docker] Environment variables

On 17 December 2013 12:53, Daniel P. Berrange wrote: > On Mon, Dec 16, 2013 at 01:04:33PM -0800, Dan Smith wrote: >> > eg use a 'env_' prefix for glance image attributes >> > >> > We've got a couple of cases now where we want to overrides these >> > same things on a per-instance basis. Kernel comm

Re: [openstack-dev] [heat] Nomination for heat-core

+1 Sent from my Verizon Wireless 4G LTE Smartphone Original message From: Steve Baker Date: 12/18/2013 8:28 PM (GMT-06:00) To: OpenStack Development Mailing List Subject: [openstack-dev] [heat] Nomination for heat-core I would like to nominate Bartosz Górski to be a heat-

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

Response inline... On 19 December 2013 13:05, Irena Berezovsky wrote: > Hi John, > I totally agree that we should define the use cases both for administration > and tenant that powers the VM. > Since we are trying to support PCI pass-through network, let's focus on the > related use cases. > Pl

Re: [openstack-dev] [neutron] [third-party-testing] Reminder: Meeting tomorrow

Apologies folks, I meant 2200 UTC Thursday. We'll still do the meeting today. On Dec 18, 2013, at 4:40 PM, Don Kehn wrote: > Wouldn't 2200 UTC be in about 20 mins? > > > On Wed, Dec 18, 2013 at 3:32 PM, Itsuro ODA wrote: > Hi, > > It seems the meeting was not held on 2200 UTC on Wednesday (t

[openstack-dev] [neutron] [ml2] Canceling next two weekly meetings

Since the next two Neutron ML2 meetings fall on Dec. 25 and Jan. 1, we'll cancel both and reconvene on Jan. 8. Thanks! Kyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-de

[openstack-dev] [climate] PTL elections: nominations

Hey all, It was decided to choose the PTL for Climate project and I've volunteered to handle it. All important questions was discussed on the last IRC team meeting [1]. You can find details on a wiki page [2]. So, we'd like to choose PTL for the rest Icehouse release cycle. To announce your candi

Re: [openstack-dev] [neutron][qa] test_network_basic_ops and the "FloatingIPChecker" control point

I would also like to point out that, since Brent used compute.build_timeout as the timeout value ***It takes more time to update FLIP in nova DB, than for a VM to build*** Yair - Original Message - From: "Sean Dague" To: "OpenStack Development Mailing List (not for usage questions)" S

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

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] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs

On 19 December 2013 06:35, Isaku Yamahata wrote: > > Hi Ian. > > I can't see your proposal. Can you please make it public viewable? > Crap, sorry - fixed. > > Even before I read the document I could list three use cases. Eric's > > covered some of them himself. > > I'm not against trunking. >

Re: [openstack-dev] [Heat] [Trove] [Savanna] [Oslo] Unified Agents - what is the actual problem?

I agree that enabling communication between guest and cloud service is a common problem for most agent designs. The only exception is agent based on hypervisor provided transport. But as far as I understand many people are interested in network-based agent, so indeed we can start a thread (or conti

Re: [openstack-dev] [heat] Nomination for heat-core

On 12/19/2013 10:21 AM, Steve Baker wrote: I would like to nominate Bartosz Górski to be a heat-core reviewer. His reviews to date have been valuable and his other contributions to the project have shown a sound understanding of how heat works. Here is his review history: https://review.openst

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

Hi John, I totally agree that we should define the use cases both for administration and tenant that powers the VM. Since we are trying to support PCI pass-through network, let's focus on the related use cases. Please see my comments inline. Regards, Irena -Original Message- From: John G

  1   2   >