Re: [openstack-dev] [nova] Questions about guest NUMA and memory binding policies

Hi Steve, Thanks for your reply. I didn't know why the blueprint numa-aware-cpu-binding seems to have no more progress until read the two mails mentioned in your mail. The use case analysis in the mails are very clear, they are also what I concern about. I agree that we shouldn't provide pCPU/

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of ports

Hi Robert, Seems to me that many code lines are duplicated following your proposal. For agent based MDs, I would prefer to inherit from SimpleAgentMechanismDriverBase and add there verify method for supported_pci_vendor_info. Specific MD will pass the list of supported pci_vendor_info list. The

[openstack-dev] [nova][pci][sriov] rewriting the the common SRIOV support blue-prints :https://blueprints.launchpad.net/nova/+spec/pci-extra-info

Hi, all this SRIOV common support bp link: https://blueprints.launchpad.net/nova/+spec/pci-extra-info after a long discuss, SRIOV design choice discuss is done and reach a agreement. i want to rewrite this blueprints, maybe use diagram to present it clear. i hope that will be done in one

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

> -Original Message- > From: Dan Smith [mailto:d...@danplanet.com] > Sent: Wednesday, March 05, 2014 9:09 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API > > > What I'd like to do next is work

Re: [openstack-dev] [Mistral] DSL model vs. DB model, renaming

I think we forgot to point to the commit itself. Here it is: https://review.openstack.org/#/c/77126/ Manas, can you please provide more details on your suggestion? For now let me just describe the background of Nikolay’s question. Basically, we are talking about how we are working with data ins

Re: [openstack-dev] [solum] use of the plan for m1

Angus, Please include a solum-dsl-version attribute in all examples. That can default to "current". It would also be wise to have a language pack attribute as Devdatta suggested. Then we don't need to bump the version to support it later. The default value for solum-language-pack should be "au

Re: [openstack-dev] [solum] use of the plan for m1

+1 for using a simple plan file for M1. I agree, the language pack id would need to be part of the plan file. -Murali On Mar 4, 2014, at 9:20 PM, devdatta kulkarni wrote: > I support this approach. > > Customization of build and deploy lifecycle actions depends on > the ability to register

[openstack-dev] [openstack][SUSE][Ceilometer] ceilometer service init script can be improved

Hi, SUSE developers Thanks for your great work on OpenStack packaging for SUSE distribution. I have tested some functionality of ceilometer on sles 11 sp3, and have two minor problem, which can create critical availability problem, but can be easily fixed . They all locate in the service init scr

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

On Tue, 04 Mar 2014 16:09:21 -0800 Dan Smith wrote: > > What I'd like to do next is work through a new proposal that > > includes keeping both v2 and v3, but with a new added focus of > > minimizing the cost. This should include a path away from the dual > > code bases and to something like the

Re: [openstack-dev] [solum] use of the plan for m1

I support this approach. Customization of build and deploy lifecycle actions depends on the ability to register different kinds of services for performing these actions. I can imagine that operators would want to provide such services as part of their Solum install. Then, app developers would be

[openstack-dev] [solum] use of the plan for m1

Hi all I just wanted to clarify our use of the camp plan file (esp. for m1). Up until now I have been under the impression that use the plan to describe the app lifecycle (build/test/deploy) and the contents of the app. After attempting to write code that converts plans like this into heat temp

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of ports

Hi Sandhya, I agree with you except that I think that the class should inherit from MechanismDriver. I took a crack at it, and here is what I got: # Copyright (c) 2014 OpenStack Foundation # All Rights Reserved. # #Licensed under the Apache License, Version 2.0 (the "License"); you may #n

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

Hi Joe, my meaning is that cloud users may not hope to create new instances or new images, because those actions may require additional approval and additional charging. Or, due to instance/image quota limits, they can not do that. Anyway, from user's perspective, saving and reverting the existing

Re: [openstack-dev] [Mistral] DSL model vs. DB model, renaming

Since the renaming is for types in mistral.model.*. I am thinking we suffix with Spec e.g. TaskObject -> TaskSpec ActionObject -> ActionSpec and so on. The "Spec" suggest that it is a specification of the final object that ends up in the DB and not the actual object. Multiple actual objects can b

Re: [openstack-dev] pep8 gating fails due to tools/config/check_uptodate.sh

On 3/4/2014 4:34 PM, Joe Gordon wrote: So since tools/config/check_uptodate.sh is oslo code, I assumed this issue falls into the domain of oslo-incubator. Until this gets resolved nova is considering https://review.openstack.org/#/c/78028/ Keystone too: https://review.openstack.org/#/c/78030

Re: [openstack-dev] [GSOC] Guidance for "Add a New Storage Backend" project.

Sai, On Sun, Mar 2, 2014 at 2:19 PM, saikrishna sripada wrote: > Hi Srinivas/Alej/All, > > Adding to my earlier mail, > > I found "Implement a re-usable shared library for vmware (oslo.vmware) to be > consumed by various OpenStack projects like Nova, Cinder or Glance" also > interesting. > Pleas

Re: [openstack-dev] [GSOC] Guidance for "Add a New Storage Backend" project.

Sai, Please get in touch with Arnaud for oslo.vmware He has graciously stepped up as a mentor. You can also talk to people on #openstack-vmware and #openstack-Oslo IRC channels. Take a look at the code so far as well - https://github.com/openstack/oslo.vmware -- dims On Sun, Mar 2, 2014 at 2:19

Re: [openstack-dev] [nova] Simulating many fake nova compute nodes for scheduler testing

On Mon, Mar 3, 2014 at 3:10 PM, Sergey Skripnick wrote: > > > > I can run multiple compute service in same hosts without containers. >> Containers give you a nice isolation and another way to try a more >> realistic scenario, but my initial goal now is to be able to simulate many >> fake compute

Re: [openstack-dev] PCI SRIOV meeting suspend?

On 2014年03月04日 20:45, Robert Li (baoli) wrote: > Hi Yongli, > > I have been looking at your patch set. Let me look at it again if you have > new update. look forward to that. thanks. > > The meeting changed back to UTC 1300 Tuesday. > > thanks, > Robert > > On 3/4/14 12:39 AM, "yongli he" wrote:

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

On Tue, 04 Mar 2014 12:10:15 -0500 Russell Bryant wrote: > > What I'd like to do next is work through a new proposal that includes > keeping both v2 and v3, but with a new added focus of minimizing the > cost. This should include a path away from the dual code bases and to > something like the "

Re: [openstack-dev] [Neutron][Testr] Brand new checkout of Neutron... getting insane unit test run results

On Mon, Jan 13, 2014 at 05:16:16PM EST, Mark McClain wrote: > I’d rather us explicitly skip the tests if the module is not available. > > mark Just wanted to close the loop on this - thanks to Darragh O'Reilly, who submitted https://review.openstack.org/#/c/66609/, which removes the Pyudev depend

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

On Wed, Mar 5, 2014 at 11:09 AM, Dan Smith wrote: >> What I'd like to do next is work through a new proposal that includes >> keeping both v2 and v3, but with a new added focus of minimizing the >> cost. This should include a path away from the dual code bases and to >> something like the "v2.1"

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

On Tue, 4 Mar 2014 11:29:27 -0600 Anne Gentle wrote: > I still sense that the struggle with Compute v3 is the lack of > documentation for contributor developers but also especially end > users so that we could get feedback early and often. > > My original understanding, passed by word-of-mouth, w

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

On March 4, 2014 at 16:13:45, Dan Smith (d...@danplanet.com) wrote: > What I'd like to do next is work through a new proposal that includes  > keeping both v2 and v3, but with a new added focus of minimizing the  > cost. This should include a path away from the dual code bases and to  > something l

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

> What I'd like to do next is work through a new proposal that includes > keeping both v2 and v3, but with a new added focus of minimizing the > cost. This should include a path away from the dual code bases and to > something like the "v2.1" proposal. I think that the most we can hope for is con

Re: [openstack-dev] [Tripleo] tripleo-cd-admins team update / contact info question

Hi On 25 February 2014 14:30, Robert Collins wrote: > So - I think we need to define two things: > - a stock way for $randoms to ask for support w/ these clouds that > will be fairly low latency and reliable. > - a way for us to escalate to each other *even if folk happen to be > away from t

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

On Tue, 4 Mar 2014 09:26:18 -0800 Vishvananda Ishaya wrote: > > On Mar 4, 2014, at 9:10 AM, Russell Bryant wrote: > > > > Thank you all for your participation on this topic. It has been > > quite controversial, but the API we expose to our users is a really > > big deal. I'm feeling more and m

Re: [openstack-dev] Incubation Request: Murano

Hi all, Completely agree with Zane. Collaboration with TOSCA TC is a way to go as Murano is very close to TOSCA. Like Murano = 0.9 * TOSCA + UI + OpenStack services integration. Let me share my thoughts on TOSCA as I read all TOSCA docs and I'm also the author of initial Murano DSL design proposa

Re: [openstack-dev] Proposal to move from Freenode to OFTC

From: Brian Cline To: openstack-dev@lists.openstack.org, Date: 03/04/2014 12:29 PM Subject:Re: [openstack-dev] Proposal to move from Freenode to OFTC On 03/04/2014 05:01 AM, Thierry Carrez wrote: > James E. Blair wrote: >> Freenode has been having a rough time lately due to a s

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

On Tue, 4 Mar 2014 13:14:01 + "Daniel P. Berrange" wrote: > On Tue, Mar 04, 2014 at 07:49:03AM -0500, Sean Dague wrote: > > So this thread is getting deep again, as I expect they all will, so > > I'm just going to top post and take the ire for doing so. > > > > I also want to summarize what

Re: [openstack-dev] Incubation Request: Murano

Hi Thomas, Zane, Thank you for bringing TOSCA to the discussion. I think this is important topic as it will help to find better alignment or even future merge of Murano DSL and Heat templates. Murano DSL uses YAML representation too, so we can easily merge use constructions from Heat and probably

Re: [openstack-dev] [Cinder] Open Source and community working together

On the topic of 'always improving our community', here is the announcement I promised On 03/03/2014 01:52 PM, Stefano Maffulli wrote: > [...] We'll have a first > edition of this program in Atlanta. Some more details on the wiki > https://wiki.openstack.org/wiki/OpenStack_Upstream_Training/Info >

Re: [openstack-dev] Proposal to move from Freenode to OFTC

I agree with Stefano. Migrating the entire community to a new service would be incredibly painful. It seems the pain of moving is not justified if we don’t know for a fact that OFTC would be more resilient to DDoS attacks. -1 to the switch as well. -Doug Mendizabal On 3/4/14, 2:48 PM, "Stefa

Re: [openstack-dev] [Nova] What is the currently accepted way to do plugins

On Tue, 2014-03-04 at 17:31 -0400, Sandy Walsh wrote: > > How about using 'unstable' as a component of the entrypoint group? > > E.g., "nova.unstable.events"… > > Wouldn't that defeat the "point" of entry points ... immutable > endpoints? What happens when an unstable event is deemed stable? Actu

Re: [openstack-dev] Incubation Request: Murano

Excerpt from Zane Bitter's message on 04/03/2014 23:16:21: > From: Zane Bitter > To: openstack-dev@lists.openstack.org > Date: 04/03/2014 23:20 > Subject: Re: [openstack-dev] Incubation Request: Murano > > On 04/03/14 00:04, Georgy Okrokvertskhov wrote: > > > It so happens that the OASIS's TOSCA t

Re: [openstack-dev] pep8 gating fails due to tools/config/check_uptodate.sh

So since tools/config/check_uptodate.sh is oslo code, I assumed this issue falls into the domain of oslo-incubator. Until this gets resolved nova is considering https://review.openstack.org/#/c/78028/ On Wed, Feb 5, 2014 at 9:21 AM, Daniel P. Berrange wrote: > On Wed, Feb 05, 2014 at 11:56:35AM

Re: [openstack-dev] Incubation Request: Murano

On 04/03/14 00:04, Georgy Okrokvertskhov wrote: First of all let me highlight that Murano DSL was much inspired by TOSCA. We carefully read this standard before our movement to Murano DSL. TOSCA standard has a lot f of very well designed concepts and ideas which we reused in Murano. There is one

Re: [openstack-dev] [heat]Policy on upgades required config changes

Excerpts from Steven Hardy's message of 2014-03-04 09:39:21 -0800: > Hi all, > > As some of you know, I've been working on the instance-users blueprint[1]. > > This blueprint implementation requires three new items to be added to the > heat.conf, or some resources (those which create keystone use

Re: [openstack-dev] Incubation Request: Murano

Hi all, I would like to pick up the TOSCA topic brought up by Zane in his mail below. TOSCA is in fact a standard that seems closely aligned with the concepts that Murano is implementing, so thanks Zane for bringing up this discussion. I saw Georgy's reply early today where he stated that Murano

[openstack-dev] LVM ephemeral storage encryption

Hello Joe, Sorry to be bugging on what is probably a very busy day for you, but it being the feature freeze and all, I just wanted to ask if there was any chance of the LVM ephemeral storage encryption patch , that you -1'ed today, making it into Iceho

Re: [openstack-dev] [Nova] What is the currently accepted way to do plugins

On 03/04/2014 05:00 PM, Kevin L. Mitchell wrote: > On Tue, 2014-03-04 at 12:11 -0800, Dan Smith wrote: >> Now, the actual concern is not related to any of that, but about whether >> we're going to open this up as a new thing we support. In general, my >> reaction to adding new APIs people expect

Re: [openstack-dev] [Nova] What is the currently accepted way to do plugins

And sorry, as to your original problem, the loadables approach is kinda messy since only the classes that are loaded when *that* module are loaded are used (vs. explicitly specifying them in a config). You may get different results when the flow changes. Either entry-points or config would give re

Re: [openstack-dev] [Nova] What is the currently accepted way to do plugins

> How about using 'unstable' as a component of the entrypoint group? > E.g., "nova.unstable.events"… Well, this is a pretty heavy way to ensure that the admin gets the picture, but maybe appropriate :) What I don't think we want is the in-tree plugins having to hook into something called "unstabl

Re: [openstack-dev] [Ceilometer] Suggestions for alarm improvements

hi Sampath tbh, i actually like the pipeline solution proposed in the blueprint... that said, there hasn't been any work done relating to this in Icehouse. there was work on adding alarms to notification https://blueprints.launchpad.net/ceilometer/+spec/alarm-on-notification but that has been

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of ports

Hi, During today's meeting, it was decided that we would re-purpose Robert's https://blueprints.launchpad.net/neutron/+spec/pci-passthrough-sriov to take care of adding a Base class to take care of common processing for SR-IOV ports. This class would: 1. Inherits from AgentMechanismDri

Re: [openstack-dev] [Neutron][FYI] Bookmarklet for neutron gerrit review

Nachi, Great! I'd been meaning to do something like this. I took yours and tweaked it a bit to highlight failed Jenkins builds in red and grey other Jenkins messages. Human reviews are left in blue. javascript:(function(){ list = document.querySelectorAll('td.GJEA35ODGC'); for(i in lis

Re: [openstack-dev] [Nova] What is the currently accepted way to do plugins

On Tue, 2014-03-04 at 12:11 -0800, Dan Smith wrote: > Now, the actual concern is not related to any of that, but about whether > we're going to open this up as a new thing we support. In general, my > reaction to adding new APIs people expect to be stable is "no". However, > I understand why things

Re: [openstack-dev] Proposal to move from Freenode to OFTC

-1 to the switch from me. this question from Sean is of fundamental value: On 03/03/2014 03:19 PM, Sean Dague wrote: > #1) do we believe OFTC is fundamentally better equipped to resist a > DDOS, or do we just believe they are a smaller target? The ongoing DDOS > on meetup.com the past 2 weeks is

Re: [openstack-dev] Change in openstack/neutron[master]: Permit ICMPv6 RAs only from known routers

On Tue, Mar 04, 2014 at 02:08:03PM EST, Robert Li (baoli) wrote: > Hi Xu Han & Sean, > > Is this code going to be committed as it is? Based on this morning's > discussion, I thought that the IP address used to install the RA rule > comes from the qr-xxx interface's LLA address. I think that I'm co

[openstack-dev] [python-openstacksdk] Minutes for 4 March Meeting

Today was the second python-openstacksdk meeting Minutes: http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-04-19.00.html Minutes (text): http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-04-19.00.txt Log: http

Re: [openstack-dev] [Nova] What is the currently accepted way to do plugins

> In a chat with Dan Smith on IRC, he was suggesting that the important > thing was not to use class paths in the config file. I can see that > internal implementation should not be exposed in the config files - > that way the implementation can change without impacting the nova > users/operators.

Re: [openstack-dev] [infra] Meeting Tuesday March 4th at 19:00 UTC

On Mon, Mar 3, 2014 at 8:53 AM, Elizabeth Krumbach Joseph wrote: > The OpenStack Infrastructure (Infra) team is hosting our weekly > meeting tomorrow, Tuesday March 4th, at 19:00 UTC in > #openstack-meeting Thanks to everyone who joined us, meeting minutes and log here: Minutes: http://eavesdro

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

On 03/04/2014 12:42 PM, Sean Dague wrote: > On 03/04/2014 12:26 PM, Vishvananda Ishaya wrote: >> >> On Mar 4, 2014, at 9:10 AM, Russell Bryant >> wrote: >>> >>> Thank you all for your participation on this topic. It has >>> been quite controversial, but the API we expose to our users is >>> a r

Re: [openstack-dev] Incubation Request: Murano

Hi, Here is an etherpad page with current Murano status http://etherpad.openstack.org/p/murano-incubation-status. Thanks Georgy On Mon, Mar 3, 2014 at 9:04 PM, Georgy Okrokvertskhov < gokrokvertsk...@mirantis.com> wrote: > Hi Zane, > > Thank you very much for this question. > > First of all le

Re: [openstack-dev] does exception need localize or not?

On 2014-02-27 02:45, yongli he wrote: > refer to : > https://wiki.openstack.org/wiki/Translations [1] > > now some exception use _ and some not. the wiki suggest do not to do that. > but i'm not sure. > > what's the correct way? > > F.Y.I > > WHAT TO TRANSLATE > > At present the convent

Re: [openstack-dev] [nova] Thought exercise for a V2 only world

On Mar 4, 2014, at 11:14 AM, Sean Dague wrote: > > I want to give the knobs to the users. If we thought it was important > enough to review and test in Nova, then we made a judgement call that > people should have access to it. Oh, I see. But, I don’t agree, certainly not for every single knob

Re: [openstack-dev] [OpenStack][Runtime Policy] A proposal for OpenStack run time policy to manage compute/storage resource

Dear All, We are working on a framework where we want to monitor the system and take certain actions when specific events or situations occur. Here are two examples of 'different' situations: Example 1: A VM's-Owner and N/W's-owner are different ==> this could mean a violation ==> we need

Re: [openstack-dev] WARNING: ... This application has not enabled MySQL traditional mode, which means silent data corruption may occur - real issue?

On Tue, Mar 4, 2014 at 11:08 AM, Ben Nemec wrote: > On 2014-03-04 12:51, Sean Dague wrote: >> >> On 03/04/2014 01:27 PM, Ben Nemec wrote: >>> >>> This warning should be gone by default once >>> >>> https://github.com/openstack/oslo-incubator/commit/dda24eb4a815914c29e801ad0176630786db8734 >>> gets

Re: [openstack-dev] [Nova] What is the currently accepted way to do plugins

In a chat with Dan Smith on IRC, he was suggesting that the important thing was not to use class paths in the config file. I can see that internal implementation should not be exposed in the config files - that way the implementation can change without impacting the nova users/operators. Sandy,

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 Tue, Mar 4, 2014 at 1:06 AM, Qin Zhao wrote: > I think the current snapshot implementation can be a solution sometimes, but > it is NOT exact same as user's expectation. For example, a new blueprint is > created last week, > https://blueprints.launchpad.net/nova/+spec/driver-specific-snapshot,

Re: [openstack-dev] WARNING: ... This application has not enabled MySQL traditional mode, which means silent data corruption may occur - real issue?

On 2014-03-04 12:51, Sean Dague wrote: On 03/04/2014 01:27 PM, Ben Nemec wrote: This warning should be gone by default once https://github.com/openstack/oslo-incubator/commit/dda24eb4a815914c29e801ad0176630786db8734 gets synced. I believe there is work underway by the db team to get that done.

Re: [openstack-dev] [nova] Thought exercise for a V2 only world

On 03/04/2014 02:03 PM, Chris Behrens wrote: > > On Mar 4, 2014, at 4:09 AM, Sean Dague > wrote: > >> On 03/04/2014 01:14 AM, Chris Behrens wrote: >>> […] >>> I don’t think I have an answer, but I’m going to throw out some of my >>> random thoughts about extensions in gene

Re: [openstack-dev] Change in openstack/neutron[master]: Permit ICMPv6 RAs only from known routers

Hi Xu Han & Sean, Is this code going to be committed as it is? Based on this morning's discussion, I thought that the IP address used to install the RA rule comes from the qr-xxx interface's LLA address. I think that I'm confused. Also this bug: Allow LLA as router interface of IPv6 subnet https:

Re: [openstack-dev] [nova] Thought exercise for a V2 only world

On Mar 4, 2014, at 4:09 AM, Sean Dague wrote: > On 03/04/2014 01:14 AM, Chris Behrens wrote: >> […] >> I don’t think I have an answer, but I’m going to throw out some of my random >> thoughts about extensions in general. They might influence a longer term >> decision. But I’m also curious if I

Re: [openstack-dev] [all][keystone] Increase of USER_ID length maximum from 64 to 255

On March 4, 2014 at 10:45:02, Vishvananda Ishaya (vishvana...@gmail.com) wrote: On Mar 3, 2014, at 11:32 AM, Jay Pipes wrote:  > On Mon, 2014-03-03 at 11:09 -0800, Vishvananda Ishaya wrote:  >> On Mar 3, 2014, at 6:48 AM, Jay Pipes wrote:  >>  >>> On Sun, 2014-03-02 at 12:05 -0800, Morgan Fainb

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

Hi, Is there something we can adopt? can you please send me some pointers to templates from other communities? -- dims On Tue, Mar 4, 2014 at 1:46 PM, Masaru Nomura wrote: > Hi, > > > I have a question about an application format as I can't find it on wiki > page. Is there any specific informat

Re: [openstack-dev] WARNING: ... This application has not enabled MySQL traditional mode, which means silent data corruption may occur - real issue?

On 03/04/2014 01:27 PM, Ben Nemec wrote: > This warning should be gone by default once > https://github.com/openstack/oslo-incubator/commit/dda24eb4a815914c29e801ad0176630786db8734 > gets synced. I believe there is work underway by the db team to get > that done. > > Note that the reason it will

[openstack-dev] [GSoC 2014] Proposal Template

Hi, I have a question about an application format as I can't find it on wiki page. Is there any specific information I should provide within a proposal? I checked other communities and some of them have an application template, so I would just like to make it clear. Thank you, Masaru Nomura

Re: [openstack-dev] Climate Incubation Application

On Tue, Mar 4, 2014 at 5:25 AM, Dina Belova wrote: > Joe, thanks for discussion. > > >> I think nova should natively support booting an instance for a > >> limited amount of time. I would use this all the time to boot up > >> devstack instances (boot devstack instance for 5 hours) > > > Really nic

Re: [openstack-dev] [Neutron][IPv6] Update the Wiki with links to blueprints and reviews

Yea. that's a good idea. I will try to find out time working on the spec. --Robert On 3/4/14 11:17 AM, "Collins, Sean" wrote: >On Tue, Mar 04, 2014 at 04:06:02PM +, Robert Li (baoli) wrote: >> Hi Sean, >> >> I just added the ipv6-prefix-delegation BP that can be found using the >> search l

Re: [openstack-dev] WARNING: ... This application has not enabled MySQL traditional mode, which means silent data corruption may occur - real issue?

This warning should be gone by default once https://github.com/openstack/oslo-incubator/commit/dda24eb4a815914c29e801ad0176630786db8734 gets synced. I believe there is work underway by the db team to get that done. Note that the reason it will be gone is that we're changing the default oslo db

Re: [openstack-dev] [all][keystone] Increase of USER_ID length maximum from 64 to 255

On Mar 3, 2014, at 11:32 AM, Jay Pipes wrote: > On Mon, 2014-03-03 at 11:09 -0800, Vishvananda Ishaya wrote: >> On Mar 3, 2014, at 6:48 AM, Jay Pipes wrote: >> >>> On Sun, 2014-03-02 at 12:05 -0800, Morgan Fainberg wrote: Having done some work with MySQL (specifically around similar data

[openstack-dev] [qa][nova] Ownership and path to schema definitions

Given that 1. there is an ongoing api discussion in which using json schemas is an important part 2. tempest now has a schema-based auto-generate feature for negative tests I think it would be a good time to have at least an initial discussion about the requirements for theses schemas and whe

Re: [openstack-dev] [Nova] Nova failed to spawn when download disk image from Glance timeout

Nora, This is a development list. Your questions sound more related to usage, so you might have better luck asking on the users list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Thanks. -Ben On 2014-03-03 03:09, Nora Zhou wrote: > Hi, > > I recently deploy Bare-meta

Re: [openstack-dev] Proposal to move from Freenode to OFTC

On 03/04/2014 05:01 AM, Thierry Carrez wrote: James E. Blair wrote: Freenode has been having a rough time lately due to a series of DDoS attacks which have been increasingly disruptive to collaboration. Fortunately there's an alternative. OFTC http://www.oftc.net/> is a robust and established a

Re: [openstack-dev] Neutron: Need help with tox failure in VPN code

All, I found the problem… There is a race condition on the LB vs VPN unit tests. I've seen it with just reference VPN code, when trying to load the service driver via configuration. Essentially, VPN sets up cfg.CONF with service driver entry, and then starts the Neutron plugin to handle various

[openstack-dev] [Murano] Hooking the external events discussion

Hi folks, On today's IRC meeting there was a very interesting discussion about publishing of handlers for external events in Murano applications. It turns out that the topic is pretty hot and requires some more discussions. So, it was suggested to host an additional meeting to cover this topic. S

[openstack-dev] [Murano] Community Meeting minutes - 03/04/2014

Hi, Thanks for joining murano weekly meeting. Here are the meeting minutes and the logs: http://eavesdrop.openstack.org/meetings/murano/2014/murano.2014-03-04-17.01.html http://eavesdrop.openstack.org/meetings/murano/2014/murano.2014-03-04-17.01.log.html See you next week! -- Regards, Alexander

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

On Tue, Mar 04, 2014 at 12:01:00PM -0500, Brian Haley wrote: > On 03/03/2014 11:18 AM, Collins, Sean wrote: > > On Mon, Mar 03, 2014 at 09:39:42PM +0800, Xuhan Peng wrote: > >> Currently, only security group rule direction, protocol, ethertype and port > >> range are supported by neutron security g

Re: [openstack-dev] [Nova] What is the currently accepted way to do plugins

This brings up something that's been gnawing at me for a while now ... why use entry-point based loaders at all? I don't see the problem they're trying to solve. (I thought I got it for a while, but I was clearly fooling myself) 1. If you use the "load all drivers in this category" feature, that

Re: [openstack-dev] [Cinder] Get volumes REST API with filters and limit

Duncan Thomas wrote on 03/04/2014 07:53:49 AM: > From: Duncan Thomas > To: "OpenStack Development Mailing List (not for usage questions)" > , > Date: 03/04/2014 08:06 AM > Subject: Re: [openstack-dev] [Cinder] Get volumes REST API with > filters and limit > > Definitely file a bug... a script to

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

On 03/04/2014 12:26 PM, Vishvananda Ishaya wrote: > > On Mar 4, 2014, at 9:10 AM, Russell Bryant wrote: >> >> Thank you all for your participation on this topic. It has been quite >> controversial, but the API we expose to our users is a really big deal. >> I'm feeling more and more confident th

[openstack-dev] [heat]Policy on upgades required config changes

Hi all, As some of you know, I've been working on the instance-users blueprint[1]. This blueprint implementation requires three new items to be added to the heat.conf, or some resources (those which create keystone users) will not work: https://review.openstack.org/#/c/73978/ https://review.open

Re: [openstack-dev] Proposal to move from Freenode to OFTC

>#1) do we believe OFTC is fundamentally better equipped to resist a >DDOS, or do we just believe they are a smaller target? The ongoing DDOS >on meetup.com the past 2 weeks is a good indicator that being a smaller >fish only helps for so long. It seems like we would need a answer to this question

Re: [openstack-dev] Toward SQLAlchemy 0.9.x compatibility everywhere for Icehouse

On 3/3/2014 8:59 AM, Thomas Goirand wrote: On 03/03/2014 01:14 PM, Thomas Goirand wrote: On 03/03/2014 11:24 AM, Thomas Goirand wrote: It looks like my patch fixes the first unit test failure. Though we still need a fix for the 2nd problem: AttributeError: 'module' object has no attribute 'Ab

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

On Mar 4, 2014, at 9:10 AM, Russell Bryant wrote: > > Thank you all for your participation on this topic. It has been quite > controversial, but the API we expose to our users is a really big deal. > I'm feeling more and more confident that we're coming through this with > a much better underst

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

On Tue, Mar 4, 2014 at 11:10 AM, Russell Bryant wrote: > On 03/03/2014 12:32 PM, Russell Bryant wrote: > > There has been quite a bit of discussion about the future of the v3 API > > recently. > > :-) > > Since this proposal was posted, it is clear that there is not much > support for it, much

Re: [openstack-dev] [Nova] What is the currently accepted way to do plugins

On 03/04/2014 06:27 AM, Murray, Paul (HP Cloud Services) wrote: > One of my patches has a query asking if I am using the agreed way to > load plugins: https://review.openstack.org/#/c/71557/ > > I followed the same approach as filters/weights/metrics using > nova.loadables. Was there an agreement

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

On 03/03/2014 12:32 PM, Russell Bryant wrote: > There has been quite a bit of discussion about the future of the v3 API > recently. :-) Since this proposal was posted, it is clear that there is not much support for it, much less consensus. That's progress because it now seems clear to me that

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

On 03/03/2014 11:18 AM, Collins, Sean wrote: > On Mon, Mar 03, 2014 at 09:39:42PM +0800, Xuhan Peng wrote: >> Currently, only security group rule direction, protocol, ethertype and port >> range are supported by neutron security group rule data structure. To allow > > If I am not mistaken, I belie

Re: [openstack-dev] [oslo] rpc concurrency control rfc

On Tue, Mar 04, 2014 at 04:15:03PM +, Duncan Thomas wrote: > On 28 November 2013 10:14, Daniel P. Berrange wrote: > > > For this specific block zero'ing case it occurred to me that it might > > be sufficient to just invoke 'ionice dd' instead of 'dd' and give it > > a lower I/O priority class

Re: [openstack-dev] Proposal to move from Freenode to OFTC

On 03/04/2014 06:13 PM, Julien Danjou wrote: > On Tue, Mar 04 2014, James E. Blair wrote: > >> If there aren't objections to this plan, I think we can propose a motion >> to the TC with a date and move forward with it fairly soon. > > That plan LGTM, and +1 for OFTC. :) Same over here, +1 for OF

Re: [openstack-dev] [oslo] rpc concurrency control rfc

On 28 November 2013 10:14, Daniel P. Berrange wrote: > For this specific block zero'ing case it occurred to me that it might > be sufficient to just invoke 'ionice dd' instead of 'dd' and give it > a lower I/O priority class than normal. Excuse the thread necromancy, I've just been searching for

Re: [openstack-dev] [marconi] Proposal to add Fei Long Wang (flwang) as a core reviewer

> Hi folks, I'd like to propose adding Fei Long Wang (flwang) as a core > reviewer on the Marconi team. He has been contributing regularly over the > past couple of months, and has proven to be a careful reviewer with good > judgment. > > All Marconi ATC's, please respond with a +1 or --1. > > C

Re: [openstack-dev] [Neutron][IPv6] Update the Wiki with links to blueprints and reviews

On Tue, Mar 04, 2014 at 04:06:02PM +, Robert Li (baoli) wrote: > Hi Sean, > > I just added the ipv6-prefix-delegation BP that can be found using the > search link on the ipv6 wiki. More details about it will be added once I > find time. Perfect - we'll probably want to do a session at the sum

Re: [openstack-dev] [3rd party testing] How to setup CI? Take #2

On Tue, 2014-03-04 at 16:31 +0100, Luke Gorrie wrote: > Option 1: Should I debug the CI implementation we developed and tested > back in December, which was not based on Tempest but rather on our > private integration test method that we used in the Havana cycle? The > debugging that is needed is m

Re: [openstack-dev] [marconi] Proposal to add Fei Long Wang (flwang) as a core reviewer

The poll has closed. flwang has been promoted to Marconi core. @kgriffs ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Update the Wiki with links to blueprints and reviews

Hi Sean, I just added the ipv6-prefix-delegation BP that can be found using the search link on the ipv6 wiki. More details about it will be added once I find time. thanks, --Robert On 3/4/14 10:05 AM, "Collins, Sean" wrote: >Hi All, > >We've got a lot of work in progress, so if you >have a blu

Re: [openstack-dev] Proposal to move from Freenode to OFTC

++, OFTC looks nice. On Tue, Mar 4, 2014 at 3:31 PM, Daniel P. Berrange wrote: > On Tue, Mar 04, 2014 at 11:12:13AM +, Stephen Gran wrote: >> On 04/03/14 11:01, Thierry Carrez wrote: >> >James E. Blair wrote: >> >>Freenode has been having a rough time lately due to a series of DDoS >> >>attac

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

On 03/03/2014 06:32 PM, Russell Bryant wrote: > There has been quite a bit of discussion about the future of the v3 API > recently. There has been growing support for the idea that we should > change course and focus on evolving the existing v2 API instead of > putting out a new major revision. T

  1   2   >