Re: [openstack-dev] [all] service catalog: TNG

On Fri, Oct 09, 2015 at 01:01:20PM -0400, Shamail wrote: :> On Oct 9, 2015, at 12:28 PM, Monty Taylor wrote: :> :>> On 10/09/2015 11:21 AM, Shamail wrote: :>> :>> :>>> On Oct 9, 2015, at 10:39 AM, Sean Dague wrote: :>>> :>>> It looks like some great

Re: [openstack-dev] [all] service catalog: TNG

On Fri, Oct 9, 2015 at 1:28 PM, Jonathan D. Proulx wrote: > On Fri, Oct 09, 2015 at 01:01:20PM -0400, Shamail wrote: > :> On Oct 9, 2015, at 12:28 PM, Monty Taylor wrote: > :> > :>> On 10/09/2015 11:21 AM, Shamail wrote: > :>> > :>> > :>>> On Oct 9,

Re: [openstack-dev] [Murano] py26 support in python-muranoclient

On Fri, Oct 9, 2015, at 10:32 AM, Vahid S Hashemian wrote: > Serg, Jeremy, > > Thank you for your response, so the issue I ran into with my patch is the > gate job failing on python26. > You can see it here: https://review.openstack.org/#/c/232271/ > > Serg suggested that we add 2.6 support

[openstack-dev] [Neutron] Returning of HEAD files?

Some time ago we merged change [1] that removes HEADS file. Validation of migration revisions using HEADS file was replaced with pep8. This allows us to avoid merge conflicts that appeared every time a new migration was merged. The problem was pointed by Kevin Benton as the original idea of HEAD

Re: [openstack-dev] [Murano] py26 support in python-muranoclient

On 2015-10-09 12:22:12 +0300 (+0300), Serg Melikyan wrote: > unfortunately we don't plan to remove support for py26 from the > python-muranoclient, most of the python-client support py26 > in order to work out of the box on different OS including CentOS 6.5 > and so on. [...] Bear in mind that we

Re: [openstack-dev] Requests + urllib3 + distro packages

Cory Benfield writes: > > The problem that occurs is the result of a few interacting things: > > - requests has very very specific versions of urllib3 it works with. > > So specific they aren't always released yet. > > This should no longer be true. Our downstream redistributors

[openstack-dev] [Heat] mox to mock migration

I forget where we left things at the last meeting with regard to whether or not there should be a blueprint on this. I was going to work on some during some downtime but I wanted to make sure I wasn't overlapping with what others may be converting (it's more time consuming than I anticipated).

Re: [openstack-dev] [Sender Auth Failure] [neutron] New cycle started. What are you up to, folks?

I¹d like to help out in some fashion with FwaaS and the IPV6 needs mentioned. Current working on the DSCP Spec and patches to implement ontop of QOS. I liked Seans comments about devstack, we have been doing tons of testing for DSCP there without really understanding how things are going to be

Re: [openstack-dev] [all] Recording little everyday OpenStack successes

On 2015-10-09 13:51:39 +0200 (+0200), Ihar Hrachyshka wrote: [...] > Another IRC service that I find useful to encourage collaboration > in teams is a karma bot. Something that would calculate > ++ messages in tracked channels. Having such a > lightweight and visible way to tell ‘thank you’ to a

Re: [openstack-dev] [all] Recording little everyday OpenStack successes

On 10/09/2015 05:42 AM, Thierry Carrez wrote: > Hello everyone, > > OpenStack has become quite big, and it's easier than ever to feel lost, > to feel like nothing is really happening. It's more difficult than ever > to feel part of a single community, and to celebrate little successes > and

Re: [openstack-dev] [all] Recording little everyday OpenStack successes

> On 09 Oct 2015, at 15:46, Jeremy Stanley wrote: > > On 2015-10-09 13:51:39 +0200 (+0200), Ihar Hrachyshka wrote: > [...] >> Another IRC service that I find useful to encourage collaboration >> in teams is a karma bot. Something that would calculate >> ++ messages in tracked

Re: [openstack-dev] [Neutron] Returning of HEAD files?

> On 09 Oct 2015, at 15:28, Anna Kamyshnikova > wrote: > > Some time ago we merged change [1] that removes HEADS file. Validation of > migration revisions using HEADS file was replaced with pep8. This allows us > to avoid merge conflicts that appeared every time a

Re: [openstack-dev] [Heat] mox to mock migration

Jay, I think, that only one person who partially do the same job is Qiming. Please ask him about it. Also I think, that will be good to create BP for it, which you may mention in commit messages. In this Bp you may specify list of directories for parallel work. There is nothing else from my side.

Re: [openstack-dev] Requests + urllib3 + distro packages

Robert Collins writes: > - Linux vendors often unbundle urllib3 from requests and then apply > what patches were needed to their urllib3; while not updating their > requests package dependencies to reflect this. I opened a bug on Fedora for them to update their requests package

Re: [openstack-dev] Scheduler proposal

Excerpts from Chris Friesen's message of 2015-10-09 10:54:36 -0700: > On 10/09/2015 11:09 AM, Zane Bitter wrote: > > > The optimal way to do this would be a weighted random selection, where the > > probability of any given host being selected is proportional to its > > weighting. > > (Obviously

Re: [openstack-dev] [Heat] mox to mock migration

This sounds good, I was hoping it'd be acceptable to use etherpad. I filed a blueprint [1] but I'm anticipating using the etherpad much more regularly to track which files are being worked or completed. [1] https://blueprints.launchpad.net/heat/+spec/mox-to-mock-conversion [2]

Re: [openstack-dev] [nova] nova-manage db archive_deleted_rows broken

On 10/9/2015 12:03 PM, Jay Pipes wrote: On 10/07/2015 11:04 AM, Matt Riedemann wrote: I'm wondering why we don't reverse sort the tables using the sqlalchemy metadata object before processing the tables for delete? That's the same thing I did in the 267 migration since we needed to process

Re: [openstack-dev] Scheduler proposal

Still the point from Chris is valid. I guess the main reason openstack is going with multiple concurrent schedulers is to scale out by distributing the load between multiple instances of schedulers because 1 instance is too slow. This discussion is about coordinating the many instances of

Re: [openstack-dev] We should move strutils.mask_password back into oslo-incubator

Excerpts from Matt Riedemann's message of 2015-10-09 09:51:28 -0500: > > On 10/9/2015 1:49 AM, Paul Carlton wrote: > > > > On 08/10/15 16:49, Doug Hellmann wrote: > >> Excerpts from Matt Riedemann's message of 2015-10-07 14:38:07 -0500: > >>> Here's why: > >>> > >>>

Re: [openstack-dev] [Neutron] L2 gateway project

Hey Kyle, We are down to couple of patches that are awaiting approval/merge. As soon as it is done, I will let you know. Thanks -Sukhdev On Fri, Oct 9, 2015 at 9:39 AM, Kyle Mestery wrote: > On Fri, Oct 9, 2015 at 10:13 AM, Gary Kotton wrote: > >>

Re: [openstack-dev] Scheduler proposal

On 10/09/2015 11:09 AM, Zane Bitter wrote: The optimal way to do this would be a weighted random selection, where the probability of any given host being selected is proportional to its weighting. (Obviously this is limited by the accuracy of the weighting function in expressing your actual

Re: [openstack-dev] [kolla] Backport policy for Liberty

As an Op, that sounds reasonable so long as they aren't defaulted on. In theory it shouldn't be much different then a distro adding additional packages. The new packages don't affect existing systems unless the op requests them to be installed. With my App Catalog hat on, I'm curious how

Re: [openstack-dev] [all] service catalog: TNG

On 10/09/2015 01:39 PM, David Stanek wrote: On Fri, Oct 9, 2015 at 1:28 PM, Jonathan D. Proulx > wrote: On Fri, Oct 09, 2015 at 01:01:20PM -0400, Shamail wrote: :> On Oct 9, 2015, at 12:28 PM, Monty Taylor

Re: [openstack-dev] Requests + urllib3 + distro packages

On 10 October 2015 at 03:57, Cory Benfield wrote: > >> On 9 Oct 2015, at 15:18, Jeremy Stanley wrote: >> >> On 2015-10-09 14:58:36 +0100 (+0100), Cory Benfield wrote: >> [...] >>> IMO, what OpenStack needs is a decision about where it’s getting >>> its

Re: [openstack-dev] [Murano] py26 support in python-muranoclient

> From: Clark Boylan > To: openstack-dev@lists.openstack.org > Date: 10/09/2015 02:00 PM > Subject: Re: [openstack-dev] [Murano] py26 support in python-muranoclient > > > > On Fri, Oct 9, 2015, at 10:32 AM, Vahid S Hashemian wrote: > > Serg, Jeremy, > > > > Thank you

Re: [openstack-dev] [Murano] py26 support in python-muranoclient

There is a need to distinguish between server side py26 support which is generally under the control of the service provider and py26 support on the client side. For a service provider to push all of their hypervisors and service machines to RHEL 7 is under their control but requiring all of their

Re: [openstack-dev] [all] service catalog: TNG

On Fri, Oct 09, 2015 at 02:17:26PM -0400, Monty Taylor wrote: :On 10/09/2015 01:39 PM, David Stanek wrote: :> :>On Fri, Oct 9, 2015 at 1:28 PM, Jonathan D. Proulx > wrote: :>As an operator I'd be happy to use SRV records to define endpoints, :>

Re: [openstack-dev] Scheduler proposal

Excerpts from Zane Bitter's message of 2015-10-09 17:09:46 +: > On 08/10/15 21:32, Ian Wells wrote: > > > > > 2. if many hosts suit the 5 VMs then this is *very* unlucky,because > > we should be choosing a host at random from the set of > > suitable hosts and that's a huge coincidence

Re: [openstack-dev] [nova] nova-manage db archive_deleted_rows broken

On 10/09/2015 02:16 PM, Matt Riedemann wrote: On 10/9/2015 12:03 PM, Jay Pipes wrote: I had a proposal [1] to completely rework the whole shadow table mess and db archiving functionality. I continue to believe that is the appropriate solution for this, and that we should rip out the existing

Re: [openstack-dev] Blueprint to change (expand) traditional Ethernet interface naming schema in Fuel

> > >I would like to pay your attention to the changing interface naming > >schema, which is proposed to be implemented in FuelA [1].A In brief, > >Ethernet network interfaces may not be named as ethX, and there is a > >reported bug about itA [2] > >There are a lot of reasons

Re: [openstack-dev] Scheduler proposal

On 10/09/2015 12:55 PM, Gregory Haynes wrote: There is a more generalized version of this algorithm for concurrent scheduling I've seen a few times - Pick N options at random, apply heuristic over that N to pick the best, attempt to schedule at your choice, retry on failure. As long as you have

Re: [openstack-dev] Scheduler proposal

On 10/09/2015 12:25 PM, Alec Hothan (ahothan) wrote: Still the point from Chris is valid. I guess the main reason openstack is going with multiple concurrent schedulers is to scale out by distributing the load between multiple instances of schedulers because 1 instance is too slow. This

[openstack-dev] Different OpenStack components

Hi Folks,I have been working with OpenStack from a while now, I know that other than the main componets (nova, neutron, glance, cinder, horizon, tempest, keystone etc) there are many more components in OpenStack (like Sahara, Trove).So, where can I see the list of all existing OpenStack components

Re: [openstack-dev] Scheduler proposal

And also we should probably deprecate/not recommend: http://docs.openstack.org/developer/nova/api/nova.scheduler.filters.json_filter.html#nova.scheduler.filters.json_filter.JsonFilter That filter IMHO basically disallows optimizations like forming SQL statements for each filter (and then

[openstack-dev] [all] service catalog: TNG

It looks like some great conversation got going on the service catalog standardization spec / discussion at the last cross project meeting. Sorry I wasn't there to participate. A lot of that ended up in here (which was an ether pad stevemar and I started working on the other day) -

Re: [openstack-dev] [all] Recording little everyday OpenStack successes

On Fri, Oct 9, 2015 at 3:42 AM, Thierry Carrez wrote: > Hello everyone, > > OpenStack has become quite big, and it's easier than ever to feel lost, > to feel like nothing is really happening. It's more difficult than ever > to feel part of a single community, and to

Re: [openstack-dev] [all] service catalog: TNG

On Fri, Oct 9, 2015 at 9:39 AM, Sean Dague wrote: > Lastly, I think it's pretty clear we probably need a dedicated workgroup > meeting to keep this ball rolling, come to a reasonable plan that > doesn't break any existing deployed code, but lets us get to a better > world in a

Re: [openstack-dev] Requests + urllib3 + distro packages

For those who are interested in more of the historical aspect around this, https://github.com/kennethreitz/requests/issues/1811 https://github.com/kennethreitz/requests/pull/1812 My own thoughts are varied here, I get the angle of vendoring, but I don't get the resistance to unvendoring it

[openstack-dev] [Horizon] Suggestions for handling new panels and refactors in the future

I have two suggestions for handling both new panels and refactoring existing panels that I think could benefit us in the future: 1) When we are creating a panel that's a major refactor of an existing it should be a new separate panel, not a direct code replacement of the existing panel 2) New

Re: [openstack-dev] We should move strutils.mask_password back into oslo-incubator

On 10/9/2015 1:49 AM, Paul Carlton wrote: On 08/10/15 16:49, Doug Hellmann wrote: Excerpts from Matt Riedemann's message of 2015-10-07 14:38:07 -0500: Here's why: https://review.openstack.org/#/c/220622/ That's marked as fixing an OSSA which means we'll have to backport the fix in nova

Re: [openstack-dev] Requests + urllib3 + distro packages

> On 9 Oct 2015, at 15:18, Jeremy Stanley wrote: > > On 2015-10-09 14:58:36 +0100 (+0100), Cory Benfield wrote: > [...] >> IMO, what OpenStack needs is a decision about where it’s getting >> its packages from, and then to refuse to mix the two. > > I have yet to find a

Re: [openstack-dev] [all] service catalog: TNG

I'm in too. David On Fri, Oct 9, 2015 at 8:51 AM, Dean Troyer wrote: > On Fri, Oct 9, 2015 at 9:39 AM, Sean Dague wrote: >> >> Lastly, I think it's pretty clear we probably need a dedicated workgroup >> meeting to keep this ball rolling, come to a reasonable

Re: [openstack-dev] [all] Recording little everyday OpenStack successes

> On Oct 9, 2015, at 10:49 AM, John Griffith wrote: > > ​Great idea Thierry, great to promote some positive things! Thanks for > putting this together.​ +1 Great indeed... thanks Thierry. Regards, Shamail

[openstack-dev] [Neutron] L2 gateway project

Hi, Who will be creating the stable/liberty branch? Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [all] service catalog: TNG

On 10/09/2015 11:07 AM, David Lyle wrote: I'm in too. Yes please. On Fri, Oct 9, 2015 at 8:51 AM, Dean Troyer wrote: On Fri, Oct 9, 2015 at 9:39 AM, Sean Dague wrote: Lastly, I think it's pretty clear we probably need a dedicated workgroup meeting to

Re: [openstack-dev] [infra] Try to introduce RFC mechanism to CI.

>-Original Message- >From: Jeremy Stanley [mailto:fu...@yuggoth.org] >Sent: Friday, October 9, 2015 1:17 PM >To: OpenStack Development Mailing List (not for usage questions) > >Subject: Re: [openstack-dev] [infra] Try to introduce RFC mechanism to

Re: [openstack-dev] [all] service catalog: TNG

> On Oct 9, 2015, at 10:39 AM, Sean Dague wrote: > > It looks like some great conversation got going on the service catalog > standardization spec / discussion at the last cross project meeting. > Sorry I wasn't there to participate. > Apologize if this is a question that has

Re: [openstack-dev] [all] service catalog: TNG

On 10/09/2015 10:39 AM, Sean Dague wrote: It looks like some great conversation got going on the service catalog standardization spec / discussion at the last cross project meeting. Sorry I wasn't there to participate. Just so folks know, the collection of existing service catalogs has been

<    1   2