Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

Hi Kevin, Does it make sense to introduce "GeneralvSwitch MD", working with VIF_TYPE_TAP? It just do very simple port bind just like OVS and bridge. Then anyone can implement their backend and agent without patch neutron drivers. Best Regards Henry On Fri, Dec 5, 2014 at 4:23 PM, Kevin Benton w

Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver

Hi Daniel, Please see inline -Original Message- From: Daniel P. Berrange [mailto:berra...@redhat.com] Sent: Tuesday, December 09, 2014 4:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

Remove everything out of tree, and leave only Neutron API framework as integration platform, would lower the attractions of the whole Openstack Project. Without a default "good enough" reference backend from community, customers have to depends on packagers to fully test all backends for them. Can

Re: [openstack-dev] [neutron][TripleO] Clear all flows when ovs agent start? why and how avoid?

On Fri, Oct 31, 2014 at 3:28 PM, Ben Nemec wrote: > On 10/29/2014 10:17 AM, Kyle Mestery wrote: > > On Wed, Oct 29, 2014 at 7:25 AM, Hly wrote: > >> > >> > >> Sent from my iPad > >> > >> On 2014-10-29, at 下午8:01, Robert van Leeuwen < > robert.vanleeu...@spilgames.com> wrote: > >> > > I find

[openstack-dev] [Mistral] Global Context and Execution Environment

Nikolay, Regarding whether the execution environment BP is the same as this global context BP, I think the difference is in the scope of the variables. The global context that I'm proposing is provided to the workflow at execution and is only relevant to this execution. For example, some context

[openstack-dev] [Murano] Oslo.messaging error

HI Team, I am installing Murano on the Ubuntu 14.04 Juno setup and when I try the below install murano-api I encounter the below error. Please assist. When I try to install I am using the Murano guide link provided below: https://murano.readthedocs.org/en/latest/install/manual.html I am try

[openstack-dev] [neutron][third-party] failing CIs

Hi all, Most of the Neutron third-party Cis are failing at the moment, and it’s because of the ongoing services split. The patch to get devstack working again will likely merge tomorrow. We will send another ML message when the split is “finished”. Thanks, Doug _

[openstack-dev] [Murano] Cannot find murano.conf

HI Team, I am installing Murano on the Ubuntu 14.04 Juno setup and when I try the below install murano-api I encounter the below error. Please assist. When I try to install $ tox -e venv -- murano-api --config-file ./etc/murano/murano.conf pip can't proceed with requirement 'pycrypto>=2.6 (fro

Re: [openstack-dev] [Mistral] Query on creating multiple resources

Hundred percent agree with all said by Zane. Renat Akhmerov @ Mirantis Inc. > On 10 Dec 2014, at 02:20, Zane Bitter wrote: > > On 09/12/14 03:48, Renat Akhmerov wrote: >> Hey, >> >> I think it’s a question of what the final goal is. For just creating >> security groups as a resource I think

Re: [openstack-dev] [Telco][NFV] Meeting Reminder - Wednesday Dec 10 @ 2200 UTC in #openstack-meeting

...and of course I meant December *10th* - sorry! -Steve - Original Message - > From: "Steve Gordon" > > Hi all, > > Just a reminder that the Telco Working Group will be meeting @ 2200 UTC in > #openstack-meeting on Wednesday December 9th. Draft agenda is available > here: > > htt

[openstack-dev] [Telco][NFV] Meeting Reminder - Wednesday Dec 9 @ 2200 UTC in #openstack-meeting

Hi all, Just a reminder that the Telco Working Group will be meeting @ 2200 UTC in #openstack-meeting on Wednesday December 9th. Draft agenda is available here: https://etherpad.openstack.org/p/nfv-meeting-agenda Please feel free to add anything you think I missed. Thanks, Steve

[openstack-dev] DVR meeting tomorrow - will be cancelled.

Hi Folks, There will be not DVR meeting tomorrow. See you all next week. Thanks Swaminathan Vasudevan Systems Software Engineer (TC) HP Networking Hewlett-Packard 8000 Foothills Blvd M/S 5541 Roseville, CA - 95747 tel: 916.785.0937 fax: 916.785.1815 email: swaminathan.vasude...@hp.com

Re: [openstack-dev] [neutron][lbaas] Kilo Midcycle Meetup

It's set. We'll be having the meetup on Feb 2-6 in San Antonio at RAX HQ. I'll add a list of hotels and the address on the etherpad. https://etherpad.openstack.org/p/lbaas-kilo-meetup Thanks, Brandon On Tue, 2014-12-02 at 17:27 +, Brandon Logan wrote: > Per the meeting, put together an eth

Re: [openstack-dev] [neutron] Linux capabilities vs sudo/rootwrap?

Afaik ovs-vsctl just talks to ovsdb-server via some regular IPC mechanism - usually a unix socket, see --db. So yes, provided the file permissions on the unix socket work out, then no root powers (or any kernel capability) is necessary. Having said that, there will be plenty of examples where sud

[openstack-dev] [NFV][Telco] Service VM v/s its basic framework

[cid:image003.png@01D0145E.75813DF0] I have some of the basic question w.r.t Service-VM running the NFV. (These Service-VMs can be vNAT, vFW, vDPI, vRouting , vCPE etc ), 1. When these service-VM runs over the cloud (over OpenStack CN) each will be treated as Routable entity in the net

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

Hi Armando, Thanks for your feedback! Okay, so if I understand you correctly, you're saying that was easier for > you to go entirely out of tree, and that you have done so already. Okay, > good for you, problem solved! > > One point that should be clear here is that, if someone is completely > co

Re: [openstack-dev] [neutron] Linux capabilities vs sudo/rootwrap?

Is ovs-vsctl gonna be happy with CAP_NET_ADMIN? On 12/10/2014 02:43 AM, Angus Lees wrote: [I tried to find any previous discussion of this and failed - I'd appreciate a pointer to any email threads / specs where this has already been discussed.] Currently neutron is given the ability to do ju

Re: [openstack-dev] [Third-party] Voting for new Third-party CI weekly IRC meeting time

So far it looks like we have centered around 2 options: Option "A" 1200 and 2200 UTC Option "D" 1500 and 0400 UTC There is still time to pick your best time. Please vote at https://www.google.com/moderator/#16/e=21b93c Special thanks to Steve, Daya, Markus, Mikhail, Emily, Nurit, Edwin and Ramy f

[openstack-dev] [neutron] Linux capabilities vs sudo/rootwrap?

[I tried to find any previous discussion of this and failed - I'd appreciate a pointer to any email threads / specs where this has already been discussed.] Currently neutron is given the ability to do just about anything to networking via rootwrap, sudo, and the IpFilter check (allow anything exce

Re: [openstack-dev] [Third-party] Voting for new Third-party CI weekly IRC meeting time

Anita, I really appreciate your willingness to host a meeting, but, the response from the group in the previous thread was in support of the alternating meeting approach. Daya, Erlon, Trinath, Steve, Misha and others all agreed. I am confused why you would not want to go with the consensus on this

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

@Armando, Okay, so if I understand you correctly, you're saying that was easier for you to go entirely out of tree, and that you have done so already. Okay, good for you, problem solved! One point that should be clear here is that, if someone is completely comfortable with being entirely out of t

Re: [openstack-dev] People of OpenStack (and their IRC nicks)

Excerpts from Angus Salkeld's message of 2014-12-09 15:25:59 -0800: > On Wed, Dec 10, 2014 at 5:11 AM, Stefano Maffulli > wrote: > > > On 12/09/2014 06:04 AM, Jeremy Stanley wrote: > > > We already have a solution for tracking the contributor->IRC > > > mapping--add it to your Foundation Member P

Re: [openstack-dev] [qa] How to delete a VM which is in ERROR state?

Hi, This case is always tested by Tempest on the gate. https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_delete_server.py#L152 So I guess this problem wouldn't happen on the latest version at least. Thanks Ken'ichi Ohmichi --- 2014-12-10 6:32 GMT+09:00 Joe Gord

Re: [openstack-dev] [Nova][Neutron][NFV][Third-party] CI for NUMA, SR-IOV, and other features that can't be tested on current infra.

On Tue, Nov 25, 2014 at 2:01 PM, Steve Gordon wrote: > - Original Message - > > From: "Daniel P. Berrange" > > To: "Dan Smith" > > > > On Thu, Nov 13, 2014 at 05:43:14PM +, Daniel P. Berrange wrote: > > > On Thu, Nov 13, 2014 at 09:36:18AM -0800, Dan Smith wrote: > > > > > That soun

[openstack-dev] [murano] Review Day Announcement

I would like to announce Review Day for Murano, that is scheduled to this Friday, Dec 12. We will start at 10:00 UTC and will continue until 10:00 of the next day to span across the globe. We encourage to join our review day anyone who is interested in Murano, not only core-reviewers. Rules: * re

Re: [openstack-dev] [nova][docker][containers][qa] nova-docker CI failing a lot on unrelated nova patches

On Tue, Dec 9, 2014 at 3:18 PM, Eric Windisch wrote: > >> While gating on nova-docker will prevent patches that cause nova-docker >> to break 100% to land, it won't do a lot to prevent transient failures. To >> fix those we need people dedicated to making sure nova-docker is working. >> >> > > Wh

Re: [openstack-dev] People of OpenStack (and their IRC nicks)

On Wed, Dec 10, 2014 at 5:11 AM, Stefano Maffulli wrote: > On 12/09/2014 06:04 AM, Jeremy Stanley wrote: > > We already have a solution for tracking the contributor->IRC > > mapping--add it to your Foundation Member Profile. For example, mine > > is in there already: > > > > http://www.openst

Re: [openstack-dev] [NFV][Telco] pxe-boot

On Wed, Dec 3, 2014 at 1:16 AM, Pasquale Porreca < pasquale.porr...@dektech.com.au> wrote: > The use case we were thinking about is a Network Function (e.g. IMS Nodes) > implementation in which the high availability is based on OpenSAF. In this > scenario there is an Active/Standby cluster of 2 Sy

Re: [openstack-dev] [nova][docker][containers][qa] nova-docker CI failing a lot on unrelated nova patches

> > > While gating on nova-docker will prevent patches that cause nova-docker to > break 100% to land, it won't do a lot to prevent transient failures. To fix > those we need people dedicated to making sure nova-docker is working. > > What would be helpful for me is a way to know that our tests ar

Re: [openstack-dev] [keystone][all] Max Complexity Check Considered Harmful

On Wed, Dec 10, 2014 at 8:43 AM, Joe Gordon wrote: > > > On Mon, Dec 8, 2014 at 5:03 PM, Brant Knudson wrote: > >> >> Not too long ago projects added a maximum complexity check to tox.ini, >> for example keystone has "max-complexity=24". Seemed like a good idea at >> the time, but in a recent at

Re: [openstack-dev] [nova][docker][containers][qa] nova-docker CI failing a lot on unrelated nova patches

On Fri, Dec 5, 2014 at 11:43 AM, Ian Main wrote: > Sean Dague wrote: > > On 12/04/2014 05:38 PM, Matt Riedemann wrote: > > > > > > > > > On 12/4/2014 4:06 PM, Michael Still wrote: > > >> +Eric and Ian > > >> > > >> On Fri, Dec 5, 2014 at 8:31 AM, Matt Riedemann > > >> wrote: > > >>> This came up

Re: [openstack-dev] [keystone][all] Max Complexity Check Considered Harmful

On Mon, Dec 8, 2014 at 5:03 PM, Brant Knudson wrote: > > Not too long ago projects added a maximum complexity check to tox.ini, for > example keystone has "max-complexity=24". Seemed like a good idea at the > time, but in a recent attempt to lower the maximum complexity check in > keystone[1][2],

[openstack-dev] [Fuel] Hard Code Freeze for 6.0

Hi all, I'm glad to announce that we've reached Hard Code Freeze (HCF) [1] criteria for 6.0 milestone. stable/6.0 branches for our repos were created. Bug reporters, please do not forget to target both 6.1 (master) and 6.0 (stable/6.0) milestones since now. If the fix is merged to master, it has

[openstack-dev] [oslo.db] engine facade status, should reader transactions COMMIT or ROLLBACK?

Hi folks - Just a reminder that the majority of the enginefacade implementation is up for review, see that at: https://review.openstack.org/#/c/138215/.Needs a lot more people looking at it. Matthew Booth raised a good point which I also came across, which is of transactions that are “read

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

On 9 December 2014 at 13:59, Ivar Lazzaro wrote: > I agree with Salvatore that the split is not an easy thing to achieve for > vendors, and I would like to bring up my case to see if there are ways to > make this at least a bit simpler. > > At some point I had the need to backport vendor code fro

Re: [openstack-dev] [Ironic] Fuel agent proposal

On Tue Dec 09 2014 at 9:45:51 AM Fox, Kevin M wrote: > We've been interested in Ironic as a replacement for Cobbler for some of > our systems and have been kicking the tires a bit recently. > > While initially I thought this thread was probably another "Fuel not > playing well with the community"

Re: [openstack-dev] [qa] How to delete a VM which is in ERROR state?

On Sat, Dec 6, 2014 at 5:08 PM, Danny Choi (dannchoi) wrote: > Hi, > > I have a VM which is in ERROR state. > > > +--+--+++-++ > > | ID

Re: [openstack-dev] [hacking] hacking package upgrade dependency with setuptools

On Tue, Dec 9, 2014 at 11:05 AM, Surojit Pathak wrote: > Hi all, > > On a RHEL system, as I upgrade hacking package from 0.8.0 to 0.9.5, I see > flake8 stops working. Upgrading setuptools resolves the issue. But I do not > see a change in version for pep8 or setuptools, with the upgrade in > setu

Re: [openstack-dev] [Ironic] Fuel agent proposal

On Tue Dec 09 2014 at 10:13:52 AM Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Kevin, > > Just to make sure everyone understands what Fuel Agent is about. Fuel > Agent is agnostic to image format. There are 3 possibilities for image > format > 1) DISK IMAGE contains GPT/MBR table and a

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

I agree with Salvatore that the split is not an easy thing to achieve for vendors, and I would like to bring up my case to see if there are ways to make this at least a bit simpler. At some point I had the need to backport vendor code from Juno to Icehouse (see first attempt here [0]). That in [0]

Re: [openstack-dev] [Ironic] Fuel agent proposal

On Tue Dec 09 2014 at 7:49:32 AM Yuriy Zveryanskyy < yzveryans...@mirantis.com> wrote: > On 12/09/2014 05:00 PM, Jim Rollenhagen wrote: > > On Tue, Dec 09, 2014 at 04:01:07PM +0400, Vladimir Kozhukalov wrote: > > >> Many many various cases are possible. If you ask why we'd like to > support > >> a

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On Tue, 2014-12-09 at 13:46 -0500, Sean Dague wrote: > Yes, the following fails H305 and H306. > > nova/tests/fixtures.py > > """Fixtures for Nova tests.""" > from __future__ import absolute_import > > import gettext > import logging > import os > import uuid > > import fixtures > from oslo.con

Re: [openstack-dev] [Mistral] Query on creating multiple resources

On 09/12/14 03:48, Renat Akhmerov wrote: Hey, I think it’s a question of what the final goal is. For just creating security groups as a resource I think Georgy and Zane are right, just use Heat. If the goal is to try Mistral or have this simple workflow as part of more complex then it’s total

Re: [openstack-dev] [Nova] question about "Get Guest Info" row in HypervisorSupportMatrix

On Tue, Dec 09, 2014 at 06:15:01PM +0100, Markus Zoeller wrote: > > > On Tue, Dec 09, 2014 at 06:33:47PM +0300, Dmitry Guryanov wrote: > > > > > > Hello! > > > > > > There is a feature in HypervisorSupportMatrix > > > (https://wiki.openstack.org/wiki/HypervisorSupportMatrix) called "Get > Guest

Re: [openstack-dev] [Ironic] Fuel agent proposal

Thank you for explaining in detail what Fuel's use case is. I was lacking this information, and taking the FuelAgent proposal in isolation. Allow me to respond to several points inline... On Tue Dec 09 2014 at 4:08:45 AM Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Just a short explan

[openstack-dev] [oslo] updated instructions for creating a library repository

Now that the infra manual includes the “Project Creator’s Guide”, I have updated our wiki page to refer to it. I could use a sanity check to make sure I don’t have things in a bad order. If you have a few minutes to help with that, please look over https://wiki.openstack.org/wiki/Oslo/CreatingAN

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On 12/09/2014 02:46 PM, Jeremy Stanley wrote: > On 2014-12-09 13:49:00 -0500 (-0500), Sean Dague wrote: > [...] >> And I also think that if a commit message change doesn't retrigger all >> the tests, people will be a lot happier updating them. > > Agreed--though this will need a newer Gerrit plus

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On 2014-12-09 13:49:00 -0500 (-0500), Sean Dague wrote: [...] > And I also think that if a commit message change doesn't retrigger all > the tests, people will be a lot happier updating them. Agreed--though this will need a newer Gerrit plus a new feature in Zuul so it recognizes the difference in

Re: [openstack-dev] [oslo][Keystone] Policy graduation

On Dec 9, 2014, at 12:18 PM, Morgan Fainberg wrote: > I would like to propose that we keep the policy library under the oslo > program. As with other graduated projects we will maintain a core team (that > while including the oslo-core team) will be comprised of the expected > individuals fro

Re: [openstack-dev] People of OpenStack (and their IRC nicks)

On 12/09/2014 06:04 AM, Jeremy Stanley wrote: > We already have a solution for tracking the contributor->IRC > mapping--add it to your Foundation Member Profile. For example, mine > is in there already: > > http://www.openstack.org/community/members/profile/5479 I recommend updating the opens

Re: [openstack-dev] [neutron] mid-cycle "hot reviews"

On Tue, Dec 9, 2014 at 3:33 AM, Miguel Ángel Ajo wrote: > > Hi all! > > It would be great if you could use this thread to post hot reviews on > stuff > that it’s being worked out during the mid-cycle, where others from different > timezones could participate. I think we've used the etherpad [1]

[openstack-dev] [hacking] hacking package upgrade dependency with setuptools

Hi all, On a RHEL system, as I upgrade hacking package from 0.8.0 to 0.9.5, I see flake8 stops working. Upgrading setuptools resolves the issue. But I do not see a change in version for pep8 or setuptools, with the upgrade in setuptools. Any issue in packaging? Any explanation of this behavi

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On 12/09/2014 12:07 PM, Jeremy Stanley wrote: > On 2014-12-09 11:56:54 -0500 (-0500), Sean Dague wrote: >> Honestly, any hard rejection ends up problematic. For instance, it >> means it's impossible to include actual urls in commit messages to >> reference things without a url shortener much of the

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On 12/09/2014 12:20 PM, Kevin L. Mitchell wrote: > On Tue, 2014-12-09 at 12:05 -0500, Sean Dague wrote: >>> I agree that dropping H302 and the grouping checks makes sense. I >> think >>> we should keep the H301, H303, H304, and the basic ordering checks, >>> however; it doesn't seem to me that the

Re: [openstack-dev] [Ironic] Fuel agent proposal

Excerpts from Yuriy Zveryanskyy's message of 2014-12-09 04:05:03 -0800: > Good day Ironicers. > > I do not want to discuss questions like "Is feature X good for release > Y?" or "Is feature Z in Ironic scope or not?". > I want to get an answer for this: Is Ironic a flexible, easy extendable > an

Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver

On Dec 9, 2014, at 7:04 AM, Daniel P. Berrange wrote: > On Tue, Dec 09, 2014 at 10:53:19AM +0100, Maxime Leroy wrote: >> I have also proposed a blueprint to have a new plugin mechanism in >> nova to load external vif driver. (nova-specs: >> https://review.openstack.org/#/c/136827/ and nova (rfc p

[openstack-dev] [neutron] Tap-aaS Spec for Kilo

Hi, The latest version of the Tap-aaS spec is available at: https://review.openstack.org/#/c/140292/ It was uploaded last night and we are hoping that it will be considered as a candidate for the Kilo release. Thanks, Anil ___ OpenStack-dev mailing l

Re: [openstack-dev] [cinder] Code pointer for processing cinder backend config

On 09:36 Sat 06 Dec , Pradip Mukhopadhyay wrote: > Where this config info is getting parsed out in the cinder code? https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/netapp/options.py https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/netapp/common.py#L76

Re: [openstack-dev] [Mistral]

Guys, May be I misunderstood something here but what is the difference between this one and https://blueprints.launchpad.net/mistral/+spec/mistral-execution-environment ? On Tue, Dec 9, 2014 at 5:35 PM, Dmitri Zimine wrote: > Winson, > > thanks for filing the blueprint: > https://blueprints.lau

[openstack-dev] [Keystone] No Meeting Today

This is a quick note that the Keystone team will not be holding a meeting today. Based upon last week’s meeting the goals for today are to review open specs[1] and blocking code reviews for the k1 milestone[2] instead. We will continue with the normal meeting schedule next week. [1]  https://re

Re: [openstack-dev] [Ironic] Fuel agent proposal

Kevin, Just to make sure everyone understands what Fuel Agent is about. Fuel Agent is agnostic to image format. There are 3 possibilities for image format 1) DISK IMAGE contains GPT/MBR table and all partitions and metadata in case of md or lvm. That is just something like what you get when run 'd

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

On 9 December 2014 at 17:32, Armando M. wrote: > > > On 9 December 2014 at 09:41, Salvatore Orlando > wrote: > >> I would like to chime into this discussion wearing my plugin developer >> hat. >> >> We (the VMware team) have looked very carefully at the current proposal >> for splitting off driv

Re: [openstack-dev] [Ironic] Fuel agent proposal

We've been interested in Ironic as a replacement for Cobbler for some of our systems and have been kicking the tires a bit recently. While initially I thought this thread was probably another "Fuel not playing well with the community" kind of thing, I'm not thinking that any more. Its deeper th

Re: [openstack-dev] [Ironic] Fuel agent proposal

Vladimir, IMO there is more "global" problem. Anyone who wants to use baremetal deploy service should resolve problems with power management, PXE/iPXE support, DHCP, etc. Or he/she can use Ironic. User has his own vision of deploy workflow and features needed for it. He hears from Ironic people:

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On Dec 9, 2014, at 10:05 AM, Sean Dague wrote: > On 12/09/2014 09:11 AM, Doug Hellmann wrote: >> >> On Dec 9, 2014, at 6:39 AM, Sean Dague wrote: >> >>> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely. >>> >>> 1 - the entire H8* group. This doesn't function on pyt

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

On 9 December 2014 at 09:41, Salvatore Orlando wrote: > I would like to chime into this discussion wearing my plugin developer hat. > > We (the VMware team) have looked very carefully at the current proposal > for splitting off drivers and plugins from the main source code tree. > Therefore the c

Re: [openstack-dev] [oslo][Keystone] Policy graduation

On 12/09/2014 12:18 PM, Morgan Fainberg wrote: I would like to propose that we keep the policy library under the oslo program. As with other graduated projects we will maintain a core team (that while including the oslo-core team) will be comprised of the expected individuals from the Identity

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On Tue, 2014-12-09 at 12:05 -0500, Sean Dague wrote: > > I agree that dropping H302 and the grouping checks makes sense. I > think > > we should keep the H301, H303, H304, and the basic ordering checks, > > however; it doesn't seem to me that these would be that difficult to > > implement or maint

[openstack-dev] [oslo][Keystone] Policy graduation

I would like to propose that we keep the policy library under the oslo program. As with other graduated projects we will maintain a core team (that while including the oslo-core team) will be comprised of the expected individuals from the Identity and other security related teams. The change in

[openstack-dev] [Nova] question about "Get Guest Info" row in HypervisorSupportMatrix

> > On Tue, Dec 09, 2014 at 06:33:47PM +0300, Dmitry Guryanov wrote: > > > > Hello! > > > > There is a feature in HypervisorSupportMatrix > > (https://wiki.openstack.org/wiki/HypervisorSupportMatrix) called "Get Guest > > Info". Does anybody know, what does it mean? I haven't found anything l

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On 2014-12-09 11:56:54 -0500 (-0500), Sean Dague wrote: > Honestly, any hard rejection ends up problematic. For instance, it > means it's impossible to include actual urls in commit messages to > reference things without a url shortener much of the time. Fair enough. I think this makes it a human

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On 12/09/2014 11:58 AM, Kevin L. Mitchell wrote: > On Tue, 2014-12-09 at 10:05 -0500, Sean Dague wrote: >> Sure, the H8* group is git commit messages. It's checking for line >> length in the commit message. > > I agree the H8* group should be dropped. It would be appropriate to > create a new gat

Re: [openstack-dev] [all] Deprecating exceptions

On 2014-12-09 16:50:48 +0100 (+0100), Jakub Ruzicka wrote: > On 22.9.2014 17:24, Ihar Hrachyshka wrote: [...] > > Aren't clients supposed to be backwards compatible? Isn't it the exact > > reason why we don't maintain stable branches for client modules? > > Supposed, yes. However, it's not ensured

Re: [openstack-dev] [Keystone] OSAAA-Policy

On December 9, 2014 at 10:43:51 AM, Adam Young (ayo...@redhat.com) wrote: On 12/09/2014 10:57 AM, Brad Topol wrote: +1!  Makes sense. --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet:  bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From:  

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On Tue, 2014-12-09 at 10:05 -0500, Sean Dague wrote: > Sure, the H8* group is git commit messages. It's checking for line > length in the commit message. I agree the H8* group should be dropped. It would be appropriate to create a new gate check job that validated that, but it should not be part

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On 12/09/2014 11:28 AM, Jeremy Stanley wrote: > On 2014-12-09 07:29:31 -0800 (-0800), Monty Taylor wrote: >> I DO like something warning about commit subject length ... but maybe >> that should be a git-review function or something. > [...] > > How about a hook in Gerrit to refuse commits based on

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On 12/09/2014 11:41 AM, Johannes Erdfelt wrote: > On Tue, Dec 09, 2014, Sean Dague wrote: >> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely. >> >> 1 - the entire H8* group. This doesn't function on python code, it >> functions on git commit message, which makes it toug

Re: [openstack-dev] [Third-party] Voting for new Third-party CI weekly IRC meeting time

On 12/09/2014 08:32 AM, Kurt Taylor wrote: > All of the feedback so far has supported moving the existing IRC > Third-party CI meeting to better fit a worldwide audience. > > The consensus is that we will have only 1 meeting per week at alternating > times. You can see examples of other teams with

Re: [openstack-dev] [Nova] question about "Get Guest Info" row in HypervisorSupportMatrix

On Tue, Dec 09, 2014 at 06:33:47PM +0300, Dmitry Guryanov wrote: > Hello! > > There is a feature in HypervisorSupportMatrix > (https://wiki.openstack.org/wiki/HypervisorSupportMatrix) called "Get Guest > Info". Does anybody know, what does it mean? I haven't found anything like > this neither i

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On Tue, Dec 09, 2014, Sean Dague wrote: > I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely. > > 1 - the entire H8* group. This doesn't function on python code, it > functions on git commit message, which makes it tough to run locally. It > also would be a reason to prev

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

I would like to chime into this discussion wearing my plugin developer hat. We (the VMware team) have looked very carefully at the current proposal for splitting off drivers and plugins from the main source code tree. Therefore the concerns you've heard from Gary are not just ramblings but are the

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On Tue, Dec 09, 2014 at 10:15:34AM -0600, Brian Curtin wrote: > On Tue, Dec 9, 2014 at 9:05 AM, Sean Dague wrote: > > - [H305 H306 H307] Organize your imports according to the `Import order > > template`_ and `Real-world Import Order Examples`_ below. > > > > I think these remain reasonable guid

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On Tue, Dec 09, 2014, Sean Dague wrote: > This check should run on any version of python and give the same > results. It does not, because it queries python to know what's in stdlib > vs. not. Just to underscore that it's difficult to get right, I found out recently that hacking doesn't do a grea

Re: [openstack-dev] [cinder] HA issues

There are some significant limitations to the pure taskflow approach, however some combination of atomic micro-state management and taskflow persistence is being looked at Duncan Thomas On Dec 9, 2014 6:24 PM, "Dulko, Michal" wrote: > And what about no recovery in case of failure mid-task? I can

Re: [openstack-dev] [Keystone] OSAAA-Policy

On 12/09/2014 10:57 AM, Brad Topol wrote: +1! Makes sense. --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Morgan Fainberg To: Adam Young , "OpenStack Development Mailing List (no

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On 2014-12-09 07:29:31 -0800 (-0800), Monty Taylor wrote: > I DO like something warning about commit subject length ... but maybe > that should be a git-review function or something. [...] How about a hook in Gerrit to refuse commits based on some simple (maybe even project-specific) rules? -- Je

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On 12/09/2014 11:15 AM, Brian Curtis wrote: > On Tue, Dec 9, 2014 at 9:05 AM, Sean Dague wrote: >> - [H305 H306 H307] Organize your imports according to the `Import order >> template`_ and `Real-world Import Order Examples`_ below. >> >> I think these remain reasonable guidelines, but H302 is ex

Re: [openstack-dev] [Ironic] Fuel agent proposal

We assume next step will be to put provision data (disk partition > scheme, maybe other data) into driver_info and make Fuel Agent driver > able to serialize those data (special format) and implement a > corresponding data driver in Fuel Agent for this format. Again very > simple. Maybe it is time

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On Tue, Dec 9, 2014 at 9:05 AM, Sean Dague wrote: > - [H305 H306 H307] Organize your imports according to the `Import order > template`_ and `Real-world Import Order Examples`_ below. > > I think these remain reasonable guidelines, but H302 is exceptionally > tricky to get right, and we keep not

Re: [openstack-dev] [cinder] HA issues

And what about no recovery in case of failure mid-task? I can see that there's some TaskFlow integration done. This lib seems to address these issues (if used with taskflow.persistent submodule, which Cinder isn't using). Any plans for further integration with TaskFlow? -Original Message---

Re: [openstack-dev] [Keystone] OSAAA-Policy

+1! Makes sense. --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Morgan Fainberg To: Adam Young , "OpenStack Development Mailing List (not for usage questions)" Date: 12/08

[openstack-dev] Hyper-V Meeting Canceled for Today

Hi All, I'm canceling the hyper-v meeting today due to a conflicting shedules, we will resume next week. Peter J. Pouliot CISSP Microsoft Enterprise Cloud Solutions C:\OpenStack New England Research & Development Center 1 Memorial Drive Cambridge, MA 02142 P: 1.(857).4536436 E: ppoul...@microsof

[openstack-dev] new library oslo.context released

The Oslo team is pleased to announce the release of oslo.context 0.1.0. This is the first version of oslo.context, the library containing the base class for the request context object. This is a relatively small module, but we’ve placed it in a separate library so oslo.messaging and oslo.log can

Re: [openstack-dev] [all] Deprecating exceptions

On 22.9.2014 17:24, Ihar Hrachyshka wrote: > On 22/09/14 17:07, Radomir Dopieralski wrote: >> Horizon's tests were recently broken by a change in the Ceilometer >> client that removed a deprecated exception. The exception was >> deprecated for a while already, but as it often is, nobody did the >

Re: [openstack-dev] [Ironic] Fuel agent proposal

On 12/09/2014 05:00 PM, Jim Rollenhagen wrote: On Tue, Dec 09, 2014 at 04:01:07PM +0400, Vladimir Kozhukalov wrote: Just a short explanation of Fuel use case. Fuel use case is not a cloud. Fuel is a deployment tool. We install OS on bare metal servers and on VMs and then configure this OS using

[openstack-dev] [Nova] question about "Get Guest Info" row in HypervisorSupportMatrix

Hello! There is a feature in HypervisorSupportMatrix (https://wiki.openstack.org/wiki/HypervisorSupportMatrix) called "Get Guest Info". Does anybody know, what does it mean? I haven't found anything like this neither in nova api nor in horizon and nova command line. -- Thanks, Dmitry Guryanov

[openstack-dev] [Third-party] Voting for new Third-party CI weekly IRC meeting time

All of the feedback so far has supported moving the existing IRC Third-party CI meeting to better fit a worldwide audience. The consensus is that we will have only 1 meeting per week at alternating times. You can see examples of other teams with alternating meeting times at: https://wiki.openstack

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On 12/09/2014 03:39 AM, Sean Dague wrote: > I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely. > > 1 - the entire H8* group. This doesn't function on python code, it > functions on git commit message, which makes it tough to run locally. It > also would be a reason to pre

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On Tue, Dec 9, 2014 at 12:39 PM, Sean Dague wrote: > 1 - the entire H8* group. This doesn't function on python code, it > functions on git commit message, which makes it tough to run locally. > I do run them locally using git-review custom script features which would launch a flake8 before sendi

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On 12/09/2014 09:11 AM, Doug Hellmann wrote: > > On Dec 9, 2014, at 6:39 AM, Sean Dague wrote: > >> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely. >> >> 1 - the entire H8* group. This doesn't function on python code, it >> functions on git commit message, which make

  1   2   >