Re: [openstack-dev] [horizon] Support for Django 1.7: there's a bit of work, though it looks fixable to me...

On 08/04/2014 05:05 PM, Romain Hardouin wrote: > Hi, > > Note that Django 1.7 requires Python 2.7 or above[1] while Juno still > requires to be compatible with Python 2.6 (Suse ES 11 uses 2.6 if my memory > serves me). > > [1] https://docs.djangoproject.com/en/dev/releases/1.7/#python-compatibi

Re: [openstack-dev] [Neutron] Route cannot be deleted

Hi, The issue was resolved by following the commands below. neutron port-update --device_owner clear neutron port-delete neutron router-delete Thanks, Sayali. On Sat, Aug 2, 2014 at 3:49 PM, Sayali Lunkad wrote: > Hi Zzelle, > > Thanks for the prompt response. > As you mentioned I clear

[openstack-dev] [taskflow] How to use the logbook

Hello, I'm currently evaluating taskflow. I read through the examples and extracted bits and peaces to write a little app in order to see how it works. Right now I'm most interested in the job board and the flows. In my code I post a Job to a jobboard, pick it up, end execute a flow (similar to t

[openstack-dev] [neutron][third-party] Protocol for bringing up CI for a new driver?

Howdy, Could somebody please clarify the protocol for bringing up a CI for a new Neutron driver? Specifically, how does one resolve the chicken-and-egg situation of: 1. CI should be enabled before the driver is merged. 2. CI should test the refspecs given by Gerrit, which will not include the c

Re: [openstack-dev] [tc][rally][qa] Application for a new OpenStack Program: Performance and Scalability

Boris Pavlovic wrote: > By the way, I am really not sure how being one Program will help us to > collaborate? What it actually changes? Being in one program means you're in the same team, the same meetings, with ultimate decisions taken by the same one PTL. It obviously makes it easier to avoid d

Re: [openstack-dev] [horizon] Support for Django 1.7: there's a bit of work, though it looks fixable to me...

On 05/08/14 08:11, Thomas Goirand wrote: > And there's also test_change_password_shows_message_on_login_page which > fails. Here's the end of the stack dump: > > File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line > 375, in send > raise ConnectionError(e, request=request) > Co

Re: [openstack-dev] [tc][rally][qa] Application for a new OpenStack Program: Performance and Scalability

Marc, A good example for that is Rally's Tempest configuration module. Currently > Rally has all the logic to configure Tempest and for that you have your > own way to build the tempest conf out of a template [1]. If the QA > team decides to rework the configuration Rally is broken. Absolutely a

Re: [openstack-dev] [neutron][third-party] Protocol for bringing up CI for a new driver?

Hi Luke, Once in place, the CI system should be able to pick up the patches from the new plugin or driver on gerrit. In my opinion, successful CI runs against those patches should constitute a sufficient proof of the validity of the CI system. Salvatore Il 05/ago/2014 09:57 "Luke Gorrie" ha scri

Re: [openstack-dev] [Neutron] Route cannot be deleted

try to check if there are floatingips on the VMs on that subnet 962b8364-a2b4-46cc-95be-28cbab62b8c2 On Tue, Aug 5, 2014 at 3:24 PM, Sayali Lunkad wrote: > Hi, > > The issue was resolved by following the commands below. > > neutron port-update --device_owner clear > neutron port-delete > neut

Re: [openstack-dev] [horizon] Support for Django 1.7: there's a bit of work, though it looks fixable to me...

On 08/05/2014 04:06 PM, Julie Pichon wrote: > On 05/08/14 08:11, Thomas Goirand wrote: >> And there's also test_change_password_shows_message_on_login_page which >> fails. Here's the end of the stack dump: >> >> File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line >> 375, in send >>

[openstack-dev] backport fixes to old branches

Hi, I would like to have the following fix for IceHouse branch because the problem happens on it but the fix was committed on Juno-2 only. Is there any process to backport fixes to old branches? https://bugs.launchpad.net/ceilometer/+bug/1326250 Best Regards, Hisashi Osanai _

[openstack-dev] [Neutron][LBaaS] "status" in entities

Hi: I think we had some discussions around 'status' attribute earlier, I don't recollect the conclusion. Does it reflect the deployment status? Meaning, if the status of an entity is ACTIVE, the user has to infer that the entity is deployed successfully in the backen

Re: [openstack-dev] backport fixes to old branches

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/08/14 11:22, Osanai, Hisashi wrote: > > Hi, > > I would like to have the following fix for IceHouse branch because > the problem happens on it but the fix was committed on Juno-2 > only. Is there any process to backport fixes to old branches

Re: [openstack-dev] [TripleO] Strategy for merging Heat HOT port

On 04/08/14 00:50, Steve Baker wrote: > On 01/08/14 12:19, Steve Baker wrote: >> The changes to port tripleo-heat-templates to HOT have been rebased to >> the current state and are ready to review. They are the next steps in >> blueprint tripleo-juno-remove-mergepy. >> >> However there is coordinat

Re: [openstack-dev] [Heat][TripleO] Heat can't retrieve stack list

On 05/08/14 08:43, Peeyush Gupta wrote: > Hi all, > > I have been trying to set up tripleo using instack. > When I try to deploy overcloud, I get a heat related > error. Here it is: > > [stack@localhost ~]$ heat stack-list > ERROR: Timeout while waiting on RPC response - topic: "engine", RPC met

Re: [openstack-dev] [Neutron] Status of A/A HA for neutron-metadata-agent?

On 8/4/14, 5:39 PM, "mar...@redhat.com" wrote: >On 03/08/14 13:07, Gary Kotton wrote: >> Hi, >> Happy you asked about this. This is an idea that we have: >> >> Below is a suggestion on how we can improve the metadata service. This >>can >> be done by leveraging the a Load balancers supports X-

[openstack-dev] [neutron][third-party] A question about building third-party CI?

Hi folks, Recently I am working on building CI for our ml2 driver. Since our code has not been merged, when running the devstack-vm-gate script, the code in neutron project will be updated so our code is missing. Without the code, devstack will fail since it is configured to use our own ml2 dri

Re: [openstack-dev] [neutron][third-party] A question about building third-party CI?

Hi- In your CI, before running devstack, configure neutron code base with your code (yet to be approved) and run stack.sh. -- Trinath Somanchi - B39208 trinath.soman...@freescale.com | extn: 4048 From: Yangxurong [mailto:yangxur...@huawei.com] Sent: Tuesday, August 05, 2014 4:06 PM To: OpenSt

Re: [openstack-dev] [git-review] Supporting development in local branches

On 08/04/2014 07:18 PM, Yuriy Taraday wrote: > Hello, git-review users! > > 0. create new local branch; > > master: M-- > \ > feature: * > > 1. start hacking, doing small local meaningful (to you) commits; > > master: M-- > \ > feature: A-B-...-C > > 2. since hac

Re: [openstack-dev] [Neutron] l2pop problems

Hi Mathieu: We have deployed the new l2pop described in the previous mail in our environment, and works pretty well. It solved the timing problem, and also reduces lots of l2pop rpc calls. I'm going to file a blueprint to propose the changes. On Fri, Jul 18, 2014 at 10:26 PM, Mathieu Rohon wrote

Re: [openstack-dev] backport fixes to old branches

Thank you for your quick response. I don't have enough rights for nominating the bug so I put the tag "icehouse-backport-potential" instead. https://bugs.launchpad.net/ceilometer/+bug/1326250 On Tuesday, August 05, 2014 6:35 PM, Ihar Hrachyshka wrote: > https://wiki.openstack.org/wiki/StableBr

Re: [openstack-dev] [neutron][third-party] Protocol for bringing up CI for a new driver?

Hi Salvatore, On 5 August 2014 10:34, Salvatore Orlando wrote: > Once in place, the CI system should be able to pick up the patches from > the new plugin or driver on gerrit. > > In my opinion, successful CI runs against those patches should constitute > a sufficient proof of the validity of the

Re: [openstack-dev] backport fixes to old branches

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/08/14 13:30, Osanai, Hisashi wrote: > > Thank you for your quick response. > > I don't have enough rights for nominating the bug so I put the tag > "icehouse-backport-potential" instead. > > https://bugs.launchpad.net/ceilometer/+bug/1326250

Re: [openstack-dev] [neutron][third-party] Protocol for bringing up CI for a new driver?

Hope this links helps you http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/ http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/ http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/ -- Trinath Somanchi - B39208 trinat

Re: [openstack-dev] Networking Docs Swarm - Brisbane 9 August

Thanks Lana! On Mon, Aug 4, 2014 at 11:32 PM, Mike Spreitzer wrote: > Lana Brindley wrote on 08/04/2014 11:05:24 > PM: > > > I just wanted to let you all know about the OpenStack Networking Docs > > Swarm being held in Brisbane on 9 August. > > ... > > +++ on this. > > I can not contribute ans

[openstack-dev] oslo.vmware 0.5.0 released

The Oslo team is pleased to announce that oslo.vmware 0.5.0, the latest version of the OpenStack/VMware integration library, has been released. This version includes: * _trunc_id to check if the session_id is not None * Enabled hacking check H305 * Imported Translations from Transifex * Add cons

Re: [openstack-dev] [git-review] Supporting development in local branches

Le 05/08/2014 13:06, Ryan Brown a écrit : On 08/04/2014 07:18 PM, Yuriy Taraday wrote: Hello, git-review users! all changes from your branch is uploaded to Gerrit as _one_ change request; master: M---N-O-... \\\E* <= uploaded feature: A-B-...-C-D-...-E +1, this

Re: [openstack-dev] Step by step OpenStack Icehouse Installation Guide

Hi ! Yes using scripts is easy for users! In this guide, our objective was to detail all the steps of installation. We will use scripts in our next guide ;) Thank you for suggestion :) Regards, Chaima Ghribi 2014-08-05 3:46 GMT+02:00 Shake Chen : > Hi > > maybe you can consider use script cre

[openstack-dev] [OpenStack][Summit] Please vote if you are interested

Hi, We submitted three simple but very interesting topics for Paris Summit, please check if you are interested. 1) Holistic Resource Scheduling: https://www.openstack.org/vote-paris/Presentation/schedule-multiple-tiers-enterprise-application-in-openstack-environment-prs-a-holistic-scheduler-for-b

Re: [openstack-dev] [OpenStack][Summit] Please vote if you are interested

Le 05/08/2014 15:56, Jay Lau a écrit : Hi, We submitted three simple but very interesting topics for Paris Summit, please check if you are interested. 1) Holistic Resource Scheduling: https://www.openstack.org/vote-paris/Presentation/schedule-multiple-tiers-enterprise-application-in-opensta

Re: [openstack-dev] [taskflow] How to use the logbook

Hi there! I'll be back next week but the feature u are wanting currently doesn't exist (so that would be why u aren't seeing such data). If u want it then a blueprint or spec seems appropriate for this kind of historical information. Sound good? Btw, the logbook is more for state and flow pers

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

On 8/4/14, 4:27 PM, Mark McClain wrote: All- tl;dr * Group Based Policy API is the kind of experimentation we be should attempting. * Experiments should be able to fail fast. * The master branch does not fail fast. * StackForge is the proper home to conduct this experiment. The disconnect her

Re: [openstack-dev] [git-review] Supporting development in local branches

On 08/05/2014 09:27 AM, Sylvain Bauza wrote: > > Le 05/08/2014 13:06, Ryan Brown a écrit : > -1 to this as git-review default behaviour. Ideally, branches should be > identical in between Gerrit and local Git. Probably not as default behaviour (people who don't want that workflow would be drive

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

Hi, Is there any description of how this will be consumed by Nova. My concern is this code landing there. Thanks Gary From: Robert Kukura mailto:kuk...@noironetworks.com>> Reply-To: OpenStack List mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, August 5, 2014 at 5:20 PM To: OpenStack L

Re: [openstack-dev] [Neutron][LBaaS] "status" in entities

Hello Vijay! Well this is a hold over from v1, but the status is a provisioning status. So yes, when something is deployed successfully it should be ACTIVE. The exception to this is the member status, in that it's status can be INACTIVE if a health check fails. Now this will probably cause edg

Re: [openstack-dev] [Neutron][LBaaS] "status" in entities

There was also talk about a third administrative status like ON/OFF... We really need a deeper status discussion - likely high bandwith to work all of that out. German -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Tuesday, August 05, 2014 8:27 AM To:

Re: [openstack-dev] [git-review] Supporting development in local branches

Hi, I like the idea ... with complex change, it could useful for the understanding to split it into smaller changes during development. Do we need to expose such feature under git review? we could define a new subcommand? git reviewflow? Cédric, ZZelle@IRC On Tue, Aug 5, 2014 at 4:49 PM,

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

Hi everyone, With the incredible growth of OpenStack, our development community is facing complex challenges. How we handle those might determine the ultimate success or failure of OpenStack. With this cycle we hit new limits in our processes, tools and cultural setup. This resulted in new limiti

Re: [openstack-dev] [Neutron][LBaaS] "status" in entities

Isn't that what admin_state_up is for? But yes we do need a deeper discussion on this and many other things. On Tue, 2014-08-05 at 15:42 +, Eichberger, German wrote: > There was also talk about a third administrative status like ON/OFF... > > We really need a deeper status discussion - likel

[openstack-dev] [Nova][Neutron][Technical Committee] nova-network -> Neutron. Throwing a wrench in the Neutron gap analysis

Hello stackers, TC, Neutron contributors, At the Nova mid-cycle meetup last week in Oregon, during the discussion about the future of nova-network, the topic of nova-network -> Neutron migration came up. For some reason, I had been clueless about the details of one of the items in the gap an

Re: [openstack-dev] [OpenStack-Infra] [git-review] Supporting development in local branches

Yuriy, It looks like this would automate a standard workflow that my group often uses: multiple commits, create “delivery” branch, git merge --squash, git review. That looks really useful. Having it be repeatable is a bonus. Per last bullet of the implementation, I would not require not modif

Re: [openstack-dev] [TripleO] devtest environment for virtual or true bare metal

Hi Ben, Thanks for your reply. Actually I'm a little confused by "virtual environment". I guess what it means is as below: - 1 Seed VM as deployment starting point. - Both undercloud and overcloud images are loaded into Glance of Seed VM. - 15 VMs are created. 1 for undercloud, 1 for overclo

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network -> Neutron. Throwing a wrench in the Neutron gap analysis

On 08/05/2014 09:18 AM, Jay Pipes wrote: Hello stackers, TC, Neutron contributors, At the Nova mid-cycle meetup last week in Oregon, during the discussion about the future of nova-network, the topic of nova-network -> Neutron migration came up. For some reason, I had been clueless about the det

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network -> Neutron. Throwing a wrench in the Neutron gap analysis

Monty Taylor wrote on 08/05/2014 12:27:14 PM: > On 08/05/2014 09:18 AM, Jay Pipes wrote: > > Hello stackers, TC, Neutron contributors, > > > > At the Nova mid-cycle meetup last week in Oregon, during the discussion > > about the future of nova-network, the topic of nova-network -> Neutron > > mi

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network -> Neutron. Throwing a wrench in the Neutron gap analysis

Jay, I do agree with you on the focus areas. I believe Neutron should focus on the nova-parity (DVR) and DB migrations more than ever, instead of increasing the priority to new API such as the GBP. Actually, yesterday Neutron IRC showed the need of having a more focused work instead of picking in

Re: [openstack-dev] [all] specs.openstack.org is live

I have a spec proposal in play that crosses the Nova/Neutron boundary. I split it in to two specs: a nova spec [1] and a Neutron spec [2]. There is a little duplication between the two at a high level but not in the details. Each of the specs references the other at various spots in the text and

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network -> Neutron. Throwing a wrench in the Neutron gap analysis

On 08/05/2014 09:34 AM, Mike Spreitzer wrote: Monty Taylor wrote on 08/05/2014 12:27:14 PM: On 08/05/2014 09:18 AM, Jay Pipes wrote: Hello stackers, TC, Neutron contributors, At the Nova mid-cycle meetup last week in Oregon, during the discussion about the future of nova-network, the topic

[openstack-dev] [Ironic] python-ironicclient 0.2.0 released

On the tail of several weeks of travel and the Juno2 milestone, I have pushed up the 0.2.0 (*) version of the python-ironicclient library. This includes all the feature changes from Juno-2 development, and some bug fixes from Juno-1. * "node-show" now includes the new "instance_info" field * add "

Re: [openstack-dev] [all] specs.openstack.org is live

This is great, thanks to everyone who helped make it happen! -D On Sat, Aug 2, 2014 at 10:16 AM, Andreas Jaeger wrote: > All OpenStack incubated projects and programs that use a -specs > repository have now been setup to publish these to > http://specs.openstack.org. With the next merged in pa

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

On 08/05/2014 09:03 AM, Thierry Carrez wrote: Hi everyone, With the incredible growth of OpenStack, our development community is facing complex challenges. How we handle those might determine the ultimate success or failure of OpenStack. With this cycle we hit new limits in our processes, tools

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network -> Neutron. Throwing a wrench in the Neutron gap analysis

On 08/05/2014 12:18 PM, Jay Pipes wrote: > Hello stackers, TC, Neutron contributors, > > At the Nova mid-cycle meetup last week in Oregon, during the discussion > about the future of nova-network, the topic of nova-network -> Neutron > migration came up. > > For some reason, I had been clueless a

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

On 8/5/14, 11:04 AM, Gary Kotton wrote: Hi, Is there any description of how this will be consumed by Nova. My concern is this code landing there. Hi Gary, Initially, an endpoint's port_id is passed to Nova using "nova boot ... --nic port-id= ...", requiring no changes to Nova. Later, slight

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

Ok, thanks for the clarification. This means that it will not be done automagically as it is today – the tenant will need to create a Neutron port and then pass that through. Thanks Gary From: Robert Kukura mailto:kuk...@noironetworks.com>> Reply-To: OpenStack List mailto:openstack-dev@lists.op

Re: [openstack-dev] DevStack program change

Thanks for the feedback everyone, I've proposed the change in https://review.openstack.org/112090. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo

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

Just to add my two cents, while I get that people need to run on older versions of software, at a certain point you have to bump the minimum version. Even libvirt 0.9.11 is from April 3rd 2012. That's two and a third years old at this point. I think at a certain point we need to say "if you wa

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

On 8/5/14, 1:23 PM, Gary Kotton wrote: Ok, thanks for the clarification. This means that it will not be done automagically as it is today -- the tenant will need to create a Neutron port and then pass that through. Not quite. Using the group policy API, the port will be created implicitly when

Re: [openstack-dev] [nova] libvirtError: XML error: Missing CPU model name on 2nd level vm

Hi Kevin, Running devstack in a VM is perfectly doable. Many developers use devstack inside a VM (I run mine inside a VM launched using libvirt on KVM). I can't comment on the issue that you're encountering, but perhaps something wasn't configured correctly when you launched the VM? Best Regards

Re: [openstack-dev] [nova] libvirtError: XML error: Missing CPU model name on 2nd level vm

cat /proc/cpuinfo Make sure the cpu model and version is listed on /usr/share/libvirt/cpu_map.xml Hope this helps. On Tue, Aug 5, 2014 at 2:49 PM, Solly Ross wrote: > Hi Kevin, > Running devstack in a VM is perfectly doable. Many developers use > devstack inside a VM (I run mine inside a VM

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

On 08/05/2014 01:23 PM, Gary Kotton wrote: > Ok, thanks for the clarification. This means that it will not be done > automagically as it is today – the tenant will need to create a Neutron > port and then pass that through. FWIW, that's the direction we've wanted to move in Nova anyway. We'd like

Re: [openstack-dev] [Heat][TripleO] Heat can't retrieve stack list

We should take this discussion off the dev list. It's really a usage question for instack from what I see. Can you possibly hop on #tripleo on freenode to discuss? For reference, I believe I've seen the same problem using instack for icehouse with a qpid version that's too new. Not sure if that

Re: [openstack-dev] [git-review] Supporting development in local branches

On 08/05/2014 10:51 AM, ZZelle wrote: > Hi, > > > I like the idea ... with complex change, it could useful for the > understanding to split it into smaller changes during development. I don't understand this. If it's a complex change that you need multiple commits to keep track of locally, why

Re: [openstack-dev] [nova][libvirt][baremetal] Nova Baremetal's Usage of Components from Libvirt

>> The second option would be to make a copy of the old ImageCacheManager >> in the Baremetal directory, and have the Baremetal driver >> use that. This seems to me to be the better option, since it means >> that when the Baremetal driver is removed, the old ImageCacheManager >> code goes with it,

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

On 08/05/2014 01:13 PM, Robert Kukura wrote: On 8/5/14, 11:04 AM, Gary Kotton wrote: Hi, Is there any description of how this will be consumed by Nova. My concern is this code landing there. Hi Gary, Initially, an endpoint's port_id is passed to Nova using "nova boot ... --nic port-id= ...",

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network -> Neutron. Throwing a wrench in the Neutron gap analysis

On Tue, Aug 05, 2014 at 12:50:45PM EDT, Monty Taylor wrote: > However, I think the cost to providing that path far outweighs > the benefit in the face of other things on our plate. Perhaps those large operators that are hoping for a Nova-Network->Neutron zero-downtime live migration, could dedicat

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

Specifying an endpoint group would achieve the --networking-template effects you described. The endpoint group would have all of the security policies, IP allocation policies, connectivity policies, etc. already setup. On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes wrote: > On 08/05/2014 01:13 PM, R

[openstack-dev] Well-tested guides for OpenStack Icehouse installation and Instance creation with Neutron

Hi all, I want to share with you our well tested OpenStack Icehouse Installation Guide for Ubuntu 14.04. https://github.com/ChaimaGhribi/OpenStack-Icehouse-Installation/blob/master/OpenStack-Icehouse-Installation.rst If you want to create your first instance with Neutron, follow the instruction

Re: [openstack-dev] [nova][libvirt][baremetal] Nova Baremetal's Usage of Components from Libvirt

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/05/2014 02:49 PM, Dan Smith wrote: >>> The second option would be to make a copy of the old >>> ImageCacheManager in the Baremetal directory, and have the >>> Baremetal driver use that. This seems to me to be the better >>> option, since it mean

[openstack-dev] [Ironic] Proposal for slight change in our spec process

Hi all! The following idea came out of last week's midcycle for how to improve our spec process and tracking on launchpad. I think most of us liked it, but of course, not everyone was there, so I'll attempt to write out what I recall. This would apply to new specs proposed for Kilo (since the new

Re: [openstack-dev] [git-review] Supporting development in local branches

On Tue, Aug 5, 2014 at 5:15 AM, Angus Salkeld wrote: > On Tue, 2014-08-05 at 03:18 +0400, Yuriy Taraday wrote: > > Hello, git-review users! > > > > > > I'd like to gather feedback on a feature I want to implement that > > might turn out useful for you. > > > > > > I like using Git for development

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

Hi all, I need some help regarding a bug [1] I'm working on. The bug is basically a request to make the mac address of a port updatable. The use case is a baremetal (Ironic) node that has a bad NIC which must be replaced, resulting in a new mac address. The bad NIC has an associated neutron

Re: [openstack-dev] [git-review] Supporting development in local branches

On Tue, Aug 5, 2014 at 3:06 PM, Ryan Brown wrote: > > On 08/04/2014 07:18 PM, Yuriy Taraday wrote: > > > > +1, this is definitely a feature I'd want to see. > > Currently I run two branches "bug/LPBUG#-local" and "bug/LPBUG#" where > the local is my full history of the change and the other branc

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

How are you implementing the change? It would be good to get to see some code in a review to get an idea of what needs to be updated. If it's just a change in the DB base plugin, just let those changes propagate to the plugins that haven't overridden the inherited behavior. On Tue, Aug 5, 2014 a

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

I agree with Kevin here. Just a note, don't bother with openvswitch and linuxbridge plugins as they are marked for deletion this cycle, imminently (already deprecated)[0]. Amir [0] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-08-04-21.02.html Announcements 2e. _

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

On 08/05/2014 03:24 PM, Kevin Benton wrote: Specifying an endpoint group would achieve the --networking-template effects you described. The endpoint group would have all of the security policies, IP allocation policies, connectivity policies, etc. already setup. OK. Is there any reason it was c

Re: [openstack-dev] [git-review] Supporting development in local branches

On Tue, Aug 5, 2014 at 5:27 PM, Sylvain Bauza wrote: > > -1 to this as git-review default behaviour. I don't suggest to make it the default behavior. As I wrote there will definitely be a config option that would turn it on. > Ideally, branches should be identical in between Gerrit and local G

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

That's right Kevin, EPG (and its association to the L2/3_Policy) capture the attributes which would represent the "network-template" being referenced here. Jay, what Bob mentioned here was an option to use the "endpoint" as a one-to-one replacement for the option of using a Neutron port. This is m

Re: [openstack-dev] [Ironic] Proposal for slight change in our spec process

Hi! I think this is a nice idea indeed. Do you plan to use this process starting from Juno or as soon as possible? - Roman On Aug 5, 2014, at 22:33, Devananda van der Veen wrote: > Hi all! > > The following idea came out of last week's midcycle for how to improve our > spec process and t

Re: [openstack-dev] [git-review] Supporting development in local branches

On Tue, Aug 5, 2014 at 6:49 PM, Ryan Brown wrote: > On 08/05/2014 09:27 AM, Sylvain Bauza wrote: > > > > Le 05/08/2014 13:06, Ryan Brown a écrit : > > -1 to this as git-review default behaviour. Ideally, branches should be > > identical in between Gerrit and local Git. > > Probably not as default

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network -> Neutron. Throwing a wrench in the Neutron gap analysis

On 08/05/2014 03:23 PM, Collins, Sean wrote: On Tue, Aug 05, 2014 at 12:50:45PM EDT, Monty Taylor wrote: However, I think the cost to providing that path far outweighs the benefit in the face of other things on our plate. Perhaps those large operators that are hoping for a Nova-Network->Neutro

[openstack-dev] [python-openstacksdk] Meeting minutes for 2014-08-05

The following logs are from today's python-openstacksdk meeting Minutes: http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-08-05-19.00.html Minutes (text): http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-08-05-19.00.

Re: [openstack-dev] [git-review] Supporting development in local branches

On Tue, Aug 5, 2014 at 7:51 PM, ZZelle wrote: > Hi, > > > I like the idea ... with complex change, it could useful for the > understanding to split it into smaller changes during development. > > > Do we need to expose such feature under git review? we could define a new > subcommand? git review

[openstack-dev] [Neutron][oslo] Problem installing oslo.config-1.4.0.0a3 from .whl files

Hi, I noticed this yesterday afternoon. I tried to run pep8 and unit tests on a patch I was going to submit. It failed with an error that no package satisfying oslo.config could be found [1]. I went to pypi and saw that the version appears to be available [2] but still couldn't install it. I t

Re: [openstack-dev] [Infra] Meeting Tuesday August 5th at 19:00 UTC

On Mon, Aug 4, 2014 at 10:12 AM, Elizabeth K. Joseph wrote: > The OpenStack Infrastructure (Infra) team is hosting our weekly > meeting on Tuesday August 5th, at 19:00 UTC in #openstack-meeting Thanks to everyone who attended, meeting minutes and log are now available: Minutes: http://eavesdrop

Re: [openstack-dev] [OpenStack-Infra] [git-review] Supporting development in local branches

On Tue, Aug 5, 2014 at 8:20 PM, Varnau, Steve (Trafodion) < steve.var...@hp.com> wrote: > Yuriy, > > > > It looks like this would automate a standard workflow that my group often > uses: multiple commits, create “delivery” branch, git merge --squash, git > review. That looks really useful. > > >

Re: [openstack-dev] [Trove] Datastore/Versions API improvements

On Wed, Jul 30, 2014 at 10:10 AM, Denis Makogon wrote: > Hello, Stackers. > > > > I’d like to gather Trove team around question related to > Datastores/Version API responses (request/response payloads and HTTP codes). > > Small INFO > > When deployer creates datastore and versions for it

Re: [openstack-dev] [Neutron][oslo] Problem installing oslo.config-1.4.0.0a3 from .whl files

Hello Carl, You should try to update your virtualenv (pip install -U virtualenv). It fixed this problem for me. Regards, Alexei On 05/08/14 23:00, Carl Baldwin wrote: Hi, I noticed this yesterday afternoon. I tried to run pep8 and unit tests on a patch I was going to submit. It failed with

[openstack-dev] [Manila] File-storage for Manila service image

Hello everyone, Currently used image for Manila is located in dropbox: ubuntu_1204_nfs_cifs.qcow2 and dropbox has limit for traffic, see https://www.dropbox.com/help/4204 Due to generation of excessive traffic, public links we

Re: [openstack-dev] [git-review] Supporting development in local branches

On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec wrote: > On 08/05/2014 10:51 AM, ZZelle wrote: > > Hi, > > > > > > I like the idea ... with complex change, it could useful for the > > understanding to split it into smaller changes during development. > > I don't understand this. If it's a complex ch

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

Thanks for the quick responses. Here's the WIP review: https://review.openstack.org/112129. The base plugin doesn't contribute to the notification decision right now, so I've modified the actual plugin code. Chuck On Aug 5, 2014, at 12:51 PM, Amir Sadoughi mailto:amir.sadou...@rackspace.com

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

Agreed with Kevin and Sumit here. As a subgroup we talked about Nova integration, and the preliminary idea, as Bob alluded to, is to add "endpoint" as an option in place of Neutron port. But if we can make Nova EPG-aware, it would be great. On Tue, Aug 5, 2014 at 12:54 PM, Sumit Naiksatam wrote:

Re: [openstack-dev] [Neutron][oslo] Problem installing oslo.config-1.4.0.0a3 from .whl files

Alexei, Thanks, that is what I was missing. I hit one more error in case anyone is interested. lxml couldn't install because the compiler couldn't find libxml/xmlversion.h. For lack of interest on my part to figure out why this happened, I did the following which allowed me to get past the prob

Re: [openstack-dev] [Containers][Nova] Containers Team Mid-Cycle Meetup to join Nova Meetup

On 7/16/2014 10:44 AM, Adrian Otto wrote: Additional Update: Two important additions: 1) No Formal Thursday Meetings. We are eliminating our plans to meet formally on the 31st. You are still welcome to meet informally. We want to keep these discussions as productive as possible,

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

On 08/05/2014 04:26 PM, Stephen Wong wrote: Agreed with Kevin and Sumit here. As a subgroup we talked about Nova integration, and the preliminary idea, as Bob alluded to, is to add "endpoint" as an option in place of Neutron port. But if we can make Nova EPG-aware, it would be great. Is anyone

Re: [openstack-dev] [Manila] File-storage for Manila service image

On Tue, 2014-08-05 at 23:13 +0300, Valeriy Ponomaryov wrote: > Hello everyone, > > > Currently used image for Manila is located in > dropbox: ubuntu_1204_nfs_cifs.qcow2 and dropbox has limit for traffic, > see https://www.dropbox.com/help/4204 > > > Due to generation of excessive traffic, publi

Re: [openstack-dev] [all] specs.openstack.org is live

On Aug 6, 2014 2:49 AM, "Carl Baldwin" wrote: > > I have a spec proposal in play that crosses the Nova/Neutron boundary. > I split it in to two specs: a nova spec [1] and a Neutron spec [2]. > There is a little duplication between the two at a high level but not > in the details. Each of the spe

Re: [openstack-dev] [Trove] Datastore/Versions API improvements

On Tue, Aug 5, 2014 at 11:06 PM, Craig Vyvial wrote: > > > > On Wed, Jul 30, 2014 at 10:10 AM, Denis Makogon > wrote: > >> Hello, Stackers. >> >> >> >> I’d like to gather Trove team around question related to >> Datastores/Version API responses (request/response payloads and HTTP codes). >>

Re: [openstack-dev] [Manila] File-storage for Manila service image

Github has file size limit in 100 Mb, see https://help.github.com/articles/what-is-my-disk-quota Our current image is about 300 Mb. On Tue, Aug 5, 2014 at 11:43 PM, Swartzlander, Ben < ben.swartzlan...@netapp.com> wrote: > On Tue, 2014-08-05 at 23:13 +0300, Valeriy Ponomaryov wrote: > > Hello e

Re: [openstack-dev] [Ironic] Proposal for slight change in our spec process

On 05/08/14 12:33 -0700, Devananda van der Veen wrote: Hi all! The following idea came out of last week's midcycle for how to improve our spec process and tracking on launchpad. I think most of us liked it, but of course, not everyone was there, so I'll attempt to write out what I recall. This

Re: [openstack-dev] [neutron] network_device_mtu is not applied to VMs

On 4 August 2014 07:03, Elena Ezhova wrote: > Hi! > > I feel I need a piece of advice regarding this bug [1]. > > The gist of the problem is that although there is an option > network_device_mtu that can be specified in neutron.conf VMs are not > getting that mtu on their interfaces. > Correct.

Re: [openstack-dev] [Manila] File-storage for Manila service image

On Tue, 2014-08-05 at 23:50 +0300, Valeriy Ponomaryov wrote: > Github has file size limit in 100 Mb, see > https://help.github.com/articles/what-is-my-disk-quota > > > Our current image is about 300 Mb. Do you think we could upload the file to launchpad somehow? I've seen LP hosting various down

  1   2   >