Re: [openstack-dev] Barbican : What is the difference between secret and order resource

Thanks a lot John for your response. It has helped me . Thanks and Regards, Asha Seshagiri On Fri, Apr 17, 2015 at 2:28 PM, John Wood wrote: > Hello Asha, > > So the last step you have is retrieving a decrypted secret from > Barbican. Barbican indeed stores the secret internally encrypted us

[openstack-dev] [keystone] Changes to Spec Proposal Freeze and Feature Freeze dates for Keystone in Liberty

As a quick update, for the Liberty cycle, keystone will be using the first milestone as our Spec Proposal Freeze (SPF), with Feature Proposal Freeze (API Impacting features must be code complete / ready for review / gating) at the second milestone. This will help to give us more time to ensure

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

> On Apr 17, 2015, at 8:53 PM, Monty Taylor wrote: > > On 04/17/2015 06:48 PM, Rochelle Grober wrote: >> I know the DevStack issue seems to be solved, but I had to >> respond.inline >> >> From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: Friday, April >> 17, 2015 12:28 To: OpenStack Deve

[openstack-dev] [keystone] keystone middleware package changing release method in Liberty

Hi everyone, I wanted to communicate to the community that the Keystone development team has determined that keystonemiddleware package should no longer be released in the same manner as the client libraries. Instead we will be releasing keystonemiddleware in the same manner as Keystone, in the

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

On 04/17/2015 06:48 PM, Rochelle Grober wrote: > I know the DevStack issue seems to be solved, but I had to > respond.inline > > From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: Friday, April > 17, 2015 12:28 To: OpenStack Development Mailing List (not for usage > questions) Subject: Re: [

[openstack-dev] [TripleO] patch review

Hi, Could experts especially cores help to review these patches? They have been there for long time. Thanks a lot. https://review.openstack.org/168208 (Fix ubuntu grub-pc install failure, uploaded on 27 March, fix bug 1437548, importance High) https://revi

[openstack-dev] Gerrit maintenance concluded

Our maintenance has concluded successfully without incident and the accompanying Gerrit outage was roughly an hour. We moved 10 repositories to new Git namespaces: stackforge/congress -> openstack/congress stackforge/murano -> openstack/murano stackforge/murano-agent -> openstack/mura

Re: [openstack-dev] [Nova][Neutron] HELP -- Please review some Kilo bug fixes

Open Reviews from the etherpad: Nova(lots), Neutron(2), Keystone(2), Glance(1), Ironic/DevStack(1) reviews I went through, checked all the reviews listed and put a notation on state of the patches, next steps, etc. Take another look. (my comments are medium blue). Some reviews are ready for c

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

See my other mail in this thread about app ecosystem. Encouraging more users/usage is a good reason to pay the cost. I think I've already given more then my fair $0.02 on the matter though so I'll stop talking about it now. Thanks, Kevin From: Rochelle Grober [ro

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

I know the DevStack issue seems to be solved, but I had to respond.inline From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: Friday, April 17, 2015 12:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default i

Re: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 23rd

On Fri, Apr 17, 2015 at 3:17 PM, Andreas Jaeger wrote: > On 04/17/2015 08:25 PM, Edgar Magana wrote: > >> Hello Folks, >> >> I would like to invite all available contributors to help us to complete >> the OpenStack Networking Guide. >> >> We are having a Networking Doc Day on April 23rd in order

[openstack-dev] [chef] A new Core member!

Hey everyone! I’d like to announce that Zhiwei Chen has stepped up as a new Core Member. Please take a moment to congratulate him! Thanks Zhiwei! JJ Asghar __ OpenStack Development Mailing List (not for usage questions) Uns

Re: [openstack-dev] [nova-docker][ceilometer][heat] Autoscaling docker in openstack

hi, i just noticed this but there was a similar spec proposed[1]. you might want to sync up with the original proposer or just take it over. [1] http://review.openstack.org/#/c/163920/ cheers, gord __

Re: [openstack-dev] [packaging][neutron] --config-dir vs. --config-file

Great! I was just worried that it was going to become one --config-dir option that pointed to /etc/neutron or something. On Fri, Apr 17, 2015 at 7:13 AM, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/13/2015 09:45 PM, Kevin Benton wrote: > > What is the order

Re: [openstack-dev] [Heat] moving sqlite migration scripts to tests

On 4/17/15 1:29 PM, Zane Bitter wrote: On 16/04/15 04:05, Anant Patil wrote: Hi, Sometime back we had a discussion on IRC regarding sqlite migration scripts. Since sqlite is mostly used for testing, we were thinking about moving the sqlite migration related code to tests folder and keep the m

Re: [openstack-dev] [neutron] Neutron scaling datapoints?

I think before we go much further with any of these major refactors, we need hard numbers that show where the scaling issues are. We can have an extremely efficient messaging system that will not make any impact in the grand scheme of things if there are other things that unnecessarily take up an o

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

On Fri, Apr 17, 2015 at 3:17 PM, Salvatore Orlando wrote: > let's default to linux bridge. At the end of the day I believe users > interested in OVS will find in a simple way in the documentation - possibly > even in the README file, a way for enabling it. We might even ship a > local.conf.ovs fi

[openstack-dev] [puppet] Managing config file values and parameter defaults

How to handle config file values, defaults and how they relate to manifest parameters was brought up in the weekly meeting up a few weeks ago. I promised to put something together. I've put written up my thoughts and my understanding of the other viewpoints presented there in an ether pad and you

Re: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 23rd

On 04/17/2015 08:25 PM, Edgar Magana wrote: Hello Folks, I would like to invite all available contributors to help us to complete the OpenStack Networking Guide. We are having a Networking Doc Day on April 23rd in order to review the current guide and make a big push on its content. Let’s use b

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

On 17 April 2015 at 21:35, Jeremy Stanley wrote: > On 2015-04-17 11:49:23 -0700 (-0700), Kevin Benton wrote: > > I definitely understand that. But what is the major complaint from > > operators? I understood that quote to imply it was around > > Neutron's model of self-service networking. > > My

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

On Fri, Apr 17, 2015 at 2:58 PM, Fox, Kevin M wrote: > Its because someone recommended devstack be switched to linux bridge so > that its easier for folks to learn openstack. but my assertion is, if all > production sites will have to run ovs I believe this is a false assertion and the crux of

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

Its because someone recommended devstack be switched to linux bridge so that its easier for folks to learn openstack. but my assertion is, if all production sites will have to run ovs (or some vendor plugin) and not linux bridge, your hurting folks by making them think they are learning somethin

Re: [openstack-dev] [puppet] naming of the project

On 04/17/2015 10:52 AM, Emilien Macchi wrote: > > > On 04/16/2015 02:32 PM, Emilien Macchi wrote: >> >> >> On 04/16/2015 02:23 PM, Richard Raseley wrote: >>> Emilien Macchi wrote: Hi all, I sent a patch to openstack/governance to move our project under the big tent, and it c

Re: [openstack-dev] [Fuel]Format of notifications about Ubuntu repositories connectivity

> On 17 Apr 2015, at 14:35, Maciej Kwiek wrote: > > Hi, > > I am currently implementing fix for > https://bugs.launchpad.net/fuel/+bug/1439686 . > > I plan to notify user about nodes which fail to connect to ubuntu > repositories via fuel notifications. My question is as follows: when I get

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

On 2015-04-17 11:49:23 -0700 (-0700), Kevin Benton wrote: > I definitely understand that. But what is the major complaint from > operators? I understood that quote to imply it was around > Neutron's model of self-service networking. My takeaway from Tom's message was that there was a concern about

Re: [openstack-dev] Barbican : What is the difference between secret and order resource

Hello Asha, So the last step you have is retrieving a decrypted secret from Barbican. Barbican indeed stores the secret internally encrypted using an internal KEK. When it is retrieved however, it is first decrypted by Barbican and then returned the client decrypted. Beyond TLS to protect this

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

No, the complaints from ops I have heard even internally, which I think is being echo'd here is "I understand how linux bridge works, I don't opensvswitch". and "I don't want to be bothered to learn to debug openvswitch because I don't think we need it". If linux bridge had feature parity with

Re: [openstack-dev] [TripleO] on supporting multiple implementations of tripleo-heat-templates

Excerpts from James Slagle's message of 2015-04-17 10:49:48 -0700: > On Fri, Apr 17, 2015 at 12:37 PM, Clint Byrum wrote: > > Excerpts from Giulio Fidente's message of 2015-04-17 06:21:28 -0700: > >> Hi, > >> > >> the Heat/Puppet implementation of the Overcloud deployment seems to be > >> surpassi

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

I definitely understand that. But what is the major complaint from operators? I understood that quote to imply it was around Neutron's model of self-service networking. If the main reason the remaining Nova-net operators don't want to use Neutron is due to the fact that they don't want to deal wit

[openstack-dev] [chef] Started the review to move from stackforge to openstack

Hey Everyone! I’ve started the review [1] to move from stackforge to openstack namespace. I’m looking for comments, ideas and any pointers. Please don’t hesitate to reach out via the review, email, or IRC on freenode. Thanks! JJ Asghar (j^2) [1]: https://review.openstack.org/175000

Re: [openstack-dev] [Nova][Neutron] Has Neutron satisfied parity with Nova network FlatDHCP?

But if I understand nova network with FlatDHCP correctly, there is no such thing as a host without a floating IP. So if every instance is given a floating IP in Neutron in a similar fashion, then the lack of SNAT distribution would not matter in that case, correct? On Fri, Apr 17, 2015 at 11:26 AM

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

On 2015-04-17 10:55:19 -0700 (-0700), Kevin Benton wrote: > I understand. What I'm saying is that switching to Linux bridge > will not change the networking model to 'just connect everything > to a simple flat network'. All of the complaints about > self-service networking will still hold. And con

Re: [openstack-dev] [heat] is cloudwatch really deprecated?

On 17/04/15 13:54, Matt Fischer wrote: On Fri, Apr 17, 2015 at 11:03 AM, Zane Bitter mailto:zbit...@redhat.com>> wrote: On 17/04/15 12:46, Matt Fischer wrote: The wiki for Using Cloudwatch states: "This feature will be deprecated or removed during the Havana cycle a

Re: [openstack-dev] [Nova][Neutron] Has Neutron satisfied parity with Nova network FlatDHCP?

DVR probably still does satisfy the same requirements as nova multi-host, because of the lack of SNAT masquerade distribution. Neutron DVR distributes the floating IP and east-west traffic, but the default gateway for each VM is still centralised, thus making the network node a SPOF. Then from a d

[openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 23rd

Hello Folks, I would like to invite all available contributors to help us to complete the OpenStack Networking Guide. We are having a Networking Doc Day on April 23rd in order to review the current guide and make a big push on its content. Let's use both the Neutron and Docs IRC channels: #open

[openstack-dev] [Nova][Neutron] Has Neutron satisfied parity with Nova network FlatDHCP?

If the Neutron topology is configured to use a router connected to an external network and a shared network, will that achieve the same semantics as Nova with a FlatDHCP network? One of the last remaining items that I was aware of was ARP poisoning protection. At the end of Kilo, we added protecti

Re: [openstack-dev] Barbican : What is the difference between secret and order resource

Hi All, I would like to know if the keys generated by Barbican through the order resource are encrypted using KEKS and then stored in the secret object or is it stored in unencypted format. Any help would be highly appreciated. root@barbican:~# curl -H 'Accept: application/json' -H 'X-Projec

Re: [openstack-dev] [Nova] Things to tackle in Liberty

True. For example, the infiniband passthrough blueprint might need port type info from neutron->nova? Thanks, Kevin From: Neil Jerram [neil.jer...@metaswitch.com] Sent: Friday, April 17, 2015 9:44 AM To: openstack-dev@lists.openstack.org Subject: Re: [open

Re: [openstack-dev] [tripleo] Building images separation and moving images into right place at right time

Dell - Internal Use - Confidential If images under consideration are for overcloud nodes then they will changing all the time also. It all depends on which layer you are working on. Just consider images for overcloud nodes as a cloud application, and then follow rules you would apply to any clo

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

Currently Murano supports part of it. It provides a per cloud region app store like functionality. But I think each deployer needs to load in the apps they want in the catalog. I'm thinking that ui should somehow plug into an openstack.org provided catalog of apps that OpenStack app developers c

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

>On the contrary, if you reread the message to which you were previously replying, it's was about the unnecessary complexity of OVS (and Neutron in general) for deployments which explicitly _don't_ need and can never take advantage of self-service networking. The implication being that Neutron need

Re: [openstack-dev] [heat] is cloudwatch really deprecated?

On Fri, Apr 17, 2015 at 11:03 AM, Zane Bitter wrote: > On 17/04/15 12:46, Matt Fischer wrote: > >> The wiki for Using Cloudwatch states: >> >> "This feature will be deprecated or removed during the Havana cycle as >> we move to using Ceilometer as a metric/alarm service instead." [1] >> >> Howeve

Re: [openstack-dev] [oslo][policy][neutron] oslo.policy API is not powerful enough to switch Neutron to it

Thanks for this analysis Ihar. Some comments inline. On 17 April 2015 at 14:45, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > tl;dr neutron has special semantics for policy targets that relies on > private symbols from oslo.policy, and it's impossible to in

Re: [openstack-dev] [TripleO] on supporting multiple implementations of tripleo-heat-templates

On Fri, Apr 17, 2015 at 12:37 PM, Clint Byrum wrote: > Excerpts from Giulio Fidente's message of 2015-04-17 06:21:28 -0700: >> Hi, >> >> the Heat/Puppet implementation of the Overcloud deployment seems to be >> surpassing in features the Heat/Elements implementation. >> >> The changes for Ceph are

[openstack-dev] [chef] PTL Candidacy

Hey everyone! Starting the process of moving Chef into the “big tent” of OpenStack, I’d like to offer my candidacy for the PTL of the Liberty cycle. My Qualifications I have been shepherding the OpenStack Chef community since July of last year. My role at Chef is the “OpenStack guy.” I have st

Re: [openstack-dev] Openstack live migration using devstack

Hi Double check that sql_connection in the [database] section of cinder.conf is not empty. Jordan On Fri, Apr 17, 2015 at 7:24 PM, Erlon Cruz wrote: > Had the same error, but with cinder. Did you find find out something about > this error? > > 2015-04-17 14:12:31.957 TR

Re: [openstack-dev] [Heat] moving sqlite migration scripts to tests

On 16/04/15 04:05, Anant Patil wrote: Hi, Sometime back we had a discussion on IRC regarding sqlite migration scripts. Since sqlite is mostly used for testing, we were thinking about moving the sqlite migration related code to tests folder and keep the migrate_repo sane (with only production cod

[openstack-dev] What's Up Doc? April 17, 2015

_Migration Day!_ Both our End User Guide and our Admin User Guide have been migrated from DocBook source to RST source and now build with Sphinx and a shiny new theme: http://docs.openstack.org/user-guide/index.html http://docs.openstack.org/user-guide-admin/index.html Multiple thanks and shout

Re: [openstack-dev] Openstack live migration using devstack

Had the same error, but with cinder. Did you find find out something about this error? 2015-04-17 14:12:31.957 TRACE cinder Traceback (most recent call last): 2015-04-17 14:12:31.957 TRACE cinder File "/usr/local/bin/cinder-volume", line 10, in 2015-04-17 14:12:31.957 TR

Re: [openstack-dev] [nova-docker][ceilometer][heat] Autoscaling docker in openstack

On 17/04/15 10:11, VACHNIS, AVI (AVI) wrote: Hi, @Ashish, if the limitation you've mentioned for #1 still exists, I join your question how heat auto-scale-group may work w/o ceilometer being able to collect docker metrics? Yeah, you're correct. Approach #2 has exactly the same problem as appr

Re: [openstack-dev] [heat] is cloudwatch really deprecated?

On 17/04/15 12:46, Matt Fischer wrote: The wiki for Using Cloudwatch states: "This feature will be deprecated or removed during the Havana cycle as we move to using Ceilometer as a metric/alarm service instead." [1] However it seems that cloudwatch is still being developed. It doesn't seem th

Re: [openstack-dev] [wsme] [ironic] [ceilometer] [magnum] [kite] [tuskar] WSME unmaintained ?

On Fri, Apr 17 2015, Lucas Alvares Gomes wrote: > Apparently not. But it would be good to get some bugs fixed in WSME > before we come up with > a final solution within each OpenStack project: Whether keep WSME or > migrate to something > else since it requires time. You are now both members of w

Re: [openstack-dev] [Nova][Neutron] HELP -- Please review some Kilo bug fixes

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/16/2015 09:54 AM, Bhandaru, Malini K wrote: > Hello Nova and Neutron developers! > > OpenStack China developers held a bug fest April 13-15. Worked on > 43 bugs and submitted patches for 29 of them. Etherpad with the bug > fix details (at the b

Re: [openstack-dev] [wsme] [ironic] [ceilometer] [magnum] [kite] [tuskar] WSME unmaintained ?

> On Fri, 17 Apr 2015, Lucas Alvares Gomes wrote: > >> /me also deliberately volunteers cdent to wsme core :-) > > > Feh. I suppose since most of the recent code and conversation has > been you and me, that makes sense. If people agree, I'm happy to > participate, but only if you're there too. That

[openstack-dev] [heat] is cloudwatch really deprecated?

The wiki for Using Cloudwatch states: "This feature will be deprecated or removed during the Havana cycle as we move to using Ceilometer as a metric/alarm service instead." [1] However it seems that cloudwatch is still being developed. So is it deprecated or not? [1] https://wiki.openstack.org/w

Re: [openstack-dev] [Nova] Things to tackle in Liberty

On 17/04/15 17:24, Daniel P. Berrange wrote: On Fri, Apr 17, 2015 at 12:16:25PM -0400, Jay Pipes wrote: On 04/10/2015 11:48 AM, Neil Jerram wrote: What I imagine, though, is that the _source_ of the plugging information could move from Nova to Neutron, so that future plugging-related code chang

Re: [openstack-dev] [wsme] [ironic] [ceilometer] [magnum] [kite] [tuskar] WSME unmaintained ?

On Fri, 17 Apr 2015, Lucas Alvares Gomes wrote: /me also deliberately volunteers cdent to wsme core :-) Feh. I suppose since most of the recent code and conversation has been you and me, that makes sense. If people agree, I'm happy to participate, but only if you're there too. That's only fair

Re: [openstack-dev] [Nova] Things to tackle in Liberty

On 17/04/15 17:16, Jay Pipes wrote: On 04/10/2015 11:48 AM, Neil Jerram wrote: What I imagine, though, is that the _source_ of the plugging information could move from Nova to Neutron, so that future plugging-related code changes are a matter for Neutron rather than for Nova. The plugging would

Re: [openstack-dev] [TripleO] on supporting multiple implementations of tripleo-heat-templates

Excerpts from Giulio Fidente's message of 2015-04-17 06:21:28 -0700: > Hi, > > the Heat/Puppet implementation of the Overcloud deployment seems to be > surpassing in features the Heat/Elements implementation. > > The changes for Ceph are an example, the Puppet based version is already > adding

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/17/2015 06:23 PM, Fox, Kevin M wrote: > Really, what I expect to see long term in a healthy OpenStack > ecosystem is some global AppStore like functionality baked in to > horizon. A user goes to it, selects "my awesome scalable web > hosting syst

Re: [openstack-dev] Barbican : What is the difference between secret and order resource

Thanks a lot John for your response. I also thank everyone who has been responding to my queries if I have missed someone . There was some problem while configuring my email .I do not receive the email response directly from openstack Dev group.I would check the archive folder for that. I will

[openstack-dev] Candidate proposals for TC (Technical Committee) positions are now open

Candidate proposals for the Technical Committee positions (7 positions) are now open and will remain open until 05:59 UTC April 23, 2015. Candidates for the Technical Committee Positions: Any Foundation individual member can propose their candidacy for an available, directly-elected TC seat. [0] (

Re: [openstack-dev] [Nova] Things to tackle in Liberty

On Fri, Apr 17, 2015 at 12:16:25PM -0400, Jay Pipes wrote: > On 04/10/2015 11:48 AM, Neil Jerram wrote: > >What I imagine, though, is that the _source_ of the plugging information > >could move from Nova to Neutron, so that future plugging-related code > >changes are a matter for Neutron rather tha

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

In an app ecosystem, the users tend not to interact directly with the low level plumbing, but the app developers do. So likely, its the app developers, not the end users that care about naas in the long run. So I do agree that most users wont directly care about naas. But they will care about th

Re: [openstack-dev] [Nova] Things to tackle in Liberty

On 04/10/2015 11:48 AM, Neil Jerram wrote: What I imagine, though, is that the _source_ of the plugging information could move from Nova to Neutron, so that future plugging-related code changes are a matter for Neutron rather than for Nova. The plugging would still _happen_ from within Nova, as

Re: [openstack-dev] [wsme] [ironic] [ceilometer] [magnum] [kite] [tuskar] WSME unmaintained ?

Hi, >> * Should projects relying on WSME start thinking about migrating their APIs >> to another technology? > > Maybe not migrating, but at least not starting something new with it. > Oh no, FWIW I don't even consider starting something new as a valid option here. > Err, yeah, right. There are

Re: [openstack-dev] [tripleo] Building images separation and moving images into right place at right time

Hey Arkady, yes, this should stay as fundamental requirement. This is tandard Glance functionality, I just want to separate discover and deploy images since these will not be very likely subject of change and they belong into undercloud installation stage. That's why I want to separate overc

Re: [openstack-dev] [chef] Naming the Project

Nice! Yes, let get Chef as formal OpenStack project. Edgar From: JJ Asghar mailto:jasg...@chef.io>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Friday, April 17, 2015 at 8:41 AM To: OpenStack Development Mailing List

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

And since we've circled back I might add that perhaps we want nova-network to deliver that. Simple, reliable networking leveraging well-established off-the-shelf technologies that satisfies the use cases Jeremy is referring to. If regardless of changes in governance pertaining openstack project th

Re: [openstack-dev] [neutron] Neutron scaling datapoints?

- Original Message - > From: "joehuang" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Friday, April 17, 2015 9:46:12 AM > Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints? > > Hi, Attila, > > only address the issue of agent status/l

[openstack-dev] [nova] No L DB migrations until...

Hi all, We're trying to land a specific DB migration as the first in L: https://review.openstack.org/#/c/174480/ In order to do that, we need to get some changes into grenade, which are blocked on other housekeeping. That should happen in a week or so. In the meantime, please don't approve any

[openstack-dev] [chef] Naming the Project

In following the footsteps of the Puppet modules becoming a OpenStack project, the Chef cookbooks are starting the process also. I’ll be starting the review to the governance project soon, but the community needs to discuss it during our weekly hangout on Monday. One of the largest challenges in

Re: [openstack-dev] [wsme] [ironic] [ceilometer] [magnum] [kite] [tuskar] WSME unmaintained ?

Hello, No need to do that, I'm OK to add any competent people to wsme-core. :) > While I don't have a great deal of experience with the WSME code base (other then being a user of it), As Ironic is currently using WSME I would offer to help. As a core on Ironic I would continue to expect that to ta

Re: [openstack-dev] [nova-docker][ceilometer][heat] Autoscaling docker in openstack

Let's wait more opinions ;) I don;t think that we know everything. Regards, Sergey. On 17 April 2015 at 18:10, wrote: > So ultimately this means there is no way to autoscale docker containers > on openstack until and unless ceilometer adds an inspector for docker > hypervisor something similar

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

On 2015-04-16 21:17:03 -0700 (-0700), Kevin Benton wrote: > What do you disagree with? I was pointing out that using Linux > bridge will not reduce the complexity of the model of self-service > networking, which is what the quote was complaining about. On the contrary, if you reread the message to

Re: [openstack-dev] [nova-docker][ceilometer][heat] Autoscaling docker in openstack

So ultimately this means there is no way to autoscale docker containers on openstack until and unless ceilometer adds an inspector for docker hypervisor something similar to this (https://github.com/openstack/ceilometer/tree/master/ceilometer/compute/virt). Regards Ashish ___

Re: [openstack-dev] [nova] Mysql db connection leaking?

On 04/16/2015 06:40 PM, Matt Riedemann wrote: On 4/16/2015 12:27 PM, Jay Pipes wrote: On 04/16/2015 09:54 AM, Sean Dague wrote: On 04/16/2015 05:20 PM, Qiming Teng wrote: Wondering if there is something misconfigured in my devstack environment, which was reinstalled on RHEL7 about 10 days ago

Re: [openstack-dev] [puppet] naming of the project

On 04/16/2015 02:32 PM, Emilien Macchi wrote: > > > On 04/16/2015 02:23 PM, Richard Raseley wrote: >> Emilien Macchi wrote: >>> Hi all, >>> >>> I sent a patch to openstack/governance to move our project under the big >>> tent, and it came up [1] that we should decide of a project name and be >>

Re: [openstack-dev] [nova] Mysql db connection leaking?

On 04/17/2015 05:26 AM, Qiming Teng wrote: On Thu, Apr 16, 2015 at 01:27:51PM -0400, Jay Pipes wrote: On 04/16/2015 09:54 AM, Sean Dague wrote: On 04/16/2015 05:20 PM, Qiming Teng wrote: Wondering if there is something misconfigured in my devstack environment, which was reinstalled on RHEL7 a

Re: [openstack-dev] [nova-docker][ceilometer][heat] Autoscaling docker in openstack

@VACHNIS: yeah. in this case we blocked by ceilometer. AFAIK, ceilometer collect metrics from Nova:Server, not from docker directly. So mentioned bp is make sense (add support for this feature to ceilomete, then to heat). Regards, Sergey. On 17 April 2015 at 17:11, VACHNIS, AVI (AVI) < avi.vach

Re: [openstack-dev] [tripleo] Building images separation and moving images into right place at right time

Oh, I see it got already split (not in this patch)! Excellent. Thanks for striking me Jay, it actually helped. Many thanks! -- Jarda On 17/04/15 16:00, Jay Dobies wrote: Have you seen Dan's first steps towards splitting the overcloud image building out of devtest_overcloud? It's not the same t

Re: [openstack-dev] [opentack-dev][meetings] Proposing changes in Rally meetings

> - We should start making agenda for each meeting and publish it to Rally wiki +1 > * Second is release management meeting, where we are discussing priorities for > current & next release. So core team will know what to review first. It would be nice to post list of high priority pat

Re: [openstack-dev] [nova-docker][ceilometer][heat] Autoscaling docker in openstack

Yes limitation #1 indeed exists, have got confirmation from few of the developers. Here is one blueprint which talks about this https://blueprints.launchpad.net/ceilometer/+spec/container-monitoring From: VACHNIS, AVI (AVI) Sent: Friday, April 17, 2015 7:41 PM

Re: [openstack-dev] [tripleo] Building images separation and moving images into right place at right time

Dell - Internal Use - Confidential We need an ability for an Admin to add/remove new images at will to deploy new overcloud images at any time. Expect that it is standard glance functionality. -Original Message- From: Jaromir Coufal [mailto:jcou...@redhat.com] Sent: Friday, April 17,

Re: [openstack-dev] [packaging][neutron] --config-dir vs. --config-file

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/13/2015 09:45 PM, Kevin Benton wrote: > What is the order of priority between the same option defined in > two files with --config-dir? Should be alphabetically sorted, but it's not yet defined in documentation. I've sent a patch for this: https

Re: [openstack-dev] [nova-docker][ceilometer][heat] Autoscaling docker in openstack

Hi, @Ashish, if the limitation you've mentioned for #1 still exists, I join your question how heat auto-scale-group may work w/o ceilometer being able to collect docker metrics? @Sergey, hey. Are you saying that ceilometer do collects metrics on docker underlying nova::server resource? -A

Re: [openstack-dev] [packaging][neutron] --config-dir vs. --config-file

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/13/2015 07:47 PM, Dimitri John Ledkov wrote: > Hello, > > For Clear Linux* for Intel Architecture we do not allow to package > things in /etc, instead we leave /etc completely empty and for > user/admin modifications only. Typically we achieve

Re: [openstack-dev] [packaging][neutron] --config-dir vs. --config-file

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/13/2015 10:08 PM, Matthew Thode wrote: > The loading seems to me in a sorted order, so we can do 1.conf > 2.conf etc. > > https://github.com/openstack/oslo.config/blob/1.9.3/oslo_config/cfg.py #L1265-L1268 It > would need to be explicitly desc

Re: [openstack-dev] [tripleo] Building images separation and moving images into right place at right time

Have you seen Dan's first steps towards splitting the overcloud image building out of devtest_overcloud? It's not the same thing that you're talking about, but it might be a step in that direction. https://review.openstack.org/#/c/173645/ On 04/17/2015 09:50 AM, Jaromir Coufal wrote: Hi All,

[openstack-dev] [release] release critical oslo.messaging changes

It turns out a number of people are hitting - https://bugs.launchpad.net/oslo.messaging/+bug/1436769 (I tripped over it this morning as well). Under a currently unknown set of conditions you can get into a heartbeat loop with oslo.messaging 1.8.1 which basically shuts down the RPC bus as every ser

Re: [openstack-dev] [opentack-dev][meetings] Proposing changes in Rally meetings

15UTC works for me, it's 23 here in China, 17UTC is really late for me ;) Cheers, Yingjun Li At 2015-04-17 21:26:29, "Boris Pavlovic" wrote: Rally team, I would like to propose next changes in Rally meetings: - We should start making agenda for each meeting and publish it to Rally w

Re: [openstack-dev] [nova-docker][ceilometer][heat] Autoscaling docker in openstack

Hi Segey, So IIUC approach #2 may still help to autoscale docker on openstack. I will try that out and post questions on heat irc thanks. Regards Ashish From: Sergey Kraynev Sent: Friday, April 17, 2015 7:01 PM To: OpenStack Development Mailing List (not for

[openstack-dev] [tripleo] Building images separation and moving images into right place at right time

Hi All, at the moment we are building discovery, deploy and overcloud images all at once. Then we face user to deal with uploading all images at one step. User should not be exposed to discovery/deploy images. This should happen automatically for the user during undercloud installation as po

Re: [openstack-dev] [nova-docker][ceilometer][heat] Autoscaling docker in openstack

Hi, Ashish. Honestly I am not familiar with most part of these ways, but can add more information from Heat side (item 2). I am surprised, that you have missed Heat autoscaling mechanism (You should look it :) ). It's one of the important part of Heat project. It allows to scale vms/stacks by usi

[openstack-dev] [opentack-dev][meetings] Proposing changes in Rally meetings

Rally team, I would like to propose next changes in Rally meetings: - We should start making agenda for each meeting and publish it to Rally wiki - We should do 2 meeting per week: * First is regular meeting (like we have now) where we are discussing everything * Second is relea

[openstack-dev] [TripleO] on supporting multiple implementations of tripleo-heat-templates

Hi, the Heat/Puppet implementation of the Overcloud deployment seems to be surpassing in features the Heat/Elements implementation. The changes for Ceph are an example, the Puppet based version is already adding features which don't have they counterpart into Elements based. Recently we sta

[openstack-dev] PTL Election Conclusion and Results

Thank you to the electorate, to all those who voted and to all candidates who put their name forward for PTL for this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible. Now for the results of the PTL election proc

Re: [openstack-dev] [api] API WG Meeting Time

On 04/16/2015 05:25 PM, Everett Toews wrote: It would be good to hear from those in Asia, Australia, and Europe on the subject. +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-

[openstack-dev] [nova-docker][ceilometer][heat] Autoscaling docker in openstack

Hi, I have been working on running docker on openstack. I had a discussion on multiple IRC and IIUC there are 5 different ways of running docker on openstack. IIUC currently there is no way to autoscale docker on openstack. Please correct me if I am wrong 1) Using nova-docker driver - Runnin

Re: [openstack-dev] Using DevStack in Kilo

On 04/17/2015 06:44 AM, Jens Rosenboom wrote: > > > 2015-04-17 12:23 GMT+02:00 Sean Dague >: > > glanceclient has always been that way it's terrible. :( > > the nova message timeout looks like it's becauce nova-cert is not > running, and it keeps trying t

  1   2   >