Re: [openstack-dev] [puppet] [fuel] more collaboration request

Greetings, On 11/06/15 19:31 -0700, Dmitry Borodaenko wrote: On Thu, Jun 11, 2015 at 05:39:28PM -0400, Emilien Macchi wrote: On 06/11/2015 10:36 AM, Matthew Mosesohn wrote: > I'm not saying it's the most community-oriented approach, but Fuel > would have never evolved and matured without it. Th

Re: [openstack-dev] [puppet] [fuel] more collaboration request

On 11/06/15 17:36 +0300, Matthew Mosesohn wrote: [..] Secondly, I'd like to point out that Fuel is not so different from what other teams are doing. At the Summit, I heard from others who all maintain internal Gerrits and internal forks of the modules. The difference is that Fuel is being worked

Re: [openstack-dev] [puppet] [fuel] more collaboration request

On Thu, Jun 11, 2015 at 11:01:19PM -0400, Emilien Macchi wrote: > > 1) "If you are adding a module that is the work of another project and > > is already tracked in separate repo (...) review should also contain the > > commit hash from the upstream repo in the commit message". Using this > > refer

Re: [openstack-dev] Proposing Brian Haley to Neutron L3 Core Reviewer Team

Here too, my vote doesn’t count, but big+1, all my interactions with Brian have been awesome, and he’s been doing a very good job for a long time. Best, Miguel Ángel Ajo On Thursday 11 June 2015 at 12:27, Gary Kotton wrote: > +1 > > On 6/10/15, 10:11 PM, "Carl Baldwin" (mailto:c...@ecbaldwin

Re: [openstack-dev] [puppet] [fuel] more collaboration request

On 06/12/2015 04:31 AM, Dmitry Borodaenko wrote: > A better alternative would be to make all upstream Puppet OpenStack > directly usable in Fuel, but even if we figure out a way to make that > work, it will take a long journey to get there. On the upstream side, > Fuel core reviewers would have to

Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team

I know my vote does not count, but “big +1” from me :) Best, Miguel Ángel Ajo On Thursday 11 June 2015 at 22:24, Armando M. wrote: > +1 > > On 11 June 2015 at 12:42, Carl Baldwin (mailto:[email protected])> wrote: > > +1 > > > > On Thu, Jun 11, 2015 at 12:15 PM, Kevin Benton > (mailto:bl

Re: [openstack-dev] [Ceilometer] Meter rename discussion

hi Edwin, i added a comment to patch, maybe we don't need to do any search/replace at all ie. if we have meter x.y that is renamed to meter y.z, if you search for either x.y or y.z, the results may contain samples with both names? and over time, it'll eventually just have the single name. the a

Re: [openstack-dev] If the trove-mgmt-client is not begin by someone, i want to do this work.

Hi Li: Thanks for stepping up, and volunteering to dig into this. Your help is much appreciated! We did talk about this at the Vancouver Summit, but as far as I'm aware no one has started on this work for Liberty. As I had mentioned in one of my previous emails, python-troveclient does have the c

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 06/10/2015 04:31 PM, Joe Gordon wrote: > > > On Wed, Jun 10, 2015 at 5:24 PM, Ian Cordasco > mailto:[email protected]>> wrote: > > > > On 6/10/15, 09:12, "Thomas Goirand" > wrote: > > >On 06/10/2015 12:25 PM, Dave Walker wrote: > >> The ini

Re: [openstack-dev] Need help! Zuul can not connect to port 29418 of review.openstack.org

On 12/06/15 17:04, liuxinguo wrote: Hi, Recentlyour CI can not connect to port 29418 of review.openstack.org. Following are the failuer message, is there anyone know the reasion why our CI can not cennect to 29418 of review.openstack.org? That port on review.openstack.org currently appears t

Re: [openstack-dev] [OpenStack-Infra] Need help! Zuul can not connect to port 29418 of review.openstack.org

Alternatively you could have a look at tunneling SSH over HTTP with corkscrew: http://www.techrepublic.com/blog/linux-and-open-source/using-corkscrew-to-tunnel-ssh-over-http/ Regards 2015-06-12 11:09 GMT+02:00 Tom Fifield : > On 12/06/15 17:04, liuxinguo wrote: > >> Hi, >> >> Recentlyour CI can

Re: [openstack-dev] If the trove-mgmt-client is not begin by someone, i want to do this work.

I prefer contribute. I think you mean, we can add mgmt-cli directly into python-troveclient? That is ok. what i should do? do i need to wirte a bp? or just write code, push it to upstream? -- Best Li Tianqing At 2015-06-12 16:52:46, "Nikhil Manchanda" wrote: Hi Li: Thanks for steppi

[openstack-dev] [cinder] Will CI failures recently cause the corresponding driver removed from the L?

Hi, Our CI can not connect to port 29418 of review.openstack.org recently, possibly because the GFW filtered the access. Now we are processing this problem as soon as we found it. According to the decision of Cinder Meeting 2015-06-10: "June 15th proposed drivers for Liberty without passing code

Re: [openstack-dev] ThirdPartyCI: Tempest job fails with "Unexpected termination of the channel"

Hi, After some more tests i was able to link the failure of the jenkins job with the errors in dmesg : [Fri Jun 12 11:04:37 2015] br100: port 2(vnet1) entered disabled state [Fri Jun 12 11:04:37 2015] device vnet1 left promiscuous mode [Fri Jun 12 11:04:37 2015] br100: port 2(vnet1) entered disabl

Re: [openstack-dev] If the trove-mgmt-client is not begin by someone, i want to do this work.

Hi Li: There's already a python-troveclient bug open for this issue [1]. As per our IRC conversation, I've gone ahead and assigned it to you. Thanks! -Nikhil [1] https://bugs.launchpad.net/python-troveclient/+bug/1250258 On Fri, Jun 12, 2015 at 2:14 AM, Li Tianqing wrote: > I prefer contribut

Re: [openstack-dev] [puppet] [fuel] more collaboration request

On Thu, Jun 11, 2015 at 11:43:09PM -0400, Emilien Macchi wrote: > What about code history and respect of commit ownership? > I'm personally wondering if it's fair to copy/paste several thousands of > lines of code from another Open-Source project without asking to the > community or notifying the a

Re: [openstack-dev] [OpenStack-Infra] Need help! Zuul can not connect to port 29418 of review.openstack.org

Thanks Tom, the method you provide is really a good idea, but probably it won't work for a 3rd CI. I have tried to change ssh to https for 3rd CI, but it is not a simple work like that. It related to lots of zuul code change. -邮件原件- 发件人: Tom Fifield [mailto:[email protected]] 发送时间: 201

Re: [openstack-dev] [puppet] [fuel] more collaboration request

On Fri, Jun 12, 2015 at 09:31:45AM +0200, Flavio Percoco wrote: > On 11/06/15 17:36 +0300, Matthew Mosesohn wrote: > >Secondly, I'd like to point out that Fuel is not so different from > >what other teams are doing. At the Summit, I heard from others who all > >maintain internal Gerrits and interna

Re: [openstack-dev] [OpenStack-Infra] Need help! Zuul can notconnect to port 29418 of review.openstack.org

Hi, I met the same problem as you. I resolve this problem by change git url. You can do like this: 1. Get a http password from https://review.openstack.org/#/settings/http-password 2. Set git url like this: git remote set-url gerrit https://username:[email protected]/openstack/stackf

[openstack-dev] [fuel][plugin] Where can I find the Test Report template?

The Fuel plugin wiki states that a test report is required for plugin certification and that it must be created according to the template, but doesn't mention where the template can be found. Is anyone able to tell me? Thanks, Emma https://wiki.openstack.org/wiki/Fuel/Plugins#Creating_documenta

Re: [openstack-dev] [Neutron] Issue with pymysql

On 06/12/2015 01:17 AM, Salvatore Orlando wrote: > It is however interesting that both "lock wait timeouts" and "missing > savepoint" errors occur in operations pertaining the same table - > securitygroups in this case. > I wonder if the switch to pymysl has not actually uncovered some other > bug

Re: [openstack-dev] [neutron] Microversioning work questions and kick-start

On 06/11/2015 06:03 PM, Salvatore Orlando wrote: > As most of you already know, work is beginning to move forward on the > micro-versioned Neutron API, for which a specification is available at [1] > > From a practical perspective there is one non-negligible preliminary > issue that needs attentio

Re: [openstack-dev] [puppet] [fuel] more collaboration request

On Fri, Jun 12, 2015 at 09:24:33AM +0200, Flavio Percoco wrote: > I'm sure you both, and the Fuel team, are acting on good faith but I > believe, in this case, there's no problem that makes copy/pasting > code, and therefore loosing commits attribution, acceptable. To sum up my previous emails, yo

Re: [openstack-dev] [Neutron] Issue with pymysql

On Fri, Jun 12, 2015 at 7:13 PM, Sean Dague wrote: > On 06/12/2015 01:17 AM, Salvatore Orlando wrote: > > It is however interesting that both "lock wait timeouts" and "missing > > savepoint" errors occur in operations pertaining the same table - > > securitygroups in this case. > > I wonder if th

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

The review for the creation of the new project is here https://review.openstack.org/190998 To confirm Adrian, do you intend to use the Magnum launchpad for UI related bps and bugs or the Magnum UI launchpad indicated in the spec (https://launchpad.net/magnum-ui)? If it’s the former I shall upda

Re: [openstack-dev] [Neutron] Issue with pymysql

On 06/12/2015 06:31 AM, Joe Gordon wrote: > > > On Fri, Jun 12, 2015 at 7:13 PM, Sean Dague > wrote: > > On 06/12/2015 01:17 AM, Salvatore Orlando wrote: > > It is however interesting that both "lock wait timeouts" and "missing > > savepoint" errors occur in o

[openstack-dev] [api] [gabbi] gabbi can poll now

In various discussion with some of the projects, on this list and at summit, one of the holdups on people being able to adopt gabbi[1] as a tool for HTTP API testing in their own stuff was because they had request handlers that return 202 in response to a POST and the created resource would not b

Re: [openstack-dev] [Neutron] Issue with pymysql

On Fri, 12 Jun 2015, Joe Gordon wrote: Glad to see us catch these issues early. Yes! CI is doing exactly the job it is supposed to be doing here. It is finding bugs in code. When that happens we should fix the bugs, not revert. Even if it stalls other stuff. -- Chris Dent tw:@anticdent freeno

Re: [openstack-dev] [puppet] drop monolithic plugins in neutron module

Makes sense to drop them to me. On Wed, Jun 10, 2015 at 7:20 PM, Emilien Macchi wrote: > Hi, > > Monolithic plugins have been dropped in Neutron tree since Juno, I think > it's time to drop the code from puppet-neutron (I guess everyone is > using ML2, at least I hope for them). > > If anyone is

Re: [openstack-dev] [Manila] Ask for help on supportting the 3-rd party CI for HDFS driver

> > It doesn't make sense to require people to learn about things they > > will never use again - and the amount of time spent answering the > > questions, diagnosing problems and so on is quite a bit higher > > than doing it simply right the first time. > > This is, I think, also a common misconc

Re: [openstack-dev] [puppet] [Swift] Multiple proxy recipes will create out of sync rings

I skimmed the code, but since I'm not familiar with the environment, I could not find where "swift-ring-builder rebalance" is invoked. I'm guessing that each time you add a device to a ring, a rebalance is also done. Leaving aside how inefficient that is, the key thing is that the rebalance comm

Re: [openstack-dev] [kolla] Proposal for changing 1600UTC meeting to 1700 UTC

I'm fairly easy on this but, if the issue is that the meeting is running into people's evening schedules (in EMEA), would it not make sense to push it back an hour or two into office hours, rather than forward? On 10/06/15 18:20, Ryan Hallisey wrote: After some upstream discussion, moving the

Re: [openstack-dev] [puppet] [fuel] more collaboration request

> Hi, > > Before you read me, please remember I know almost nothing about puppet. :) > > On 06/11/2015 11:03 PM, Matt Fischer wrote: > > Matt, > > I appreciate a lot who you are, and all the help you've given me so far, > but what you are asking here is wrong. You shouldn't ask Emilien to > tra

Re: [openstack-dev] [OpenStack-Infra] Need help! Zuul can not connect to port 29418 of review.openstack.org

On 2015-06-12 09:46:34 + (+), liuxinguo wrote: > Thanks Tom, the method you provide is really a good idea, but > probably it won't work for a 3rd CI. I have tried to change ssh to > https for 3rd CI, but it is not a simple work like that. It > related to lots of zuul code change. It would

Re: [openstack-dev] [Murano] Does Murano support nested HOT templates?

Currently Murano doesn't support nested template unless they are specified by URL. However this is going to be fixed in current release cycle as there are many requests for this feature. Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis On Thu, Jun 11, 2015 at 1:55 AM, Vahid S

Re: [openstack-dev] [murano] python versions

I'd rather go with Heat approach (job first) because it makes easier to track what is left to port to Py34 and track progress in this area Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis On Mon, Jun 8, 2015 at 2:46 PM, Kirill Zaitsev wrote: > I’ve looked into several OS pro

Re: [openstack-dev] [puppet] [fuel] more collaboration request

On 12/06/15 03:28 -0700, Dmitry Borodaenko wrote: On Fri, Jun 12, 2015 at 09:24:33AM +0200, Flavio Percoco wrote: I'm sure you both, and the Fuel team, are acting on good faith but I believe, in this case, there's no problem that makes copy/pasting code, and therefore loosing commits attribution

Re: [openstack-dev] [puppet] [fuel] more collaboration request

On 12/06/15 03:04 -0700, Dmitry Borodaenko wrote: On Fri, Jun 12, 2015 at 09:31:45AM +0200, Flavio Percoco wrote: On 11/06/15 17:36 +0300, Matthew Mosesohn wrote: >Secondly, I'd like to point out that Fuel is not so different from >what other teams are doing. At the Summit, I heard from others w

Re: [openstack-dev] Looking for help getting git-review to work over https

Hi David, Ok, sudo python setup.py install without pbr install is not working behind an http proxy. Because you should use sudo -E python setup.py install to pass http(s)_proxy ernv variables. But even if you do so python setup.py install will try to install pbr WITHOUT taking into account proxy

Re: [openstack-dev] [nova] vif type libvirt-network

> But I still need to > figure out more details about device renaming and what other side > effects might come with it. Device renaming might not be a good idea in the macvtap context, as the interface used could also be used with by other applications that might insist on a fixed device name. It

Re: [openstack-dev] [nova] Should we add instance action event to live migration?

On 06/11/15 at 06:54pm, Ian Wells wrote: On 11 June 2015 at 12:37, Richard Raseley wrote: Andrew Laski wrote: There are many reasons a deployer may want to live-migrate instances around: capacity planning, security patching, noisy neighbors, host maintenance, etc... and I just don't think th

Re: [openstack-dev] [nova] Should we add instance action event to live migration?

On 6/12/15 7:46 AM, "Andrew Laski" wrote: >On 06/11/15 at 06:54pm, Ian Wells wrote: >>On 11 June 2015 at 12:37, Richard Raseley wrote: >> >>> Andrew Laski wrote: >>> There are many reasons a deployer may want to live-migrate instances around: capacity planning, security patching, noi

Re: [openstack-dev] [nova] FreeBSD host support, round 2

Daniel P. Berrange wrote: > On Tue, Jun 09, 2015 at 07:52:39PM +0300, Roman Bogorodskiy wrote: > > Hi, > > > > Few months ago I've started a discussion on FreeBSD host support for > > OpenStack. [1] At a result of discussion it was figured out that there > > are a number of limitations, mainly

Re: [openstack-dev] [nova] Should we add instance action event to live migration?

Le 12/06/2015 15:27, Matt Van Winkle a écrit : On 6/12/15 7:46 AM, "Andrew Laski" wrote: On 06/11/15 at 06:54pm, Ian Wells wrote: On 11 June 2015 at 12:37, Richard Raseley wrote: Andrew Laski wrote: There are many reasons a deployer may want to live-migrate instances around: capacity

Re: [openstack-dev] [kolla] Proposal for changing 1600UTC meeting to 1700 UTC

Even though 7am is not ideal for the west coast, I¹d be willing to go back that far. That would put the meeting at the morning school rush for the west coast folks though (although we are in summer break in the US and we could renegotiate a time in 3 months when school starts up again if its a pro

[openstack-dev] [Neutron] VLAN-aware VMs meeting

Hi, Since we reopened the review for this blueprint we've got a large number of comments. It can be clearly seen that the original proposal has to be changed, although it still requires some discussion to define a reasonable design that provides the desired feature and is aligned with the archi

Re: [openstack-dev] [puppet] [fuel] more collaboration request

Folks As Dmitry already said, we are open towards merging with upstream and would like to make our code divergence no more than several percents of lines, but there are historical reasons for this divergence with which we are not happy either. So let's just point out that both sides look into the

Re: [openstack-dev] [puppet] [fuel] more collaboration request

On 06/12/2015 05:43 AM, Dmitry Borodaenko wrote: > On Thu, Jun 11, 2015 at 11:43:09PM -0400, Emilien Macchi wrote: >> What about code history and respect of commit ownership? >> I'm personally wondering if it's fair to copy/paste several thousands of >> lines of code from another Open-Source proj

Re: [openstack-dev] [puppet] [fuel] more collaboration request

On 06/12/2015 08:29 AM, Flavio Percoco wrote: > On 12/06/15 03:04 -0700, Dmitry Borodaenko wrote: >> On Fri, Jun 12, 2015 at 09:31:45AM +0200, Flavio Percoco wrote: >>> On 11/06/15 17:36 +0300, Matthew Mosesohn wrote: >>> >Secondly, I'd like to point out that Fuel is not so different from >>> >wh

Re: [openstack-dev] [puppet] [fuel] more collaboration request

On 06/12/2015 07:58 AM, Bogdan Dobrelya wrote: >> Hi, >> >> Before you read me, please remember I know almost nothing about puppet. :) >> >> On 06/11/2015 11:03 PM, Matt Fischer wrote: >> >> Matt, >> >> I appreciate a lot who you are, and all the help you've given me so far, >> but what you are a

[openstack-dev] [kolla] general invitation to people involved with Kolla to join the Kolla-drivers team

The kolla-drivers team in launchpad is a restricted team because people can damage the issue tracker and cause a bunch of work on my end to fix. That said, I’m going to open up the kolla-drivers launchpad team to a wider group of any individual involved in Kolla. This is different from the cor

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

Adrian, Great thanks for that. I would recommend one change and that is for one magnum-drivers team across launchpad trackers. The magnum-drivers team as you know (this is for the benefit of others) is responsible for maintaining the states of the launchpad trackers. Regards, -steve From: A

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

Brad, Each repo should have a separate launchpad tracker. I reconfigured the magnum-ui launchpad tracker with the liberty series and the liberty milestones. This is common best practice in OpenStack governance. I recommend a common drivers team however, which should be magnum-drivers. Regar

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

Steve, There is no need for a second LP project at all. Adrian Original message From: "Steven Dake (stdake)" Date: 06/12/2015 7:41 AM (GMT-08:00) To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [magnum][horizon] Making a dashb

Re: [openstack-dev] [puppet] [fuel] more collaboration request

-1. You are correct in that it is allowed in free source, and done in practice. There has to be a very good reason for it for it though. It feels like you are using the nuclear option when there are other ways to solve the problem that are more friendly to the attribution of the authors. One of

[openstack-dev] [taskflow] Returning information from reverted flow

Hi, In Cinder we had merged a complicated piece of code[1] to be able to return something from flow that was reverted. Basically outside we needed an information if volume was rescheduled or not. Right now this is done by injecting information needed into exception thrown from the flow. Another

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

Adiran, Disagree. The python-magnumclient and heat-coe-templates have separate launchpad trackers. I suspect we will want a separate tracker for python-k8sclient when we are ready for that. IMO each repo should have a separate launchpad tracker to make the lives of the folks maintaining the

Re: [openstack-dev] [neutron] Microversioning work questions and kick-start

On Thu, Jun 11, 2015, Salvatore Orlando wrote: > Finally, I received queries from several community members that would be keen > on helping supporting this microversioning effort. I wonder if the PTL and the > API lieutenants would ok with agreeing to have a team of developers meeting > regularly,

Re: [openstack-dev] Looking for help getting git-review to work over https

As I apparently have to sudo this, it would likely be more effective, if at all, to specify the proxy on the command line. Unfortunately, it didn’t make any difference: # pip install --proxy "https://one.proxy.att.com:8080"; . Processing /home/dk068x/work/git-review Complete output from comm

Re: [openstack-dev] [puppet] [fuel] more collaboration request

On Fri, 2015-06-12 at 02:43 -0700, Dmitry Borodaenko wrote: > On Thu, Jun 11, 2015 at 11:43:09PM -0400, Emilien Macchi wrote: > > What about code history and respect of commit ownership? > > I'm personally wondering if it's fair to copy/paste several thousands of > > lines of code from another Open

[openstack-dev] [tc][openstack-ansible] Proposal to move project openstack-ansible

Hello TC members and fellow stackers, The `os-ansible-deployment`[0] project has submitted a review to to change the Governance of the project[1]. Our community of developers and deployers have discussed the move at length, in IRC/meetings and on etherpad[2], and believe that we're ready to be

Re: [openstack-dev] [Ironic] [TC] Discussion: changing Ironic's release model

On Thu, May 28, 2015 at 12:55:50PM -0700, Jim Rollenhagen wrote: > [snip] > > I also put an informational spec about this change up in the > ironic-specs repo: https://review.openstack.org/#/c/185171/. My goal was > to discuss this in the spec, but the mailing list is fine too. There are > some un

Re: [openstack-dev] [Neutron] Issue with pymysql

On 6/11/15 9:32 PM, Eugene Nikanorov wrote: Hi neutrons, I'd like to draw your attention to an issue discovered by rally gate job: http://logs.openstack.org/96/190796/4/check/gate-rally-dsvm-neutron-rally/7a18e43/logs/screen-q-svc.txt.gz?level=TRACE I don't have bandwidth to take a deep look

Re: [openstack-dev] [Neutron] Issue with pymysql

On 6/12/15 6:42 AM, Sean Dague wrote: On 06/12/2015 06:31 AM, Joe Gordon wrote: On Fri, Jun 12, 2015 at 7:13 PM, Sean Dague mailto:[email protected]>> wrote: On 06/12/2015 01:17 AM, Salvatore Orlando wrote: > It is however interesting that both "lock wait timeouts" and "missing >

[openstack-dev] [Fuel] 7.0 (master branch) ISO nightly builds are available

Hi, everyone, as we are heading to Fuel 6.1 release, we went through 6.1 Hard Code Freeze milestone and created stable/6.1 branch in stackforge/fuel-* repositories [1] >From now on our master branch (which is a future 7.0) is open for new features and we've enabled nightly builds for it. You can

Re: [openstack-dev] [puppet] [fuel] more collaboration request

Hi, I have read all this thread trying to understand what's going on. It has many emotions but very few logical proposals. Let me try to sum up and make some proposals. * A bug is reported in both Fuel Library and the Puppet module having > trouble. A patch is provided in Fuel Library (your fork

Re: [openstack-dev] [taskflow] Returning information from reverted flow

Dulko, Michal wrote: Hi, In Cinder we had merged a complicated piece of code[1] to be able to return something from flow that was reverted. Basically outside we needed an information if volume was rescheduled or not. Right now this is done by injecting information needed into exception thrown fr

Re: [openstack-dev] [Neutron] Issue with pymysql

Excerpts from Chris Dent's message of 2015-06-12 03:47:02 -0700: > On Fri, 12 Jun 2015, Joe Gordon wrote: > > > Glad to see us catch these issues early. > > Yes! CI is doing exactly the job it is supposed to be doing here. It > is finding bugs in code. When that happens we should fix the bugs, >

[openstack-dev] [nova] How to microversion API code which is not in API layer

Hi We have [1] in the db layer and it's directly used by API layer , the filters is directly from client's input In this case, when doing [2] or similar changes, do we need to consider microversion usage when we change options? Thanks [1] https://github.com/

Re: [openstack-dev] [puppet] [fuel] more collaboration request

On 06/12/2015 11:41 AM, Sergii Golovatiuk wrote: > Hi, > > I have read all this thread trying to understand what's going on. It has > many emotions but very few logical proposals. Let me try to sum up and > make some proposals. > > * A bug is reported in both Fuel Library and the Puppet mod

Re: [openstack-dev] [Neutron] Issue with pymysql

This is exactly what I did in [1]. Cheers, Armando [1] https://review.openstack.org/#/q/status:open+branch:master+topic:neutron-unstable,n,z On 12 June 2015 at 09:00, Clint Byrum wrote: > Excerpts from Chris Dent's message of 2015-06-12 03:47:02 -0700: > > On Fri, 12 Jun 2015, Joe Gordon wrote

Re: [openstack-dev] [OpenStack-Infra] Need help! Zuul can not connect to port 29418 of review.openstack.org

On 2015-06-12 09:04:09 + (+), liuxinguo wrote: > Recently our CI can not connect to port 29418 of > review.openstack.org. Following are the failuer > message, is there anyone know the reasion why our CI can not > cennect to 29418 of review.openstack.org? See the several other threads on th

Re: [openstack-dev] Looking for help getting git-review to work over https

David, FYI, I used corkscrew with pypi as well with another .ssh/config line of: Host pypi.python.org ProxyCommand corkscrew 80 %h %p On Fri, Jun 12, 2015 at 11:29 AM KARR, DAVID wrote: > As I apparently have to sudo this, it would likely be more effective, > if at all, to specify the

Re: [openstack-dev] [Neutron] Issue with pymysql

On 6/12/15 11:37 AM, Mike Bayer wrote: On 6/11/15 9:32 PM, Eugene Nikanorov wrote: Hi neutrons, I'd like to draw your attention to an issue discovered by rally gate job: http://logs.openstack.org/96/190796/4/check/gate-rally-dsvm-neutron-rally/7a18e43/logs/screen-q-svc.txt.gz?level=TRACE I

Re: [openstack-dev] Looking for help getting git-review to work over https

Good idea, but that also made no difference. In any case, I don’t think this is attempting a direct ssh connection, so I don’t see how setting up a ssh proxy would make any difference. I tried this as “myself” and also with “sudo –E bash” with the same result: $ pip install . Processing /home/

[openstack-dev] [packaging] RPM Packaging for OpenStack IRC Meeting

Hi, A couple of packagers from RDO and SUSE met today on IRC to kick off brain storming on unified upstream rpm packaging for OpenStack. Please note: there are currently two movements going on: RDO would like to move their Liberty packaging from github.com and gerrithub to openstack gerrit, and R

Re: [openstack-dev] Nominating Joshua Hesketh for infra-root

On Thu, Jun 11, 2015 at 9:54 AM, James E. Blair wrote: > The Infrastructure program has a unique three-tier team structure: > contributors (that's all of us!), core members (people with +2 ability > on infra projects in Gerrit) and root members (people with > administrative access). Read all abou

[openstack-dev] [nova][drivers] hypervisor support matrix: feature "serial console"

The "serial console" feature was introduced during the Juno cycle and is an alternative to remote access via VNC, RDP, SPICE for platforms which don't support these. The review 180912 adds a new row for this feature in the hypervisor support matrix [1]. Please have a look if you can make a support

Re: [openstack-dev] Looking for help getting git-review to work over https

Python has generally awful support for doing HTTPS over an HTTPS proxy. Can you try doing: # pip install --proxy http://one.proxy.att.com: Cheers, Ian On 6/12/15, 10:26, "KARR, DAVID" wrote: >As I apparently have to sudo this, it would likely be more effective, if >at all, to specify the proxy

Re: [openstack-dev] [packaging] RPM Packaging for OpenStack IRC Meeting

On 06/12/2015 12:47 PM, Dirk Müller wrote: > Hi, > > A couple of packagers from RDO and SUSE met today on IRC to kick off > brain storming on unified upstream rpm packaging for OpenStack. > > Please note: there are currently two movements going on: RDO would > like to move their Liberty packaging

Re: [openstack-dev] Looking for help getting git-review to work over https

> -Original Message- > From: Ian Cordasco [mailto:[email protected]] > Sent: Friday, June 12, 2015 9:57 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] Looking for help getting git-review to > work over https > > Python has gene

Re: [openstack-dev] [packaging] RPM Packaging for OpenStack IRC Meeting

Hi Russel, > I'm just kind of curious ... as both the RDO and SUSE folks look closer > at this, how big are the differences? >From the overall big picture, we're doing pretty much the same thing. We have both a tool chain to continuously track changes as they happen in upstream git, packaging tha

[openstack-dev] [Openstack][Neutron][OVN] OVN-Neutron - TODO List

Hello All, I wanted to share some of our next working items and hopefully get more people on board with the project. I personally would mentor any new comer that wants to get familiar with the project and help with any of these items. You can also feel free to approach Russell Bryant (rbry...@redh

Re: [openstack-dev] [packaging] RPM Packaging for OpenStack IRC Meeting

On 06/12/2015 01:31 PM, Dirk Müller wrote: >> If instead it seems >> the differences are minor enough that combining efforts is a win for >> everyone, then that's even better, but I don't see it as the required >> outcome here personally. > > Right. We've started with an open discussion and not st

Re: [openstack-dev] [packaging] RPM Packaging for OpenStack IRC Meeting

Dirk Müller wrote: Hi Russel, I'm just kind of curious ... as both the RDO and SUSE folks look closer at this, how big are the differences? From the overall big picture, we're doing pretty much the same thing. We have both a tool chain to continuously track changes as they happen in upstream

Re: [openstack-dev] [Neutron] Issue with pymysql

Excerpts from Mike Bayer's message of 2015-06-12 09:42:42 -0700: > > On 6/12/15 11:37 AM, Mike Bayer wrote: > > > > > > On 6/11/15 9:32 PM, Eugene Nikanorov wrote: > >> Hi neutrons, > >> > >> I'd like to draw your attention to an issue discovered by rally gate job: > >> http://logs.openstack.org/9

Re: [openstack-dev] [Neutron] Issue with pymysql

Sean, Thanks for quick fix/revert https://review.openstack.org/#/c/191010/ This unblocked Rally gates... Best regards, Boris Pavlovic On Fri, Jun 12, 2015 at 8:56 PM, Clint Byrum wrote: > Excerpts from Mike Bayer's message of 2015-06-12 09:42:42 -0700: > > > > On 6/12/15 11:37 AM, Mike Bayer w

Re: [openstack-dev] [Magnum] Discuss configurable-coe-api-port Blueprint

Thanks for raising this for discussion. Although I do think that the API port humber should be expressed in a URL that the local client can immediately use for connecting a native client to the API, I am not convinced that this needs to be a separate attribute on the Bay resource. In general, I

[openstack-dev] [Magnum] Docker Native Networking

Team, OpenStack Networking support for Magnum Bays was an important topic for us in Vancouver at the design summit. Here is one blueprint that requires discussion that’s beyond the scope of what we can easily fit in the BP whiteboard: https://blueprints.launchpad.net/magnum/+spec/native-docker-

[openstack-dev] [Magnum] Essential and High priority blueprints

Team, Starting next week, I will be asking our blueprint assignees (or a chosen delegate) to provide a brief team update on each of our Essential and High priority blueprints. We currently have 11 of them so, let’s plan to keep the updates concise in the < 3 min range. Remember that if you are

Re: [openstack-dev] [Magnum] Discuss configurable-coe-api-port Blueprint

Egor makes a good point. If we have the API port number on the Baymodel, and Magnum sets the api_address value to a URL that contains the correct protocol, address, and port for the native API service. Here is the blueprint for that: https://blueprints.launchpad.net/magnum/+spec/magnum-api-addre

[openstack-dev] [tc][Cue] Add Cue to OpenStack

Hello OpenStack TC and stackers! We’ve submitted a patch to add Cue to the OpenStack project list. https://review.openstack.org/#/c/191173/ For those not familiar, Cue is a Message Broker Provisioning and Lifecycle Management service for OpenStack. We’ve focused initially on RabbitMQ, and are s

[openstack-dev] [cinder] : DotHill FC/iSCSI Drivers ; Copyright attribution incident

Dear Mike It has come to my attention that during the work done to submit code into OpenStack one of our Engineers had accidently deleted the original copyright notice thereby failing to give credit to the original authors of the code namely “Objectif Libre”. It was inadvertent and there was no

Re: [openstack-dev] Looking for help getting git-review to work over https

On Fri, 2015-06-12 at 17:08 +, KARR, DAVID wrote: > Thanks. I already tried that. It's not even clear this is failing to > connect. I don't know what this is telling me. > -- > # pip install --proxy http://one.proxy.att.com:8080 . > Processing /home/dk068x/work/git-review >

Re: [openstack-dev] Looking for help getting git-review to work over https

It looks like it can't run the setup.py because it can't find pbr. Could you provide the following: - Version of pip you're using (pip --version) - How you installed pip (e.g., apt-get install -y python-pip) - Contents of your global pip configuration (if one exists, it will be in ~/.pip/) - What

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

Okay, I will think on that a bit. Adrian Original message From: "Steven Dake (stdake)" Date: 06/12/2015 8:04 AM (GMT-08:00) To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need

Re: [openstack-dev] [puppet] [fuel] more collaboration request

On Fri, Jun 12, 2015 at 02:25:31PM +0200, Flavio Percoco wrote: > >I have already explained in the thread how we address the problem of > >tracking down and managing the Fuel specific changes in forked modules. > >With that problem addressed, I don't see any other objective reason for > >frustratio

[openstack-dev] [Neutron] Proposing Rossella Sblendido for the Control Plane core team

Hello! As the Lieutenant of the built-in control plane[1], I would like Rossella Sblendido to be a member of the control plane core reviewer team. Her review stats are in line with other cores[2] and her feedback on patches related to the agents has been great. Additionally, she has been working

Re: [openstack-dev] Looking for help getting git-review to work over https

> -Original Message- > From: Kevin L. Mitchell [mailto:[email protected]] > Sent: Friday, June 12, 2015 12:05 PM > To: [email protected] > Subject: Re: [openstack-dev] Looking for help getting git-review to > work over https > > On Fri, 2015-06-12 at 17:08 +,

Re: [openstack-dev] [Neutron] Proposing Rossella Sblendido for the Control Plane core team

On Fri, Jun 12, 2015 at 2:44 PM, Kevin Benton wrote: > Hello! > > As the Lieutenant of the built-in control plane[1], I would like Rossella > Sblendido to be a member of the control plane core reviewer team. > > Her review stats are in line with other cores[2] and her feedback on > patches relate

  1   2   >