[openstack-dev] [nova] [bug?] live migration fails with boot-from-volume

Hi, I was just testing the current icehouse code and came across some behaviour that looked suspicious. I have two nodes, an all-in-one and a compute node. I was not using shared instance storage. I created a volume from an image and then booted an instance from the volume. Once the imag

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

On Fri, Mar 7, 2014 at 5:41 PM, Stephen Gran wrote: > Hi, > > Given that Yuriy says explicitly 'unix socket', I dont think he means 'MQ' > when he says 'RPC'. I think he just means a daemon listening on a unix > socket for execution requests. This seems like a reasonably sensible idea > to me. >

Re: [openstack-dev] openstack-swift put performance

Well... What results did you get? What did you expect? What do you hope to achieve? How are you balancing your client requests across the five nodes? I'm not sure you're going to get anywhere near 2000^H^H requests a second from a single thread (!?) - Swift's performs best against many concurre

Re: [openstack-dev] [Cinder] FFE for vmdk-storage-policy-volume-type

Shouldn't be a problem, I'll sort through the items but I was looking earlier and didn't see anything concerning. All of them have been in process for some time so I think an exception is fair. On Mar 6, 2014 10:40 AM, "Subramanian" wrote: > Hi, > > > https://blueprints.launchpad.net/cinder/+spe

Re: [openstack-dev] OpenStack and GSoC 2014

Davanum, Now that students are in application phase, how can we mentors help them? Any meetings planned for the mentors to sync up on next steps. thanks, -Sriram On Mon, Feb 24, 2014 at 12:35 PM, Victoria Martínez de la Cruz < victo...@vmartinezdelacruz.com> wrote: > So happy to hear that! Co

Re: [openstack-dev] [Mistral] Crack at a "Real life" workflow

What are the benefits of MuranoPL over a already established language? I noted the following and don't quite understand why they are needed (reinventing a language): - https://wiki.openstack.org/wiki/Murano/DSL/Blueprint#Extends - https://wiki.openstack.org/wiki/Murano/DSL/Blueprint#Block_constr

Re: [openstack-dev] [Mistral] Crack at a "Real life" workflow

@ Dmitri ;) Sure lets catch up, most always I'm on IRC, feel free to ping me. Or jump into #openstack-state-management (for more good times). From: Dmitri Zimine mailto:d...@stackstorm.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.open

Re: [openstack-dev] [Nova] API weekly meeting

I'm interested in this. I can join except 13-21 UTC. Thanks, -- Masayuki IGAWA 2014/03/07 9:53 "Christopher Yeoh" : > > Hi, > > I'd like to start a weekly IRC meeting for those interested in > discussing Nova API issues. I think it would be a useful forum for: > > - People to keep up with what wo

Re: [openstack-dev] [Nova] API weekly meeting

> -Original Message- > From: Christopher Yeoh [mailto:cbky...@gmail.com] > Sent: Friday, March 07, 2014 9:46 AM > To: openstack-dev@lists.openstack.org > Subject: [openstack-dev] [Nova] API weekly meeting > > Hi, > > I'd like to start a weekly IRC meeting for those interested in > discus

Re: [openstack-dev] [Nova] API weekly meeting

Yep, I'm interested! I'm in ACST (UTC+9:30) > On 7 Mar 2014, at 11:15 am, Christopher Yeoh wrote: > > Hi, > > I'd like to start a weekly IRC meeting for those interested in > discussing Nova API issues. I think it would be a useful forum for: > > - People to keep up with what work is going on

Re: [openstack-dev] 答复: [OSSN] Live migration instructions recommend unsecured libvirt remote access

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/07/2014 03:13 AM, Luohao (brian) wrote: > Nathan, > > I have another idea of allowing vm migration without need for > remote access to libvirt daemon between compute servers. > > As I know, vm migration data path can be independent with libvirt

Re: [openstack-dev] [Nova] API weekly meeting

Any time except 15-22 UTC On 2014年03月07日 08:45, Christopher Yeoh wrote: Hi, I'd like to start a weekly IRC meeting for those interested in discussing Nova API issues. I think it would be a useful forum for: - People to keep up with what work is going on the API and where its headed. - Cloud

Re: [openstack-dev] testr help

On 03/07/2014 04:30 PM, Clark Boylan wrote: > Now onto indirectly answering some of the questions you have. If a > single unittest is producing thousands of lines of log output that is > probably a bug. The test scope is too large or the logging is too > verbose or both. To work around this we pro

Re: [openstack-dev] [Ironic] A ramdisk agent

Vladimir, I just put up https://review.openstack.org/#/c/79088/ for review to get the teeth-agent imported into openstack. I'm not sure if we want this merged immediately or if we want to get the outstanding non-Openstack dependencies settled before then, but hopefully this can help get things

Re: [openstack-dev] testr help

On 03/07/2014 04:33 PM, Steve Kowalik wrote: > On 07/03/14 12:56, John Dennis wrote: >> Question: How do you list just the failing tests? I don't want to see >> the contents of the logging data stored under the pythonlogging: key. >> Ideally I'd like to see the name of the test, what the failure wa

Re: [openstack-dev] [Ironic] A ramdisk agent

Thanks for putting that info together! I'm not sure exactly what order things need to happen in, but Jay (JayF) is working on the infra bits of getting a repository and CI, and Jim (jroll) is getting the Pecan+WSME part done. Hopefully we'll have it all ready by Monday. On Fri, Mar 7, 2014 at 12:

[openstack-dev] [sahara] Sahara (ex. Savanna) project renaming process [savanna]

Hey folks, we're now starting working on the project renaming. You can find details in the etherpad [0]. We'll move all work items to the blueprints, one blueprint per sub-project to well track progress and work items. The general blueprint is [1], it'll depend on all other blueprints and it's cur

Re: [openstack-dev] testr help

On 07/03/14 12:56, John Dennis wrote: Question: How do you list just the failing tests? I don't want to see the contents of the logging data stored under the pythonlogging: key. Ideally I'd like to see the name of the test, what the failure was, and possibly the associated stacktrace. Should be s

Re: [openstack-dev] testr help

On Fri, Mar 7, 2014 at 12:56 PM, John Dennis wrote: > I've read the following documents as well as the doc for subunit and > testtools but I'm still missing some big picture usage. > > https://wiki.openstack.org/wiki/Testr > https://testrepository.readthedocs.org/en/latest/index.html > > The bigge

[openstack-dev] python-novaclient 2.17.0 released

I just pushed a new release of python-novaclient: 2.17.0. The primary feature in this release is support for a new API, os-server-external-events, which is needed for some important coordination fixes between Nova and Neutron. There are a few bug fixes included in this release, as well. Please r

Re: [openstack-dev] [nova][vmware] Locking: A can of worms

Thanks Matt, good points raised here. I think at minimum we should address the single-node case by @synchronized-ing all access to the image cache data on the datastore, in a way that is fairly easy to reason about. Spawn failures are not desirable but acceptable in edge cases if a subsequent ret

Re: [openstack-dev] [Nova] Proposal to merge blueprints that just missed Icehouse-3 in early Juno-1

On Thu, Mar 6, 2014 at 2:51 AM, John Garbutt wrote: > On 5 March 2014 15:02, Russell Bryant wrote: > > Nova is now feature frozen for the Icehouse release. Patches for > > blueprints not already merged will need a feature freeze exception (FFE) > > to be considered for Icehouse. > > > > In addi

[openstack-dev] testr help

I've read the following documents as well as the doc for subunit and testtools but I'm still missing some big picture usage. https://wiki.openstack.org/wiki/Testr https://testrepository.readthedocs.org/en/latest/index.html The biggest problem seems to be whenever tests are listed I get thousands

Re: [openstack-dev] [Ironic] A ramdisk agent

Russell, Great to hear you are going to move towards Pecan+WSME. Yesterday I had a look at teeth projects. Next few days I am going to start contributing. First of all, I think, we need to arrange all that stuff about pluggable architecture. I've created a wiki page about Ironic python agent https

Re: [openstack-dev] [Climate] New name voting results (round #2)

Galactic epic win ! Let's start calling our project now Blazar (Climate). Very impressive word :-) 2014-03-07 20:13 GMT+01:00 Dina Belova : > Hello everyone! > > I've closed round #2 of new name choosing voting for Climate: > > http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_e2f53ce1b331590f

Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?

On Fri, Mar 7, 2014 at 1:26 AM, Qin Zhao wrote: > Hi Joe, > Maybe my example is very rare. However, I think a new type of 'in-place' > snapshot will have other advantages. For instance, the hypervisor can > support to save memory content in snapshot file, so that user can revert > his VM to runni

Re: [openstack-dev] [oslo][neutron][rootwrap] Performance considerations, sudo?

On Fri, Mar 7, 2014 at 12:27 AM, Miguel Angel Ajo wrote: > > I'm really happy to see that I'm not the only one concerned about > performance. > > > I'm reviewing the thread, and summarizing / replying to multiple people on > the thread: > > > Ben Nemec, > > * Thanks for pointing us to the previous

Re: [openstack-dev] [Neutron] Developer documentation

On Fri, Mar 07, 2014 at 02:20:24PM EST, Miguel Angel Ajo wrote: > > Good work on the documentation, it's something that will really help > new neutron developers. > Thank you everyone! I am very happy! I'll start cranking out some patchsets to address some of the comments that Henry Gessau, Aki

[openstack-dev] Constructive Conversations

Folks, I’m sure that I’m not the first person to bring this up, but I’d like to get everyone’s thoughts on what concrete actions we, as a community, can take to improve the status quo. There have been a variety of instances where community members have expressed their ideas and concerns via em

Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review & approval

The recent operator gathering (https://etherpad.openstack.org/p/operators-feedback-mar14) concluded a similar proposal, based on Blueprint-on-Blueprints (BoB for short). The aim was that operators of production OpenStack clouds should engage to give input at an early stage - Raising concerns

Re: [openstack-dev] [cinder] Blueprint cinder-rbd-driver-qos

On 03/05/2014 07:24 AM, git harry wrote: Hi, https://blueprints.launchpad.net/cinder/+spec/cinder-rbd-driver-qos I've been looking at this blueprint with a view to contributing on it, assuming I can take it. I am unclear as to whether or not it is still valid. I can see that it was registered

Re: [openstack-dev] [Neutron] Developer documentation

Good work on the documentation, it's something that will really help new neutron developers. On 03/07/2014 07:44 PM, Akihiro Motoki wrote: Hi Carl, I really appreciate you for writing this up! I have no hurdle to remove my -1 for the review. I just thought it is an item easy to fix. It is a

[openstack-dev] [Climate] New name voting results (round #2)

Hello everyone! I've closed round #2 of new name choosing voting for Climate: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_e2f53ce1b331590f *Blazar* is the most popular variant, heh :) 1. *Blazar* (Not defeated in any contest vs. another choice)2. Forecast, loses to Blazar by 6-53. Proph

Re: [openstack-dev] [Trove] datastore version-specific disk-image-builder element

"Lowery, Mathew" writes: > We have a need to support multiple versions of a single datastore with > a single set of disk-image-builder elements. Let's take MySQL on > Ubuntu as an example. 5.5 is already present in > trove-integration. Let's say we want to add 5.6 to coexist. Let's also > assume

Re: [openstack-dev] [Neutron][IPv6][Security Group] BP: Support ICMP type filter by security group

Hi Robert, Thanks for the clarification. I understand the motivation. I think the problem can be split into two categories: (a) user configurable rules vs infra enforced rule, and (b) DHCP/RA service exists inside or outside of Neutron Regarding (a), I believe DHCP or RA related rules is better

Re: [openstack-dev] [TROVE] Trove capabilities

Denis Makogon writes: > Let me elaborate a bit. > > [...] > > Without storing static API contract capabilities gonna be 100% corrupted, > because there's no API description inside Trove. Im not sure i understand what you mean here. > About reloading, file should not be reloaded, file is a stati

Re: [openstack-dev] [Neutron] Developer documentation

Hi Carl, I really appreciate you for writing this up! I have no hurdle to remove my -1 for the review. I just thought it is an item easy to fix. It is a great start line towards useufl developer documentation. Thanks, Akihiro On Sat, Mar 8, 2014 at 3:12 AM, Collins, Sean wrote: > Hi, > > I kn

Re: [openstack-dev] [nova][vmware] Locking: A can of worms

On Fri, Mar 7, 2014 at 12:55 PM, Doug Hellmann wrote: > http://git.openstack.org/cgit/stackforge/tooz This is good stuff. The only solution I could come up with for image cache management was to have yet another service that you would set up to manage the shared image cache resource. The current

Re: [openstack-dev] [Neutron] Developer documentation

I agree this is a valid request. As a team we should consider this special request and help is possible. Specially on Documentation!! :-) Edgar On 3/7/14 10:12 AM, "Collins, Sean" wrote: >Hi, > >I know everyone is very busy working on the I-3 release, but I wanted >solicit feedback on my devel

Re: [openstack-dev] [Neutron][ML2]

1) Does it mean an interim solution is to have our own plugin (and have all the changes in it) and declare it as core_plugin instead of Ml2Plugin? 2) The other issue as I mentioned before, is that the extension(s) is not showing up in the result, for instance when create_network is called [*result

Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements

From: Russell Bryant To: openstack-dev@lists.openstack.org, Date: 03/07/2014 11:31 AM Subject:Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements On 03/07/2014 12:09 PM, Matt Riedemann wrote: > Dan (Smith), Sean, Jim, Jay and myself talked about this in IRC

Re: [openstack-dev] [Neutron] Developer documentation

Hi, I know everyone is very busy working on the I-3 release, but I wanted solicit feedback on my developer documentation review. https://review.openstack.org/#/c/72428/ Currently, we have a couple +1's and a +2 from Nachi - Akihirio Motoki and Henry Gessau brought up valid points about the TESTI

Re: [openstack-dev] [nova] bugs that needs to be reviewed

Please see Thierry's post on review requests: http://lists.openstack.org/pipermail/openstack-dev/2013-September/015264.html -Ben On 2014-03-07 02:41, sahid wrote: Greetings, There are two fixes for bugs that need to be reviewed. One for the feature shelve instance and the other one for the AP

Re: [openstack-dev] [nova][vmware] Locking: A can of worms

On Fri, Mar 7, 2014 at 11:53 AM, Matthew Booth wrote: > We need locking in the VMware driver. There are 2 questions: > > 1. How much locking do we need? > 2. Do we need single-node or multi-node locking? > > I believe these are quite separate issues, so I'm going to try not to > confuse them. I'm

Re: [openstack-dev] [nova][vmware] Locking: A can of worms

Tooz folks has been thinking about this problem (as well as myself) for a little while. I've started something like: https://review.openstack.org/#/c/71167/ Also: https://wiki.openstack.org/wiki/StructuredWorkflowLocks Perhaps we can get more movement on that (sorry I haven't had tons of time to

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

I had a reply drafted up to Miguel's original post and now I realize that I never actually sent it. :( So, I'll clean up and update my draft and send it. This is a huge impediment to scaling Neutron and I believe this needs some attention before Icehouse releases. I believe this problem needs t

Re: [openstack-dev] [Mistral] Crack at a "Real life" workflow

Hello everyone! Actually it is possible to construct YAML-based DSL that has all the constructs of regular OOP language like Python and at the same time be safe enough to be used for execution of untrusted code on shared server. Take a look at Murano DSL. For example the code above defines class

Re: [openstack-dev] sqlalchemy-migrate release impending

On 02/26/2014 11:24 AM, David Ripton wrote: I'd like to release a new version of sqlalchemy-migrate in the next couple of days. The only major new feature is DB2 support. If anyone thinks this is a bad time, please let me know. sqlalchemy-migrate 0.9 is now available via pip. Notable new fea

Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements

On 03/07/2014 12:09 PM, Matt Riedemann wrote: > Dan (Smith), Sean, Jim, Jay and myself talked about this in IRC this > morning and I didn't realize the recent oslo bug was uncovered due to > something changing in how the audit logs were showing up after the > initial nova patch was pushed up on 2/1

Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements

On 3/7/2014 9:39 AM, Matt Riedemann wrote: On 3/7/2014 4:15 AM, Sean Dague wrote: On 03/06/2014 04:46 PM, James Carey wrote: Please consider a FFE for i18n Message improvements: BP: https://blueprints.launchpad.net/nova/+spec/i18n-messages The base enablement for lazy translation

Re: [openstack-dev] [Nova] FFE Request: Ephemeral RBD image support

On 03/07/2014 11:16 AM, Russell Bryant wrote: > On 03/07/2014 04:19 AM, Daniel P. Berrange wrote: >> On Thu, Mar 06, 2014 at 12:20:21AM -0800, Andrew Woodward wrote: >>> I'd Like to request A FFE for the remaining patches in the Ephemeral >>> RBD image support chain >>> >>> https://review.openstack

Re: [openstack-dev] [Ironic] A ramdisk agent

Vladmir, Hey, I'm on the team working on this agent, let me offer a little history. We were working on a system of our own for managing bare metal gear which we were calling "Teeth". The project was mostly composed of: 1. teeth-agent: an on-host provisioning agent 2. teeth-overlord: a centralized

[openstack-dev] [nova][vmware] Locking: A can of worms

We need locking in the VMware driver. There are 2 questions: 1. How much locking do we need? 2. Do we need single-node or multi-node locking? I believe these are quite separate issues, so I'm going to try not to confuse them. I'm going to deal with the first question first. In reviewing the imag

[openstack-dev] [savanna] team meeting minutes March 6

Thanks everyone who have joined Savanna meeting. Here are the logs from the meeting: Minutes: http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-03-06-18.02.html Log: http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-03-06-18.02.log.html It was decided to rename

Re: [openstack-dev] [Neutron][L3] FFE request: L3 HA VRRP

+1 On Fri, Mar 7, 2014 at 2:42 AM, Édouard Thuleau wrote: > +1 > I though it must merge as experimental for IceHouse, to let the community > tries it and stabilizes it during the Juno release. And for the Juno > release, we will be able to announce it as stable. > > Furthermore, the next work, wi

Re: [openstack-dev] [Nova] FFE Request: Ephemeral RBD image support

On Fri, Mar 7, 2014 at 12:30 AM, Matt Riedemann wrote: > What would be awesome in Juno is some CI around RBD/Ceph. I'd feel a lot > more comfortable with this code if we had CI running Tempest Seb has been working to add ceph support into devstack which could be a start, https://review.opensta

Re: [openstack-dev] [Ironic] A ramdisk agent

As far as I understand, there are 4 projects which are connected with this topic. Another two projects which were not mentioned by Devananda are https://github.com/rackerlabs/teeth-rest https://github.com/rackerlabs/teeth-overlord Vladimir Kozhukalov On Fri, Mar 7, 2014 at 4:41 AM, Devananda van

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

On Mar 6, 2014, at 3:31 AM, Miguel Angel Ajo wrote: > > Yes, one option could be to coalesce all calls that go into > a namespace into a shell script and run this in the > ootwrap > ip netns exec > > But we might find a mechanism to determine if some of the steps failed, and > what was the re

Re: [openstack-dev] [Nova] FFE Request: Ephemeral RBD image support

On 03/07/2014 04:19 AM, Daniel P. Berrange wrote: > On Thu, Mar 06, 2014 at 12:20:21AM -0800, Andrew Woodward wrote: >> I'd Like to request A FFE for the remaining patches in the Ephemeral >> RBD image support chain >> >> https://review.openstack.org/#/c/59148/ >> https://review.openstack.org/#/c/5

Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review & approval

On 2014-03-06 18:16, Christopher Yeoh wrote: On Thu, 06 Mar 2014 13:05:15 -0500 Sean Dague wrote: In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (an

Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review & approval

On Fri, Mar 7, 2014 at 10:47 AM, Steve Gordon wrote: > - Original Message - > > On Thu, Mar 6, 2014 at 12:05 PM, Sean Dague wrote: > > > > > I think this is really worthwhile to try -- and it might offer an > > interesting, readable history of decisions made. Plus how funny it was > also

Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements

From: Sean Dague To: "OpenStack Development Mailing List (not for usage questions)" , Date: 03/07/2014 04:25 AM Subject:Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements On 03/06/2014 04:46 PM, James Carey wrote: > Please consider a FFE for i18n Mess

Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review & approval

Yep, great idea. Do it. On 03/07/2014 02:53 AM, Chris Behrens wrote: > > On Mar 6, 2014, at 11:09 AM, Russell Bryant wrote: > […] >> I think a dedicated git repo for this makes sense. >> openstack/nova-blueprints or something, or openstack/nova-proposals if >> we want to be a bit less tied to la

Re: [openstack-dev] [Neutron][IPv6][Security Group] BP: Support ICMP type filter by security group

Hi Akihiro, In the case of IPv6 RA, its source IP is a Link Local Address from the router's RA advertising interface. This LLA address is automatically generated and not saved in the neutron port DB. We are exploring the idea of retrieving this LLA if a native openstack RA service is running on th

Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review & approval

- Original Message - > On Thu, Mar 6, 2014 at 12:05 PM, Sean Dague wrote: > > I think this is really worthwhile to try -- and it might offer an > interesting, readable history of decisions made. Plus how funny it was also > brought up at the Ops Summit. Convergence, cool. > > It also go

Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements

On 3/7/2014 4:15 AM, Sean Dague wrote: On 03/06/2014 04:46 PM, James Carey wrote: Please consider a FFE for i18n Message improvements: BP: https://blueprints.launchpad.net/nova/+spec/i18n-messages The base enablement for lazy translation has already been sync'd from oslo. This pat

[openstack-dev] [Climate] Meeting minutes

Hello, OS folks! Thanks everyone for taking part in our weekly meeting :) Meeting minutes are: Minutes: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-07-15.01.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-07-15.01.txt Log: http

Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements

On 3/7/2014 3:23 AM, Daniel P. Berrange wrote: On Thu, Mar 06, 2014 at 03:46:24PM -0600, James Carey wrote: Please consider a FFE for i18n Message improvements: BP: https://blueprints.launchpad.net/nova/+spec/i18n-messages The base enablement for lazy translation has already been sy

Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review & approval

On Mar 6, 2014 1:11 PM, "Sean Dague" wrote: > > One of the issues that the Nova team has definitely hit is Blueprint > overload. At some point there were over 150 blueprints. Many of them > were a single sentence. > > The results of this have been that design review today is typically not > happen

Re: [openstack-dev] [Neutron][LBaaS] Mini-summit Interest?

+1 - that is a good idea! Having it several days before the J-Summit in Atlanta would be great. - Stephen On Fri, Mar 7, 2014 at 1:33 AM, Eugene Nikanorov wrote: > I think mini summit is no worse than the summit itself. > Everyone who wants to participate can join. > In fact what we really need

Re: [openstack-dev] [Nova] API weekly meeting

On 03/07/14 at 11:15am, Christopher Yeoh wrote: Hi, I'd like to start a weekly IRC meeting for those interested in discussing Nova API issues. I think it would be a useful forum for: - People to keep up with what work is going on the API and where its headed. - Cloud providers, SDK maintainers

Re: [openstack-dev] [ceilometer] FFE Request: monitoring-network-from-opendaylight

On Fri, Mar 07 2014, Sean Dague wrote: > Are the reviews already posted? Yes. > And are there 2 ceilometer core members signed up for review (names > please)? I can be one, and I'm sure Lianhao Lu and Gordon Chung will continue to look at it. > Are we sure this is mergable by Tuesday - pre rel

Re: [openstack-dev] [Neutron][LBaaS] Mini-summit Interest?

+1 to the idea of having the mini-summit in Atlanta a few days prior to the OS summit. On Mar 7, 2014, at 3:37 AM, "Eugene Nikanorov" mailto:enikano...@mirantis.com>> wrote: I think mini summit is no worse than the summit itself. Everyone who wants to participate can join. In fact what we rea

Re: [openstack-dev] [TripleO] os-cloud-config ssh access to cloud

On 03/07/2014 10:30 AM, Jiří Stránský wrote: Hi, there's one step in cloud initialization that is performed over SSH -- calling "keystone-manage pki_setup". Here's the relevant code in keystone-init [1], here's a review for moving the functionality to os-cloud-config [2]. The consequence of thi

Re: [openstack-dev] Incubation Request: Murano

On Fri, Mar 7, 2014 at 2:53 AM, Thierry Carrez wrote: > Steven Dake wrote: > > I'm a bit confused as well as to how a incubated project would be > > differentiated from a integrated project in one program. This may have > > already been discussed by the TC. For example, Red Hat doesn't > > offic

Re: [openstack-dev] [Neutron][ML2]

On 3/7/14, 3:53 AM, Édouard Thuleau wrote: Yes, that sounds good to be able to load extensions from a mechanism driver. But another problem I think we have with ML2 plugin is the list extensions supported by default [1]. The extensions should only load by MD and the ML2 plugin should only im

Re: [openstack-dev] stored userdata

On 07/03/14 05:05, Hiroyuki Eguchi wrote: I'm envisioning a stored userdata feature. < https://blueprints.launchpad.net/nova/+spec/stored-userdata > Currently, OpenStack allow user to execute script or send configuration file when creating a instance by using --user-data /path/to/filename option

Re: [openstack-dev] [GSoC 2014] Proposal Template

>Sai, > >There may be more than one person on a topic, so it would make sense >to have additional questions per person. Yes, link to project idea is >definitely needed. > >-- dims > >On Thu, Mar 6, 2014 at 11:41 AM, saikrishna sripada >krishna1256 at gmail.com >

Re: [openstack-dev] [Cinder] Do you think we should introduce the online-extend feature to cinder ?

On Mar 7, 2014, at 7:55 AM, Paul Marshall wrote: > > On Mar 6, 2014, at 9:56 PM, Zhangleiqiang wrote: > >>> get them working. For example, in a devstack VM the only way I can get the >>> iSCSI target to show the new size (after an lvextend) is to delete and >>> recreate >>> the target, some

Re: [openstack-dev] stored userdata

On Fri, Mar 07, 2014 at 05:05:46AM +, Hiroyuki Eguchi wrote: > I'm envisioning a stored userdata feature. > < https://blueprints.launchpad.net/nova/+spec/stored-userdata > > > Currently, OpenStack allow user to execute script or send configuration file > when creating a instance by using --use

Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review & approval

The principle is excellent, I think there are two points/objectives worth keeping in mind: 1. We need an effective way to make and record the design decisions 2. We should make the whole development process easier In my mind the point of the design review part is to agree up front something tha

Re: [openstack-dev] [Cinder] Do you think we should introduce the online-extend feature to cinder ?

On Mar 6, 2014, at 9:56 PM, Zhangleiqiang wrote: >> get them working. For example, in a devstack VM the only way I can get the >> iSCSI target to show the new size (after an lvextend) is to delete and >> recreate >> the target, something jgriffiths said he doesn't want to support ;-). > > I kn

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

Hi, Given that Yuriy says explicitly 'unix socket', I dont think he means 'MQ' when he says 'RPC'. I think he just means a daemon listening on a unix socket for execution requests. This seems like a reasonably sensible idea to me. Cheers, On 07/03/14 12:52, Miguel Angel Ajo wrote: I tho

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

I thought of this option, but didn't consider it, as It's somehow risky to expose an RPC end executing priviledged (even filtered) commands. If I'm not wrong, once you have credentials for messaging, you can send messages to any end, even filtered, I somehow see this as a higher risk option. An

Re: [openstack-dev] [ceilometer] FFE Request: monitoring-network-from-opendaylight

On 03/07/2014 07:22 AM, Julien Danjou wrote: > On Fri, Mar 07 2014, Yuuichi Fujioka wrote: > > Hi, > >> We would like to request FFE for monitoring-network-from-opendaylight.[1][2] >> Unfortunately, it was not merged by Icehouse-3. >> >> This is the first driver of the bp/monitoring-network.(It w

Re: [openstack-dev] [ceilometer] FFE Request: monitoring-network-from-opendaylight

On Fri, Mar 07 2014, Yuuichi Fujioka wrote: Hi, > We would like to request FFE for monitoring-network-from-opendaylight.[1][2] > Unfortunately, it was not merged by Icehouse-3. > > This is the first driver of the bp/monitoring-network.(It was merged)[3] > We strongly believe this feature will enh

Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review & approval

On 03/07/2014 06:30 AM, Thierry Carrez wrote: > Sean Dague wrote: >> One of the issues that the Nova team has definitely hit is Blueprint >> overload. At some point there were over 150 blueprints. Many of them >> were a single sentence. >> >> The results of this have been that design review today i

Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review & approval

On Fri, Mar 07, 2014 at 12:30:15PM +0100, Thierry Carrez wrote: > Sean Dague wrote: > > One of the issues that the Nova team has definitely hit is Blueprint > > overload. At some point there were over 150 blueprints. Many of them > > were a single sentence. > > > > The results of this have been th

Re: [openstack-dev] asymmetric gating and stable vs unstable tests

Hey Deva, It really could be a huge issue for incubated projects. I have now good ideas about how to solve it... One of the bad ideas is that we could extend jenkins success message to include note that will be visible even if comment isn't expanded. Or post separated comment like "Please, note

Re: [openstack-dev] time.sleep is affected by eventlet.monkey_patch()

Hi, Yes, a monotonic *must* be used to compute timeouts. I wrote the time.monotonic() function of Python 3.3 and the PEP 418. For my Trollius project, I wrote this code for Python 2 using ctypes. It works on Linux, Windows, Mac OS X, OpenBSD, FreeBSD and Solaris: https://bitbucket.org/enovance/

Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review & approval

Sean Dague wrote: > One of the issues that the Nova team has definitely hit is Blueprint > overload. At some point there were over 150 blueprints. Many of them > were a single sentence. > > The results of this have been that design review today is typically not > happening on Blueprint approval, b

[openstack-dev] [[savanna] Design Summit session suggestions

Hey Sahara (Savanna) folks , Design Summit session suggestions now open, so, please, add topics you'd like to discuss on summit. More info [0]. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-March/029319.html -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc.

Re: [openstack-dev] Session suggestions for the Juno Design Summit now open

Sergey Lukjanov wrote: > thanks for opening sessions suggestions for Design Summit. Could you, > please, rename Savanna topic to "Sahara (ex. Savanna)"? Done! -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org htt

[openstack-dev] 答复: [OSSN] Live migration instructions recommend unsecured libvirt remote access

Nathan, I have another idea of allowing vm migration without need for remote access to libvirt daemon between compute servers. As I know, vm migration data path can be independent with libvirt daemon. For example, libvirt supports delegating vm migration to the hypervisor. When a vm migration

Re: [openstack-dev] Session suggestions for the Juno Design Summit now open

Hi Thierry, thanks for opening sessions suggestions for Design Summit. Could you, please, rename Savanna topic to "Sahara (ex. Savanna)"? On Fri, Mar 7, 2014 at 1:17 PM, Thierry Carrez wrote: > Hi everyone, > > TL;DR: > The session suggestion website for the Juno Design Summit (which will > happ

Re: [openstack-dev] [Nova][Cinder] Feature about volume delete protection

do a code review and found a function _reclaim_queued_deletes will do the soft_delete reclaim if you set reclaim_instance_interval > 0 , then delete will be soft_delete and it will be reclaimed if it's old enough by default reclaim_instance_interval is 0, so delete will be hard delete , user can t

Re: [openstack-dev] [savanna] Feature Freeze and end of the I cycle

I'd like to add that we should concentrate on testing and bug fixing for the next several weeks. This period will include project renaming too... The release-critical bugs will be tracked on the icehouse-rc1 [0] milestone pages. When all such issues will be fixed the first release candidate will be

Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review & approval

On Thu, Mar 06, 2014 at 01:05:15PM -0500, Sean Dague wrote: > One of the issues that the Nova team has definitely hit is Blueprint > overload. At some point there were over 150 blueprints. Many of them > were a single sentence. > > The results of this have been that design review today is typicall

Re: [openstack-dev] I am taking sick leave for today

Ooops, sorry, wrong recepient :-) 7 марта 2014 г., 14:13 пользователь Dmitry Mescheryakov написал: > Коллеги, > > Сегодня я опять беру выходной по болезни. Начал поправляться но все > еще чувствую себя неуверенно. Надеюсь вылечиться целиком ко вторнику. > > Дмитрий ___

Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements

On 03/06/2014 04:46 PM, James Carey wrote: > Please consider a FFE for i18n Message improvements: > BP: https://blueprints.launchpad.net/nova/+spec/i18n-messages > > The base enablement for lazy translation has already been sync'd > from oslo. This patch was to enable lazy translation

  1   2   >