Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

> -Original Message- > From: Alan Pevec [mailto:ape...@gmail.com] > Sent: Friday, November 20, 2015 10:46 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) > WAS Re: [Openstack-operators]

Re: [openstack-dev] [release][stable] OpenStack 2014.2.4 (juno)

On 11/19/2015 08:56 PM, Rochelle Grober wrote: > Again, my plea to leave the Juno repository on git.openstack.org, but locked > down to enable at least grenade testing for Juno->Kilo upgrades. For upgrade > testing purposes, python2.6 is not needed as any cloud would have to upgrade > python

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

There is something that isn't clear to me from your patch and based on your description of the workflow below. It sounds like you are following the basic L3 to ToR topology so each rack is a broadcast domain. If that’s the case, each rack should be a Neutron network and the mapping should be

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

On 11/17/2015 10:51 PM, Matt Riedemann wrote: > > I *don't* see any DB APIs for deleting instance actions. > > Kind of an important difference there. Jay got it at least. :) > >> >> Were we just planning on instance_actions living forever in the database? >> >> Should we soft delete

Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs

+1 for "refuel" to trigger Fuel CI only, awesome idea. "recheck" will trigger both. 2015-11-20 21:12 GMT+07:00 Sergey Vasilenko : > > On Fri, Nov 20, 2015 at 4:00 PM, Alexey Shtokolov > wrote: > >> Probably we should use another keyword for

Re: [openstack-dev] [infra][devstack][gnocchi] Unable to run devstack-gate with stable/1.3

On Fri, Nov 20 2015, Clark Boylan wrote: > You need a mapping of some sort. How should devstack be configured for > stable/X.Y? What about stable/Y.Z? This is one method of providing that > mapping and it is very explicit. We can probably do better but we need > to understand what the desired

Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs

Alexey, First of all, “refuel” sounds very cool. Thanks for raising this topic, I would like to hear more opinions here. On one hand, different keyword would help to prevent unnecessary infrastructure load, I agree with you on that. And on another hand, using existing keywords helps to avoid

Re: [openstack-dev] [neutron][fwaas]some architectural advice on fwaas driver writing

Hi- As I understand you are not sure on "How to locate the Hardware Appliance" which you have as your FW? Am I right? If so you can look into, https://github.com/jumpojoy/generic_switch kind of approach. - Trinath From: Oguz Yarimtepe [mailto:oguzyarimt...@gmail.com] Sent: Friday,

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Hello, Igor. >But I'd like to hear from QA how do we rely on container-based infrastructure? Would it be hard to change our sys-tests in short time? At first glance, system tests are using docker only to fetch logs and run shell commands. Also, docker is used to run Rally. If there is an action

Re: [openstack-dev] [neutron] [QoS] meeting rebooted

Correct, thanks Moshe. One of the first proposals is probably changing the periodicity of the meeting to 2-weeks instead if every week. We could vote on that by the end of the meeting, depending on how things go. And of course, we could change that back to 1-week later in the cycle as

Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs

On Fri, Nov 20, 2015 at 4:00 PM, Alexey Shtokolov wrote: > Probably we should use another keyword for Fuel CI to prevent an extra > load on the infrastructure? For example "refuel" or smth like this? IMHO we should have ability to restart each one of two deployment

Re: [openstack-dev] [nova] build_instance pre hook cannot set injected_files for new instance

On 11/19/2015 10:34 AM, Rich Megginson wrote: I have some code that uses the build_instance pre hook to set injected_files in the new instance. With the kilo code, the argv[7] was passed as [] - so I could append/extend this value to add more injected_files. With the latest code, this is

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Hi Andrey, As far as I remember from the last usage of fuel master node, there was > Centos + py26 installation. Python 2.6 is old enough and sometimes it is > hard to launch some application on fuel node without docker (image with > py27/py3). Are you planning to provide py27 at least or my note

Re: [openstack-dev] How to add a periodic check for typos?

So, just for grins, I took this approach out for a spin on Trove and noticed this as part of the change proposed by topy. - "hebrew": ["hebrew_general_ci", "hebrew_bin"], + "Hebrew": ["hebrew_general_ci", "hebrew_bin"], - "greek": ["greek_general_ci",

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Hi team, I think it too late to make such significant changes for MOS 8.0 now, but I'm ok with the idea to remove docker containers in the future releases if our dev team want to do this. Any way, before we will do this, we need to plan how we will perform updates between different releases with

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Hi! I'm not fuel developer, so opinion below is based on user-view. As far as I remember from the last usage of fuel master node, there was Centos + py26 installation. Python 2.6 is old enough and sometimes it is hard to launch some application on fuel node without docker (image with py27/py3).

Re: [openstack-dev] [Fuel] Number of IP addresses in a public network

We have more generic ticket: https://bugs.launchpad.net/fuel/+bug/1354803 and corresponding CR: https://review.openstack.org/#/c/245941/ Aleksey Kasatkin On Fri, Nov 20, 2015 at 11:24 AM, Aleksey Kasatkin wrote: > It's not about Public networks only. There can be the

Re: [openstack-dev] [release][stable] OpenStack 2014.2.4 (juno)

2015-11-20 3:22 GMT+01:00 Davanum Srinivas : > fyi https://review.openstack.org/#/c/247677/ That's not the right answer to Rochelle's plea :) It was actually already answered by Matt, with a suggestion that _Kilo_ grenade job could simply checkout 2014.2.4 tag instead of

Re: [openstack-dev] [neutron][taas] proposal: dedicated tunnel for carrying mirrored traffic

Hi, Thank you for your interest and suggestion. A blueprint [1] has already proposed to add port mirroring capabilities to Neutron. [1] https://blueprints.launchpad.net/neutron/+spec/port-mirroring Because our proposal is for the current design of TaaS (tap-as-a-service), I guess a RFE is not

Re: [openstack-dev] OpenStack-Announce List

On Fri, Nov 20, 2015 at 4:41 AM, Thierry Carrez wrote: > We could definitely go back to "the place users wanting to keep up with > upstream news directly affecting them should subscribe to", and post only: > > - user-facing service releases (type:service deliverables), on

Re: [openstack-dev] [neutron][fwaas]some architectural advice on fwaas driver writing

I created a sample driver by looking at vArmour driver that is at the Github FWaaS repo. I am planning to call the FW's REST API from the suitable functions. The problem is, i am still not sure how to locate the hardware appliance. One of the FWaaS guy says that Service Chaining can help, any

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

> So we were brainstorming this with Rocky the other night. Would this be > possible to do by following: > 1) we still tag juno EOL in few days time > 2) we do not remove the stable/juno branch Why not? > 3) we run periodic grenade jobs for kilo >From a quick look, grenade should work with a

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

-Original Message- From: Davanum Srinivas [mailto:dava...@gmail.com] Sent: 20 November 2015 16:59 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils Abhishek, Go for it! Thank you Dims, I am on

[openstack-dev] [neutron] [QoS] meeting rebooted

Hi everybody, We're restarting the QoS meeting for next week, Here are the details, and a preliminary agenda, https://etherpad.openstack.org/p/qos-mitaka Let's keep QoS moving!, Best, Miguel Ángel.

Re: [openstack-dev] [neutron] [QoS] meeting rebooted

Miguel Angel Ajo wrote: Hi everybody, We're restarting the QoS meeting for next week, Here are the details, and a preliminary agenda, https://etherpad.openstack.org/p/qos-mitaka Let's keep QoS moving!, Best, Miguel Ángel. I think you

Re: [openstack-dev] [neutron][taas] proposal: dedicated tunnel for carrying mirrored traffic

Thank you for your interest. The (dedicated) tunnel is used only to carry mirrored packets. Time stamp and order of a mirrored packet is the same as original packet. We may need to consider the issue you pointed out, but I think it's independent from whether dedicated tunnel is used or

Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs

Hi Stanislaw, The reason behind this is simple - deployment tests are heavy. Each deployment test occupies whole server for ~2 hours, for each commit we have 2 deployment tests (for current fuel-library master) and that’s just because we don’t test CentOS deployment for now. If we assume that

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

On Fri, Nov 20, 2015 at 03:22:04AM +, Li, Xiaoyan wrote: > Hi all, > > To fix bug [1][2] in Cinder, Cinder needs to use nova/volume/encryptors[3] > to attach/detach encrypted volumes. > > To decrease the code duplication, I raised a BP[4] to move encryptors to > os-brick[5]. > > Once it is

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

> -Original Message- > From: Thierry Carrez [mailto:thie...@openstack.org] > Sent: Friday, November 20, 2015 10:45 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) > WAS Re: [Openstack-operators] [stable][all] Keeping

Re: [openstack-dev] [ironic] Redfish drivers in ironic

On 11/20/2015 12:50 AM, Bruno Cornec wrote: Hello, Vladyslav Drok said on Thu, Nov 19, 2015 at 03:59:41PM +0200: Hi list and Bruno, I’m interested in adding virtual media boot interface for redfish ( https://blueprints.launchpad.net/ironic/+spec/redfish-virtual-media-boot). It depends on

Re: [openstack-dev] [OpenStack-Infra] Report from Gerrit User Summit

Superb report Jim, thanks ! On Thu, Nov 19, 2015 at 10:47 AM, Markus Zoeller wrote: > David Pursehouse wrote on 11/12/2015 09:22:50 > PM: > > > From: David Pursehouse > > To: OpenStack Development Mailing List >

Re: [openstack-dev] [nova] Versioned notifications... who cares about the version?

> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] > Sent: November 19, 2015 23:29 > On 11/19/2015 4:05 PM, Ryan Rossiter wrote: > > Reading through [1] I started getting worries in the back of my head > > about versioning these notifications. The main concern being how can > > the

Re: [openstack-dev] OpenStack-Announce List

Tom Fifield wrote: > I'd like to get your thoughts about the OpenStack-Announce list. > > We describe the list as: > > """ > Subscribe to this list to receive important announcements from the > OpenStack Release Team and OpenStack Security Team. > > This is a low-traffic, read-only list. > """

Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs

Igor, it is much more clear for me now. Thank you :) On Fri, Nov 20, 2015 at 2:09 PM, Igor Belikov wrote: > Hi Stanislaw, > > The reason behind this is simple - deployment tests are heavy. Each > deployment test occupies whole server for ~2 hours, for each commit we have

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

On 19 November 2015 at 09:43, Thierry Carrez wrote: > > So we have three models. The release:independent model is for projects > that don't follow the common development cycle, and therefore won't make > a "liberty" release. The release:cycle-with-milestones model is the >

Re: [openstack-dev] [ironic] Redfish drivers in ironic

On Fri, Nov 20, 2015 at 1:50 AM, Bruno Cornec wrote: > Hello, > > Vladyslav Drok said on Thu, Nov 19, 2015 at 03:59:41PM +0200: > >> Hi list and Bruno, >> >> I’m interested in adding virtual media boot interface for redfish ( >>

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

On 11/20/2015 06:01 AM, Kuvaja, Erno wrote: >> -Original Message- >> From: Alan Pevec [mailto:ape...@gmail.com] >> Sent: Friday, November 20, 2015 10:46 AM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [stable][infra][qa] Preparing

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

On Fri, Nov 20, 2015, at 04:32 AM, Julien Danjou wrote: > On Fri, Nov 20 2015, Clark Boylan wrote: > > > If you have a stable/X.Y branch or stable/foo but are still wanting to > > map onto the 6 month release cycle (we know this because you are running > > devstack-gate) how do we make that

Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs

Hi Igor, would you be so kind tell, why fuel-library deployment tests doesn't support this? Maybe there is a link with previous talks about it? On Fri, Nov 20, 2015 at 1:34 PM, Igor Belikov wrote: > Hi, > > I’d like to inform you that all jobs running on Fuel CI (with

Re: [openstack-dev] [neutron] [QoS] meeting rebooted

Just to add more details about the when and where :) We will have a weekly meeting on Wednesday at 1400 UTC in #openstack-meeting-3 http://eavesdrop.openstack.org/#Neutron_QoS_Meeting Thanks, Moshe Levi. > -Original Message- > From: Ihar Hrachyshka

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

Brick does not have to take over the decisions in order to be a useful repository for the code. The motivation for this work is to avoid having the dm setup code copied wholesale into cinder, where it becomes difficult to keep in sync with the code in nova. Cinder needs a copy of this code since

Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs

Igor, Thank you for this feature. Afaiu recheck/reverify is mostly useful for internal CI-related fails. And Fuel CI and Openstack CI are two different infrastructures. So if smth is broken on Fuel CI, "recheck" will restart all jobs on Openstack CI too. And opposite case works the same way.

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

Abhishek, Go for it! On Fri, Nov 20, 2015 at 2:32 AM, Kekane, Abhishek wrote: > -Original Message- > From: Doug Hellmann [mailto:d...@doughellmann.com] > Sent: 16 November 2015 21:46 > To: openstack-dev > Subject: Re: [openstack-dev] [oslo] Graduate

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

On Thu, Nov 19, 2015, at 12:55 PM, Chris Dent wrote: > On Thu, 19 Nov 2015, Julien Danjou wrote: > > > It would be good to support that as being *normal*, not "potentially > > incorrect and random"! > > Yes. > > The underlying issue in this thread is the dominance of the six month > cycle and

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

On Fri, Nov 20 2015, Clark Boylan wrote: > If you have a stable/X.Y branch or stable/foo but are still wanting to > map onto the 6 month release cycle (we know this because you are running > devstack-gate) how do we make that mapping? is it arbitrary? is there > some deterministic method? Things

Re: [openstack-dev] [nova] What things do we want to get into a python-novaclient 3.0 release?

I wrote this a while back, which implements 'migrate everything off this compute host' in the most robust manner I could come up with using only the external api: https://gist.github.com/mdbooth/163f5fdf47ab45d7addd It obviously overlaps considerably with host-servers-migrate, which is supposed

[openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs

Hi, I’d like to inform you that all jobs running on Fuel CI (with the exception of fuel-library deployment tests) now support retriggering via “recheck” or “reverify” comments in Gerrit. Exact regex is the same one used in Openstack-Infra’s zuul and can be found here

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

Kuvaja, Erno wrote: > So we were brainstorming this with Rocky the other night. Would this be > possible to do by following: > 1) we still tag juno EOL in few days time > 2) we do not remove the stable/juno branch > 3) we run periodic grenade jobs for kilo > > I'm not that familiar with the

Re: [openstack-dev] [infra][devstack][gnocchi] Unable to run devstack-gate with stable/1.3

On Thu, Nov 19, 2015, at 05:17 AM, Julien Danjou wrote: > Hi, > > The Gnocchi gate is broken for stable/1.3 because of devstack-gate > saying¹: > ERROR: branch not allowed by features matrix: 1.3 > > From what I understand, that's because devstack-gate thinks it should > try to pull stable/1.3

Re: [openstack-dev] [Fuel] Number of IP addresses in a public network

It's not about Public networks only. There can be the same problem with other networks as well. It's required to check all the networks (across all node groups). But it is done just for Public network now (and VIPs for plugins are not taken into account). Aleksey Kasatkin On Fri, Nov 20, 2015

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

Julien Danjou wrote: > On Thu, Nov 19 2015, Doug Hellmann wrote: > >> In my mind the “independent” release model was originally meant to mean that >> the project was completely on their own, doing potentially incorrect and >> random >> releases. It wasn’t something I anticipated projects

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

> -Original Message- > From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] > Sent: Tuesday, November 17, 2015 2:57 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [stable] Preparing 2014.2.4 (Juno) WAS Re: > [Openstack-operators] [stable][all] Keeping Juno

Re: [openstack-dev] [tripleo] When to use parameters vs parameter_defaults

On 11/16/2015 04:25 PM, Steven Hardy wrote: Hi all, I wanted to start some discussion re $subject, because it's been apparrent that we have a lack of clarity on this issue (and have done ever since we started using parameter_defaults). Some context: - Historically TripleO has provided a

Re: [openstack-dev] [Fuel][library] CI gate for regressions detection in deployment data

> Hi, > > let me try to rephrase this a bit and Bogdan will correct me if I'm wrong > or missing something. > > We have a set of top-scope manifests (called Fuel puppet tasks) that we use > for OpenStack deployment. We execute those tasks with "puppet apply". Each > task supposed to bring target

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

+1 to remove docker in new CentOS 7. On Fri, Nov 20, 2015 at 7:31 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Bogdan, > > >> So, we could only deprecate the docker feature for the 8.0. > > What do you mean exactly when saying 'deprecate docker feature'? I can not > even imagine

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

On 11/20/2015 8:18 AM, Sean Dague wrote: On 11/17/2015 10:51 PM, Matt Riedemann wrote: I *don't* see any DB APIs for deleting instance actions. Kind of an important difference there. Jay got it at least. :) Were we just planning on instance_actions living forever in the database?

[openstack-dev] [nova] FKs in the DB

We just had a fun discussion in IRC about whether foreign keys are evil. Initially I thought this was crazy but mordred made some good points. To paraphrase, that if you have a scale-out app already it's easier to manage integrity in your app than scale-out your persistence layer. Currently the

[openstack-dev] [nova]New Quota Subteam on Nova

Hi guys Me and other guys are working in the nested quota driver ( https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nested-quota-driver-api,n,z) on Nova. in addition, We want discuss the re-design of the quota implementation on nova and in other

Re: [openstack-dev] [nova] What things do we want to get into a python-novaclient 3.0 release?

On 11/20/2015 3:48 AM, Matthew Booth wrote: I wrote this a while back, which implements 'migrate everything off this compute host' in the most robust manner I could come up with using only the external api: https://gist.github.com/mdbooth/163f5fdf47ab45d7addd It obviously overlaps

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Bogdan, >> So, we could only deprecate the docker feature for the 8.0. What do you mean exactly when saying 'deprecate docker feature'? I can not even imagine how we can live with and without docker containers at the same time. Deprecation is usually related to features which directly impact UX

Re: [openstack-dev] [nova] Versioned notifications... who cares about the version?

gord chung said on Thu, Nov 19, 2015 at 11:59:33PM -0500: > just to clarify, the idea doesn't involve tailoring the notification > payload to ceilometer, just that if a producer is producing a > notification it knows contains a useful datapoint, the producer > should tell someone explicitly 'this

Re: [openstack-dev] [Neutron] Mid-cycle meetup for Mitaka

Gareth, For the time being, we don't have a Neutron mid-cycle scheduled. Later in the Mitaka cycle, it will be assessed whether we need to schedule on or not. But for the time being, the decision is we are not having one Cheers On Thu, Nov 19, 2015 at 10:23 PM, Gareth

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

On 11/20/2015 10:04 AM, Andrew Laski wrote: On 11/20/15 at 09:51am, Matt Riedemann wrote: On 11/20/2015 8:18 AM, Sean Dague wrote: On 11/17/2015 10:51 PM, Matt Riedemann wrote: I *don't* see any DB APIs for deleting instance actions. Kind of an important difference there. Jay got it

Re: [openstack-dev] [nova][bugs] Weekly Status Report

Below are the bug stats of the week "Mitaka R-20". Increases/decreases compared to "Mitaka R-21" are in parantheses. The bug count of the novaclient is added now. Stats = New bugs which are *not* assigned to any subteam count: 30 (+2)

Re: [openstack-dev] [nova] FKs in the DB

On Fri, Nov 20 2015, Alexis Lee wrote: > We just had a fun discussion in IRC about whether foreign keys are evil. > Initially I thought this was crazy but mordred made some good points. To > paraphrase, that if you have a scale-out app already it's easier to > manage integrity in your app than

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

On 20.11.2015 15:10, Timur Nurlygayanov wrote: > Hi team, > > I think it too late to make such significant changes for MOS 8.0 now, > but I'm ok with the idea to remove docker containers in the future > releases if our dev team want to do this. > Any way, before we will do this, we need to plan

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

On 11/20/15 at 09:51am, Matt Riedemann wrote: On 11/20/2015 8:18 AM, Sean Dague wrote: On 11/17/2015 10:51 PM, Matt Riedemann wrote: I *don't* see any DB APIs for deleting instance actions. Kind of an important difference there. Jay got it at least. :) Were we just planning on

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

Jesse Pretorius wrote: > [...] > The deployment projects, and probably packaging projects too, are faced > with the same issue. There's no guarantee that their x release will be > done on the same day as the OpenStack services release their x branches > as the deployment projects still need some

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

On 20.11.2015 17:31, Vladimir Kozhukalov wrote: > Bogdan, > >>> So, we could only deprecate the docker feature for the 8.0. > > What do you mean exactly when saying 'deprecate docker feature'? I can > not even imagine how we can live with and without docker containers at > the same time.

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

Stanislaw, In my opinion the whole feature shouldn't be in the separate package simply because it will actually affect the code of many, if not all, components of Fuel. The only services whose capabilities will have to be managed by puppet are those, which are installed from upstream packages

Re: [openstack-dev] [nova] What things do we want to get into a python-novaclient 3.0 release?

On 11/20/2015 10:20 AM, Matt Riedemann wrote: On 11/20/2015 3:48 AM, Matthew Booth wrote: I wrote this a while back, which implements 'migrate everything off this compute host' in the most robust manner I could come up with using only the external api:

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

On 11/20/2015 11:36 AM, Matt Riedemann wrote: > > > On 11/20/2015 10:04 AM, Andrew Laski wrote: >> On 11/20/15 at 09:51am, Matt Riedemann wrote: >>> >>> >>> On 11/20/2015 8:18 AM, Sean Dague wrote: On 11/17/2015 10:51 PM, Matt Riedemann wrote: > > I *don't* see any DB APIs for

Re: [openstack-dev] [Neutron] Bug update

On 19 November 2015 at 23:10, Gary Kotton wrote: > Hi, > There are a ton of old and ancient bugs that have not been trained. If you > guys have some time then please go over them. In most cases some are not > even bugs and are just questions. I have spent the last few days

Re: [openstack-dev] [Neutron] Bug update

I think Gary got auto-corrected: training = triaging brace = rbac On Nov 20, 2015, at 12:41 PM, Armando M. > wrote: On 19 November 2015 at 23:10, Gary Kotton > wrote: Hi, There are a ton of old and

Re: [openstack-dev] [nova] Versioned notifications... who cares about the version?

On 20/11/15 11:33 AM, Alexis Lee wrote: gord chung said on Thu, Nov 19, 2015 at 11:59:33PM -0500: just to clarify, the idea doesn't involve tailoring the notification payload to ceilometer, just that if a producer is producing a notification it knows contains a useful datapoint, the producer

[openstack-dev] Neutron L3 Sub-team meeting canceled on November 26th

Dear Neutron L3 Sub-team members, We are canceling our weekly IRC meeting on November 26th, due to the Thanksgiving holiday in the US. We will reconvene again on December 3rd at the usual time. Best regards __ OpenStack

[openstack-dev] [third-party][infra][CI] Common OpenStack 'Third-party' CI Solution - DONE!

All, I’m happy to announce that there is now a working ‘Common’ OpenStack ‘third-party’ CI Solution available! This is a 3rd party CI solution that uses the same tools and scripts as the upstream ‘Jenkins’ CI. The last few pieces were particularly challenging. Big thanks to Yolanda Robla for

Re: [openstack-dev] [Neutron] Bug update

On 19 November 2015 at 23:20, Gary Kotton wrote: > Hi, > One extra thing. A large chunk of the latest bugs opened are RFE’s. These > are tagged with ‘rfe’. In addition to this I would suggest changing the > title of the bug to have [RFE]. This will at least help those who are

Re: [openstack-dev] [Glance] M-1 Bugs/Reviews squash day

On 16/11/15 16:45 -0300, Flavio Percoco wrote: Greetings, At our last meeting, we discussed the idea of having a Bug/Reviews squash day before the end of M-1. I'm sending this email out to propose that we do this work on one of the following dates: - Friday November 20th (ALL TZs) - Monday

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

On Fri, Nov 20, 2015 at 02:45:15PM +0200, Duncan Thomas wrote: > Brick does not have to take over the decisions in order to be a useful > repository for the code. The motivation for this work is to avoid having > the dm setup code copied wholesale into cinder, where it becomes difficult > to keep

Re: [openstack-dev] [Neutron] Bug update

On 20 November 2015 at 09:47, John Belamaric wrote: > I think Gary got auto-corrected: > > training = triaging > brace = rbac > ah! > > On Nov 20, 2015, at 12:41 PM, Armando M. wrote: > > > > On 19 November 2015 at 23:10, Gary Kotton

Re: [openstack-dev] [nova] FKs in the DB

On 11/20/2015 10:19 AM, Alexis Lee wrote: We just had a fun discussion in IRC about whether foreign keys are evil. Initially I thought this was crazy but mordred made some good points. To paraphrase, that if you have a scale-out app already it's easier to manage integrity in your app than

[openstack-dev] Nova compute hooks are not called

Hello, I am trying to get Nova Compute create_instance hook to be called. However, although the VM gets started from Horizon properly, the hook does not get called and there is no reference in it to the logs. When I run the hook script from the command line, it runs fine. Please let me

Re: [openstack-dev] [third-party][infra][CI] Common OpenStack 'Third-party' CI Solution - DONE!

Ramy, I had previously used your os-ext-testing repo to build a 3rd party CI, and today I’ve been trying out this new approach. I’ve noticed a piece of the puzzle appears to be missing. In the new instructions [1], there is no mention of having to manually install the Jenkins SCP plugin v1.9.

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

Dmitry, I just propose the way I think is right, because it's strange enough - install package from *.deb file and then set any privileges to it by third-party utility. Set permissions for app now mostly managed by post-install scripts. Moreover - if it isn't - it should, cause if you set

Re: [openstack-dev] [nova] FKs in the DB

On 11/20/2015 11:19 AM, Alexis Lee wrote: > We just had a fun discussion in IRC about whether foreign keys are evil. > Initially I thought this was crazy but mordred made some good points. To > paraphrase, that if you have a scale-out app already it's easier to > manage integrity in your app

Re: [openstack-dev] [nova] FKs in the DB

On 11/20/2015 02:29 PM, Mike Bayer wrote: > > > On 11/20/2015 11:19 AM, Alexis Lee wrote: >> We just had a fun discussion in IRC about whether foreign keys are evil. >> Initially I thought this was crazy but mordred made some good points. To >> paraphrase, that if you have a scale-out app

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

On Nov 20, 2015, at 6:18, Sean Dague wrote: > instance_actions seems extremely useful, and at the ops meetups I've > been to has been one of the favorite features because it allows and easy > interface for "going back in time" to figure out what happened. Agreed, we're using it

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

Stanislaw, I want to clarify: there are 2 types of services, run on the Fuel node: - Those, which are a part of Fuel (astute, nailgun etc) - Those, which are not (e.g. atop) Capabilities for the former can easily be managed via post-install scripts, embedded in respective package spec file

Re: [openstack-dev] [third-party][infra][CI] Common OpenStack 'Third-party' CI Solution - DONE!

Hi Sid, Instead of documenting it, was simple enough to automate it. Please try these out: https://review.openstack.org/248223 https://review.openstack.org/248226 Feel free to propose your own fixes or improvements. I think this is one of best parts of getting it all in sync upstream. Best

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Hi Igor and Alexander, >But I'd like to hear from QA how do we rely on container-based > infrastructure? Would it be hard to change our sys-tests in short > time? QA team hadn't significant dependencies from docker images in our tests [0], I think we can change all docker-based code from our

Re: [openstack-dev] [third-party][infra][CI] Common OpenStack 'Third-party' CI Solution - DONE!

Hi Sid, Sorry, you’re right: log server fix is here. [1] I thought I documented the scp v1.9 plugin issue, but I don’t see it now. I will submit a patch to add that. Thanks for raising these issues! Ramy [1] https://review.openstack.org/#/c/242800/ From: Siddharth Bhatt

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

On 11/20/2015 10:19 AM, Daniel P. Berrange wrote: On Fri, Nov 20, 2015 at 02:45:15PM +0200, Duncan Thomas wrote: Brick does not have to take over the decisions in order to be a useful repository for the code. The motivation for this work is to avoid having the dm setup code copied wholesale

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

On 11/20/2015 01:19 PM, Daniel P. Berrange wrote: On Fri, Nov 20, 2015 at 02:45:15PM +0200, Duncan Thomas wrote: Brick does not have to take over the decisions in order to be a useful repository for the code. The motivation for this work is to avoid having the dm setup code copied wholesale

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

On 11/20/2015 3:00 PM, Sylvain Bauza wrote: Le 20/11/2015 17:36, Matt Riedemann a écrit : On 11/20/2015 10:04 AM, Andrew Laski wrote: On 11/20/15 at 09:51am, Matt Riedemann wrote: On 11/20/2015 8:18 AM, Sean Dague wrote: On 11/17/2015 10:51 PM, Matt Riedemann wrote: I *don't* see

[openstack-dev] [horizon][bug] Mitigation to BREACH vulnerability

Until django releases an official patch for the BREACH vulnerability, I think we should take a look at django-debreach. The django-debreach package provides some, possibly enough, protection against a BREACH attack. Its integration to Horizon is clear by following the configuration found here:

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

Le 20/11/2015 17:36, Matt Riedemann a écrit : On 11/20/2015 10:04 AM, Andrew Laski wrote: On 11/20/15 at 09:51am, Matt Riedemann wrote: On 11/20/2015 8:18 AM, Sean Dague wrote: On 11/17/2015 10:51 PM, Matt Riedemann wrote: I *don't* see any DB APIs for deleting instance actions.

Re: [openstack-dev] [nova] FKs in the DB

Excerpts from Mike Bayer's message of 2015-11-20 11:29:31 -0800: > > On 11/20/2015 11:19 AM, Alexis Lee wrote: > > We just had a fun discussion in IRC about whether foreign keys are evil. > > Initially I thought this was crazy but mordred made some good points. To > > paraphrase, that if you have

Re: [openstack-dev] [nova] FKs in the DB

Excerpts from Matt Riedemann's message of 2015-11-20 10:58:55 -0800: > > On 11/20/2015 10:19 AM, Alexis Lee wrote: > > We just had a fun discussion in IRC about whether foreign keys are evil. > > Initially I thought this was crazy but mordred made some good points. To > > paraphrase, that if you

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Hey Timur, > I think we can change all docker-based code from our tests / scripts > in 2-3 days That sounds good. > Do we really want to remove docker containers from master node? Yes, we do. Currently we're suffering from using container-based architecture on master node, and since we've

  1   2   >