[openstack-dev] 答复: [daisycloud-core] Agenda for IRC meeting Aug. 5 2016

Forgot to mentioned , the channel has been changed from #daisycloud to #openstack-meeting B.R., Zhijiang 发件人: HuZhiJiang180967/user/zte_ltd 收件人: hu.zhiji...@zte.com.cn, huzhiji...@gmail.com, lu.yao...@zte.com.cn, zhou...@zte.com.cn, sun.jin...@zte.com.cn,

[openstack-dev] [daisycloud-core] Agenda for IRC meeting Aug. 5 2016

1) Roll Call 2) Daisy Call Graph doc and CI doc 3) Git tag sync between Kolla code and images 4) Getting backend type and its use cases 5) Image 2.0.3 login problem 6) Daisy4nfv related status update B.R., Zhijiang __

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

I disagree as well. From users perspective, Glare looks like a Glance API v3. Having Glare and Glance as two independent services is quite confusing. I guess you would get a lot of questions like "what is the difference between Glance and Glare?", "does Glance depends on Glare?", "is Glare a

Re: [openstack-dev] [tc] persistently single-vendor projects

I think all the problem is caused by the definition "official OpenStack project" for one big-tent project. I understand that each OpenStack vendor wants some differentiation in their solution, while also would like to collaborate with common core projects. If we replace the title "official

[openstack-dev] [tripleo] Progress on overcloud upgrade / update jobs

Hi, I'm currently working by iteration to get a new upstream job that test upgrades and update. Until now, I'm doing baby steps. I bootstrapped the work to upgrade undercloud, see https> ://review.openstack.org/#/c/346995/ for details (it's almost working hitting a packaging issue now). Now I am

Re: [openstack-dev] [all] devstack changing to neutron by default RSN

On 4 August 2016 at 11:35, Sean Dague wrote: > One of the cycle goals in newton was to get devstack over to neutron by > default. Neutron is used by 90+% of our users, and nova network is > deprecated, and is not long for this world. > > Because devstack is used by developers as

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

On 08/04/2016 06:40 PM, Clint Byrum wrote: Excerpts from Jay Pipes's message of 2016-08-04 18:14:46 -0400: On 08/04/2016 05:30 PM, Clint Byrum wrote: Excerpts from Fox, Kevin M's message of 2016-08-04 19:20:43 +: I disagree. I see glare as a superset of the needs of the image api and one

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

Excerpts from Jay Pipes's message of 2016-08-04 18:14:46 -0400: > On 08/04/2016 05:30 PM, Clint Byrum wrote: > > Excerpts from Fox, Kevin M's message of 2016-08-04 19:20:43 +: > >> I disagree. I see glare as a superset of the needs of the image api and > >> one feature I need thats image

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

On 08/04/2016 05:30 PM, Clint Byrum wrote: Excerpts from Fox, Kevin M's message of 2016-08-04 19:20:43 +: I disagree. I see glare as a superset of the needs of the image api and one feature I need thats image related was specifically shot down as "the artefact api will solve that". You

[openstack-dev] [TripleO] a new Undercloud install driven by Heat

Last week I started some prototype work on what could be a new way to install the Undercloud. The driving force behind this was some of the recent "composable services" work we've done in TripleO so initially I called in composable undercloud. There is an etherpad here with links to some of the

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

Excerpts from Fox, Kevin M's message of 2016-08-04 19:20:43 +: > I disagree. I see glare as a superset of the needs of the image api and one > feature I need thats image related was specifically shot down as "the > artefact api will solve that". > > You have all the same needs to

Re: [openstack-dev] Project mascots update

From: Heidi Joy Tretheway > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Thursday, August 4, 2016 at 9:13 AM To: "OpenStack

Re: [openstack-dev] [Neutron] stable/liberty busted

Hitless restart logic in the agent. On Aug 4, 2016 14:07, "Rick Jones" wrote: > On 08/04/2016 01:39 PM, Kevin Benton wrote: > >> Yep. Some tests are making sure there are no packets lost. Some are >> making sure that stuff starts working eventually. >> > > Not to be

Re: [openstack-dev] [Neutron] stable/liberty busted

On 08/04/2016 01:39 PM, Kevin Benton wrote: Yep. Some tests are making sure there are no packets lost. Some are making sure that stuff starts working eventually. Not to be pedantic, but what sort of requirement exists that no packets be lost? rick

Re: [openstack-dev] [Neutron] stable/liberty busted

Yep. Some tests are making sure there are no packets lost. Some are making sure that stuff starts working eventually. On Aug 4, 2016 12:28, "Brian Haley" wrote: > On 08/04/2016 03:16 PM, Rick Jones wrote: > >> On 08/04/2016 12:04 PM, Kevin Benton wrote: >> >>> Yeah, I

Re: [openstack-dev] [tc] persistently single-vendor projects

On 08/04/2016 01:52 PM, Jay Faulkner wrote: Ironic does have radosgw support, and it's documented here: http://docs.openstack.org/developer/ironic/deploy/radosgw.html -- clearly it's not "first class" as we don't validate it in CI like we do with swift, but the code exists and I believe we have

Re: [openstack-dev] [Nova] Some thoughts on API microversions

On 08/04/2016 01:17 PM, Chris Friesen wrote: On 08/04/2016 09:28 AM, Edward Leafe wrote: The idea that by specifying a distinct microversion would somehow guarantee an immutable behavior, though, is simply not the case. We discussed this at length at the midcycle regarding the dropping of the

Re: [openstack-dev] [tc] persistently single-vendor projects

Awesome. Thanks for letting me know. :) This does raise it back up on my priority list a bit, as i know its more likely to work now with less effort. Thanks, Kevin From: Jay Faulkner [j...@jvf.cc] Sent: Thursday, August 04, 2016 12:52 PM To: OpenStack Development

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

That's fine, I might have an idea who have been saying so, but that statement has never been the consensus even among the Glance core team. In fct you would be well aware of this if you did follow the pretty colorful discussion around glance spec. We also have not had any intention to provide

Re: [openstack-dev] [tc] persistently single-vendor projects

On Aug 4, 2016, at 12:43 PM, Fox, Kevin M > wrote: The problem is, OpenStack is a very fractured landscape. It takes significant amounts of time for an operator to deploy "one more service". So, I spent a while deploying Trove, got it 90% working,

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

I get that. I don't blame Mirantis for that either. Thats a really difficult place to be in. This is the kind of silo disconnect I've been talking about though, where users of a project have real concrete needs, and the project doesn't listen as they think the current solution is "good enough"

Re: [openstack-dev] [tc] persistently single-vendor projects

The problem is, OpenStack is a very fractured landscape. It takes significant amounts of time for an operator to deploy "one more service". So, I spent a while deploying Trove, got it 90% working, then discovered Trove didn't work with RadosGW. RadosGW was a done deal long ago, and couldn't be

Re: [openstack-dev] [Neutron] stable/liberty busted

On 08/04/2016 03:25 PM, Brian Haley wrote: On 08/04/2016 03:16 PM, Rick Jones wrote: On 08/04/2016 12:04 PM, Kevin Benton wrote: Yeah, I wasn't thinking when I +2'ed that. There are two use cases for the pinger, one for ensuring continuous connectivity and one for eventual connectivity. I

[openstack-dev] [ironic] Abandoning specs without recent updates

Hi all, I'd like to abandon any ironic-specs reviews that haven't had any updates in 6 months or more. This works out to about 27 patches. The primary reason for this is to get items out of the review queue that are old and stale. I'll be performing this action next week unless there's

Re: [openstack-dev] [tc] persistently single-vendor projects

On 08/04/2016 03:02 PM, Fox, Kevin M wrote: Nope. The incompatibility was for things that never were in radosgw, not things that regressed over time. tmpurls differences and the namespacing things were there since the beginning first introduced. At the last summit, I started with the DefCore

Re: [openstack-dev] [Neutron] stable/liberty busted

On 08/04/2016 03:16 PM, Rick Jones wrote: On 08/04/2016 12:04 PM, Kevin Benton wrote: Yeah, I wasn't thinking when I +2'ed that. There are two use cases for the pinger, one for ensuring continuous connectivity and one for eventual connectivity. I think the revert is okay for a quick fix, but

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

I disagree. I see glare as a superset of the needs of the image api and one feature I need thats image related was specifically shot down as "the artefact api will solve that". You have all the same needs to version/catalog/store images. They are not more special then a

Re: [openstack-dev] [Neutron] stable/liberty busted

On 08/04/2016 12:04 PM, Kevin Benton wrote: Yeah, I wasn't thinking when I +2'ed that. There are two use cases for the pinger, one for ensuring continuous connectivity and one for eventual connectivity. I think the revert is okay for a quick fix, but we really need a new argument to the pinger

[openstack-dev] [new][glance] glance_store 0.16.0 release (newton)

We are jubilant to announce the release of: glance_store 0.16.0: OpenStack Image Service Store Library This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/glance_store With package available at:

Re: [openstack-dev] [Neutron] stable/liberty busted

Yeah, I wasn't thinking when I +2'ed that. There are two use cases for the pinger, one for ensuring continuous connectivity and one for eventual connectivity. I think the revert is okay for a quick fix, but we really need a new argument to the pinger for strictness to decide which behavior the

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

On Thu, Aug 4, 2016 at 7:13 PM, Tim Bell wrote: > >> On 04 Aug 2016, at 19:34, Erno Kuvaja wrote: >> >> On Thu, Aug 4, 2016 at 5:20 PM, Clint Byrum wrote: >>> Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +: On 04

Re: [openstack-dev] [tc] persistently single-vendor projects

Nope. The incompatibility was for things that never were in radosgw, not things that regressed over time. tmpurls differences and the namespacing things were there since the beginning first introduced. At the last summit, I started with the DefCore folks and worked backwards until someone

Re: [openstack-dev] [Neutron] stable/liberty busted

On 4 August 2016 at 11:45, Brian Haley wrote: > On 08/04/2016 01:36 PM, Armando M. wrote: > >> Hi Neutrinos, >> >> I have noticed that Liberty seems to be belly up [1]. I wonder if anyone >> knows >> anything or has the time to look into it. >> >> Many thanks, >> Armando >>

Re: [openstack-dev] [tc] persistently single-vendor projects

  -Original Message- From: Fox, Kevin M Reply: OpenStack Development Mailing List (not for usage questions) Date: August 4, 2016 at 13:40:53 To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

  -Original Message- From: Tim Bell Reply: OpenStack Development Mailing List (not for usage questions) Date: August 4, 2016 at 13:19:02 To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [Neutron] stable/liberty busted

On 08/04/2016 01:36 PM, Armando M. wrote: Hi Neutrinos, I have noticed that Liberty seems to be belly up [1]. I wonder if anyone knows anything or has the time to look into it. Many thanks, Armando [1] https://review.openstack.org/#/c/349039/ This could be due to this backport;

Re: [openstack-dev] [tc] persistently single-vendor projects

Sorry, I was a bit unclear here. I meant the radosgw in particular. I've seen multiple OpenStack projects fail to integrate with it. The most recent example I can think of is Trove can't do database backups to it as the namespacing is slightly different in the older radosgw versions. (I think

Re: [openstack-dev] [Nova] Some thoughts on API microversions

On 08/04/2016 12:47 PM, John Garbutt wrote: > On 4 August 2016 at 14:18, Andrew Laski wrote: >> On Thu, Aug 4, 2016, at 08:20 AM, Sean Dague wrote: >>> On 08/03/2016 08:54 PM, Andrew Laski wrote: I've brought some of these thoughts up a few times in conversations

[openstack-dev] [all] devstack changing to neutron by default RSN

One of the cycle goals in newton was to get devstack over to neutron by default. Neutron is used by 90+% of our users, and nova network is deprecated, and is not long for this world. Because devstack is used by developers as well as by out test infrastructure, the major stumbling block was coming

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

+1. This moves yet more work towards the operators. That should be taken into account. Thanks, Kevin From: Tim Bell [tim.b...@cern.ch] Sent: Thursday, August 04, 2016 8:55 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re:

Re: [openstack-dev] [Nova] Some thoughts on API microversions

On Aug 4, 2016, at 12:17 PM, Chris Friesen wrote: >> The idea that by specifying a distinct microversion would somehow guarantee >> an immutable behavior, though, is simply not the case. We discussed this at >> length at the midcycle regarding the dropping of the

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

> On 04 Aug 2016, at 19:34, Erno Kuvaja wrote: > > On Thu, Aug 4, 2016 at 5:20 PM, Clint Byrum wrote: >> Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +: >>> >>> On 04 Aug 2016, at 17:27, Mikhail Fedosin >>>

[openstack-dev] [all][api] POST /api-wg/news

Greetings OpenStack community, This week, the API-WG was visited by Deepti Ramakrishna from the Cinder project. Deepti brought up a spec currently being implemented by the Cinder team about resource capabilities, "New public core APIs to expose system capabilities"[5][6]. The result of this

[openstack-dev] [openstack-ansible][security] Adding RHEL 7 STIG to openstack-ansible-security

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey there, The existing openstack-ansible-security role uses security configurations from the Security Technical Implementation Guide (STIG) and the new Red Hat Enterprise Linux 7 STIG is due out soon. The role is currently based on the RHEL 6

[openstack-dev] [Neutron] stable/liberty busted

Hi Neutrinos, I have noticed that Liberty seems to be belly up [1]. I wonder if anyone knows anything or has the time to look into it. Many thanks, Armando [1] https://review.openstack.org/#/c/349039/ __ OpenStack

[openstack-dev] [Neutron] Drivers meeting - switching gear

Folks, As some of you may be familiar with, the typical agenda for the drivers meeting [1] involves the members of the drivers team going over triaged RFEs. Prior to the meeting we typically process confirmed and new RFEs to see whether some of them are worth triaging (i.e. discussed during the

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

On Thu, Aug 4, 2016 at 5:20 PM, Clint Byrum wrote: > Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +: >> >> On 04 Aug 2016, at 17:27, Mikhail Fedosin >> > wrote: >> > >> > Hi all, >> > > > after 6 months of Glare

Re: [openstack-dev] [tc] persistently single-vendor projects

On 08/04/2016 11:57 AM, Fox, Kevin M wrote: Ok. I'll play devils advocate here and speak to the other side of this, because you raised an interesting issue... Ceph is outside of the tent. It provides a (mostly) api compatible implementation of the swift api (radosgw), and it is commonly used

Re: [openstack-dev] [tc] persistently single-vendor projects

On Thu, Aug 4, 2016 at 9:57 AM, Fox, Kevin M wrote: > Ok. I'll play devils advocate here and speak to the other side of this, > because you raised an interesting issue... > > Ceph is outside of the tent. It provides a (mostly) api compatible > implementation of the swift api

Re: [openstack-dev] [Nova] Some thoughts on API microversions

On 08/04/2016 09:28 AM, Edward Leafe wrote: The idea that by specifying a distinct microversion would somehow guarantee an immutable behavior, though, is simply not the case. We discussed this at length at the midcycle regarding the dropping of the nova-network code; once that's dropped, there

Re: [openstack-dev] [tc] persistently single-vendor projects

On Thu, Aug 4, 2016 at 9:56 AM, Duncan Thomas wrote: > On 1 August 2016 at 18:14, Adrian Otto wrote: >> >> I am struggling to understand why we would want to remove projects from >> our big tent at all, as long as they are being actively

Re: [openstack-dev] [tc] persistently single-vendor projects

On Thu, 2016-08-04 at 10:10 +0200, Thierry Carrez wrote: > Devdatta Kulkarni wrote: > > As current PTL of one of the projects that has the team:single > > -vendor tag, I have following thoughts/questions on this issue. > > In preamble I'd like to reiterate that the proposal is not on the > table

Re: [openstack-dev] [tc] persistently single-vendor projects

Kevin, What do you mean by "Other OpenStack projects don't take it into account because its not a big tent thing"? I think there is pretty decent adoption of Ceph across the projects where it would make sense. Also I doubt none of them would be against 3rd party Ceph gates to those project if the

Re: [openstack-dev] [Nova] Some thoughts on API microversions

On 4 August 2016 at 14:18, Andrew Laski wrote: > On Thu, Aug 4, 2016, at 08:20 AM, Sean Dague wrote: >> On 08/03/2016 08:54 PM, Andrew Laski wrote: >> > I've brought some of these thoughts up a few times in conversations >> > where the Nova team is trying to decide if a

Re: [openstack-dev] [Nova] Some thoughts on API microversions

On Thu, Aug 4, 2016, at 11:40 AM, John Garbutt wrote: > On 4 August 2016 at 16:28, Edward Leafe wrote: > > On Aug 4, 2016, at 8:18 AM, Andrew Laski wrote: > > > >> This gets to the point I'm trying to make. We don't guarantee old > >> behavior in all cases at

Re: [openstack-dev] [Magnum] Adding opensuse as new driver to Magnum

Michal, The right place for drivers is the /drivers folder. Take a look at the existing drivers as an examples. You'll also need to update this file https://github.com/openstack/magnum/blob/master/setup.cfg#L60 and add a new entry point for the driver. I would encourage you to hold off on

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +: > > On 04 Aug 2016, at 17:27, Mikhail Fedosin > > wrote: > > > > Hi all, > > > > after 6 months of Glare v1 API development we have decided to continue > > our work in a separate

[openstack-dev] Project mascots update

Steve Dake asked: “Heidi, I received a related question from a Kolla core reviewer. Do the project teams have input into the mascot design? If this has already been discussed on the list, I may have missed it.” HJ: While we haven’t discussed this on the ML, we referenced a bit in the web page.

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

On Thu, Aug 4, 2016 at 4:46 PM, Alexander Tivelkov wrote: > I am the one who started the initiative 2.5 years ago, and was always > advocating the "let's stay in Glance" approach during numerous discussions > on "where should it belong" for all these years. > Now I believe

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

On 04 Aug 2016, at 17:27, Mikhail Fedosin > wrote: Hi all, after 6 months of Glare v1 API development we have decided to continue our work in a separate project in the "openstack" namespace with its own core team (me, Kairat Kushaev, Darja

Re: [openstack-dev] [tc] persistently single-vendor projects

Ok. I'll play devils advocate here and speak to the other side of this, because you raised an interesting issue... Ceph is outside of the tent. It provides a (mostly) api compatible implementation of the swift api (radosgw), and it is commonly used in OpenStack deployments. Other OpenStack

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

I am the one who started the initiative 2.5 years ago, and was always advocating the "let's stay in Glance" approach during numerous discussions on "where should it belong" for all these years. Now I believe that it is time to move forward indeed. Some things remain to be defined (first of all the

Re: [openstack-dev] [Nova] Some thoughts on API microversions

On 4 August 2016 at 16:28, Edward Leafe wrote: > On Aug 4, 2016, at 8:18 AM, Andrew Laski wrote: > >> This gets to the point I'm trying to make. We don't guarantee old >> behavior in all cases at which point users can no longer rely on >> microversions to

Re: [openstack-dev] [Nova] Some thoughts on API microversions

On Aug 4, 2016, at 8:18 AM, Andrew Laski wrote: > This gets to the point I'm trying to make. We don't guarantee old > behavior in all cases at which point users can no longer rely on > microversions to signal non breaking changes. And where we do guarantee > old behavior

[openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

Hi all, after 6 months of Glare v1 API development we have decided to continue our work in a separate project in the "openstack" namespace with its own core team (me, Kairat Kushaev, Darja Shkhray and the original creator - Alexander Tivelkov). We want to thank Glance community for their support

Re: [openstack-dev] [horizon] [horizon-plugin] AngularJS 1.5.8

+1 On 8/3/16, 5:36 PM, "Thomas Goirand" wrote: On 08/03/2016 12:19 PM, Rob Cresswell wrote: > Hi all, > > Angular 1.5.8 is now updated in its XStatic > repo: https://github.com/openstack/xstatic-angular > > I've done some manual testing of the

Re: [openstack-dev] [Nova] Nova compute reports the disk usage

Hi Chris, Actually, the system does not belong to us therefore we only had the log file. But it seems reasonable that besides the size of ephemeral diisk in _base, we also have the image of vm downloaded from Glance that consumes the disk capacity. That can make the strange value of

[openstack-dev] [Gluon] Face-to-Face Meeting Planned on August 18 & 19 in Silicon Valley

Hello team, During the IRC meeting on August 3 [1], the group agreed to have a face-to-face meeting on August 18 & 19 in Silicon Valley to discuss various topics and set up schedule for a potential demo in OpenStack Summit in Barcelona. The meeting logistics is available at [2], and tentative

Re: [openstack-dev] [nova] os-capabilities library created

On 08/04/2016 10:31 AM, Jim Rollenhagen wrote: On Wed, Aug 03, 2016 at 07:47:37PM -0400, Jay Pipes wrote: Hi Novas and anyone interested in how to represent capabilities in a consistent fashion. I spent an hour creating a new os-capabilities Python library this evening:

Re: [openstack-dev] [nova] os-capabilities library created

On Wed, Aug 03, 2016 at 07:47:37PM -0400, Jay Pipes wrote: > Hi Novas and anyone interested in how to represent capabilities in a > consistent fashion. > > I spent an hour creating a new os-capabilities Python library this evening: > > http://github.com/jaypipes/os-capabilities > > Please see

Re: [openstack-dev] [Manila] Nominate Tom Barron for core reviewer team

I have zero say here, but just want to say Tom is always a great guy to have around and knows his stuff. +1 from me that he should be core. On Wed, Aug 03, 2016 at 02:42:04PM -0400, Ben Swartzlander wrote: > Tom (tbarron on IRC) has been working on OpenStack (both cinder and > manila) for more

Re: [openstack-dev] [Nova] Nova compute reports the disk usage

On 08/04/2016 02:42 AM, Tuan Luong wrote: Hi Chris, Yes we used qcow image. However I still have something not clear. What I know is that: - disk_available_least = free_disk - disk_over_commit - disk_over_commit = int(virt_size) - physical_disk_size Before launching: - free_disk = 1025 -

Re: [openstack-dev] [all] Reviewing coverage jobs set up

On 2016-08-04 09:36:18 -0400 (-0400), Jim Rollenhagen wrote: [...] > Nice! FWIW, it's also documented here: > http://docs.openstack.org/infra/manual/developers.html#automated-testing I just proposed a note clarifying the situation with URLs for merge commits too, since that seems to have been

Re: [openstack-dev] [TripleO] Improving Swift deployments with TripleO

On 08/04/2016 01:26 PM, Christian Schwede wrote: On 04.08.16 10:27, Giulio Fidente wrote: On 08/02/2016 09:36 PM, Christian Schwede wrote: Hello everyone, thanks Christian, I'd like to improve the Swift deployments done by TripleO. There are a few problems today when deployed with the

Re: [openstack-dev] [all] Reviewing coverage jobs set up

On Thu, Aug 04, 2016 at 09:24:15AM -0400, Doug Hellmann wrote: > Excerpts from Kiall Mac Innes's message of 2016-08-04 01:27:23 +0100: > > On 18/07/16 20:14, Jeremy Stanley wrote: > > > Note that this will only be true if the change's parent commit in > > > Gerrit was the branch tip at the time it

Re: [openstack-dev] [all] Reviewing coverage jobs set up

Excerpts from Kiall Mac Innes's message of 2016-08-04 01:27:23 +0100: > On 18/07/16 20:14, Jeremy Stanley wrote: > > Note that this will only be true if the change's parent commit in > > Gerrit was the branch tip at the time it landed. Otherwise (and > > quite frequently in fact) you will need to

Re: [openstack-dev] [Nova] Some thoughts on API microversions

On Thu, Aug 4, 2016, at 08:20 AM, Sean Dague wrote: > On 08/03/2016 08:54 PM, Andrew Laski wrote: > > I've brought some of these thoughts up a few times in conversations > > where the Nova team is trying to decide if a particular change warrants > > a microversion. I'm sure I've annoyed some

Re: [openstack-dev] [all] [infra] Reviewing coverage jobs set up

On 2016-08-04 01:27:23 +0100 (+0100), Kiall Mac Innes wrote: > Without wanting to diverge too much from the topic at hand, I believe this > is why those of us who only occasionally want to look at post job output > usually just give up! Keeping this in your head for the once every few > months

Re: [openstack-dev] How to clone deleted branch, rre we keeping the history of the last commit id of deleted stable branches.

On 2016-08-03 19:08:22 -0500 (-0500), Matt Riedemann wrote: > On 8/3/2016 6:34 PM, Saju M wrote: > > I want to clone deleted icehouse branch of cinder. I know that, > > we can't clone it directly. Are we keeping the history of the > > last commit id of deleted stable branches. Please share the

Re: [openstack-dev] [tc] persistently single-vendor projects

Thomas Goirand wrote: > On 08/01/2016 09:39 AM, Thierry Carrez wrote: >> But if a project is persistently single-vendor after some time and >> nobody seems interested to join it, the technical value of that project >> being "in" OpenStack rather than a separate project in the OpenStack >>

Re: [openstack-dev] [Nova] Some thoughts on API microversions

On 08/03/2016 08:54 PM, Andrew Laski wrote: > I've brought some of these thoughts up a few times in conversations > where the Nova team is trying to decide if a particular change warrants > a microversion. I'm sure I've annoyed some people by this point because > it wasn't germane to those

[openstack-dev] [cinder][qa] Volume attachment intermittently failing

Hi all, I'm running on Kilo (by customer demands) and I have a problem where I get random failures while deploying a stack, the stack is a series of DB instances, each with their own volume. I can reproduce it in pretty much every run, usually in a different instance each time. The problem is

Re: [openstack-dev] [tc] persistently single-vendor projects

On 07/31/2016 05:59 PM, Fox, Kevin M wrote: > This sounds good to me. > > What about making it iterative but with a delayed start. Something like: > > There is a grace period of 1 year for projects that newly join the big tent. > After which, the following criteria will be evaluated to keep a

Re: [openstack-dev] [TripleO] Improving Swift deployments with TripleO

On 04.08.16 10:27, Giulio Fidente wrote: > On 08/02/2016 09:36 PM, Christian Schwede wrote: >> Hello everyone, > > thanks Christian, > >> I'd like to improve the Swift deployments done by TripleO. There are a >> few problems today when deployed with the current defaults: >> >> 1. Adding new

Re: [openstack-dev] [Manila] Nominate Tom Barron for core reviewer team

Yeah, Tom consists of experience. +1 On Thu, Aug 4, 2016 at 12:35 PM, Ramana Raja wrote: > +1. Tom's reviews and guidance are helpful > and spot-on. > > -Ramana > > On Thursday, August 4, 2016 7:52 AM, Zhongjun (A) > wrote: > > Subject: Re:

[openstack-dev] [kolla][osic] Accessing the osic VPN

For those starting work on the OSIC cluster, I was having some trouble installing the F5 VPN browser plugin, not to mention it's no good if wanting to access the cluster remotely. In the spirit of Kolla here's a Dockerfile I knocked up to run the VPN client in a container:

Re: [openstack-dev] [Manila] Nominate Tom Barron for core reviewer team

+1. Tom's reviews and guidance are helpful and spot-on. -Ramana On Thursday, August 4, 2016 7:52 AM, Zhongjun (A) wrote: > Subject: Re: [openstack-dev] [Manila] Nominate Tom Barron for core reviewer > team > > > > +1 Tom will be a great addition to the core team. >

Re: [openstack-dev] [juju charms] How to configure glance charm for specific cnider backend?

Hi Andrey On Wed, 3 Aug 2016 at 14:35 Andrey Pavlov wrote: > Instead of adding one more relation to glance, I can relate my charm to > new relation 'cinder-volume-service' > almost > > So there is no more changes in the glance charm. > And additional in my charm will be

Re: [openstack-dev] [juju charms] How to configure glance charm for specific cnider backend?

On Tue, 2 Aug 2016 at 16:54 Andrey Pavlov wrote: > James, thank you for your answer. > No problem. I'll file bug to glance - but in current releases glance-charm have to > do it himself, right? > We should be able to add the required bits using an Ubuntu SRU - lets raise

Re: [openstack-dev] [tc] persistently single-vendor projects

On 1 August 2016 at 18:14, Adrian Otto wrote: > I am struggling to understand why we would want to remove projects from > our big tent at all, as long as they are being actively developed under the > principles of "four opens". It seems to me that working to disqualify

Re: [openstack-dev] [Nova] Nova compute reports the disk usage

Hi Chris, Yes we used qcow image. However I still have something not clear. What I know is that: - disk_available_least = free_disk - disk_over_commit - disk_over_commit = int(virt_size) - physical_disk_size Before launching: - free_disk = 1025 - disk_available_least = 1016 If we use the

Re: [openstack-dev] [TripleO] Improving Swift deployments with TripleO

On 08/02/2016 09:36 PM, Christian Schwede wrote: Hello everyone, thanks Christian, I'd like to improve the Swift deployments done by TripleO. There are a few problems today when deployed with the current defaults: 1. Adding new nodes (or replacing existing nodes) is not possible, because

[openstack-dev] [Magnum] Adding opensuse as new driver to Magnum

Hi, I would like to put for discussion adding new driver to Magnum. We would like to propose opensuse with kubernetes as driver. I did some initial work in bug https://launchpad.net/bugs/1600197 and changes https://review.openstack.org/339480 https://review.openstack.org/349994 I've got

Re: [openstack-dev] [tc] persistently single-vendor projects

On 08/01/2016 09:39 AM, Thierry Carrez wrote: > But if a project is persistently single-vendor after some time and > nobody seems interested to join it, the technical value of that project > being "in" OpenStack rather than a separate project in the OpenStack > ecosystem of projects is limited.

Re: [openstack-dev] [tc] persistently single-vendor projects

Devdatta Kulkarni wrote: > As current PTL of one of the projects that has the team:single-vendor tag, > I have following thoughts/questions on this issue. In preamble I'd like to reiterate that the proposal is not on the table at this stage -- this is just a discussion to see whether it would be

Re: [openstack-dev] [tc] Stepping Down.

Morgan Fainberg wrote: > Based upon my personal time demands among a number of other reasons I > will be stepping down from the Technical Committee. This is planned to > take effect with the next TC election so that my seat will be up to be > filled at that time. > > For those who elected me in,

Re: [openstack-dev] [Watcher] Promote Alexchadin to the core team.

Alexander Chadin did prove he knew the various moving parts of Watcher by participating the numerous design discussions and blueprints during the last months which makes him a precious asset for our team. So that's a definite +1 for me as well. On 04/08/2016 09:11, Jean-Émile DARTOIS wrote: >

[openstack-dev] [Watcher] Promote Alexchadin to the core team.

Hi all, alexchadin has consistently contributed to Watcher for a while. He is also very active on IRC. Based on his contribution (e.g: continuously-optimization blueprint) and expertise which adds concrete value to Watcher, I'd like to promote alexchadin to the core team. According to the

Re: [openstack-dev] Project mascots update

On Thu, Aug 4, 2016 at 4:26 PM, Antoni Segura Puimedon < toni+openstac...@midokura.com> wrote: > > It would be really awesome if, in true OSt and OSS spirit this work > happened in an OpenStack repository with an open, text based format like > SVG. This way people could contribute and review. > >

Re: [openstack-dev] Project mascots update

On Wed, Aug 3, 2016 at 11:00 PM, Heidi Joy Tretheway wrote: > *Steve Hardy wrote:* > *"I have one question regarding the review process for the logos when > they are drafted? In the cases where projects have their existing community > generated logos I can imagine there

  1   2   >