Re: [openstack-dev] [oslo][nova] Messaging: everything can talk to everything, and that is a bad thing

> On Mar 21, 2016, at 9:43 PM, Adam Young wrote: > > I had a good discussion with the Nova folks in IRC today. > > My goal was to understand what could talk to what, and the short according to > dansmith > > " any node in nova land has to be able to talk to the queue for

Re: [openstack-dev] [fuel] FFE for fuel-openstack-tasks and fuel-remove-conflict-openstack

On 03/22/2016 09:25 AM, Matthew Mosesohn wrote: > Andrew, > > The stubs + deprecation warning is exactly the approach I believewe > should take for renaming/moving tasks. LGTM to me as far as it keeps plugins intact. So let's please update the patch [0] or submit required patches to unblock it.

[openstack-dev] [Solar] Weekly update

Hello, This is weekly update from Solar project. F2S: - we're working on Class2 LCM demo using Fuel tasks Solar itself: - staging procedure supports now both implicit and explicit stages - centos 7 patches merged (can be used instead of ubuntu) - better pg pool implementation - various bug

Re: [openstack-dev] [Fuel] Wiping node's disks on delete

On Tue, 2016-03-22 at 13:07 +0300, Dmitry Guryanov wrote: > Hello, > > .. > > [0] https://github.com/openstack/fuel-astute/blob/master/mcagents/era > se_node.rb#L162-L174 > [1] https://github.com/openstack/fuel- > agent/blob/master/fuel_agent/manager.py#L194-L221 Sorry, here is a correct

[openstack-dev] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates

Hello everyone, My name is Claudiu Belu, the current PTL for the Winstackers team. I apologize for missing such an important matter. It is a new project / team, I didn't expect to go through elections this cycle. I will be more careful in the future. As for the os-win, the project has been

Re: [openstack-dev] [Tempest][cinder] jenkins fails due to server fault

Poornima, Both Masayuki commented in the review request. For more details you can check cinder-api logs. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, Mar 21, 2016 at 8:18 AM, Poornima Kshirsagar wrote: > Hi, > > Wrote a Tempest test to check

[openstack-dev] [release][stable][ironic] ironic-python-agent 1.2.0 release (mitaka)

We are delighted to announce the release of: ironic-python-agent 1.2.0: Ironic Python Agent Ramdisk This release is part of the mitaka stable release series. For more details, please see below. 1.2.0 ^ New Features * Add new 'system_vendor' information to data - Add

[openstack-dev] [release][horizon][i18n] can we release django-openstack-auth of stable/mitaka for translations

Hi release management team, Can we have a new release of django-openstack-auth from stable/mitaka branch for translations? What is happening? django-openstack-auth is a library project consumed by Horizon. The (soft) string freeze happens when the milestone-3 is cut. The milestone-3 is also the

Re: [openstack-dev] [release][horizon][i18n] can we release django-openstack-auth of stable/mitaka for translations

> On Mar 22, 2016, at 6:18 AM, Akihiro Motoki wrote: > > Hi release management team, > > Can we have a new release of django-openstack-auth from stable/mitaka > branch for translations? > > What is happening? > django-openstack-auth is a library project consumed by Horizon.

[openstack-dev] [release][documentation] openstack-doc-tools 0.34.0 release

We are glad to announce the release of: openstack-doc-tools 0.34.0: Tools for OpenStack Documentation With source available at: http://git.openstack.org/cgit/openstack/openstack-doc-tools Please report issues through launchpad: http://bugs.launchpad.net/openstack-manuals For more

Re: [openstack-dev] [Tempest][cinder] jenkins fails due to server fault

Also our Mellanox CI failed See log[1] Looks like missing function /opt/stack/tempest/.tox/venv/local/lib/python2.7/site-packages/tempest_lib/__init__.py:28: DeprecationWarning: tempest-lib is deprecated for future bug-fixes and code changes in favor of tempest. Please change your imports from

Re: [openstack-dev] OpenStack Contributor Awards

Reminder :) We'll probably stop taking entries at the end of next week. On 16/02/16 18:43, Tom Fifield wrote: Hi all, I'd like to introduce a new round of community awards handed out by the Foundation, to be presented at the feedback session of the summit. Nothing flashy or starchy - the

Re: [openstack-dev] [networking-ovn][ovn4nfv]

Hi, Thanks for posting this. This is very interesting. I think that there are a number of different things to take into account here: 1. There is a service chaining project in Neutron https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining. Is the API there sufficient or

[openstack-dev] [neutron][dvr]How to get the relationship of veth pair device?

hi, all. In DVR mode, a veth pair devices were generated when I create a floating ip and associate it to a vm. And one of the pair device in fip namespace, the other one in qrouter namespace. How can I get the relationship between the veth pair device? I know the command "ethtool

Re: [openstack-dev] [TripleO] propose EmilienM for core

On 03/20/2016 07:22 PM, Dan Prince wrote: I'd like to propose that we add Emilien Macchi to the TripleO core review team. Emilien has been getting more involved with TripleO during this last release. In addition to help with various Puppet things he also has experience in building OpenStack

Re: [openstack-dev] [fuel] FFE for fuel-openstack-tasks and fuel-remove-conflict-openstack

Andrew, The stubs + deprecation warning is exactly the approach I believewe should take for renaming/moving tasks. If it was possible for a plugin to override a task, but preserve the fields from the original task, we could avoid such scenarios. What I mean is that if the following task: - id:

[openstack-dev] [Fuel] Wiping node's disks on delete

Hello, Here is a start of the discussion - http://lists.openstack.org/pipermail/openstack-dev/2015-December/083021.html . I've subscribed to this mailing list later, so can reply there. Currently we clear node's disks in two places. The first one is before reboot into bootstrap image [0] and the

Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

Steven Dake (stdake) wrote: Technical Committee, Please accept my proposal of a new type of project called a deployment [1]. If people don’t like the type name, we can change it. The basic idea is there are a class of projects unrepresented by type:service and type:library which are

[openstack-dev] [Kuryr] - Austin design summit sessions

Hello all, We have started this etherpad [1] in order to asses the number of sessions needed for Kuryr. We have received 5 work sessions and 1 fishbowl session. [2] Lets brainstorm and propose more ideas on the etherpad and start splitting the subjects to sessions with priorities. Anyone that

Re: [openstack-dev] [oslo][nova] Messaging: everything can talk to everything, and that is a bad thing

On 21/03/2016 9:43 PM, Adam Young wrote: > I had a good discussion with the Nova folks in IRC today. > > My goal was to understand what could talk to what, and the short > according to dansmith > > " any node in nova land has to be able to talk to the queue for any > other one for the most part:

Re: [openstack-dev] [Neutron] Plan for changes affecting DB schema

na...@vn.fujitsu.com wrote: Hi everyone, Two weeks ago, I received an information about changing affecting DB schema [1] from Henry Gessau just a day before the deadline. I was so surprised about this and could not change my plan for my patch sets. Do you know any plan for this ? In the

[openstack-dev] [Smaug]- IRC Meeting tomorrow (03/22) - 1400 UTC

Hi All, We will hold our bi-weekly IRC meeting today (Tuesday, 03/22) at 1400 UTC in #openstack-meeting Please review the proposed meeting agenda here: https://wiki.openstack.org/wiki/Meetings/smaug Please feel free to add to the agenda any subject you would like to discuss. Thanks, Saggi

[openstack-dev] [nova] Nova API sub-team meeting

Hi, We have weekly Nova API meeting tomorrow. The meeting is being held Wednesday UTC1300 and irc channel is #openstack-meeting-4. The proposed agenda and meeting details are here: https://wiki.openstack.org/wiki/Meetings/NovaAPI Please feel free to add items to the agenda. Thanks

Re: [openstack-dev] [oslo][nova] Messaging: everything can talk to everything, and that is a bad thing

On Tue, Mar 22, 2016, at 07:00 AM, Doug Hellmann wrote: > > > > On Mar 21, 2016, at 9:43 PM, Adam Young wrote: > > > > I had a good discussion with the Nova folks in IRC today. > > > > My goal was to understand what could talk to what, and the short according > > to

[openstack-dev] [all] FYI: how-to subscribe to specific bug tags

I was a little surprised when I found this, maybe you're in the same position. Use case: I'm interested in new/changed bug reports which are flagged with a specific tag but I don't want to open Launchpad everytime to query them. I'd like to get a notification by mail. How to:

Re: [openstack-dev] [oslo][nova] Messaging: everything can talk to everything, and that is a bad thing

On 21/03/16 21:43 -0400, Adam Young wrote: I had a good discussion with the Nova folks in IRC today. My goal was to understand what could talk to what, and the short according to dansmith " any node in nova land has to be able to talk to the queue for any other one for the most part:

Re: [openstack-dev] [Fuel] Wiping node's disks on delete

What about GPT[1] disks? As I know we have plans to support UEFI boot and GPT disks. [1] https://en.wikipedia.org/wiki/GUID_Partition_Table Regards, Bulat Gaifullin Mirantis Inc. > On 22 Mar 2016, at 13:46, Dmitry Guryanov wrote: > > On Tue, 2016-03-22 at 13:07

Re: [openstack-dev] [puppet] weekly meeting #75

rrow at 3pm UTC on > #openstack-meeting4. > > https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack > > As usual, free free to bring topics in this etherpad: > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160322 > > We'll start discussing about the Summit,

[openstack-dev] [kolla] Managing bug backports to Mitaka branch

Hi folks, Thierry (ttx in the irc log at [1]) proposed the standard way projects typically handle backports of newton fixes that should be fixed in an rc, while also maintaining the information in our rc2/rc3 trackers. Here is an example bug with the process applied:

[openstack-dev] [tc][deb][kolla][rpm] Introduce a new tag for type:packaging

Technical Committee, Thierry in this thread [1] suggested we need a type:packaging tag. Please accept my proposal for this work in this review [2]. Thanks! -steve [1] http://lists.openstack.org/pipermail/openstack-dev/2016-March/090096.html [2] https://review.openstack.org/295972

[openstack-dev] [cross-project] Meeting SKIPPED, Tue March 22th, 21:00 UTC

Hi all! We will not be having a cross-project meeting today, since there are no proposed agenda items [1]. All cross-project spec liaisons [2] should be ready to discuss the following items possibly next week: * Add centralized configuration options specification [3] * What are cross-project

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

> On Mar 22, 2016, at 2:10 PM, Alan Pevec wrote: > > 2016-02-26 19:51 GMT+01:00 Robert Collins : >>> On 27 February 2016 at 00:13, Neil Jerram >>> wrote: >>> I understand the semantic versioning algorithm for

Re: [openstack-dev] [magnum] High Availability

  -Original Message- From: Hongbin Lu Reply: OpenStack Development Mailing List (not for usage questions) Date: March 21, 2016 at 22:22:01 To: OpenStack Development Mailing List (not for usage questions)

[openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

2016-02-26 19:51 GMT+01:00 Robert Collins : > On 27 February 2016 at 00:13, Neil Jerram wrote: >> I understand the semantic versioning algorithm for calculating a new >> version. But what do I run, in a git repository, to do that calculation

Re: [openstack-dev] [nova] Trailing Slashes on URLs

On 03/22/2016 12:34 PM, Shoham Peller wrote: > Hi, > > Nova-api behaves different whether a trailing-slash is given in the URL > or not. > These 2 requests produce different results: > > * GET /v2/{tenant-id}/servers - gets a list of servers > * GET /v2/{tenant-id}/servers/ - gets an info

Re: [openstack-dev] [magnum] High Availability

From: Hongbin Lu > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Monday, March 21, 2016 at 8:19 PM To: "OpenStack Development

Re: [openstack-dev] [networking-ovn][ovn4nfv]

Gary, Thanks for replying. I did chat briefly to one of the authors of SFC last week and will talk with them more. I will admit I am coming at the general service insertion problem from a very specific use case; easily protecting east-west traffic between applications by dynamically inserting

Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

On Tue, 2016-03-22 at 15:37 +, Steven Dake (stdake) wrote: > > On 3/22/16, 2:15 AM, "Thierry Carrez" wrote: > > > > > Steven Dake (stdake) wrote: > > > > > > Technical Committee, > > > > > > Please accept my proposal of a new type of project called a > > >

Re: [openstack-dev] [Fuel] Packaging CI for Fuel

On 2016-03-22 15:20:22 + (+), Tristan Cacqueray wrote: [...] > With only my VMT hat on, this makes me wonder why the packaging needs > special care. Is there a reason why stable branch aren't built continuously? [...] My concern was more over handling packaging-specific security

[openstack-dev] [nova] Trailing Slashes on URLs

Hi, Nova-api behaves different whether a trailing-slash is given in the URL or not. These 2 requests produce different results: - GET /v2/{tenant-id}/servers - gets a list of servers - GET /v2/{tenant-id}/servers/ - gets an info for a server with an "empty id" - produces 404 IMHO, a

Re: [openstack-dev] [tripleo] becoming third party CI (was: enabling third party CI)

On Thu, 2016-03-10 at 23:24 +, Jeremy Stanley wrote: > On 2016-03-10 16:09:44 -0500 (-0500), Dan Prince wrote: > > > > This seems to be the week people want to pile it on TripleO. > > Talking > > about upstream is great but I suppose I'd rather debate major > > changes > > after we branch

Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

On 3/22/16, 2:15 AM, "Thierry Carrez" wrote: >Steven Dake (stdake) wrote: >> Technical Committee, >> >> Please accept my proposal of a new type of project called a deployment >> [1]. If people don¹t like the type name, we can change it. The basic >> idea is there are a

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

> The release team discussed this at the summit and agreed that it didn't > really matter. The only folks seeing the auto-generated versions are those > doing CD from git, and they should not be mixing different branches of a > project in a given environment. So I don't think it is strictly

Re: [openstack-dev] [fuel][puppet] Switching fuel-library to consume stable/mitaka

Hi, > Additionally we will want to ensure that the fuel-ci will work for the > upstream stable/mitaka branches as it currently[0] isn't working since we > haven't cut a stable/mitaka branch for Fuel yet. Igor Belikov has been > notified of the current issues and is looking into a fix. I

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

I've started my merging effort here https://github.com/dmitryilyin/openstack-puppet-pacemaker Can I change the interface of pcmk_resource? You have pcmk_constraint but I have pcmk_location/colocation/order separately. I can merge then into a single resource like you did or I can keep them

Re: [openstack-dev] [cinder] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method?

* liuxinguo wrote: > Hi Cinder team, > > We are going to implement storage-assisted volume migrate in our > driver between different backend storage array or even different array > of different vendors. This is really high-efficiency than the > host-copy migration between

[openstack-dev] [puppet] Modules release-notes

Today during our meeting we discussed about release note management. In Mitaka, we started to use Reno [1], here is an example with puppet-openstack_spec_helper [2]. In few months ago, when we decided that we would use reno, we wanted to educate people using it so this is what we decided to do

[openstack-dev] [puppet] Puppet OpenStack Community Session in Austin Summit

Puppet OpenStack group will have a Community Session during the next Summit in Austin. This session is great to gather feedback from anyone in OpenStack community: * developers can ask questions about how to contribute. * operators / users can give feedback at how modules work on their

Re: [openstack-dev] [barbican] High Availability

Hi Daneyon, We have been working on deploying a highly-available Barbican at Rackspace for a while now. We just recently made it publicly available through an early access program: http://go.rackspace.com/cloud-keep.html We don't have a full deployment of Barbican yet. Our early access

Re: [openstack-dev] [magnum] High Availability

Team, Time to close down this thread and start a new one. I’m going to change the subject line, and start with a summary. Please restrict further discussion on this thread to the subject of High Availability. Thanks, Adrian On Mar 22, 2016, at 11:52 AM, Daneyon Hansen (danehans)

[openstack-dev] [cross-project] What are specifications?

Hey all, Last Cross-Project meeting [1] I feel like there was some confusion around what our specifications should be used for. This mainly came up because of the rolling upgrade specification [2]. I want to clarify that this document exists as an incomplete specification that was contributed

[openstack-dev] [fuel][puppet] Switching fuel-library to consume stable/mitaka

Hey everyone, Emilien is in the process of cutting the stable/mitaka branches for all of the upstream puppet modules. As Fuel approaches SCF, we will want to switch from the master branches we are currently tracking to leverage the stable/mitaka branches. In talking with some other folks, I

[openstack-dev] [magnum] Streamline adoption of Magnum

Team, This thread is a continuation of a branch of the previous High Availability thread [1]. As the Magnum PTL, I’ve been aware of a number of different groups who have started using Magnum in recent months. For various reasons, there have been multiple requests for information about how to

Re: [openstack-dev] [nova] Trailing Slashes on URLs

Thank you for your answer Sean. Well understood. However, I think that if not fix this issue, at least we should supply guidelines on the matter. For example tempest's "test_delete_security_group_without_passing_id" test actually checks this behavior by addressing a security group with an "empty

Re: [openstack-dev] [oslo][nova] Messaging: everything can talk to everything, and that is a bad thing

>> Shouldn't we be trying to remove central bottlenecks by >> decentralizing communications where we can? > > I think that's a good goal to continue having. Some deployers have > setup firewalls between compute nodes, or between compute nodes and > the database, so we use the conductor to

Re: [openstack-dev] Hummingbird Roadmap

I don't have the original email but this is in reply to: Hi all, I was wondering what the roadmap for Hummingbird is. Will development continue? Will support continue? Is it expected to reach feature parity or even replace the Python code? Thank you, Avishay Yes- we are in active development

Re: [openstack-dev] [magnum] Streamline adoption of Magnum

On 03/22/2016 06:27 PM, Kevin Carter wrote: Comments in-line. On 03/22/2016 02:46 PM, Adrian Otto wrote: Team, This thread is a continuation of a branch of the previous High Availability thread [1]. As the Magnum PTL, I’ve been aware of a number of different groups who have started using

[openstack-dev] [release][stable][ironic] ironic-python-agent 1.0.2 release (liberty)

We are pumped to announce the release of: ironic-python-agent 1.0.2: Ironic Python Agent Ramdisk This release is part of the liberty stable release series. For more details, please see below. 1.0.2 ^ Bug Fixes * This enables virtual media deploy even if virtual floppy device name is

Re: [openstack-dev] [os-brick][nova][cinder] os-brick/privsep change is done and awaiting your review

On Sat, 19 Mar 2016 at 06:27 Matt Riedemann wrote: > I stared pretty hard at the nova rootwrap filter change today [1] and > tried to keep that in my head along with the devstack change and the > changes to os-brick (which depend on the devstack/cinder/nova changes).

Re: [openstack-dev] [oslo][nova] Messaging: everything can talk to everything, and that is a bad thing

On 03/22/2016 05:42 PM, Dan Smith wrote: Shouldn't we be trying to remove central bottlenecks by decentralizing communications where we can? I think that's a good goal to continue having. Some deployers have setup firewalls between compute nodes, or between compute nodes and the database, so we

Re: [openstack-dev] [oslo][nova] Messaging: everything can talk to everything, and that is a bad thing

On 03/22/2016 09:15 AM, Flavio Percoco wrote: On 21/03/16 21:43 -0400, Adam Young wrote: I had a good discussion with the Nova folks in IRC today. My goal was to understand what could talk to what, and the short according to dansmith " any node in nova land has to be able to talk to the

[openstack-dev] Newton summit planning etherpad

The summit planning etherpad for Keystone is here: https://etherpad.openstack.org/p/keystone-newton-summit-brainstorm Please brainstorm / toss ideas up / discuss Newton cycle goals Thanks, Steve Martinelli OpenStack Keystone Project Team Lead

Re: [openstack-dev] [magnum] Streamline adoption of Magnum

Comments in-line. On 03/22/2016 02:46 PM, Adrian Otto wrote: > Team, > > This thread is a continuation of a branch of the previous High > Availability thread [1]. As the Magnum PTL, I’ve been aware of a number > of different groups who have started using Magnum in recent months. For > various

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

  -Original Message- From: Alan Pevec Reply: OpenStack Development Mailing List (not for usage questions) Date: March 22, 2016 at 14:21:47 To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] Newton summit planning etherpad

On 03/22/2016 05:42 PM, Steve Martinelli wrote: > > The summit planning etherpad for Keystone is here: > https://etherpad.openstack.org/p/keystone-newton-summit-brainstorm > > Please brainstorm / toss ideas up / discuss Newton cycle goals > > Thanks, > > Steve Martinelli > OpenStack Keystone

Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

+1 for TripleO taking a look at Kolla. Some random thoughts: I'm in the middle of deploying a new cloud and I couldn't use either TripleO or Kolla for various reasons. A few reasons for each: * TripeO - worries me for ever having to do a major upgrade of the software, or needing to do oddball

Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

On Tue, Mar 22, 2016 at 6:01 PM, Fox, Kevin M wrote: > +1 for TripleO taking a look at Kolla. > > Some random thoughts: > > I'm in the middle of deploying a new cloud and I couldn't use either > TripleO or Kolla for various reasons. A few reasons for each: > * TripeO -

[openstack-dev] [release]how to release an non-official project in Mitaka

Hi, Thanks for the help. There is a plan for not only Tricircle but also Kingbird to do a release in Mitaka, both of them are not OpenStack official project yet. The question is whether these projects can leverage the facility https://github.com/openstack/releases to do a release, or is there

Re: [openstack-dev] Newton summit planning etherpad

On 3/22/2016 5:07 PM, Anita Kuno wrote: On 03/22/2016 05:42 PM, Steve Martinelli wrote: The summit planning etherpad for Keystone is here: https://etherpad.openstack.org/p/keystone-newton-summit-brainstorm Please brainstorm / toss ideas up / discuss Newton cycle goals Thanks, Steve

Re: [openstack-dev] [infra][neutron][nova] publish and update Gerrit dashboard link automatically

> From: Jeremy Stanley > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 02/18/2016 02:05 AM > Subject: Re: [openstack-dev] [infra][neutron] publish and update > Gerrit dashboard link automatically > > On

Re: [openstack-dev] [Neutron] Plan for changes affecting DB schema

na...@vn.fujitsu.com wrote: > Two weeks ago, I received an information about changing affecting DB schema > [1] from Henry Gessau just a day before the deadline. I was so surprised about > this and could not change my plan for my patch sets. Do you know any plan for > this ?

Re: [openstack-dev] [Sahara][QA] Notes about the move of the Sahara Tempest API test to sahara-tests

Thanks Luigi, sounds good to me. I'll be happy to help with reviews/approvals as needed. Trevor On Mon, 2016-03-21 at 12:05 +0100, Luigi Toscano wrote: > On Monday 21 of March 2016 10:50:30 Evgeny Sikachev wrote: > > Hi, Luigi! > > > > Thanks for this short spec :) > > Changes looking good

Re: [openstack-dev] [neutron] CI jobs take pretty long, can we improve that?

Thanks for doing this. I dug into the test_volume_boot_pattern test to see what was going on. On the first boot, Nova called Neutron to create a port at 23:29:44 and it took 441ms to return the port to Nova.[1] Nova then plugged the interface for that port into OVS a little over 6 seconds later

Re: [openstack-dev] [Fuel] Wiping node's disks on delete

For GPT disks and non-UEFI boot this method will work, since MBR will still contain first stage of a bootloader code. For UEFI boot things are little more complicated, we have to find EFI system partition, mount it and remove/edit some files. On Tue, Mar 22, 2016 at 4:26 PM, Bulat Gaifullin

Re: [openstack-dev] [TripleO] propose EmilienM for core

On Sun, Mar 20, 2016 at 02:22:49PM -0400, Dan Prince wrote: > I'd like to propose that we add Emilien Macchi to the TripleO core > review team. Emilien has been getting more involved with TripleO during > this last release. In addition to help with various Puppet things he > also has experience in

Re: [openstack-dev] [Openstack] Boot instance from volume via Horizon dashboard fails

Hi, thanks for your response. Having said that, there is probably a bug in Horizon since it's defaulting to vda for the device name when booting from volume. I think so, too. I'm quite new to Openstack and not 100% sure about my statements, but I think my question is not a support issue.

[openstack-dev] [Neutron]Debug with Pycharm

Hi everybody, Have you configured PyCharm to debug Neutron project. I confuged but it's not ok. If you have any archive, could you please share it with openstacker ? __ OpenStack Development Mailing List (not for usage

[openstack-dev] [nova] how to recover instances with different hypervisor-id on the same compute node

Hi All, Due to a hostname change, we ended up having a new hypervisor-id for one of our compute nodes. It was already running two instances and then, we didn't catch the updated hypervisor-id. This ended up with new instances spawning up with new hypervisor-id. Now, the instances with older

Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

OK. Got it. Thanks a lot for your help! Best regards, Yipei On Wed, Mar 23, 2016 at 11:41 AM, joehuang wrote: > Hi, Yipei, > > > > When you play Tricircle, it’s important to know that Tricircle is the > OpenStack API gateway to other OpenStack instances. In the Readme,

Re: [openstack-dev] [all][elections] PTL Voting is now open

On Fri, Mar 18, 2016 at 11:13:25AM +1100, Tony Breeds wrote: > Elections are underway and will remain open for you to cast your vote until > 2016-03-24, 23:59 UTC We've been informed that CIVS doesn't work correctly with a number of languages important in our community, including but not limited

Re: [openstack-dev] [Neutron] Plan for changes affecting DB schema

Thanks for your answer. -Original Message- From: Henry Gessau [mailto:hen...@gessau.net] Sent: Tuesday, March 22, 2016 8:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Plan for changes affecting DB schema

Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

Hi, Yipei, When you play Tricircle, it’s important to know that Tricircle is the OpenStack API gateway to other OpenStack instances. In the Readme, Pod1, Pod2 are two OpenStack instances, before trying Tricircle, you can make sure the environment is normal or not by executeing command

[openstack-dev] [tricircle]weekly meeting of Mar. 23

Hi, IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 13:00. Agenda: # Mitaka release preparation #Newton release features discussion # Link: https://etherpad.openstack.org/p/TricircleToDo Best Regards Chaoyi Huang ( Joe Huang )

Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

On Wed, Mar 23, 2016 at 12:41 PM, joehuang wrote: > Hi, Yipei, > > > > When you play Tricircle, it’s important to know that Tricircle is the > OpenStack API gateway to other OpenStack instances. In the Readme, Pod1, > Pod2 are two OpenStack instances, before trying Tricircle,

Re: [openstack-dev] [tricircle] Using in-memory database for unit tests

On 22 March 2016 at 12:09, Shinobu Kinjo wrote: > Thank you for your comment (inline for my message). > > On Tue, Mar 22, 2016 at 11:53 AM, Vega Cai wrote: > > Let me try to explain some. > > > > On 22 March 2016 at 10:09, Shinobu Kinjo

Re: [openstack-dev] [neutron][taas] Asynchronous TaaS APIs

Hi Anil, >I think we should adopt an asynchronous model, where we maintain the state for >>tap-service and tap-flow objects. Valid states could be "created", >"create->pending" and "failed." In addition, we will need a suitable mechanism >to have >the plugin extract the current state from the

Re: [openstack-dev] [keystone][ptls] Newton summit planning etherpad

I've added Keystone to the subject line. Keystone folks, please see email below from Steve! -amrith > -Original Message- > From: Anita Kuno [mailto:ante...@anteaya.info] > Sent: Tuesday, March 22, 2016 6:08 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] Newton

[openstack-dev] [tricircle] playing tricircle with two node configuration

Hi, Joe and Zhiyuan, I have already finished installing devstack in two nodes with tricircle. I encounter some errors when testing cross-pod L3 networking with DevStack. I followed the README.md in github, every thing goes well until I boot virtual machines with the following command: nova boot

Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

On 3/22/16, 2:15 AM, "Thierry Carrez" wrote: >Steven Dake (stdake) wrote: >> Technical Committee, >> >> Please accept my proposal of a new type of project called a deployment >> [1]. If people don¹t like the type name, we can change it. The basic >> idea is there are a

Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

On 22 March 2016 at 09:15, Thierry Carrez wrote: > > For OSA, we don't produce the deployment tool, only a set of playbooks. I > was thinking we might need a type:packaging tag to describe which things we > produce are just about packaging OpenStack things for usage by

Re: [openstack-dev] [neutron] CI jobs take pretty long, can we improve that?

On Tue, Mar 22, 2016 at 9:31 AM, Kevin Benton wrote: > Thanks for doing this. I dug into the test_volume_boot_pattern test to see > what was going on. > > On the first boot, Nova called Neutron to create a port at 23:29:44 and it > took 441ms to return the port to Nova.[1] >

Re: [openstack-dev] [Fuel] Packaging CI for Fuel

On 03/19/2016 06:53 PM, Jeremy Stanley wrote: > On 2016-03-19 05:10:18 -0500 (-0500), Monty Taylor wrote: > [...] >> It would also be good to tie off with the security team about >> this. One of the reasons we stopped publishing debs years ago is >> that it made us a de-facto derivative distro.

Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

From: Jesse Pretorius > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Tuesday, March 22, 2016 at 7:40 AM To: "OpenStack