Re: [openstack-dev] [neutron] Juno-3 BP meeting

Good for me. - Original Message - > Works perfect for me. I will join. > > Sent from my Android phone using TouchDown ( www.nitrodesk.com ) > > > -Original Message- > From: Carl Baldwin [c...@ecbaldwin.net] > Received: Wednesday, 27 Aug 2014, 5:07 > To: OpenStack Development Mai

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

>Incubator doesn't mean being kicked out of tree, it just mean that the API and resource model needs to be baked for fast iteration, and can't be put in tree temporarily. That was exactly my point about developing a major feature like DVR. Even with a limited API change (the new distributed flag),

Re: [openstack-dev] [neutron] Juno-3 BP meeting

Works perfect for me. I will join. Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Carl Baldwin [c...@ecbaldwin.net] Received: Wednesday, 27 Aug 2014, 5:07 To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org] Subject: Re: [

Re: [openstack-dev] [oslo] usage patterns for oslo.config

On Tue, 2014-08-26 at 10:00 -0400, Doug Hellmann wrote: > On Aug 26, 2014, at 6:30 AM, Mark McLoughlin wrote: > > > On Mon, 2014-08-11 at 15:06 -0400, Doug Hellmann wrote: > >> On Aug 8, 2014, at 7:22 PM, Devananda van der Veen > >> wrote: > >> > >>> On Fri, Aug 8, 2014 at 12:41 PM, Doug Hellm

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

On Wed, Aug 27, 2014 at 12:42 PM, Kevin Benton wrote: > >I think that "opensource" is not the only factor, it's about built-in > vs. 3rd backend. Built-in must be opensource, but opensource is not > necessarily built-in. By my thought, current OVS and linuxbridge are > built-in, but shim RESTful

[openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to start a discussion about how to support l3 agent HA when IP version is IPv6. This problem is triggered by bug [1] where sending gratuitous arp packet for HA doesn't work for IPv6 subnet gateways. This is because neighbor d

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

>I think that "opensource" is not the only factor, it's about built-in vs. 3rd backend. Built-in must be opensource, but opensource is not necessarily built-in. By my thought, current OVS and linuxbridge are built-in, but shim RESTful proxy for all kinds of sdn controller should be 3rd, for they ke

Re: [openstack-dev] [neutron] Juno-3 BP meeting

Kyle, These are three good ones. I've been reviewing the HA ones and have had an eye on the other two. 1300 is a bit early but I'll plan to be there. Carl On Aug 26, 2014 4:04 PM, "Kyle Mestery" wrote: > I'd like to propose a meeting at 1300UTC on Thursday in > #openstack-meeting-3 to discuss

Re: [openstack-dev] [OpenStack][Nova]May be performance issues of connect_volume in Nova

Hi, joe Thanks for your replay. I want to confirm whether we use “--rescan” for another reason. If only for connecting volume, it should be a bug. I will report it soon. From: Joe Gordon [mailto:joe.gord...@gmail.com] Sent: Wednesday, August 27, 2014 1:12 AM To: OpenStack Development Mailing List

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

On August 26, 2014, Anne Gentle wrote: On Mon, Aug 25, 2014 at 8:36 AM, Sean Dague mailto:s...@dague.net>> wrote: On 08/20/2014 12:37 PM, Zane Bitter wrote: > On 11/08/14 05:24, Thierry Carrez wrote: >> So the idea that being (and remaining) in the integrated release should >> also be judged on

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

Forwarded from other thread discussing about incubator: http://lists.openstack.org/pipermail/openstack-dev/2014-August/044135.html > Completely agree with this sentiment. Is there a crisp distinction between > a "vendor" plugin and an "open source" plugin though? > > I think that "opensource" is

Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective

On Sun, Aug 24, 2014 at 5:09 PM, Luke Gorrie wrote: > On 21 August 2014 12:12, Ihar Hrachyshka wrote: > >> Let the ones that are primarily interested in >> good quality of that code (vendors) to drive development. And if some >> plugins become garbage, it's bad news for specific vendors; if neu

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

Incubator doesn't mean being kicked out of tree, it just mean that the API and resource model needs to be baked for fast iteration, and can't be put in tree temporarily. As kyle has said, incubator is not talking about moving 3rd drivers out of tree, which is in another thread. For DVR, as it has

[openstack-dev] [Octavia] Agenda for tomorrow's meeting, where meeting is happening

Hello, The current agenda for tomorrow's Octavia meeting is posted here: https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda Please feel free to add agenda items as necessary. Also, based on the poll Doug Wiegley created on where we should hold our weekly meetings (IRC vs. webex

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

>From what I understand, the intended projects for the incubator can't operate without neutron because they are just extensions/plugins/drivers. For example, if the DVR modifications to the reference reference L3 plugin weren't already being developed in the tree, DVR could have been developed in

[openstack-dev] [infra][qa][neutron] Neutron full job, advanced services, and the integrated gate

TL; DR A few folks are proposing to stop running tests for neutron advanced services [ie: (lb|vpn|fw)aas] in the integrated gate, and run them only on the neutron gate. Reason: projects like nova are 100% orthogonal to neutron advanced services. Also, there have been episodes in the past of unreli

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

Thanks Salvatore. We will try to rebase the patches with master in our environment before running devstack. From: Salvatore Orlando [mailto:sorla...@nicira.com] Sent: Tuesday, August 26, 2014 3:53 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [ne

Re: [openstack-dev] [nova] Server Groups - remove VM from group?

On 08/25/2014 11:25 AM, Joe Cropper wrote: I was thinking something simple such as only allowing the add operation to succeed IFF no policies are found to be in violation... and then nova wouldn't need to get into all the complexities you mention? Personally I would be in favour of this...nothi

Re: [openstack-dev] [zaqar] [marconi] Juno Performance Testing (Round 1)

Correction: there were 25 workers per producer process, not 10. On 8/26/14, 4:41 PM, "Kurt Griffiths" wrote: >### Event Broadcasting (Balanced) ### > >This test uses the same number of producers and consumers, but note that >the observers are still listing (up to) 5 messages at a time[5], so the

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

On 2014-08-27 00:52:35 +0200 (+0200), Salvatore Orlando wrote: [...] > In this case you might try to rebase the patch you're going to > test on master before running devstack, which I think it's also > what happens in the upstream gate. More or less. Technically we try to merge the proposed change

[openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

Hi, After reading https://wiki.openstack.org/wiki/Network/Incubator I have some thoughts about the proposed workflow. We have quite a bit of experience and some good tools around splitting code out of projects and into new projects. But we don't generally do a lot of importing code into projects

Re: [openstack-dev] [qa][all][Heat] Packaging of functional tests

Excerpts from Steve Baker's message of 2014-08-26 14:25:46 -0700: > On 27/08/14 03:18, David Kranz wrote: > > On 08/26/2014 10:14 AM, Zane Bitter wrote: > >> Steve Baker has started the process of moving Heat tests out of the > >> Tempest repository and into the Heat repository, and we're looking >

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

Hi Karthik, what do you mean that the plugin is incompatible with https://review.openstack.org/#/c/114393/? you're mentioning a rebase issue - but the patch in question appears to cleanly apply to master. Is your probably because patch #114393 does not have in its log some changes you need to acc

Re: [openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report

On 23/08/14 07:39, Zane Bitter wrote: > We held the inaugural Heat mid-cycle meetup in Raleigh, North Carolina > this week. There were a dozen folks in attendance, and I think > everyone agreed that it was a very successful event. Notes from the > meetup are on the Etherpad here: > > https://etherp

Re: [openstack-dev] [neutron] Juno-3 BP meeting

Hi Kyle, I have conflicts for 13 UTC - Thursday is already full for me, but I'll try anyway, to join the convo on IRC. I agree the 3 blueprints you've mentioned are the ones we should really merge for Juno. To this aim, I wonder why [1] has not been set to high. Nevertheless it does not matter a

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

On Wed, Aug 27, 2014 at 4:01 AM, Joe Gordon wrote: > > > > On Wed, Aug 20, 2014 at 2:25 AM, Eoghan Glynn wrote: > >> >> >> > > > Additional cross-project resources can be ponied up by the large >> > > > contributor companies, and existing cross-project resources are not >> > > > necessarily dive

Re: [openstack-dev] [Openstack][TripleO] What if undercloud machines down, can we reboot overcloud machines?

Thank you very much. And sorry for the cross-posting. *Best Regards！* *Chao Yan--**My twitter：Andy Yan @yanchao727 * *My Weibo：http://weibo.com/herewearenow --* 2014-08-26 23:17 GMT+08:00 Ben Nemec : > Oh

[openstack-dev] [Fuel] Beta milestone of Fuel 5.1 now available!

Hi All, I¹m thrilled to announce that we¹ve reached the beta milestone for the Fuel Project. This beta release is made available to allow a broad user base to test and evaluate the next minor version of Fuel, but is not recommended for production use at this stage. What¹s New in Fuel 5.1?

[openstack-dev] [neutron] Juno-3 BP meeting

I'd like to propose a meeting at 1300UTC on Thursday in #openstack-meeting-3 to discuss Neutron BPs remaining for Juno at this point. We're taking specifically about medium and high priority ones, with a focus on these three: https://blueprints.launchpad.net/neutron/+spec/l3-high-availability) htt

Re: [openstack-dev] [rally] Introduction to feature request mechanism in Rally

Joe, Why not just use wishlist bugs in launchpad? The launchpad definition of > Wishlist is 'Not a bug. It's an enhancement/new feature.' The are few reasons: 1) It's not a wish list it's roadmap of project, that is based on end users requests 2) It should be easy for everybody to understand,

[openstack-dev] [zaqar] [marconi] Juno Performance Testing (Round 1)

Hi folks, I ran some rough benchmarks to get an idea of where Zaqar currently stands re latency and throughput for Juno. These results are by no means conclusive, but I wanted to publish what I had so far for the sake of discussion. Note that these tests do not include results for our new Redis d

Re: [openstack-dev] [Neutron] Use public IP address as instance fixed IP

VLAN tag, VXLAN id, etc. On Tue, Aug 26, 2014 at 2:27 PM, Bao Wang wrote: > Sorry, not good with neutron. Could you explain what "use a regular > segmentation identifer like the rest of the network" ? What is this > segmentation identifier ? > > > On Tue, Aug 26, 2014 at 3:07 PM, Kevin Benton

Re: [openstack-dev] [neutron][OpenDayLight CI] Is this a real failure? The failure log is gone

There is an opendaylight failure on one of my patches as well. Can the maintainer update the message it posts with the syntax to retrigger a check? On Tue, Aug 26, 2014 at 2:27 PM, Kyle Mestery wrote: > Looking at the console output from the ODL Jenkins failure, it appears > like Jenkins reaped

Re: [openstack-dev] [neutron][VMware NSX CI] How to see the log for failure.

Hi Salvatore, Thanks for the information. Will do the recheck-vmware. Regards, Nader. On Tue, Aug 26, 2014 at 12:43 PM, Salvatore Orlando wrote: > Hi Nader, > > Sorry about that failure. > We have temporarily stopped mine sweeper for neutron while we update our > devstack images. > However,

Re: [openstack-dev] [neutron][OpenDayLight CI] Is this a real failure? The failure log is gone

Looking at the console output from the ODL Jenkins failure, it appears like Jenkins reaped this instance before everything was complete. I've copied Dave Tucker who may be able to provide some additional input from the ODL side as well. On Tue, Aug 26, 2014 at 3:13 PM, Milton Xu (mxu) wrote: >

Re: [openstack-dev] [Neutron] Use public IP address as instance fixed IP

Sorry, not good with neutron. Could you explain what "use a regular segmentation identifer like the rest of the network" ? What is this segmentation identifier ? On Tue, Aug 26, 2014 at 3:07 PM, Kevin Benton wrote: > No, the gateway_external_network_id option just refers to how your network > i

Re: [openstack-dev] [qa][all][Heat] Packaging of functional tests

On 27/08/14 03:18, David Kranz wrote: > On 08/26/2014 10:14 AM, Zane Bitter wrote: >> Steve Baker has started the process of moving Heat tests out of the >> Tempest repository and into the Heat repository, and we're looking >> for some guidance on how they should be packaged in a consistent way. >>

Re: [openstack-dev] [Trove] Proposal to add Amrith Kumar to trove-core

Thanks everyone for the show of support. Amrith: welcome to trove-core! On Tue, Aug 26, 2014 at 12:02 PM, Craig Vyvial wrote: > +1 > > > On Tue, Aug 26, 2014 at 1:55 PM, Vipul Sabhaya wrote: > >> +1 >> >> >> On Tue, Aug 26, 2014 at 11:43 AM, Robert Myers >> wrote: >> >>> +1 >>> >>> >>> On Tue

[openstack-dev] [congress] specs update

current specs are updated and current with the project blueprints https://blueprints.launchpad.net/congress enjoy! ~ sean ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-d

Re: [openstack-dev] [nova][neutron] Migration from nova-network to Neutron for large production clouds

On Tue, Aug 26, 2014 at 7:59 PM, Tim Bell wrote: > > > > From: Michael Still [mailto:mi...@stillhq.com] > > Sent: 25 August 2014 23:38 > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [nova][neutron] Migration from nova-network to > > Neutron f

Re: [openstack-dev] [neutron][OpenDayLight CI] Is this a real failure? The failure log is gone

Thanks Salvatore for the quick response for the NSX CI failure! OpenDayLight CI experts, We are also seeing a failure on OpenDayLight CI but it appears there is no log at the link below. This is an urgent issue for us. Appreciate your prompt help here. OpenDaylight CI 9:35 AM Patch Set 24: Ve

Re: [openstack-dev] [Neutron] Use public IP address as instance fixed IP

No, the gateway_external_network_id option just refers to how your network is deployed. If the external network uses a regular segmentation identifier like the rest of the networks, this will work. If not, it won't because the instances will try to use a segmentation identifier. In other words, if

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

On Mon, Aug 25, 2014 at 11:37 AM, Elizabeth K. Joseph wrote: > The OpenStack Infrastructure (Infra) team is hosting our weekly > meeting on Tuesday August 26th, at 19:00 UTC in #openstack-meeting Thanks to everyone who joined us for the meeting, log and minutes available here: Minutes: http://e

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

Hi Edgar, We are also facing CI issues when the neutron patch set is not rebased with latest changes. For e.g. CI audit that you posted today (https://review.openstack.org/#/c/114393/) is not rebased with neutron test_lib related changes. We had refactored the Brocade Vyatta plugin unit tests t

Re: [openstack-dev] [neutron][VMware NSX CI] How to see the log for failure.

On 08/26/2014 03:43 PM, Salvatore Orlando wrote: > Hi Nader, > > Sorry about that failure. > We have temporarily stopped mine sweeper for neutron while we update our > devstack images. > However, unfortunately some jobs did not complete properly, and therefore > you had failures without logs being

Re: [openstack-dev] [neutron][VMware NSX CI] How to see the log for failure.

Hi Nader, Sorry about that failure. We have temporarily stopped mine sweeper for neutron while we update our devstack images. However, unfortunately some jobs did not complete properly, and therefore you had failures without logs being reported. The situation should be back to normal soon, and yo

Re: [openstack-dev] [Heat][Docker] How to Dockerize your applications with OpenStack Heat in simple steps

Hey Stackers! Wait! =) Let me ask something... Why are you guys using Docker within a VM?!?! What is the point of doing such thing?! I thought Docker was here to entirely replace the virtualization layer, bringing a "bare metal-cloud", am I right?! Tks! Thiago On 26 August 2014 05:45, Marou

Re: [openstack-dev] [Neutron] Use public IP address as instance fixed IP

Just want to clarify something. this public ip as private ip is only for external facing interfaces on a set of VM instances. At the same time, the majority of interfaces on hte same set of VM instances will not have public ip and their subnets are isolated networks. Will this change your conclusio

Re: [openstack-dev] [Trove] Proposal to add Amrith Kumar to trove-core

+1 On Tue, Aug 26, 2014 at 1:55 PM, Vipul Sabhaya wrote: > +1 > > > On Tue, Aug 26, 2014 at 11:43 AM, Robert Myers wrote: > >> +1 >> >> >> On Tue, Aug 26, 2014 at 8:54 AM, Tim Simpson >> wrote: >> >>> +1 >>> >>> >>> From: Sergey Gotliv [sgot...@redhat.

Re: [openstack-dev] [Trove] Proposal to add Amrith Kumar to trove-core

+1 On Tue, Aug 26, 2014 at 11:43 AM, Robert Myers wrote: > +1 > > > On Tue, Aug 26, 2014 at 8:54 AM, Tim Simpson > wrote: > >> +1 >> >> >> From: Sergey Gotliv [sgot...@redhat.com] >> Sent: Tuesday, August 26, 2014 8:11 AM >> To: openstack-dev@lists.open

[openstack-dev] [neutron][VMware NSX CI] How to see the log for failure.

Hi, The VMWare NSX CI is failing and I'm not able to get any failure log to find the reason of failure. The message that I get is this: VMware NSX CI has posted comments on this change. Patch Set 24: Verified-1 You might have hit the following known bug(s): bug #1271230 Add review comme

Re: [openstack-dev] [Trove] Proposal to add Amrith Kumar to trove-core

+1 On Tue, Aug 26, 2014 at 8:54 AM, Tim Simpson wrote: > +1 > > > From: Sergey Gotliv [sgot...@redhat.com] > Sent: Tuesday, August 26, 2014 8:11 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Trove] Proposal to add Amrith Kuma

Re: [openstack-dev] [Trove] Proposal to add Amrith Kumar to trove-core

+1 On 8/26/14, 6:54 AM, "Tim Simpson" wrote: >+1 > > >From: Sergey Gotliv [sgot...@redhat.com] >Sent: Tuesday, August 26, 2014 8:11 AM >To: openstack-dev@lists.openstack.org >Subject: Re: [openstack-dev] [Trove] Proposal to add Amrith Kumar to >trove-core

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On Aug 26, 2014, at 11:28 AM, Matthew Treinish wrote: > On Tue, Aug 26, 2014 at 10:04:41AM -0400, Doug Hellmann wrote: >> >> On Aug 26, 2014, at 5:13 AM, Thierry Carrez wrote: >> >>> OK, now that we have evacuated the terminology issue (we'll use liaison >>> or janitor or secretary, not czar)

Re: [openstack-dev] [rally] Introduction to feature request mechanism in Rally

On Tue, Aug 26, 2014 at 5:31 AM, Boris Pavlovic wrote: > Hi stackers, > > > It goes without saying that end users, that are actually using your > tool/project/service, usually don't have enough time to join community, > understand all technical details and road map of project and after that > con

Re: [openstack-dev] What does NASA not using OpenStack mean to OS's future

Don't feed the troll. :)   :)= On Monday, August 25, 2014 12:39 PM, Joshua Harlow wrote: So to see if we can get something useful from this thread. What was your internal analysis, can it be published? Even negative analysis is useful to make openstack better... It'd be nice to have some

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

On Wed, Aug 20, 2014 at 2:25 AM, Eoghan Glynn wrote: > > > > > > Additional cross-project resources can be ponied up by the large > > > > contributor companies, and existing cross-project resources are not > > > > necessarily divertable on command. > > > > > > Sure additional cross-project resour

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

On Mon, Aug 25, 2014 at 6:36 AM, Sean Dague wrote: > On 08/20/2014 12:37 PM, Zane Bitter wrote: > > On 11/08/14 05:24, Thierry Carrez wrote: > >> So the idea that being (and remaining) in the integrated release should > >> also be judged on technical merit is a slightly different effort. It's > >

Re: [openstack-dev] [OpenStack][Nova]May be performance issues of connect_volume in Nova

On Tue, Aug 26, 2014 at 5:36 AM, Wang Shen wrote: > Hi, All > I have done some work to test the performance of LUN scanning, use > "iscsiadm" with "--rescan" like what Nova dose. In my test, a host > connected with a lot of LUNs , more than 1000 LUNs. Because "--rescan" > will cause kernel to sca

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

On Mon, Aug 25, 2014 at 8:36 AM, Sean Dague wrote: > On 08/20/2014 12:37 PM, Zane Bitter wrote: > > On 11/08/14 05:24, Thierry Carrez wrote: > >> So the idea that being (and remaining) in the integrated release should > >> also be judged on technical merit is a slightly different effort. It's > >

Re: [openstack-dev] [infra] [keystone] pysaml2/xmlsec1 dep blocking keystone-to-keystone federation

On Tue, Aug 26, 2014 at 6:44 AM, Sean Dague wrote: > On 08/26/2014 05:38 AM, Thierry Carrez wrote: > > Hi keystone/infra, > > > > One key upcoming Juno feature (Keystone to keystone federation) is > > currently blocked on adding pysaml2 to requirements: > > > > https://review.openstack.org/#/c/11

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On Tue, Aug 26, 2014 at 10:04:41AM -0400, Doug Hellmann wrote: > > On Aug 26, 2014, at 5:13 AM, Thierry Carrez wrote: > > > OK, now that we have evacuated the terminology issue (we'll use liaison > > or janitor or secretary, not czar), and side-stepped the offtopic > > development (this is not a

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On 08/26/2014 10:04 AM, Doug Hellmann wrote: On Aug 26, 2014, at 5:13 AM, Thierry Carrez wrote: OK, now that we have evacuated the terminology issue (we'll use liaison or janitor or secretary, not czar), and side-stepped the offtopic development (this is not about suppressing PTLs, just a fram

Re: [openstack-dev] [qa][all][Heat] Packaging of functional tests

On 08/26/2014 10:14 AM, Zane Bitter wrote: Steve Baker has started the process of moving Heat tests out of the Tempest repository and into the Heat repository, and we're looking for some guidance on how they should be packaged in a consistent way. Apparently there are a few projects already pac

Re: [openstack-dev] [Openstack][TripleO] What if undercloud machines down, can we reboot overcloud machines?

Oh, after writing my response below I realized this is cross-posted between openstack and openstack-dev. Please don't do that. I suppose this probably belongs on the users list, but since I've already written the response I guess I'm not going to argue too much. :-) On 08/26/2014 07:36 AM, 严超 wr

[openstack-dev] [horizon] JavaScript library support

Horizon has been actively moving away from having 3rd party JavaScript libraries bundled in the Horizon repo. Most have been removed barring one or two exceptions. Moving forward new JavaScript libraries dependencies should either use existing xstatic packages or need a new one created for the lib

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On 08/26/2014 05:13 AM, Thierry Carrez wrote: > OK, now that we have evacuated the terminology issue (we'll use liaison > or janitor or secretary, not czar), and side-stepped the offtopic > development (this is not about suppressing PTLs, just a framework to let > them delegate along predetermined

Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective

On 8/26/14, 4:49 AM, "Maru Newby" wrote: > >On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi) > wrote: > >> >> >> On 8/23/14, 5:36 PM, "Maru Newby" wrote: >> >>> >>> On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam >>> wrote: >>> On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery

Re: [openstack-dev] gettext question about oslo.i18n library

Hi Peng, We're using the spec process described in https://wiki.openstack.org/wiki/Oslo#Design_Proposals to manage blueprints now. You'll need to create a spec review as described in the wiki for this. Unfortunately, I don't think we've opened up Kilo specs yet, so you might want to either wait

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On Tue, Aug 26, 2014 at 9:48 AM, Doug Hellmann wrote: > > On Aug 26, 2014, at 10:10 AM, Kyle Mestery wrote: > >> On Fri, Aug 22, 2014 at 8:19 PM, John Dickinson wrote: >>> I think Anne makes some excellent points about the pattern being proposed >>> being unlikely to be commonly implemented acr

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On Aug 26, 2014, at 10:10 AM, Kyle Mestery wrote: > On Fri, Aug 22, 2014 at 8:19 PM, John Dickinson wrote: >> I think Anne makes some excellent points about the pattern being proposed >> being unlikely to be commonly implemented across all the programs (or, at >> best, very difficult). Let's

Re: [openstack-dev] [infra] [keystone] pysaml2/xmlsec1 dep blocking keystone-to-keystone federation

On Aug 26, 2014, at 10:18 AM, Steve Martinelli wrote: > > > From: Doug Hellmann > > To: "OpenStack Development Mailing List (not for usage questions)" > > , > > Date: 08/26/2014 10:11 AM > > Subject: Re: [openstack-dev] [infra] [keystone] pysaml2/xmlsec1 dep > > blocking keystone-to-keyst

Re: [openstack-dev] [infra] [keystone] pysaml2/xmlsec1 dep blocking keystone-to-keystone federation

> From: Doug Hellmann > To: "OpenStack Development Mailing List (not for usage questions)" > , > Date: 08/26/2014 10:11 AM > Subject: Re: [openstack-dev] [infra] [keystone] pysaml2/xmlsec1 dep > blocking keystone-to-keystone federation > > > On Aug 26, 2014, at 7:44 AM, Sean Dague wrote: >

[openstack-dev] [qa][all][Heat] Packaging of functional tests

Steve Baker has started the process of moving Heat tests out of the Tempest repository and into the Heat repository, and we're looking for some guidance on how they should be packaged in a consistent way. Apparently there are a few projects already packaging functional tests in the package .tes

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On Mon, Aug 25, 2014 at 4:45 AM, Alan Kavanagh wrote: > That's a fair point Jay. The Czar does sound like a reasonable approach and > what would be useful and helpful would be to appoint additional PTL's and not > have the burden of everything falling on one individual which becomes over > load

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On Fri, Aug 22, 2014 at 8:19 PM, John Dickinson wrote: > I think Anne makes some excellent points about the pattern being proposed > being unlikely to be commonly implemented across all the programs (or, at > best, very difficult). Let's not try to formalize another "best practice" > that works

Re: [openstack-dev] [Fuel] Use lrzip for upgrade tarball - reject?

As an update, please check and review commit [1] to fuel-specs with detailed feature description. According to this feature, we are going to switch our CI system to lrzipped tarballs. [1] https://review.openstack.org/#/c/116874/ On Thu, Aug 21, 2014 at 5:50 PM, Dmitry Pyzhov wrote: > Fuelers

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On Aug 26, 2014, at 5:13 AM, Thierry Carrez wrote: > OK, now that we have evacuated the terminology issue (we'll use liaison > or janitor or secretary, not czar), and side-stepped the offtopic > development (this is not about suppressing PTLs, just a framework to let > them delegate along predet

Re: [openstack-dev] [infra] [keystone] pysaml2/xmlsec1 dep blocking keystone-to-keystone federation

On Aug 26, 2014, at 7:44 AM, Sean Dague wrote: > On 08/26/2014 05:38 AM, Thierry Carrez wrote: >> Hi keystone/infra, >> >> One key upcoming Juno feature (Keystone to keystone federation) is >> currently blocked on adding pysaml2 to requirements: >> >> https://review.openstack.org/#/c/113294/ >

[openstack-dev] [nova] Configuring libivrt VIF driver

Hi, Following the conversation [1]: My understanding was that the way to use out of the tree vif_driver is to set vif_driver option in nova.conf until there is a better way to support such cases but the commit [2] removed this option. Can someone clarify the current status (i.e. what is the cur

Re: [openstack-dev] [oslo] usage patterns for oslo.config

On Aug 26, 2014, at 6:30 AM, Mark McLoughlin wrote: > On Mon, 2014-08-11 at 15:06 -0400, Doug Hellmann wrote: >> On Aug 8, 2014, at 7:22 PM, Devananda van der Veen >> wrote: >> >>> On Fri, Aug 8, 2014 at 12:41 PM, Doug Hellmann >>> wrote: That’s right. The preferred approach is t

Re: [openstack-dev] [Trove] Proposal to add Amrith Kumar to trove-core

+1 From: Sergey Gotliv [sgot...@redhat.com] Sent: Tuesday, August 26, 2014 8:11 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Trove] Proposal to add Amrith Kumar to trove-core Strong +1 from me! > -Original Message- > Fro

Re: [openstack-dev] [Trove] Proposal to add Amrith Kumar to trove-core

+1. Congratulations, Amrith. Best regards, Denis M. вторник, 26 августа 2014 г. пользователь Sergey Gotliv написал: > Strong +1 from me! > > > > -Original Message- > > From: Nikhil Manchanda [mailto:nik...@manchanda.me ] > > Sent: August-26-14 3:48 AM > > To: OpenStack Development Mailin

Re: [openstack-dev] [Trove] Proposal to add Amrith Kumar to trove-core

Strong +1 from me! > -Original Message- > From: Nikhil Manchanda [mailto:nik...@manchanda.me] > Sent: August-26-14 3:48 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [Trove] Proposal to add Amrith Kumar to trove-core > > Hello folks: >

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

On 08/25/2014 03:50 PM, Adam Lawson wrote: I recognize I'm joining the discussion late but I've been following the dialog fairly closely and want to offer my perspective FWIW. I have a lot going through my head, not sure how to get it all out there so I'll do a brain dump, get some feedback and a

[openstack-dev] [OpenStack][Nova]May be performance issues of connect_volume in Nova

Hi, All I have done some work to test the performance of LUN scanning, use "iscsiadm" with "--rescan" like what Nova dose. In my test, a host connected with a lot of LUNs , more than 1000 LUNs. Because "--rescan" will cause kernel to scan all of the LUNs connected to the host, it costs several minu

[openstack-dev] [Openstack][TripleO] What if undercloud machines down, can we reboot overcloud machines?

Hi, All: I've deployed undercloud and overcloud on some baremetals. All overcloud machines are deployed by undercloud. Then I tried to shutdown undercloud machines. After that, if I reboot one overcloud machine, it will never boot from net, AKA PXE used by undercloud. Is tha

Re: [openstack-dev] [nova][neutron] Migration from nova-network to Neutron for large production clouds

Hi, I'd like to encourage everybody interested to take a look and leave comments on the Neutron migration spec here: https://review.openstack.org/#/c/101921 The design currently includes both "cold" and "live" approaches, supports host-by-host migration (as opposite to big bang) and doesn't requi

[openstack-dev] [rally] Introduction to feature request mechanism in Rally

Hi stackers, It goes without saying that end users, that are actually using your tool/project/service, usually don't have enough time to join community, understand all technical details and road map of project and after that contribute code that implements their features... But it's well know tha

[openstack-dev] Private IP allocation

Hi, Openstack deployment detail : Single node devstack setup Issue Description: We are writing a core plugin and trying to create instance provisioned by our plugin. We are able to launch the VM instance successfully via OpenStack horizon. From the horizon, we could see the IP is getting all

[openstack-dev] [mistral] Access filtering BP

Team, Please take a look at the new BP https://blueprints.launchpad.net/mistral/+spec/mistral-access-filtering. Interested in your feedback and shared experience. Although it’s a purely internal design thing I find pretty important to be accurate about things like that. Thanks Renat Akhmerov

Re: [openstack-dev] [infra] [keystone] pysaml2/xmlsec1 dep blocking keystone-to-keystone federation

On 08/26/2014 05:38 AM, Thierry Carrez wrote: > Hi keystone/infra, > > One key upcoming Juno feature (Keystone to keystone federation) is > currently blocked on adding pysaml2 to requirements: > > https://review.openstack.org/#/c/113294/ > > It was -1ed by Doug after the discussion at the releas

Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax additions/changes

On 08/25/2014 10:06 PM, Brandon Logan wrote: >> >> 2. Therefor, there should be some configuration to specifically enable >> either version (not both) in case LBaaS is needed. In this case, the >> other version is disabled (ie. a REST query for non-active version >> should return a "not activated

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On 08/26/2014 11:13 AM, Thierry Carrez wrote: > OK, now that we have evacuated the terminology issue (we'll use liaison > or janitor or secretary, not czar), and side-stepped the offtopic > development (this is not about suppressing PTLs, just a framework to let > them delegate along predetermined

Re: [openstack-dev] [Fuel] Issues with hardcoded versions of requirements in specs of packages

It is not enough, you need to review requirements in the code of nailgun, ostf and astute. I'll be happy to have our requirements files and specs as close to global-requirements as possible. It will ruin our current solid structure, where we have same versions of dependencies on production, on dev

Re: [openstack-dev] [Heat] [Keystone] Heat cfn-push-stats failed with '403 SignatureDoesNotMatch', it may be Keystone problem.

On Sun, Aug 24, 2014 at 02:55:14PM +0900, Yukinori Sagara wrote: >Hi. > >I am trying Heat instance HA, using RDO Icehouse. > >After instance boot, instance push own stats to heat alarm with >cfn-push-stats command. > >But cfn-push-stats always failed with error '403 Signature

Re: [openstack-dev] [oslo] usage patterns for oslo.config

On Mon, 2014-08-11 at 15:06 -0400, Doug Hellmann wrote: > On Aug 8, 2014, at 7:22 PM, Devananda van der Veen > wrote: > > > On Fri, Aug 8, 2014 at 12:41 PM, Doug Hellmann > > wrote: > >> > >> That’s right. The preferred approach is to put the register_opt() in > >> *runtime* code somewhere be

Re: [openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report

On Fri, Aug 22, 2014 at 03:39:24PM -0400, Zane Bitter wrote: > We held the inaugural Heat mid-cycle meetup in Raleigh, North Carolina this > week. There were a dozen folks in attendance, and I think everyone agreed > that it was a very successful event. Notes from the meetup are on the > Etherpad h

Re: [openstack-dev] [Keystone] Domain-specific Drivers

Hi It was fully merged for Juno-2 - so if you are having problems, feel free to share the settings in you main config and keystone.heat.config files Henry On 26 Aug 2014, at 10:26, Bruno Luis Dos Santos Bompastor wrote: > Hi folks! > > I would like to know what is the status on the “Domain-s

[openstack-dev] [infra] Centos 7 images for HP Helion

Hi, I would like to get centos 7 based testing working, but I am stuck without images being provided in the HP Cloud. Rackspace has a (slightly quirky, but workable) image and we have an experimental job that runs fine. I am aware that building our own custom images with disk-image-builder is t

  1   2   >