Re: [openstack-dev] [Neutron][LBaaS] Continuing on "Calling driver interface on every API request"

Hi The right layer for this validation is the Neutron REST layer. Since the current validation engine in this layer can only do attribute level validation (e.g make sure timeout is int and timeout > 5) but can't do entity level validation (e.g timeout > delay), you can find entity level validat

Re: [openstack-dev] [nova] fair standards for all hypervisor drivers

On Mon, 2014-08-11 at 15:25 -0700, Joe Gordon wrote: > > > > On Sun, Aug 10, 2014 at 11:59 PM, Mark McLoughlin > wrote: > On Fri, 2014-08-08 at 09:06 -0400, Russell Bryant wrote: > > On 08/07/2014 08:06 PM, Michael Still wrote: > > > It seems to me that the tension here

Re: [openstack-dev] [Nova] PCI support

Hi Gary, Mellanox already established CI support on Mellanox SR-IOV NICs, as one of the jobs of Mellanox External Testing CI (Check-MLNX-Neutron-ML2-Sriov-driver). Meanwhile not voting, but will be soon. BR, Irena F

Re: [openstack-dev] [Neutron][LBaaS] Use cases with regards to VIP and routers

In the context of Octavia and Neutron LBaaS. Susanne On Mon, Aug 11, 2014 at 5:44 PM, Stephen Balukoff wrote: > Susanne, > > Are you asking in the context of Load Balancer services in general, or in > terms of the Neutron LBaaS project or the Octavia project? > > Stephen > > > On Mon, Aug 11, 2

Re: [openstack-dev] [Neutron] Is network ordering of vNICs guaranteed?

This bug was true in grizzly and older (and was reintroduced in icehouse for a few days but was fixed before the nova icehouse shipped). Aaron On Mon, Aug 11, 2014 at 7:10 AM, CARVER, PAUL wrote: >Armando M. [mailto:arma...@gmail.com] wrote: > > > > >>On 9 August 2014 10:16, Jay Pipes wro

[openstack-dev] [Ceilometer] Add a pollster plugin

Hi Folks, Is there any best practices or good way to debug whether new pollster plugin work fine for ceilometer? I'd like to add a new pollster plugin into Ceilometer by - adding a new item under enterypoint/ceilometer.poll.central in setup.cfg file - adding the implementation code in

[openstack-dev] [nova] 9 days until feature proposal freeze

Hi, this is just a friendly reminder that we are now 9 days away from feature proposal freeze for nova. If you think your blueprint isn't going to make it in time, then now would be a good time to let me know so that we can defer it until Kilo. That will free up reviewer time for other blueprints.

Re: [openstack-dev] [OpenStack][Docker][HEAT] Cloud-init and docker container

Hi, Are you aware of the dockter_container resource type (DockerInc::Docker::Container) in Heat contrib directory? I am seeing a 'CMD' property which is a list of command to run after the container is spawned. Is that what you want? Regards, Qiming On Tue, Aug 12, 2014 at 02:27:39PM +0800, J

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

Hi Paul, Below are some other useful GBP reference pages: https://wiki.opendaylight.org/view/Project_Proposals:Group_Based_Policy_Plugin http://www.cisco.com/en/US/prod/collateral/netmgtsw/ps13004/ps13460/white-paper-c11-729906_ns1261_Networking_Solutions_White_Paper.html I think the root cause o

Re: [openstack-dev] [OpenStack][Docker][HEAT] Cloud-init and docker container

Thanks Qiming. ;-) Yes, this is one solution for running user data when using docker container in HEAT. I see that the properties include almost all of the parameters used in "docker run". Do you know if docker container support cloud-init in a image? My understanding is NOT as I did not see "use

Re: [openstack-dev] [OpenStack][Docker][HEAT] Cloud-init and docker container

Don't have an answer to this. You may try it though. Regards, Qiming On Tue, Aug 12, 2014 at 04:52:58PM +0800, Jay Lau wrote: > Thanks Qiming. ;-) > > Yes, this is one solution for running user data when using docker container > in HEAT. I see that the properties include almost all of the par

[openstack-dev] Gantt project

This is to make sure that everyone knows about the Gantt project and to make sure that no one has a strong aversion to what we are doing. The basic goal is to split the scheduler out of Nova and create a separate project that, ultimately, can be used by other OpenStack projects that have a need

[openstack-dev] [ceilometer] gate-ceilometer-python33 failed because of wrong setup.py in happybase

Hi, # I'm sending same content email again because previous subject is not suitable. I did cherry-pick for "https://bugs.launchpad.net/ceilometer/+bug/1326250"; and executed git review (https://review.openstack.org/#/c/112806/). In review phase I got the error message from Jenkins. The reason

[openstack-dev] [ceilometer] tox -epy26 failed because of insufficient test environment

Hi, I got an error message when Jenkins executed "tox -epy26" in the following fix. https://review.openstack.org/#/c/112771/ I think that the reason of the error message is a mongod isn't installed in test environment. (it works in my test env) Do you have any idea to solve this? - setup-tes

Re: [openstack-dev] [OpenStack][Docker][HEAT] Cloud-init and docker container

I did not have the environment set up now, but by reviewing code, I think that the logic should be as following: 1) When using nova docker driver, we can use cloud-init or/and CMD in docker images to run post install scripts. myapp: Type: OS::Nova::Server Properties: flavor:

Re: [openstack-dev] [nova] fair standards for all hypervisor drivers

On Mon, Aug 11, 2014 at 03:25:39PM -0700, Joe Gordon wrote: > I am not sure if I follow. The gate issue with live snapshots has been > worked around by turning it off [0], so presumably this patch is forward > facing. I fail to see how this patch is needed to help the gate in the > future. Wouldn

Re: [openstack-dev] [tc][ceilometer] Some background on the gnocchi project

> >> Doesn't InfluxDB do the same? > > InfluxDB stores timeseries data primarily. > > > > Gnocchi in intended to store strongly-typed OpenStack resource > > representations (instance, images, etc.) in addition to providing > > a means to access timeseries data associated with those resources. > >

Re: [openstack-dev] [ceilometer] tox -epy26 failed because of insufficient test environment

Hisashi Osanai, yes, that is blocking the Ceilometer gate at all for now. The reason might be in updated centos6 image in the gate, but I have no opportunity to check it actually. Infra folks, can you help us? Thanks, Dina On Tue, Aug 12, 2014 at 1:47 PM, Osanai, Hisashi < osanai.hisa...@jp.fu

[openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Hey Nova-istas, While I was hacking on [1] I was considering how to approach the fact that we now need to track one more thing (NUMA node utilization) in our resources. I went with - "I'll add it to compute nodes table" thinking it's a fundamental enough property of a compute host that it deserves

Re: [openstack-dev] [ceilometer] tox -epy26 failed because of insufficient test environment

On Tuesday, August 12, 2014 7:05 PM, Dina Belova wrote: > that is blocking the Ceilometer gate at all for now. Thank you for your quick response. I understand current situation. Thanks again! Hisashi Osanai ___ OpenStack-dev mailing list OpenStack-dev

Re: [openstack-dev] [ceilometer] tox -epy26 failed because of insufficient test environment

Folks, it looks like mongo packages were retired as a result of this ticket: https://fedorahosted.org/rel-eng/ticket/5963 Although also it looks like this mistake was quickly reverted here: http://pkgs.fedoraproject.org/cgit/mongodb.git/commit/?h=el6 Let's wait if it fixed the issue, but it looks

[openstack-dev] [keystone] Configuring protected API functions to allow public access

Hi All, Correct me if I am wrong but I don't think you can configure the Keystone policy.json to allow public access to an API function, as far as I can tell you can allow access to any authenticated user regardless of role assignments but not public access. My use case is a client which allow

Re: [openstack-dev] [neutron] make mac address updatable: which plugins?

Hi Chuck, I'll comment regarding Mellanox Plug-in and Ml2 Mech driver in the review. BR, Irena -Original Message- From: Carlino, Chuck (OpenStack TripleO, Neutron) [mailto:chuck.carl...@hp.com] Sent: Wednesday, August 06, 2014 10:42 PM To: OpenStack Development Mailing List (not for usa

Re: [openstack-dev] Which program for Rally

On Aug 11, 2014, at 12:00 PM, David Kranz wrote: > On 08/06/2014 05:48 PM, John Griffith wrote: >> I have to agree with Duncan here. I also don't know if I fully understand >> the limit in options. Stress test seems like it could/should be different >> (again overlap isn't a horrible thing)

[openstack-dev] [neutron] Feature Proposal Freeze is 9 days away

Just a reminder that Neutron observes FPF [1], and it's 9 days away. We have an incredible amount of BPs which do not have code submitted yet. My suggestion to those who own one of these BPs would be to think hard about whether or not you can realistically land this code in Juno before jamming thin

Re: [openstack-dev] [oslo] oslo.concurrency repo review

On Mon, Aug 11 2014, Joshua Harlow wrote: > Sounds great, I've been wondering why > https://github.com/stackforge/tooz/commit/f3e11e40f9871f8328 happened/merged > (maybe it should be changed?). For the simple reason that there's people wanting to use a lock distributed against several processes w

Re: [openstack-dev] [ceilometer] gate-ceilometer-python33 failed because of wrong setup.py in happybase

On Tue, Aug 12 2014, Osanai, Hisashi wrote: > I did cherry-pick for "https://bugs.launchpad.net/ceilometer/+bug/1326250"; > and > executed git review (https://review.openstack.org/#/c/112806/). > > In review phase I got the error message from Jenkins. > The reason of the error is happybase-0.8 (

Re: [openstack-dev] [Ceilometer] Add a pollster plugin

On Aug 12, 2014, at 4:11 AM, Duan, Li-Gong (Gary@HPServers-Core-OE-PSC) wrote: > Hi Folks, > > Is there any best practices or good way to debug whether new pollster plugin > work fine for ceilometer? > > I’d like to add a new pollster plugin into Ceilometer by > - adding a new item un

Re: [openstack-dev] [Nova] PCI support

Thanks, the concern is for the code in Nova and not in Neutron. That is, there is quite a lot of PCI code being added and no way of knowing that it actually works (unless we trust the developers working on it :)). Thanks Gary From: Irena Berezovsky mailto:ire...@mellanox.com>> Date: Tuesday, Aug

Re: [openstack-dev] [nova] fair standards for all hypervisor drivers

On 08/12/2014 05:54 AM, Daniel P. Berrange wrote: >> I am less concerned about the contents of this patch, and more concerned >> with how such a big de facto change in nova policy (we accept untested code >> sometimes) without any discussion or consensus. In your comment on the >> revert [2], you s

[openstack-dev] Implications of moving functional tests to projects (was Re: Which program for Rally)

Changing subject line to continue thread about new $subj On 08/12/2014 08:56 AM, Doug Hellmann wrote: On Aug 11, 2014, at 12:00 PM, David Kranz > wrote: On 08/06/2014 05:48 PM, John Griffith wrote: I have to agree with Duncan here. I also don't know if I fully und

Re: [openstack-dev] [devstack] Core team proposals

These changes have been completed. Welcome Ian! dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][cisco] Cisco Nexus requires patched ncclient

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hey all, as per [1], Cisco Nexus ML2 plugin requires a patched version of ncclient from github. I wonder: - - whether this information is still current; - - why don't we depend on ncclient thru our requirements.txt file. [1]: https://wiki.openstac

Re: [openstack-dev] [oslo] oslo.concurrency repo review

Sure, thats great as to why a feature like it might exist (and I think such a feature is great to have, for cases when a bigger *distributed* system isn't desired). Just the one there taken from lockutils has some issues that IMHO I think tooz would be better to avoid for the time-being (until

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Hi Nikola, Le 12/08/2014 12:21, Nikola Đipanov a écrit : Hey Nova-istas, While I was hacking on [1] I was considering how to approach the fact that we now need to track one more thing (NUMA node utilization) in our resources. I went with - "I'll add it to compute nodes table" thinking it's a fu

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

(sorry for reposting, missed 2 links...) Hi Nikola, Le 12/08/2014 12:21, Nikola Đipanov a écrit : Hey Nova-istas, While I was hacking on [1] I was considering how to approach the fact that we now need to track one more thing (NUMA node utilization) in our resources. I went with - "I'll add it

Re: [openstack-dev] [oslo] oslo.concurrency repo review

On Tue, Aug 12 2014, Joshua Harlow wrote: […] > What do u think about waiting until pylockfile is ready and avoiding 1-4 > from above? At least if taskflow uses tooz I surely don't want taskflow to > have to deal with #1-4 (which it will inherit from tooz if taskflow starts > to use tooz by the v

[openstack-dev] [nova] Retrospective veto revert policy

Hey (Terrible name for a policy, I know) >From the version_cap saga here: https://review.openstack.org/110754 I think we need a better understanding of how to approach situations like this. Here's my attempt at documenting what I think we're expecting the procedure to be: https://etherpad

Re: [openstack-dev] [nova] Retrospective veto revert policy

On 08/12/2014 10:56 AM, Mark McLoughlin wrote: > Hey > > (Terrible name for a policy, I know) > > From the version_cap saga here: > > https://review.openstack.org/110754 > > I think we need a better understanding of how to approach situations > like this. > > Here's my attempt at documenting

Re: [openstack-dev] [neutron][cisco] Cisco Nexus requires patched ncclient

On 8/12/2014 10:27 AM, Ihar Hrachyshka wrote: > as per [1], Cisco Nexus ML2 plugin requires a patched version of > ncclient from github. I wonder: > > - - whether this information is still current; Please see: https://review.openstack.org/112175 But we need to do backports before updating the wi

Re: [openstack-dev] [nova] Retrospective veto revert policy

> Looks reasonable to me. +1 --Dan signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Gantt project

Thanks for the info. It does seem like most OpenStack projects have some concept of a "scheduler", as you mentioned. Perhaps that's expected in any distributed system. Is it expected or assumed that Gantt will become the common scheduler for all OpenStack projects? That is, is Gantt's plan and/

Re: [openstack-dev] [OpenStack][Docker][HEAT] Cloud-init and docker container

On Tue, Aug 12, 2014 at 5:53 AM, Jay Lau wrote: > I did not have the environment set up now, but by reviewing code, I think > that the logic should be as following: > 1) When using nova docker driver, we can use cloud-init or/and CMD in > docker images to run post install scripts. > myapp: >

Re: [openstack-dev] [keystone] Configuring protected API functions to allow public access

Hi Kristy, Have you try the "[]" or "@" rule as mentioned here? https://github.com/openstack/keystone/blob/master/keystone/openstack/common/ policy.py#L71 Guang > -Original Message- > From: K.W.S.Siu [mailto:k.w.s@kent.ac.uk] > Sent: Tuesday, August 12, 2014 3:44 AM > To: opensta

Re: [openstack-dev] [nova] Retrospective veto revert policy

On 08/12/2014 10:56 AM, Mark McLoughlin wrote: Hey (Terrible name for a policy, I know) From the version_cap saga here: https://review.openstack.org/110754 I think we need a better understanding of how to approach situations like this. Here's my attempt at documenting what I think we're

Re: [openstack-dev] introducing cyclops

On Tue, Aug 12, 2014 at 05:47:49PM +1200, Fei Long Wang wrote: > Our suggestion for the first IRC meeting is 25/August 8PM-10PM UTC time on > Freenodes's #openstack-rating channel. > > Thoughts? Please reply with the best date/time for you so we can figure out a > time to start. > I'll like to p

Re: [openstack-dev] [nova] Retrospective veto revert policy

On Tue, Aug 12, 2014 at 9:56 AM, Mark McLoughlin wrote: > Hey > > (Terrible name for a policy, I know) > > From the version_cap saga here: > > https://review.openstack.org/110754 > > I think we need a better understanding of how to approach situations > like this. > > Here's my attempt at docume

[openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?

Hi, I'm trying to use the built in secure decorator in Pecan for access control, and I'ld like to get the name of the method that is wrapped from within the decorator. For instance, if I'm wrapping MetersController.get_all with an @secure decorator, is there a way for the decorator code to know

Re: [openstack-dev] [nova] Retrospective veto revert policy

On Tue, Aug 12, 2014 at 8:46 AM, Jay Pipes wrote: > On 08/12/2014 10:56 AM, Mark McLoughlin wrote: > >> Hey >> >> (Terrible name for a policy, I know) >> >> From the version_cap saga here: >> >>https://review.openstack.org/110754 >> >> I think we need a better understanding of how to approac

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

Per the blueprint spec [1], what has been proposed are optional extensions which complement the existing Neutron core resources' model: " The main advantage of the extensions described in this blueprint is that they allow for an application-centric interface to Neutron that complements the existin

Re: [openstack-dev] [neutron] Feature Proposal Freeze is 9 days away

What would be the best practice for those who realize their work will not make it in Juno? Is it enough to not submit code for review? Would it be better to also request a change in milestone? Thanks, Mohammad From: Kyle Mestery To: "OpenStack Development Mailing List (not for usage q

Re: [openstack-dev] [Neutron][LBaaS] Continuing on "Calling driver interface on every API request"

Hi, I think we are debating some edge-case. An important part of the flavor framework is the ability of me the operator to say failover from Octavia to an F5. So as an operator I would ensure to only offer the features in that flavor which both support. So in order to arrive at Brandon’s exampl

Re: [openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?

Do u know if ceilometer is using six.wraps? If so, that helper adds in the `__wrapped__` attribute to decorated methods (which can be used to find the original decorated function). If just plain functools are used (and python3.x isn't used) then it will be pretty hard afaik to find the origin

Re: [openstack-dev] [cinder] Bug#1231298 - size parameter for volume creation

On 11 August 2014 21:03, Dean Troyer wrote: > On Mon, Aug 11, 2014 at 5:34 PM, Duncan Thomas > wrote: >> >> Making an previously mandatory parameter optional, at least on the >> command line, does break backward compatibility though, does it? >> Everything that worked before will still work. > >

Re: [openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?

This should give you what you need: from pecan.core import state state.controller On 08/12/14 04:08 PM, Pendergrass, Eric wrote: > Hi, I'm trying to use the built in secure decorator in Pecan for access > control, and I'ld like to get the name of the method that is wrapped from > within the dec

Re: [openstack-dev] [neutron] [third-party] Cisco NXOS is not tested anymore

If this plugin will be deprecated in Juno it means that the code will be there for this release, I will expect to have the CI still running for until the code is completely removed from the Neutron tree. Anyway, Infra guys will have the last word here! Edgar On 8/11/14, 5:38 PM, "Anita Kuno" wr

Re: [openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?

Thanks Ryan, but for some reason the controller attribute is None: (Pdb) from pecan.core import state (Pdb) state.__dict__ {'hooks': [, , , ], 'app': , 'request': http://localhost:8777/v2/meters>, 'controller': None, 'response': } > -Original Message- > From: Ryan Petrello [mailto:rya

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

On 08/12/2014 04:49 PM, Sylvain Bauza wrote: > (sorry for reposting, missed 2 links...) > > Hi Nikola, > > Le 12/08/2014 12:21, Nikola Đipanov a écrit : >> Hey Nova-istas, >> >> While I was hacking on [1] I was considering how to approach the fact >> that we now need to track one more thing (NUMA

Re: [openstack-dev] [neutron] Feature Proposal Freeze is 9 days away

If you know it won't make it, please let me know so I can remove your BP from the LP milestone. Thanks! Kyle On Tue, Aug 12, 2014 at 11:18 AM, Mohammad Banikazemi wrote: > What would be the best practice for those who realize their work will not > make it in Juno? Is it enough to not submit co

Re: [openstack-dev] [keystone] Configuring protected API functions to allow public access

On Tue, Aug 12, 2014 at 10:30 AM, Yee, Guang wrote: > Hi Kristy, > > Have you try the "[]" or "@" rule as mentioned here? > That still requires valid authentication though, just not any specific authorization. I don't think we have a way to express truly public resources in oslo.policy. > > >

Re: [openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?

Can you share some code? What do you mean by, "is there a way for the decorator code to know it was called by MetersController.get_all" On 08/12/14 04:46 PM, Pendergrass, Eric wrote: > Thanks Ryan, but for some reason the controller attribute is None: > > (Pdb) from pecan.core import state > (Pd

Re: [openstack-dev] [all] The future of the integrated release

On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon wrote: > > > > On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery wrote: > >> On Thu, Aug 7, 2014 at 1:26 PM, Joe Gordon wrote: >> > >> > >> > >> > On Tue, Aug 5, 2014 at 9:03 AM, Thierry Carrez >> > wrote: >> >> >> >> Hi everyone, >> >> >> >> With the in

Re: [openstack-dev] Which program for Rally

On Mon, Aug 11, 2014 at 07:06:11PM -0400, Zane Bitter wrote: > On 11/08/14 16:21, Matthew Treinish wrote: > >I'm sorry, but the fact that the > >docs in the rally tree has a section for user testimonials [4] I feel speaks > >a > >lot about the intent of the project. > > What... does that even mea

Re: [openstack-dev] [neutron][cisco] Cisco Nexus requires patched ncclient

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/08/14 17:12, Henry Gessau wrote: > On 8/12/2014 10:27 AM, Ihar Hrachyshka wrote: >> as per [1], Cisco Nexus ML2 plugin requires a patched version of >> ncclient from github. I wonder: >> >> - - whether this information is still current; > >

Re: [openstack-dev] [nova] Retrospective veto revert policy

On Tue, Aug 12, 2014 at 03:56:44PM +0100, Mark McLoughlin wrote: > Hey > > (Terrible name for a policy, I know) > > From the version_cap saga here: > > https://review.openstack.org/110754 > > I think we need a better understanding of how to approach situations > like this. > > Here's my atte

Re: [openstack-dev] [neutron] [third-party] Cisco NXOS is not tested anymore

On 2014-08-12 16:35:18 + (+), Edgar Magana wrote: > If this plugin will be deprecated in Juno it means that the code > will be there for this release, I will expect to have the CI still > running for until the code is completely removed from the Neutron > tree. > > Anyway, Infra guys will

Re: [openstack-dev] [all] The future of the integrated release

On Aug 12, 2014, at 1:44 PM, Dolph Mathews wrote: > > On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon wrote: > > > > On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery wrote: > On Thu, Aug 7, 2014 at 1:26 PM, Joe Gordon wrote: > > > > > > > > On Tue, Aug 5, 2014 at 9:03 AM, Thierry Carrez > > wro

Re: [openstack-dev] [Neutron][QA] Enabling full neutron Job

And just when the patch was only missing a +A, another bug slipped in! The nova patch to fix it is available at [1] And while we're there, it won't be a bad idea to also push the neutron full job, as non-voting, into the integrated gate [2] Thanks in advance, (especially to the nova and infra cor

Re: [openstack-dev] [all] The future of the integrated release

On Tue, Aug 12, 2014 at 10:44 AM, Dolph Mathews wrote: > > On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon wrote: >> >> Slow review: by limiting the number of blueprints up we hope to focus our >> efforts on fewer concurrent things >> slow code turn around: when a blueprint is given a slot (runway)

Re: [openstack-dev] [all] The future of the integrated release

On Aug 12, 2014, at 11:08 AM, Doug Hellmann wrote: > > On Aug 12, 2014, at 1:44 PM, Dolph Mathews wrote: > >> >> On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon wrote: >> >> >> >> On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery wrote: >> On Thu, Aug 7, 2014 at 1:26 PM, Joe Gordon wrote: >> >

[openstack-dev] [Horizon] Feature Proposal Freeze date Aug 14

It came to my attention today that I've only communicated this in Horizon team meetings. Due to the high number of blueprints already targeting Juno-3 and the resource contention of reviewers, I have set the Horizon Feature Proposal Deadline at August 14 (August 12 actually, but since I didn't inc

Re: [openstack-dev] [all] The future of the integrated release

> It seems like this is exactly what the slots give us, though. The core review > team picks a number of slots indicating how much work they think they can > actually do (less than the available number of blueprints), and then > blueprints queue up to get a slot based on priorities and turnaround

Re: [openstack-dev] [neutron][cisco] Cisco Nexus requires patched ncclient

On 8/12/2014 1:53 PM, Ihar Hrachyshka wrote: > On 12/08/14 17:12, Henry Gessau wrote: >> On 8/12/2014 10:27 AM, Ihar Hrachyshka wrote: >>> as per [1], Cisco Nexus ML2 plugin requires a patched version of >>> ncclient from github. I wonder: >>> >>> - - whether this information is still current; >>

Re: [openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?

Sure, here's the decorated method from v2.py: class MetersController(rest.RestController): """Works on meters.""" @pecan.expose() def _lookup(self, meter_name, *remainder): return MeterController(meter_name), remainder @wsme_pecan.wsexpose([Meter],

Re: [openstack-dev] [neutron] [third-party] Cisco NXOS is not tested anymore

On 8/12/2014 2:04 PM, Jeremy Stanley wrote: > On 2014-08-12 16:35:18 + (+), Edgar Magana wrote: >> If this plugin will be deprecated in Juno it means that the code >> will be there for this release, I will expect to have the CI still >> running for until the code is completely removed from

Re: [openstack-dev] [nova] 9 days until feature proposal freeze

On 08/12/2014 04:13 AM, Michael Still wrote: Hi, this is just a friendly reminder that we are now 9 days away from feature proposal freeze for nova. If you think your blueprint isn't going to make it in time, then now would be a good time to let me know so that we can defer it until Kilo. That w

Re: [openstack-dev] [neutron] [third-party] Cisco NXOS is not tested anymore

Henry, That makes a lot of sense to me. If the code will be remove in Juno, then there is nothing else to discuss. Thank you so much for providing detailed information and sorry for bothering you with this issue. Edgar On 8/12/14, 11:49 AM, "Henry Gessau" wrote: >On 8/12/2014 2:04 PM, Jeremy

Re: [openstack-dev] [all] The future of the integrated release

On Tue, Aug 12, 2014 at 1:08 PM, Doug Hellmann wrote: > > On Aug 12, 2014, at 1:44 PM, Dolph Mathews > wrote: > > > On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon > wrote: > >> >> >> >> On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery wrote: >> >>> On Thu, Aug 7, 2014 at 1:26 PM, Joe Gordon >>> wro

[openstack-dev] [Neutron] [LBaaS] Followup on Service Ports and IP Allocation - IPAM from LBaaS Mid Cycle meeting

Hi Mark, Going through the notes from our midcycle meeting (see https://etherpad.openstack.org/p/juno-lbaas-mid-cycle-hackathon) I noticed your name next to the Service Port and IPAM: Service Ports * Owner: Mark * Nova hacks * Nova port that nova borrows but doesn't

Re: [openstack-dev] [Neutron][LBaaS] Use cases with regards to VIP and routers

>From the perspective of Blue Box: * Load balancing appliances will often (usually?) live outside the same subnet as back-end member VMs. * The network in which the load balancing appliances live will usually have a default router (gateway) * We don't anticipate the need for using extra_routes at

Re: [openstack-dev] [nova] fair standards for all hypervisor drivers

On Mon, Aug 11, 2014 at 08:05:26AM -0400, Russell Bryant wrote: > On 08/11/2014 07:58 AM, Russell Bryant wrote: > > On 08/11/2014 05:53 AM, Daniel P. Berrange wrote: > >> There is work to add support for this in devestack already which I > >> prefer since it makes it easy for developers to get an e

[openstack-dev] [NFV] Meeting cancelled and time for next week.

Hi all, I am not available to run the meeting tomorrow and was not able to identify someone to step in, given this I think it makes sense to cancel for this week. For next week I would like to trial the new alternate time we discussed, 1600 UTC on a Thursday, and assuming there is reasonable a

[openstack-dev] [Octavia] Agenda for 13 Aug 2014 meeting

Hi folks! This is what I have for my tentative agenda for tomorrow's Octavia meeting. Please e-mail me if you want anything else added to this list. (Also, I will start putting these weekly agendas in the wiki in the near future.) * Discuss future of Octavia in light of Neutron-incubator project

Re: [openstack-dev] [neutron] [third-party] Cisco NXOS is not tested anymore

On 08/12/2014 01:16 PM, Edgar Magana wrote: > Henry, > > That makes a lot of sense to me. > If the code will be remove in Juno, then there is nothing else to discuss. > > Thank you so much for providing detailed information and sorry for > bothering you with this issue. > > Edgar I don't think i

Re: [openstack-dev] [nova] fair standards for all hypervisor drivers

On 08/12/2014 03:40 PM, Kashyap Chamarthy wrote: > On Mon, Aug 11, 2014 at 08:05:26AM -0400, Russell Bryant wrote: >> On 08/11/2014 07:58 AM, Russell Bryant wrote: >>> On 08/11/2014 05:53 AM, Daniel P. Berrange wrote: There is work to add support for this in devestack already which I pref

Re: [openstack-dev] [nova] Retrospective veto revert policy

Dan Smith wrote: >> Looks reasonable to me. > > +1 +1 -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Le 12/08/2014 18:54, Nikola Đipanov a écrit : On 08/12/2014 04:49 PM, Sylvain Bauza wrote: (sorry for reposting, missed 2 links...) Hi Nikola, Le 12/08/2014 12:21, Nikola Đipanov a écrit : Hey Nova-istas, While I was hacking on [1] I was considering how to approach the fact that we now need

Re: [openstack-dev] [nova] Retrospective veto revert policy

On Tue, Aug 12, 2014 at 9:56 AM, Mark McLoughlin wrote: > Hey > > (Terrible name for a policy, I know) > > From the version_cap saga here: > > https://review.openstack.org/110754 > > I think we need a better understanding of how to approach situations > like this. > > Here's my attempt at docum

Re: [openstack-dev] [nova] Retrospective veto revert policy

This looks reasonable to me, with a slight concern that I don't know what step five looks like... What if we can never reach a consensus on an issue? Michael On Wed, Aug 13, 2014 at 12:56 AM, Mark McLoughlin wrote: > Hey > > (Terrible name for a policy, I know) > > From the version_cap saga here

Re: [openstack-dev] [nova] so what do i do about libvirt-python if i'm on precise?

On Wed, 2014-07-30 at 15:34 -0700, Clark Boylan wrote: > On Wed, Jul 30, 2014, at 03:23 PM, Jeremy Stanley wrote: > > On 2014-07-30 13:21:10 -0700 (-0700), Joe Gordon wrote: > > > While forcing people to move to a newer version of libvirt is > > > doable on most environments, do we want to do that

Re: [openstack-dev] [all] The future of the integrated release

On Tue, Aug 12, 2014 at 11:08 AM, Doug Hellmann wrote: > > On Aug 12, 2014, at 1:44 PM, Dolph Mathews > wrote: > > > On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon > wrote: > >> >> >> >> On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery wrote: >> >>> On Thu, Aug 7, 2014 at 1:26 PM, Joe Gordon >>> wr

Re: [openstack-dev] [Nova] Nominating Jay Pipes for nova-core

On Wed, 2014-07-30 at 14:02 -0700, Michael Still wrote: > Greetings, > > I would like to nominate Jay Pipes for the nova-core team. > > Jay has been involved with nova for a long time now. He's previously > been a nova core, as well as a glance core (and PTL). He's been around > so long that the

Re: [openstack-dev] [Heat] SoftwareDeployment resource is always in progress

On 11/08/14 20:42, david ferahi wrote: > Hello, > > I 'm trying to create a simple stack with heat (Icehouse release). > The template contains SoftwareConfig, SoftwareDeployment and a single > server resources. > > The problem is that the SoftwareDeployment resource is always in > progress ! > So f

Re: [openstack-dev] [neutron] [third-party] Update on third party CI in Neutron

Kyle, One Convergence third-party CI is failing due to https://bugs.launchpad.net/neutron/+bug/1353309. Let me know if we should turn off the CI logs until this is fixed or if we need to fix anything on the CI end. I think one other third-party CI (Mellanox) is failing due to the same issue. Reg

Re: [openstack-dev] [nova] Retrospective veto revert policy

Should subsequent patches be reverted as well that depended on the change in question? On Tue, Aug 12, 2014 at 7:56 AM, Mark McLoughlin wrote: > Hey > > (Terrible name for a policy, I know) > > From the version_cap saga here: > > https://review.openstack.org/110754 > > I think we need a bette

Re: [openstack-dev] [neutron] [third-party] Update on third party CI in Neutron

On 08/12/2014 03:23 PM, Hemanth Ravi wrote: > Kyle, > > One Convergence third-party CI is failing due to > https://bugs.launchpad.net/neutron/+bug/1353309. > > Let me know if we should turn off the CI logs until this is fixed or if we > need to fix anything on the CI end. I think one other third-

Re: [openstack-dev] [OpenStack][Docker][HEAT] Cloud-init and docker container

Thanks Eric for the confirmation ;-) 2014-08-12 23:30 GMT+08:00 Eric Windisch : > > > > On Tue, Aug 12, 2014 at 5:53 AM, Jay Lau wrote: > >> I did not have the environment set up now, but by reviewing code, I think >> that the logic should be as following: >> 1) When using nova docker driver, w

Re: [openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?

Yep, you're right, this doesn't seem to work. The issue is that security is enforced at routing time (while the controller is still actually being discovered). In order to do this sort of thing with the `check_permissions`, we'd probably need to add a feature to pecan. On 08/12/14 06:38 PM, Pend

[openstack-dev] [TripleO] lists and merges

Just ran into a merge conflict with https://review.openstack.org/#/c/105878/ which looks like this: - name: nova_osapi port: 8774 net_binds: *public_binds - name: nova_metadata port: 8775 net_binds: *public_binds

[openstack-dev] [Neutron] Ryu plugin deprecation

hi, As announced in the last neutron meeting [1], the Ryu plugin is being deprecated. Juno is the last release to support Ryu plugin. The Ryu team will be focusing on the ofagent going forward. btw, i'll be mostly offline from Aug 16 to Aug 31. sorry for inconvenience. [1] http://eavesdrop.ope

  1   2   >