Re: [openstack-dev] [nova][mistral] Automatic evacuation as a long running task

- Original Message - > From: "Roman Dobosz" > To: "OpenStack Development Mailing List" > > Hi all, > > The case of automatic evacuation (or resurrection currently), is a topic > which surfaces once in a while, but it isn't yet

[openstack-dev] [nova][neutron] ports management

… The problem. There are use cases, when it us needed to attach vnic to some specific network interface instead of br-int. For example, working with trunk ports, it is better to attach vnic to a specific trunk bridge, and the bridge add to br-int. But it doesn't fit in the

Re: [openstack-dev] [Fuel][PTL] PTL Candidates Q Session

Which is actually contradictory and ambiguous and shows that PTL has less power than CLs while CLs at the same time have less power than PTL. I think this is the time when universe should collapse as we found that time-space is contradicting laws of propositional calculus. On Tue, Oct 6, 2015 at

[openstack-dev] [Neutron][Kuryr] - IRC Meetings

Hello Everyone, Our current IRC meeting time is 15:00 UTC every Monday. I have received several requests from US people saying its hard for them to attend at this early time. We want to allow anyone that shows interest in the project to join, so we discussed this in yesterday's IRC meeting and

Re: [openstack-dev] [Fuel] py.test vs testrepository

I've already wrote in the review that caused this thread that I do not want to blindly follow rules for using one or another. We should always consider technical requirements. And I do not see a reason to leave py.test (and nobody show me such reason) and replace it with something else.

Re: [openstack-dev] [fuel] What to do when a controller runs out of space

Eugene With all due respect to you and other OpenStack developers, I as a system administrator do not believe when someone says that something is working that way. Actually, what I would prefer to do is to stress-test these services on their 'statelessness'. Currently we have l3-agent not so

Re: [openstack-dev] [Fuel][PTL] PTL Candidates Q Session

Hi That’s right, but we made slight change here: "Define architecture direction & review majority of design specs. Rely on Component Leads and Core Reviewers" So we assume that detailed architectural work will be relayed to Component Leads > On 02 Oct 2015, at 10:12, Evgeniy L

[openstack-dev] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron

[Sorry, but I do not know if the thundering silence is because these questions are too hard, too easy, grossly off-topic, or simply because nobody cares.] I have been looking at http://docs.openstack.org/developer/devstack/guides/neutron.htmland wonder about a few things. In the section

Re: [openstack-dev] [nova] live migration in Mitaka

On Tue, Oct 06, 2015 at 02:54:21PM +0100, Paul Carlton wrote: > https://review.openstack.org/#/c/85048/ was raised to address the > migration of instances that are not running but people did not warm to > the idea of bringing a stopped/suspended instance to a paused state to > migrate it. Is

[openstack-dev] [Glance] Process to clean up the review queue from non-active patches

Greetings, Not so long ago, Erno started a thread[0] in this list to discuss the abandon policies for patches that haven't been updated in Glance. I'd like to go forward and start following that policy with some changes that you can find below: 1) Lets do this on patches that haven't had any

Re: [openstack-dev] [nova][mistral] Automatic evacuation as a long running task

Hi, Roman, Evacuated has been on my radar for a while and this post has prodded me to take a look at the code. I think it's worth starting by explaining the problems in the current solution. Nova client is currently responsible for doing this evacuate. It does: 1. List all instances on the

[openstack-dev] [Keystone] Mitaka design summit schedule

Keystoners and Keystone enthusiasts, At our last Keystone meeting we decided on the topics for the design summit, the schedule is now available online: - http://mitakadesignsummit.sched.org/type/Keystone#.VhSpPBNVhBc Please note the start times and locations. I've gone ahead and created

[openstack-dev] [Neutron] [openstack-infra] stable changes to python-neutronclient unable to merge

Hi folks, We are unable to merge stable changes to python-neutronclient (as shown in [1,2]) because of the missing master fixes [3,4]. We should be able to untangle Liberty with [5], but to unblock Kilo, I may need to squash [6] with a cherry pick of [3] and wait [5] to merge. Please bear with

[openstack-dev] [TripleO] Blueprints for upgrades

I've started an etherpad collecting a list of potential blueprints for achieving major version upgrades of in TripleO, with an initial target of upgrading Kilo to Liberty using a stable/liberty undercloud. There's still a bunch of unanswered questions (especially around compute nodes), and

[openstack-dev] [horizon][keystone]

Dear All One of my students, Anton Brida, has developed an Attribute Mapping GUI for Horizon as part of his MSc project. Attribute mappings are an essential, though complex, part of federated Keystone. Currently they can only be created as JSON objects in the config file. The Horizon code allows

Re: [openstack-dev] [searchlight] Liberty release finalization

Woohoo! It's a feat! On 10/6/15 12:19 PM, Tripp, Travis S wrote: > > On 10/6/15, 2:28 AM, "Thierry Carrez" wrote: > >> The "intermediary" model requires the project following it to be mature >> enough (and the project team following it to be disciplined enough) to >>

Re: [openstack-dev] [nova] live migration in Mitaka

On 10/06/2015 11:27 AM, Paul Carlton wrote: On 06/10/15 17:30, Chris Friesen wrote: On 10/06/2015 08:11 AM, Daniel P. Berrange wrote: On Tue, Oct 06, 2015 at 02:54:21PM +0100, Paul Carlton wrote: https://review.openstack.org/#/c/85048/ was raised to address the migration of instances that

Re: [openstack-dev] [devstack] A few questions on configuring DevStack for Neutron

On Sun, Oct 4, 2015 at 9:16 PM, Mike Spreitzer wrote: > [Apologies for re-posting, but I botched the subject line the first time and > know that people use filters.] > > I have been looking at > http://docs.openstack.org/developer/devstack/guides/neutron.htmland wonder >

[openstack-dev] [release][ironic] Announcing ironic-python-agent 1.0.0

Hi all, We're ecstatic to announce the release of ironic-python-agent 1.0.0. This is the first ever release of this project, and is the basis for a stable/liberty branch. We will continue to do intermediary releases and stable branches for IPA, following Ironic's release model. IPA is the heart

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

Excerpts from Flavio Percoco's message of 2015-10-06 23:36:53 +0900: > Greetings, > > Not so long ago, Erno started a thread[0] in this list to discuss the > abandon policies for patches that haven't been updated in Glance. > > I'd like to go forward and start following that policy with some >

[openstack-dev] [ceilometer] external projects extending ceilometer

hi, telemetry is a big space and its requirements differ from company to company. there are existing projects that extend/leverage the functionality of Ceilometer to either customise, fill in gaps or resolve complementary problems. as the projects are not all managed by the Ceilometer team,

[openstack-dev] [Neutron][Kuryr] Kuryr Open Tasks

Hello All, I have opened a Trello board to track all Kuryr assigned tasks and their assignee. In addition to all the non assigned tasks we have defined. You can visit and look at the board here [1]. Please email back if i missed you or any task that you are working on, or a task that you think

Re: [openstack-dev] [Ironic] backwards compat issue with PXEDeply and AgentDeploy drivers

Well it's nice to fix, but I really don't know if we should be fixing it. As discussed in one of the Ironic meetings before, we might need to define what is our driver API or SDK or DDK or whatever we choose to call it . Please see inline for my thoughts. On Tue, Oct 6, 2015 at 5:54 AM, Devananda

Re: [openstack-dev] [heat] perfomance benchmark metrics of heat-api

On 10/06/2015 05:20 AM, ESWAR RAO wrote: Has anyone done any performance tests on heat-api servers on any standard setup so as to know how many stack requests it can handle before it can stumble so that we can deploy scaling of heat-servers ?? It depends on your environment and you should run

Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor

Using `message flavor` works for me, and having two words is just fine. I'm in the process of collecting all of the existing "object" works are putting them online, there's a lot of them. Hopefully this will reduce the collisions in the future. Thanks, Steve Martinelli OpenStack Keystone Core

Re: [openstack-dev] [Fuel] Core Reviewers groups restructure

Update here: patch was marked as WIP for now due to comment from Anita Kuno: > On Oct. 17 all active stackforge projects that have themselves listed on the stackforge retirement wikipage will be moved. This includes reviewing all acl files for that move. > Can we mark this patch wip until after

[openstack-dev] [Zaqar][cli][openstack-client] conflict in nova flavor and zaqar flavor

Greetings, I am implementing cli commands for Zaqar flavors, the command should be like: "openstack flavor " But there is already same command present for Nova flavors. After discussing with Zaqar devs we thought to change all zaqar commands such that they include `message` word after

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

On 10/06/2015 02:36 PM, Sofer Athlan-Guyot wrote: Rich Megginson writes: On 09/30/2015 11:43 AM, Sofer Athlan-Guyot wrote: Gilles Dubreuil writes: On 30/09/15 03:43, Rich Megginson wrote: On 09/28/2015 10:18 PM, Gilles Dubreuil wrote: On 15/09/15

Re: [openstack-dev] [Fuel] py.test vs testrepository

On 10/06/2015 10:52 AM, Sebastian Kalinowski wrote: I've already wrote in the review that caused this thread that I do not want to blindly follow rules for using one or another. We should always consider technical requirements. And I do not see a reason to leave py.test (and nobody show me such

Re: [openstack-dev] [Fuel] py.test vs testrepository

Sebastian, I am really hoping that the items Monty listed below are enough. Also, if you are interested, folks do use other things for running their tests especially to find problems when testr hides some errors. Example, please see:

[openstack-dev] conflicting names in python-openstackclient: could we have some exception handling please?

Hi, tl;dr: let's add a exception handling so that python-*client having conflicting command names isn't a problem anymore, and "openstack help" always work as much as it can. Longer version: This is just a suggestion for contributors to python-openstackclient. I saw a few packages that had

Re: [openstack-dev] [Neutron] Defect management

Hi, I was trying to help a bit, for now, but I don't have access in launchpad to update importance, etc. I will add comments on the bugs themselves, and set a ? in the spreadsheet. Cheers, and thanks Armando for leading this, it's a good change. I will be happy to take the bug deputy

Re: [openstack-dev] [searchlight] Liberty release finalization

Tripp, Travis S wrote: > Thanks for the info! We had discussed the release models a couple times in > our IRC meeting and we thought that the release cycle with intermediary > releases sounded good to us. One reason is that we actually wanted to be > able to release more frequently if needed

Re: [openstack-dev] [heat] perfomance benchmark metrics of heat-api

On 6 October 2015 at 10:18, Christian Berendt wrote: > On 10/06/2015 05:20 AM, ESWAR RAO wrote: >> >> Has anyone done any performance tests on heat-api servers on any >> standard setup so as to know how many stack requests it can handle >> before it can stumble so that we

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

On 10/6/15 1:53 PM, Doug Hellmann wrote: > Excerpts from Flavio Percoco's message of 2015-10-06 23:36:53 +0900: >> Greetings, >> >> Not so long ago, Erno started a thread[0] in this list to discuss the >> abandon policies for patches that haven't been updated in Glance. >> >> I'd like to go

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

Rich Megginson writes: > On 09/30/2015 11:43 AM, Sofer Athlan-Guyot wrote: >> Gilles Dubreuil writes: >> >>> On 30/09/15 03:43, Rich Megginson wrote: On 09/28/2015 10:18 PM, Gilles Dubreuil wrote: > On 15/09/15 19:55, Sofer Athlan-Guyot wrote:

Re: [openstack-dev] [Fuel][PTL] PTL Candidates Q Session

Looks like we need to make it totally clear in our policy... > So we assume that detailed architectural work will be relayed to Component Leads I don't agree with this statement, as it implies that _all_ architectural work will be relayed to component leads. PTL is fully responsible for

Re: [openstack-dev] [Fuel] py.test vs testrepository

On 10/06/2015 06:01 PM, Thomas Goirand wrote: On 10/06/2015 01:14 PM, Yuriy Taraday wrote: On Mon, Oct 5, 2015 at 5:40 PM Roman Prykhodchenko > wrote: Atm I have the following pros. and cons. regarding testrepository: pros.: 1. It’s

[openstack-dev] [Congress] Couple new bugs for liberty

Hi all, Another round of manual testing revealed a couple more bugs. The ones at the bottom without the Fix-committed: https://bugs.launchpad.net/congress/+bugs/?field.tag=liberty-rc2 I have a patch for 1503392 in review. It'd be great if someone could pick up

Re: [openstack-dev] [nova][mistral] Automatic evacuation as a long running task

Roman, Here are some things that may help you: In Mistral we’ve been aware of this post-message-processing ACK problem since we began to use oslo.messaging and we’ve been communicating with oslo team in order to fix that. Patch [1] is supposed to help us finally solve it. I would encourage you

Re: [openstack-dev] [Fuel] py.test vs testrepository

On 10/06/2015 01:14 PM, Yuriy Taraday wrote: > On Mon, Oct 5, 2015 at 5:40 PM Roman Prykhodchenko > wrote: > > Atm I have the following pros. and cons. regarding testrepository: > > pros.: > > 1. It’s ”standard" in OpenStack so using it

Re: [openstack-dev] [openstack-ansible] Security spec status update

Great work on this Major! I look forward to seeing the role built out and adding it into the stack. If anyone out there is interested, the greater OpenStack-Ansible community would love feedback on the initial role import [0]. [0] - https://review.openstack.org/#/c/231165 -- Kevin Carter

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

On Mon, Oct 5, 2015 at 5:48 AM, Emilien Macchi <emil...@redhat.com> wrote: > Hello! > > Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC > in #openstack-meeting-4: > > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151006

Re: [openstack-dev] [Manila] CephFS native driver

On Thu, Oct 1, 2015 at 3:32 PM, John Spray wrote: > On Thu, Oct 1, 2015 at 8:36 AM, Deepak Shetty wrote: > > > > > > On Thu, Sep 24, 2015 at 7:19 PM, John Spray wrote: > >> > >> Hi all, > >> > >> I've recently started work on a CephFS

Re: [openstack-dev] [Neutron] Defect management

> > On 05 Oct 2015, at 17:27, Armando M. wrote: > > > > On 5 October 2015 at 03:14, Ihar Hrachyshka wrote: > > On 02 Oct 2015, at 02:37, Armando M. wrote: > > > > Hi neutrinos, > > > > Whilst we go down the path of revising the way

Re: [openstack-dev] [fuel] What to do when a controller runs out of space

On Tue, Oct 6, 2015 at 4:22 PM, Vladimir Kuklin wrote: > Eugene > > For example, each time that you need to have one instance (e.g. master > instance) of something non-stateless running in the cluster. > Right. This is theoretical. Practically, there are no such services

Re: [openstack-dev] [fuel] What to do when a controller runs out of space

> 2) I think you misunderstand what is the difference between > upstart/systemd and Pacemaker in this case. There are many cases when you > need to have syncrhonized view of the cluster. Otherwise you will hit > split-brain situations and have your cluster misfunctioning. Until > OpenStack

Re: [openstack-dev] [Neutron] Defect management

> On 06 Oct 2015, at 10:36, Miguel Angel Ajo wrote: > > Hi, I was trying to help a bit, for now, but I don't have access in launchpad > to update importance, > etc. > > I will add comments on the bugs themselves, and set a ? in the > spreadsheet. I believe you need to

Re: [openstack-dev] [fuel] What to do when a controller runs out of space

Eugene I would prefer to tackle your points in the following way: 1) Regarding rabbitmq - you and me both know that this a major flaw in how OpenStack operates - it uses message broker in very unoptimal way sending lots of unneeded data through when it actually may not send it. So far we

Re: [openstack-dev] [fuel] What to do when a controller runs out of space

Eugene For example, each time that you need to have one instance (e.g. master instance) of something non-stateless running in the cluster. You are right that currently lots of things are fixed already - heat engine is fine, for example. But I still see this issue with l3 agents and I will not

Re: [openstack-dev] [Neutron] Defect management

On 6 October 2015 at 06:10, Ihar Hrachyshka wrote: > > On 06 Oct 2015, at 10:36, Miguel Angel Ajo wrote: > > > > Hi, I was trying to help a bit, for now, but I don't have access in > launchpad to update importance, > > etc. > > > > I will add comments

[openstack-dev] [Designate][Ceilometer] Liberty RC2 available

Hello everyone, Due to release-critical issues spotted in Designate and Ceilometer during RC1 testing (as well as last-minute translations imports), new release candidates were created for Liberty. The list of RC2 fixes, as well as RC2 tarballs are available at:

Re: [openstack-dev] [nova] live migration in Mitaka

https://review.openstack.org/#/c/85048/ was raised to address the migration of instances that are not running but people did not warm to the idea of bringing a stopped/suspended instance to a paused state to migrate it. Is there any work in progress to get libvirt enhanced to perform the

Re: [openstack-dev] [Fuel] py.test vs testrepository

On Mon, Oct 5, 2015 at 5:40 PM Roman Prykhodchenko wrote: > Atm I have the following pros. and cons. regarding testrepository: > > pros.: > > 1. It’s ”standard" in OpenStack so using it gives Fuel more karma and > moves it more under big tent > I don't think that big tent model

Re: [openstack-dev] [magnum] New Core Reviewers

Thanks everyone! I really appreciate this. Happy to join Magnum-Core :) We have a great team, very diverse and very dedicated. It's pleasure to work with all of you. Thanks, Vilobh On Mon, Oct 5, 2015 at 5:26 PM, Adrian Otto wrote: > Team, > > In accordance with

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

On Tue, Oct 06 2015, Flavio Percoco wrote: I send patches to Glance from time to time, and they usually got 0 review for *weeks* (sometimes months, because, well there are no reviewers active in Glance, so: > 1) Lets do this on patches that haven't had any activity in the last 2 > months. This

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

Hi, Le 06/10/2015 16:36, Flavio Percoco a écrit : Not so long ago, Erno started a thread[0] in this list to discuss the abandon policies for patches that haven't been updated in Glance. (...) 1) Lets do this on patches that haven't had any activity in the last 2 months. This adds one more month

Re: [openstack-dev] [nova] live migration in Mitaka

On 06/10/15 17:30, Chris Friesen wrote: On 10/06/2015 08:11 AM, Daniel P. Berrange wrote: On Tue, Oct 06, 2015 at 02:54:21PM +0100, Paul Carlton wrote: https://review.openstack.org/#/c/85048/ was raised to address the migration of instances that are not running but people did not warm to the

[openstack-dev] [Neutron] Prepare for expiration bugs without activity

Hi everyone, As decided during last neutron meeting[1], we try to let Launchpad expire outdated bugs. The status of every bug without activity in last year has been set to Incomplete and their assignee/milestone unset in order to let Launchpad expire them in 60 days[2]. It gives us a 60-days

Re: [openstack-dev] [searchlight] Liberty release finalization

On 10/6/15, 2:28 AM, "Thierry Carrez" wrote: > >The "intermediary" model requires the project following it to be mature >enough (and the project team following it to be disciplined enough) to >internalize the QA process. > >In the "with-milestones" model, you produce

Re: [openstack-dev] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron

On Tue, Oct 06, 2015 at 11:25:03AM EDT, Mike Spreitzer wrote: > [Sorry, but I do not know if the thundering silence is because these > questions are too hard, too easy, grossly off-topic, or simply because > nobody cares.] You sent your first e-mail on a Saturday. I saw it and flagged it for

[openstack-dev] [searchlight] Mitaka Summit Sessions

Hi Searchlighters, We need to have our summit sessions decided by October 15. I’ve put up an ether pad capturing some of the initial ideas we had discussed previously in IRC. https://etherpad.openstack.org/p/searchlight-mitaka-summit Please jump on there and add comments, suggestions,

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

> On 06 Oct 2015, at 19:10, Thomas Goirand wrote: > > On 10/01/2015 03:45 PM, Ihar Hrachyshka wrote: >> Hi all, >> >> I talked recently with several contributors about what each of us plans for >> the next cycle, and found it’s quite useful to share thoughts with others, >>

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

Overall I think this is a good idea and the time frame proposal also looks good. Few suggestions in-line. On 10/6/15 10:36 AM, Flavio Percoco wrote: > Greetings, > > Not so long ago, Erno started a thread[0] in this list to discuss the > abandon policies for patches that haven't been updated in

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

This again becomes a part of the undefinied priority concept. It's hard to come up with a list of priorities all at the beginning of the cycle so, conflicting priority items may get missed every now and then. I hope the dashboard will help however, this is more of a people problem than a process

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

I think Glance reviewer brandwidth is pretty low and the feedback time can be quite high. For specs, I had requested a section describing the core reviewer who will be vouching for your spec to be added to the spec itself. I think in general we have not seen anyone doing that strongly. If a spec

Re: [openstack-dev] [nova] live migration in Mitaka

On 10/06/2015 08:11 AM, Daniel P. Berrange wrote: On Tue, Oct 06, 2015 at 02:54:21PM +0100, Paul Carlton wrote: https://review.openstack.org/#/c/85048/ was raised to address the migration of instances that are not running but people did not warm to the idea of bringing a stopped/suspended

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

On 10/01/2015 03:45 PM, Ihar Hrachyshka wrote: > Hi all, > > I talked recently with several contributors about what each of us plans for > the next cycle, and found it’s quite useful to share thoughts with others, > because you have immediate yay/nay feedback, and maybe find companions for >

Re: [openstack-dev] [Fuel] py.test vs testrepository

Hey Roman, > It’s ”standard" in OpenStack so using it gives Fuel more karma > and moves it more under big tent As far as I understand it doesn't affect our movement under big tent. > It’s in global requirements, so it doesn’t cause dependency hell Honestly I have no idea how py.test caused a

[openstack-dev] [Cinder][Keystone] Liberty RC2 available

Hello everyone, Due to release-critical issues spotted in Cinder and Keystone during RC1 testing (as well as last-minute translations imports), new release candidates were created for Liberty. The list of RC2 fixes, as well as RC2 tarballs are available at:

Re: [openstack-dev] [Neutron] AZ Support

On Mon, Oct 5, 2015 at 10:41 PM, Ihar Hrachyshka wrote: >> On 05 Oct 2015, at 15:32, Gary Kotton wrote: >> >> >> >> On 10/5/15, 3:21 AM, "Ihar Hrachyshka" wrote: >> On 04 Oct 2015, at 19:21, Gary Kotton