[openstack-dev] [horizon][release][infra] New xstatic package release proposal

[Richard Jones]

TL;DR: "Releasing xstatic packages" https://review.openstack.org/#/c/253296/

xstatic  is an existing standard for packaging up
static resources for web development (HTML, Javascript and CSS) as Python
modules. Horizon makes use of two dozen xstatic packages.

We need a better-organised method of releasing those packages. Currently
those packages are maintained and released in an ad-hoc manner by
individuals who come and go in the community, with differing release
processes, requiring maintenance handovers, sometimes with people who go
quiet. This does not scale to the dozens of xstatic packages Horizon wishes
to consume.

We therefore wish to use OpenStack's existing release pipeline, handing
over upload to PyPI to that system, while also allowing review of updates
to the packages.

A problem arises in doing so: xstatic packages version themselves using the
three-digit version of the static package they bundle (eg. JQuery-1.2.3)
with an added build number (eg. xstatic-jquery-1.2.3.4) to allow
re-building if the packaging goes wrong. Currently we cannot release these
packages through the OpenStack release pipeline because pbr (a requirement
of that pipeline) does not allow 4 digit version strings. A proposal to
extend pbr to allow 4 digit versions was abandoned today:
https://review.openstack.org/#/c/205623/ (in short, we are only using the
version git tag extraction facility of pbr, and even then not all of that,
and pbr would become more complex with the special-casing required to ...
special-case xstatic packaging).

We will look to use setuptools_scm instead of pbr. Some support work will
be required to make the proposal above happen. This is outlined in
"Releasing xstatic packages" https://review.openstack.org/#/c/253296/

Also, a patch has been submitted to a sample xstatic package implementing
the proposed new workflow: https://review.openstack.org/#/c/252752/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Congress] Python 3 ready

[Eric K]

Congress can finally pass python34 gating.

Here¹s the last patch needed to make it happen.
https://review.openstack.org/#/c/253298/


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [networking-sfc] Temporary instructions

[Cathy Zhang]

Here it is (I posted this in today's IRC meeting too).

https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining

Thanks,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Thursday, December 03, 2015 10:34 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] [networking-sfc] Temporary instructions

Hi networking-sfc,

What is the recommended place to host the temporary installation instructions?

Best regards,
Igor.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

[Ryota Mibu]

Hi Ifat,


> > > Let me see if I got this right: are you suggesting that we create
> > > on-the-fly alarm definitions with no alarm_actions, for every
> > > deduced
> > alarm that we want to raise? And this will spare us the extra alarm
> > evaluation in AODH?
> >
> > Yes. But, please note that could be the first step. The next step
> > would be make vitrage to send out alarm event to ceilometer/aodh the
> > pre- configured event alarm will recognize the alarm and fire the
> > alarm notification to another service or an end user. Eventually, we
> > should have relevant alarm type and evaluator to proxy evaluation in
> > vitrage, I think.
> 
> The next step can happen if and when Aodh supports alarm templates.
> If Vitrage can handle about 30 alarm types, and there are 100 instances, we 
> don't want to pre-configure 3000 alarms,
> which most likely will never be triggered.


I understand your concern. Aodh is user facing service, so having lots of 
alarms doesn't make sense.

Can we clarify use case again in terms of service role definition?

Aodh provides alarming mechanism to *notify* events and situations calculated 
from various data sources. But, original/master information of resource 
including latest resource state is owned by other services such as nova.

So, user who wants to know current resource state to find out dead resources 
(instances), can simply query instances via nova api. And, user who wants to 
know when/what failure occurred can query events via ceilometer api. Aodh has 
alarm state and history though.



> > > Another question is our need to get alarms from other sources, like
> > > Nagios, zabbix, ganglia, etc. We thought that Vitrage would query
> > > these Alarms from each source directly, and then create alarms in
> > AODH in the same way as our deduced alarms: for example create
> > nagios_ovs_vswitchd alarm if nagios check_ovs_vswitchd test failed.
> > > An alternative could be to integrate nagios directly with AODH.
> > > What do you think?
> >
> > Hmm, I don't have clear view on this. If the source can includes
> > OpenStack IDs and can be generate relevant meter/sample, it should be
> > useful to integrate with ceilometer. But if you want to do some
> > operations (like correlation), then it is reasonable to integrate with
> > vitrage.
> 
> The source may include alarms on resources that are not defined in OpenStack, 
> like switches or ports. And the alarms
> are not necessarily related to meters, they can be test nagios failures for 
> example.


Yes, so it depends on type of resource and its parameter.



> > > > BTW, is it useful to have on-the-fly evaluation of combination
> > alarm
> > > > with event alarms for alarm aggregation or other cases?
> > >
> > > I'm not sure I understand. Can you give a detailed example?
> >
> > OK. The 'combination' type alarm enables you to aggregate multiple
> > alarm to one alarm. This can be used when you want to receive alarm
> > when the both of physical NIC ports are downed to recognize logical
> > connection unavailability if the ports are teamed for redundancy. Now,
> > the combination alarms are evaluated periodically that means you can
> > receive combination alarm not on-the-fly while you are using event
> > alarms as source of combination alarm though.
> 
> I think I understand your point. It means that certain alarms will arrive to 
> Vitrage in delay, due to your evaluation
> policy. I think we will have to address this issue at some point, but it 
> won't change our overall design.

Yes, I'm just curious if there is any user can get benefit from this 
improvement to set priority.



> > > In addition, in Vitrage we plan to handle alarm aggregation by
> > > creating aggregation rule templates, for example based on the RCA
> > information.
> > > The user will be able to see only the root cause alarms, and then
> > > drill down to all specific alarms. But I doubt if this will be done
> > for Mitaka.
> >
> > I think 'the RCA information' means information for RCA. I mean
> > vitrage will use the resource topologies or relationship in
> > aggregation, rather than result of RCA. Am I right?
> 
> The term "aggregation" is used in different contexts, which may be confusing. 
> Our plan is to examine the already-computed
> RCA information, and see, for example, that a switch failure alarm caused 
> alarms on 100 related instances. In horizon,
> the result will be 101 alarms shown to the user in a flat list.
> By "alarm aggregation based on RCA" we mean that we will have an API to get 
> root cause alarms, which will return only
> the switch alarm. The horizon user will see one alarm, and may then ask to 
> expand the view and see all the other alarms
> that were caused by it.

I see. I used the term "aggregation" for aggregation process in alarm 
evaluation.



Thanks,
Ryota


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [openstack-ansible] Install Openstack-Ansible

[Sharma Swati6]

Hi Major,

Thanks for the steps.

To add a new container, we have followed the steps as mentioned in the 
extra_container.yml.example. Please find the sample designate.yml file attached 
and created as per the steps.

To add the new roles in openstack-ansible repository, shall I create the 
directory looking at what is there for keystone or other components and make 
the configuration changes only, or can I clone it from somewhere also?

Thereafter, as suggested by you, I have to test this new container with the 
existing ones.

I believe there is no such link available with such steps and 'how to' part for 
openstack-ansible. Please let me know if you/anyone else have already done this 
part to add a new component container similarly.

Thanks & Regards
 Swati Sharma
 System Engineer
 Tata Consultancy Services
 Ground to 8th Floors, Building No. 1 & 2,
 Skyview Corporate Park, Sector 74A,NH 8
 Gurgaon - 122 004,Haryana
 India
 Cell:- +91-9717238784
 Mailto: sharma.swa...@tcs.com
 Website: http://www.tcs.com
 
 Experience certainty.  IT Services
Business Solutions
Consulting
 
 

-Major Hayden  wrote: -
To: "OpenStack Development Mailing List (not for usage questions)" 

From: Major Hayden 
Date: 12/02/2015 01:49AM
Subject: Re: [openstack-dev] [openstack-ansible] Install Openstack-Ansible

On Tue, 2015-12-01 at 20:35 +0530, Sharma Swati6 wrote:
> However, I just want to know if I have to implement this in
> openstack-ansible, or for that matter, I want to add any new
> component to it, are there any steps or guidelines to be followed.
> For example, first I create containers and mention/add it to config
> files. etc. 
> I went through http://docs.openstack.org/developer/openstack-ansible/
> developer-docs/extending.html but this is not much self-explanatory.
> 
> If the steps provided by you are helpful I can begin with this and
> contribute soon.

Hello Sharma,

I haven't implemented a new service in openstack-ansible quite yet, but
I'll give you some tips.

First, you'll need to use the extra_container.yml.example[1] to make a
new container.

Next, you'll want to create a role that will configure the operating
system and the required services within the container. You can review
the roles within the openstack-ansible repository to see what is
typically configured in each one.  The keystone role[2] might be a good
place to start.

>From there, you'll need to test the container build-out and
configuration to make sure the service works well with the other
services (like authentication with keystone).

[1] 
https://github.com/openstack/openstack-ansible/tree/master/etc/openstack_deploy/env.d
[2] 
https://github.com/openstack/openstack-ansible/tree/master/playbooks/roles/os_keystone

-- 
Major Hayden



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you




designate.yml
Description: Binary data
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] What repos to migrate to OpenStack infrastructure

[Sandro Mathys]

On Wed, Dec 2, 2015 at 4:05 PM, Sandro Mathys  wrote:
> Hi all,
>
> Trying to prepare moving our repos to the OpenStack infrastructure, I
> got reminded just how many repos we have in our GitHub organization
> [1] - and how many of those seem to be deprecated or tangential.
>
> Now, do we still want to migrate them? Pretty sure the answer is "no"
> for the deprecated ones but I wonder about the tangential ones. Well,
> to be honest, I also wonder which are actually deprecated/tangential
> and which are considered "important".
>
> First of all, I think repos that are not set up on GerritHub, don't
> need to be migrated. Partially because they don't seem important
> enough, and partially because migration would force Gerrit upon them
> (i.e. Gerrit is the main repo for a project in OpenStack, the others
> are just mirrors). But the list of midonet repos on GerritHub [2] is
> still very long.
>
> Of those, I figure these are deprecated and shouldn't be migrated:
> * arrakis
> * midostack
>
> Also, I'm only looking at what repos to migrate under the "midonet"
> umbrella. These repos should probably be migrated under a different
> umbrella, if at all:
> * ansible-* (-> ansible-openstack)
> * puppet-* (-> puppet-openstack)
> * zephyr (-> zephyr)
>
> Furthermore, these seem to be forks that should (no longer) see
> downstream commits, right?
> * python-midonetclient
> * python-neutronclient
>
> Last but not least, we have repos that have only a single contributor
> and should probably not be part of the midonet organization anyway -
> and repos with (virtually) no commits:
> * bees
> * docker-openvpn-client
> * docker-zk-web
> * orizuru
> * toscana
> * ubuntu-integration

Looks like ubuntu-integration is an empty repo, so no need to migrate anyway.

> Alright, this leaves us with 11 repos - much better number!
>
> These, I think we should migrate:
> * mdts

This one actually only exists on GerritHub but not GitHub (anymore?),
so we don't need to migrate it.

> * midonet
> * midonet-docs
> * midonet-sandbox
>
> These, we could migrate but they are low priority and might actually
> go away so let's defer:
> * midonethomepage
> * planet-midonet
>
> However, I have no idea about these - are they still needed? Do they
> belong under the midonet umbrella?
> * jmx_exporter
> * midonet-charms

Same as with mdts.

> * midonet-dockerfile
> * tempest-add
> * zktimemachine
>
> Please share your thoughts - did I exclude some that should be
> included in the migration? Should some be included that are not
> currently configured on GerritHub? And what about those 5 repos in the
> last list?
>
> Note, that all repos we want to migrate under the midonet umbrella
> probably need to have a "midonet-" in front, so it would need to be
> added to those who don't have it. (Well, planet-midonet will become
> midonet-planet and midonethomepage gain a dash).
>
> Thanks,
> Sandro
>
> PS. the "when" and "how" will be discussed later - let's focus on the
> "what" in this thread, please.
>
> [1] https://github.com/midonet
> [2] https://review.gerrithub.io/#/admin/projects/?filter=midonet%252F

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Testing concerns around boot from UEFI spec

[Tony Breeds]

On Thu, Dec 03, 2015 at 07:42:43PM -0600, Matt Riedemann wrote:

> I already mentioned this to sdague before the nova meeting today (these are
> the things I think about while driving in the middle of nowhere), but option
> #3 won't work because boot from UEFI requires libvirt>=1.9.0, which we don't
> have in the gate (ubuntu 14.04 has liberty 1.2.2).  There is a newer version
> of libvirt in the fc21 job in the experimental queue, but ovmf isn't
> available from Fedora [1].

We're woring on a devstack plugin that will allow us to test newer
libvirt/qemu.  Which doesn't really solve the testing problem but it helps.

Yours Tony.


pgp6B7ASk9IRU.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Murano] How to debug a failed deployment?

[Stan Lagun]

Vahid,

The only reason HOT deployment could last forever is that Heat stack never
enters Ready of Failed state. Please check what is the Heat stack status. I
guess it is not Murano issue
(except for the fact that we don't provide timeout for HOT deployment :) )

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis



On Thu, Dec 3, 2015 at 11:54 AM, Ekaterina Chernova 
wrote:

> Hi!
>
> Murano agent doesn't involved in the deployment of hot packages, that's
> why this setting doesn't help.
>
> Please attach agent logs and heat logs also (check if heat stack is
> created or not).
>
> Regards, Kate.
>
>
> Regards,
> Kate.
>
>
> On Thu, Dec 3, 2015 at 11:44 AM, Dmytro Dovbii 
> wrote:
>
>> Hi Vahid,
>>
>> Could you provide your logs anyway? Please publish them to
>> http://paste.openstack.org/ for example
>>
>> 2015-12-02 23:08 GMT+02:00 Vahid S Hashemian :
>>
>>> Hello,
>>>
>>> I am trying to deploy a hello world HOT package in murano but the
>>> deployment runs forever and does not stop (does not succeed or fail).
>>> Stan advised me to modify the config setting below to set a timeout:
>>>
>>> # Time for waiting for a response from murano agent during the
>>> # deployment (integer value)
>>> agent_timeout = 300
>>>
>>> As you see I set the timeout to 300 seconds and restarted murano API,
>>> but even after 15 minutes my deployment is still going.
>>> I think my environment is not configured correctly for this to happen.
>>>
>>> I have devstack running on a VM, and my murano development is done on a
>>> separate VM.
>>> I bring up murano API and UI on my dev VM that successfully connect to
>>> my devstack VM.
>>>
>>> I am able to deploy the HOT yaml using heat without an issue.
>>> From what I can see it seems that murano is not able to talk to heat,
>>> because I don't see any stack being created as a result of my deployment.
>>>
>>> I have also enabled murano logging in the config file as below:
>>>
>>> # (Optional) Name of log file to output to. If no default is set,
>>> # logging will go to stdout. (string value)
>>> # Deprecated group/name - [DEFAULT]/logfile
>>> log_file = /opt/stack/logs/murano.log
>>>
>>> But no error  is reported while the deployment is in progress.
>>>
>>> Any tips on how to force the timeout, and also on how to resolve the
>>> deployment problem is appreciated.
>>>
>>> Regards,
>>> --Vahid
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][midonet] networking-midonet weekly irc meeting

[Sandro Mathys]

On Thu, Dec 3, 2015 at 7:25 PM, Thierry Carrez  wrote:
> Sandro Mathys wrote:
>> On Thu, Dec 3, 2015 at 1:07 PM, Takashi Yamamoto  
>> wrote:
>>> On Mon, Nov 30, 2015 at 12:52 PM, Takashi Yamamoto
>>>  wrote:
 hi,

 we are going to migrate networking-midonet meeting from slack to irc.
 the plan is to have it 7:00 UTC on every Tuesdays.
 if you are interested but have a different time preference,
 please speak up.
 thank you.
>>>
>>> it will be held from the next week.
>>> http://eavesdrop.openstack.org/#Networking_Midonet_meeting
>>
>> I imported the ICS file, but the only event in it is a "Neutron
>> Distributed Virtual Router Meeting"...?
>
> You must have clicked the wrong one. I just downloaded:
> http://eavesdrop.openstack.org/calendars/networking-midonet.ics
> http://eavesdrop.openstack.org/irc-meetings.ical
>
> and Midonet's meeting appears in both.

Right, seems I did...twice.

Thanks,
Sandro

> Cheers,
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

[Igor Kalnitsky]

> shouldn't we switch tests to work with python2.7 instead of python2.6?

Currently we run tests using both py26 and py27, see the

* gate-fuel-web-python27 (openstack infra)
* verify-fuel-web-py27 (fuel infra)

So the question is should we drop py26 jobs? I think yes, we should..
but once CentOS 7 is merged.

I want to notice that, the py26 gate has been removed from openstack
infra in this patch [1] and due to this bug [2].

Honestly, I have no idea why there were no discussions regarding this
=/ it looks like Alex Kislitsky is issue reporter.

[1] https://review.openstack.org/#/c/249242/
[2] https://bugs.launchpad.net/fuel/+bug/1519371

- I

On Thu, Dec 3, 2015 at 12:35 PM, Andreas Jaeger  wrote:
> On 2015-12-03 11:21, Evgeniy L wrote:
>>
>> Hi,
>>
>> During Fuel master migration to CentOS7 there was found a problem that
>> tests
>> get failed [0] for python2.6
>>
>> As far as I can see it's a common practise to drop python2.6
>> compatibility [1],
>> shouldn't we switch tests to work with python2.7 instead of python2.6?
>>
>> It looks like fuelclient will be an exception, because clients continue
>> supporting
>> python2.6 [1]
>
>
> Clients are not supporting python 2.6 with Juno EOL anymore. Fuelclient has
> no 2.6 gates anymore since yesterday.
>
> As mentioned already, we're disabling python 2.6 everywhere.
>
> Patch to remove it from nearly all repos including fuel is at
> https://review.openstack.org/#/c/252448/
>
> Andreas
>
>> Thanks,
>>
>> [0] https://review.openstack.org/#/c/251120/
>> [1]
>>
>> https://wiki.openstack.org/wiki/Python3#Python_2:_Python_2.6_support_dropped.2C_Python_2.7_only
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

[Sergii Golovatiuk]

Hi,


On Thu, Dec 3, 2015 at 11:49 AM, Igor Kalnitsky 
wrote:

> > shouldn't we switch tests to work with python2.7 instead of python2.6?
>
> Currently we run tests using both py26 and py27, see the
>
> * gate-fuel-web-python27 (openstack infra)
> * verify-fuel-web-py27 (fuel infra)
>
> So the question is should we drop py26 jobs? I think yes, we should..
> but once CentOS 7 is merged.
>

In transition phase when we have builds for CentOS 6 and CentOS 7 we should
support both. Once we merge we can remove py26 and clean up manifests to
remove code for CentOS 6


>
> I want to notice that, the py26 gate has been removed from openstack
> infra in this patch [1] and due to this bug [2].
>
> Honestly, I have no idea why there were no discussions regarding this
> =/ it looks like Alex Kislitsky is issue reporter.
>
> [1] https://review.openstack.org/#/c/249242/
> [2] https://bugs.launchpad.net/fuel/+bug/1519371
>
> - I
>
> On Thu, Dec 3, 2015 at 12:35 PM, Andreas Jaeger  wrote:
> > On 2015-12-03 11:21, Evgeniy L wrote:
> >>
> >> Hi,
> >>
> >> During Fuel master migration to CentOS7 there was found a problem that
> >> tests
> >> get failed [0] for python2.6
> >>
> >> As far as I can see it's a common practise to drop python2.6
> >> compatibility [1],
> >> shouldn't we switch tests to work with python2.7 instead of python2.6?
> >>
> >> It looks like fuelclient will be an exception, because clients continue
> >> supporting
> >> python2.6 [1]
> >
> >
> > Clients are not supporting python 2.6 with Juno EOL anymore. Fuelclient
> has
> > no 2.6 gates anymore since yesterday.
> >
> > As mentioned already, we're disabling python 2.6 everywhere.
> >
> > Patch to remove it from nearly all repos including fuel is at
> > https://review.openstack.org/#/c/252448/
> >
> > Andreas
> >
> >> Thanks,
> >>
> >> [0] https://review.openstack.org/#/c/251120/
> >> [1]
> >>
> >>
> https://wiki.openstack.org/wiki/Python3#Python_2:_Python_2.6_support_dropped.2C_Python_2.7_only
> >>
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > --
> >  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> >   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> >GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> >HRB 21284 (AG Nürnberg)
> > GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] get_reality implementation: default values, specified in config files

[Thomas Herve]

On Thu, Dec 3, 2015 at 1:00 PM, Peter Razumovsky 
wrote:

>
> Hello!
>
> During get_reality implementation next problem raised: if I don't specify
> optional not update allowed property (like availabiliy_zone in
> OS::Cinder::Volume), default value will be set for this property in entity.
> This default value defined in configuration of entity's project (i.e. if I
> create OS::Cinder::Volume without az, volume will be created with az =
> default value, which defined in cinder.conf).
>
> So, if I want to get live state of entity, I get az with value, but in
> template no value has been specified for az, and that's mean, stack will be
> repalced during update, which is awful (e.g. if we have huge stack with
> this problem for each resource, updating will be very slow).
>
> What I can do with such properties with default values, defined in config
> options? I don't know any methods to get value from config of other project.
>

I haven't thought too much about it, but I'm sure getting config from other
projects is not the right idea :). One possible solution would be to get
the live state of the entity just after creation, so that we can fill those
default properties right away. What do you think?

-- 
Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Proposal to add Richard Jones to horizon-core

[Zhenguo Niu]

+1 for both

On Thu, Dec 3, 2015 at 2:57 AM, David Lyle  wrote:

> Let's try that again.
>
> I propose adding Richard Jones[1] to horizon-core.
>
> Over the last several cycles Richard has consistently been providing
> great reviews, actively participating in the Horizon community, and
> making meaningful contributions around angularJS and overall project
> stability and health.
>
> Please respond with comments, +1s, or objections within one week.
>
> Thanks,
> David
>
> [1]
> http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s=all
>
> On Wed, Dec 2, 2015 at 11:56 AM, David Lyle  wrote:
> > I propose adding Richard Jones[1] to horizon-core.
> >
> > Over the last several cycles Timur has consistently been providing
> > great reviews, actively participating in the Horizon community, and
> > making meaningful contributions around angularJS and overall project
> > stability and health.
> >
> > Please respond with comments, +1s, or objections within one week.
> >
> > Thanks,
> > David
> >
> > [1]
> http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s=all
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Duncan Thomas]

On 3 December 2015 at 11:14, Li, Xiaoyan  wrote:

> Just to clear the data operations cinder needs to touch plaintext data are:
>  1) Create volume from glance image
>  2) Create glance image from volume
>  3) Retype encrypted volumes. That is to change a volume from unencrypted
> to encrypted, or vice visa.
>
> Backup/Restore doesn't need to decrypt data.
>

Backup / restore doesn't currently decrypt the data. There are some people
commenting that it is not useful for DR work to have a backup that requires
keys from a key service that is itself not backed up, so there may be some
proposal incoming about not encrypting backups, or else giving them their
own key rather than require access to the original volume key during
restore - needing that access also makes things like re-keying the original
volume difficult/impossible.

Again, we have multiple use-cases for encryption, and they are not all
going to be solved by solved by draconian dictates that there shall only be
one way of doing things.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

[Morgan Fainberg]

Chunked Encoding is a bad idea with mod_wsgi in general. While enabling it
like that is fine, you are not guaranteed to get 100% consistent results
simply because the wsgi spec did not/does not support it. Not all versions
of mod_wsgi can enable it.

So, in short, officially keystone does not support chunked encoding. If
radosgw cannot work without it, it is a bug against radosgw or something
RDO itself is doing with radosgw.

--morgan
On Dec 2, 2015 23:00, "Adam Young"  wrote:

> On 12/01/2015 03:50 PM, Fox, Kevin M wrote:
>
>> I just upgraded to keystone liberty for one of my production clouds, and
>> went with apache since eventlet was listed as deprecated. It was pretty
>> easy. Just ran into one issue. RadosGW wouldn't work against it until I
>> added "WSGIChunkedRequest On'" in the config. otherwise, the config as
>> shipped with RDO worked fine. I am running giant radosgw, so future
>> versions may not require that.
>>
>
> Thanks for the note.  Should this be bug?
>
>
>> Thanks,
>> Kevin
>> 
>> From: Sean Dague [s...@dague.net]
>> Sent: Tuesday, December 01, 2015 4:05 AM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [Openstack-operators] [keystone] Removing
>> functionality that was deprecated in Kilo and upcoming deprecated
>> functionality in Mitaka
>>
>> On 12/01/2015 01:57 AM, Steve Martinelli wrote:
>>
>>> Trying to summarize here...
>>>
>>> - There isn't much interest in keeping eventlet around.
>>> - Folks are OK with running keystone in a WSGI server, but feel they are
>>> constrained by Apache.
>>>
>>  From an interop perspective, this concerns me a bit. My understanding is
>> that Apache is specifically needed for Federation. Federation is the
>> norm that we want for environments in the future.
>>
>> I'd hate to go down a path where the reference architecture we put out
>> there doesn't support this. It's going to be all the pain of cells /
>> non-cells that Nova's or nova-net / neutron bifurcation.
>>
>> Whatever the reference architecture is, it should support Federation. A
>> non federation capable keystone should be the exception.
>>
>> - uWSGI could help to support multiple web servers.
>>>
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

[Igor Belikov]

Just want to make a couple of things clear:

1. Openstack-Infra is dropping py26 jobs support, as Andreas said,
so once https://review.openstack.org/#/c/252448/ is merged all openstack 
projects
(including Fuel, of course) won’t have py26 gates.

2. We still run py26 tests on Fuel-CI side and don’t plan to drop them along 
with 
OS-Infra folks, so it’s absolutely possible to have a working py26 CI for the 
duration
of Centos 7 migration (or keep it even after that).

> On 03 Dec 2015, at 13:49, Igor Kalnitsky  wrote:
> 
>> shouldn't we switch tests to work with python2.7 instead of python2.6?
> 
> Currently we run tests using both py26 and py27, see the
> 
> * gate-fuel-web-python27 (openstack infra)
> * verify-fuel-web-py27 (fuel infra)
> 
> So the question is should we drop py26 jobs? I think yes, we should..
> but once CentOS 7 is merged.
> 
> I want to notice that, the py26 gate has been removed from openstack
> infra in this patch [1] and due to this bug [2].
> 
> Honestly, I have no idea why there were no discussions regarding this
> =/ it looks like Alex Kislitsky is issue reporter.
> 
> [1] https://review.openstack.org/#/c/249242/
> [2] https://bugs.launchpad.net/fuel/+bug/1519371
> 
> - I
> 
> On Thu, Dec 3, 2015 at 12:35 PM, Andreas Jaeger  wrote:
>> On 2015-12-03 11:21, Evgeniy L wrote:
>>> 
>>> Hi,
>>> 
>>> During Fuel master migration to CentOS7 there was found a problem that
>>> tests
>>> get failed [0] for python2.6
>>> 
>>> As far as I can see it's a common practise to drop python2.6
>>> compatibility [1],
>>> shouldn't we switch tests to work with python2.7 instead of python2.6?
>>> 
>>> It looks like fuelclient will be an exception, because clients continue
>>> supporting
>>> python2.6 [1]
>> 
>> 
>> Clients are not supporting python 2.6 with Juno EOL anymore. Fuelclient has
>> no 2.6 gates anymore since yesterday.
>> 
>> As mentioned already, we're disabling python 2.6 everywhere.
>> 
>> Patch to remove it from nearly all repos including fuel is at
>> https://review.openstack.org/#/c/252448/
>> 
>> Andreas
>> 
>>> Thanks,
>>> 
>>> [0] https://review.openstack.org/#/c/251120/
>>> [1]
>>> 
>>> https://wiki.openstack.org/wiki/Python3#Python_2:_Python_2.6_support_dropped.2C_Python_2.7_only
>>> 
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>> 
>> 
>> --
>> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>>  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>>   HRB 21284 (AG Nürnberg)
>>GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [FUEL] FFE request for erlang and rabbitmq-server packaged for centos7

[Andrey Sledzinskiy]

Hi everybody,
please, note that we faced next issue [0] during 7.0-MU1 testing and one of
the possible solutions was to upgrade rabbitmq to 3.5.5.
This issue is also present in 8.0 and affects at least one SWARM
destructive test.

[0] https://bugs.launchpad.net/fuel/+bug/1513511

On Thu, Dec 3, 2015 at 1:32 AM, Mike Scherbakov 
wrote:

> Based on time of this request, you seem to be late to the party...
> FF is in action. Formally it was requested before FF, but as I mentioned
> in my email [1], we'd need at least a day for consider exception and assess
> related risks. Filing it couple of hours before FF doesn't give a chance to
> do it.
>
> Any other opinions?
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/080895.html
>
> On Wed, Dec 2, 2015 at 9:52 AM Artem Silenkov 
> wrote:
>
>> Hello!
>>
>> We have got
>> - erlang=18.1 https://review.fuel-infra.org/#/c/12896/
>> - rabbitmq-server=3.5.6 https://review.fuel-infra.org/#/c/12901/
>> packaged for ubuntu trusty in corresponding requests.
>>
>> Those requests are not merged yet but probably would today evening.
>> We need some time to backport it for centos7 in order to keep versions
>> synced.
>>
>> It is not rocket science to package it for centos7 and it could take not
>> more then one working day.
>> This work could be done as soon as ubuntu packages are landed.
>>
>> Regards,
>> Artem Silenkov
>> ---
>> MOS~Packaging
>> mirantis.com
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
> Mike Scherbakov
> #mihgen
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,
Andrey Sledzinskiy
QA Engineer,
Mirantis, Kharkiv
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] [QA] Improving Horizon Integration Tests

[Timur Sufiev]

Hello, folks!

As you probably already know, integration tests were recently made voting
again in Horizon. Next logical step in ensuring Horizon/OpenStack stability
is increasing their coverage. I've reworked initial GoogleDoc version of
tests breakdown (wasn't very popular due to the restricted access) as an
etherpad doc [1].

First I suggest to discuss it inline,
* leaving your '+1' marks (if the test case seems really important to you)
inline -> this will help us to prioritize the further work (in a manner
similar we usually prioritize topics for summit)
* or making comments about some tests being excessive/ unnecessary/ missing

Then, once we consider the tests breakdown mature enough, it will be used
for coordination of work, so developers won't write the same test
simultaneously. Finally, this will be used for reviewing purposes (what
test should I review first? - again, as we already do with release cycle
priorities in Horizon), embedding the bug/ review link into the general
document.

In the meantime, I'm going to write additional docs about writing
integration tests.  There is already a good starting section [2], but it's
more aimed for experienced developers, who need debugging clues. So, that
is another area where your feedback is greatly appreciated. If you ever
have tried writing an integration test in Horizon and went away feeling
confused and lost, please describe what was the greatest source of your
confusion.

[1] https://etherpad.openstack.org/p/horizon-integration-tests
[2] https://review.openstack.org/#/c/238959/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] CentOS7: merge freeze announcement

[Andrew Maksimov]

Hi All,

1. According to CentOS7 Merging plan [1] we assessed list of FF exceptions
and decided to  integrate remaining commits into CentOS7 merge plan. So if
your patch was listed in FF exceptions list please contact Dmitry Teselkin
to add it in our merge plan.
2. We are freezing all git repositories that go into Fuel ISO, the only
exception is patch for bugfix [2] (BVT blocker).
3. Dmitry Teselkin's team will spend the rest of the day rebasing and
cleaning up the rest of the CentOS7 commits to make sure they're all in
mergeable state by the end of the day.

PS.
 This decision was made with Igor Marnat and Nastya Urlapova.

[1] -
http://lists.openstack.org/pipermail/openstack-dev/2015-December/081026.html
[2] - https://bugs.launchpad.net/fuel/+bug/1516993

Regards,
Andrey Maximov,
Fuel Project Manager
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

[Igor Kalnitsky]

> possible to have a working py26 CI for the duration
> of Centos 7 migration (or keep it even after that)

I'd prefer to drop py26 as well as py27 from Fuel CI. We have
openstack gating, that should be more than enough. :)

Fuel CI should be kept for running Fuel UI tests.

On Thu, Dec 3, 2015 at 1:17 PM, Igor Belikov  wrote:
> Just want to make a couple of things clear:
>
> 1. Openstack-Infra is dropping py26 jobs support, as Andreas said,
> so once https://review.openstack.org/#/c/252448/ is merged all openstack 
> projects
> (including Fuel, of course) won’t have py26 gates.
>
> 2. We still run py26 tests on Fuel-CI side and don’t plan to drop them along 
> with
> OS-Infra folks, so it’s absolutely possible to have a working py26 CI for the 
> duration
> of Centos 7 migration (or keep it even after that).
>
>> On 03 Dec 2015, at 13:49, Igor Kalnitsky  wrote:
>>
>>> shouldn't we switch tests to work with python2.7 instead of python2.6?
>>
>> Currently we run tests using both py26 and py27, see the
>>
>> * gate-fuel-web-python27 (openstack infra)
>> * verify-fuel-web-py27 (fuel infra)
>>
>> So the question is should we drop py26 jobs? I think yes, we should..
>> but once CentOS 7 is merged.
>>
>> I want to notice that, the py26 gate has been removed from openstack
>> infra in this patch [1] and due to this bug [2].
>>
>> Honestly, I have no idea why there were no discussions regarding this
>> =/ it looks like Alex Kislitsky is issue reporter.
>>
>> [1] https://review.openstack.org/#/c/249242/
>> [2] https://bugs.launchpad.net/fuel/+bug/1519371
>>
>> - I
>>
>> On Thu, Dec 3, 2015 at 12:35 PM, Andreas Jaeger  wrote:
>>> On 2015-12-03 11:21, Evgeniy L wrote:

 Hi,

 During Fuel master migration to CentOS7 there was found a problem that
 tests
 get failed [0] for python2.6

 As far as I can see it's a common practise to drop python2.6
 compatibility [1],
 shouldn't we switch tests to work with python2.7 instead of python2.6?

 It looks like fuelclient will be an exception, because clients continue
 supporting
 python2.6 [1]
>>>
>>>
>>> Clients are not supporting python 2.6 with Juno EOL anymore. Fuelclient has
>>> no 2.6 gates anymore since yesterday.
>>>
>>> As mentioned already, we're disabling python 2.6 everywhere.
>>>
>>> Patch to remove it from nearly all repos including fuel is at
>>> https://review.openstack.org/#/c/252448/
>>>
>>> Andreas
>>>
 Thanks,

 [0] https://review.openstack.org/#/c/251120/
 [1]

 https://wiki.openstack.org/wiki/Python3#Python_2:_Python_2.6_support_dropped.2C_Python_2.7_only


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>>
>>>
>>> --
>>> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>>>  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>>   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>>>   HRB 21284 (AG Nürnberg)
>>>GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Manila] Tempest scenario tests vs. gate condition

[John Spray]

Hi,

We're working towards getting the devstack/CI parts ready to test the
forthcoming ceph native driver, and have a question: will a driver be
accepted into the tree if it has CI for running the api/ tempest
tests, but not the scenario/ tempest tests?

The context is that because the scenario tests require a client to
mount the shares, that's a bit more work for a new protocol such as
cephfs.  Naturally we intend to do get that done, but would like to
know if it will be a blocker in getting the driver in tree.

Many thanks,
John

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Heat] get_reality implementation: default values, specified in config files

[Peter Razumovsky]

Hello!

During get_reality implementation next problem raised: if I don't specify
optional not update allowed property (like availabiliy_zone in
OS::Cinder::Volume), default value will be set for this property in entity.
This default value defined in configuration of entity's project (i.e. if I
create OS::Cinder::Volume without az, volume will be created with az =
default value, which defined in cinder.conf).

So, if I want to get live state of entity, I get az with value, but in
template no value has been specified for az, and that's mean, stack will be
repalced during update, which is awful (e.g. if we have huge stack with
this problem for each resource, updating will be very slow).

What I can do with such properties with default values, defined in config
options? I don't know any methods to get value from config of other project.

-- 
Best regards,
Peter Razumovsky
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sean Dague]

On 12/02/2015 04:11 PM, Matt Riedemann wrote:
> 
> 
> On 12/2/2015 2:33 PM, Jeremy Stanley wrote:
>> [Apologies for the delayed reply, after more than a week without
>> Internet access it's taking me more than a week to catch up with
>> everything on the mailing lists.]
>>
>> On 2015-11-20 10:21:47 + (+), 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
>>
>> Hopefully by the end of this week, once I finish making sure I'm up
>> to speed on everything that's been said while I was out (anything
>> less would be irresponsible of me).
>>
>>> 2) we do not remove the stable/juno branch
>>
>> As pointed out later in this thread by Alan, it's technically
>> possible to use a tag instead of a branch name (after all, both are
>> just Git refs in the end), and deleting the branch sends a clearer
>> message that there are no new commits coming for stable/juno ever
>> again.
>>
>>> 3) we run periodic grenade jobs for kilo
>>>
>>> I'm not that familiar with the grenade job itself so I'm doing
>>> couple of assumptions, please correct me if I'm wrong.
>>>
>>> 1) We could do this with py27 only
>>
>> Our Grenade jobs are only using Python 2.7 anyway.
>>
>>> 2) We could do this with Ubuntu 1404 only
>>
>> That's the only place we run Grenade now that stable/icehouse is EOL
>> (it was the last branch for which we supported Ubuntu 12.04).
>>
>>> If this is doable would we need anything special for these jobs in
>>> infra point of view or can we just schedule these jobs from the
>>> pool running our other jobs as well?
>>>
>>> If so is there still "quiet" slots on the infra utilization so
>>> that we would not be needing extra resources poured in for this?
>>>
>>> Is there something else we would need to consider in QA/infra
>>> point of view?
>> [...]
>>
>> There are no technical Infra-side blockers to changing how we've
>> done this in the past and instead continuing to run stable/kilo
>> Grenade jobs for some indeterminate period after stable/juno is
>> dead, but it's also not (entirely) up to Infra to decide this. I
>> defer to the Grenade maintainers and QA team to make this
>> determination, and they seem to be pretty heavily against the idea.
>>
>>> Big question ref the 2), what can we do if the grenade starts
>>> failing? In theory we won't be merging anything to kilo that
>>> _should_ cause this and we definitely will not be merging anything
>>> to Juno to fix these issues anymore. How much maintenance those
>>> grenade jobs themselves needs?
>>
>> That's the kicker. As I explained earlier in the thread from which
>> this one split, keeping Juno-era DevStack and Tempest and all the
>> bits on which they rely working in our CI without being able to make
>> any modifications to them is intractable (mainly because of the
>> potential for behavior changes in transitive dependencies not under
>> our control):
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081109.html
>>
>>
>>> So all in all, is the cost doing above too much to get indicator
>>> that tells us when Juno --> Kilo upgrade is not doable anymore?
>>
>> Yes. This is how we arrived at the EOL timeline for stable/juno in
>> the first place: gauging our ability to keep running things like
>> DevStack and Tempest on it. Now is not the time to discuss how we
>> can keep Juno on some semblance of life support (that discussion
>> concluded more than a year ago), it's time for discussing what we
>> can implement in Mitaka so we have more reasonable options for
>> keeping the stable/mitaka branch healthy a year from now.
>>
>>
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> I agree with Jeremy. We might be able to consider something like this
> for stable/liberty, since that's when we started doing
> upper-constraints, which should make the dependency creep more manageable.

However, only if there are enough active QA contributors / reviewers to
keep up on this. Which means anyone interested in this needs to start
engaging and ramping up on Tempest / Devstack / Grenade on master *now*.

People showing up the month before eol, and only focussing on the eoled
elements is not productive.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Murano] How to debug a failed deployment?

[Dmytro Dovbii]

Hi Vahid,

Could you provide your logs anyway? Please publish them to
http://paste.openstack.org/ for example

2015-12-02 23:08 GMT+02:00 Vahid S Hashemian :

> Hello,
>
> I am trying to deploy a hello world HOT package in murano but the
> deployment runs forever and does not stop (does not succeed or fail).
> Stan advised me to modify the config setting below to set a timeout:
>
> # Time for waiting for a response from murano agent during the
> # deployment (integer value)
> agent_timeout = 300
>
> As you see I set the timeout to 300 seconds and restarted murano API, but
> even after 15 minutes my deployment is still going.
> I think my environment is not configured correctly for this to happen.
>
> I have devstack running on a VM, and my murano development is done on a
> separate VM.
> I bring up murano API and UI on my dev VM that successfully connect to my
> devstack VM.
>
> I am able to deploy the HOT yaml using heat without an issue.
> From what I can see it seems that murano is not able to talk to heat,
> because I don't see any stack being created as a result of my deployment.
>
> I have also enabled murano logging in the config file as below:
>
> # (Optional) Name of log file to output to. If no default is set,
> # logging will go to stdout. (string value)
> # Deprecated group/name - [DEFAULT]/logfile
> log_file = /opt/stack/logs/murano.log
>
> But no error  is reported while the deployment is in progress.
>
> Any tips on how to force the timeout, and also on how to resolve the
> deployment problem is appreciated.
>
> Regards,
> --Vahid
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][infra] heat-templates dsvm gate

[Manickam, Kanagaraj]

From: Pavlo Shchelokovskyy [mailto:pshchelokovs...@mirantis.com]
Sent: Thursday, December 03, 2015 1:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [heat][infra] heat-templates dsvm gate

Hi all,

I would like to discuss how to fix and improve $subject, which targets to 
validate the templates present in the repo. Current state is the following:

the gate does merely validate the "parseability" of YAML/JSON templates and 
very basic check on template structure. Any other real checks as would be 
actually performed in real deployment are not executed because:
- only Heat and Keystone are installed on this gate;
- for resources for any other service service-based resource exposure kicks in 
early, producing "Service {name} does not have required endpoint in service 
catalog for the resource type {resource}" errors,


[Manickam, Kanagaraj]  ‘Service not available’ error could be handled once the 
ignore_erros options for validate template blueprint [3] is completed. Below 
command line option would help for it

heat template-validate –ignore-errors 990002 –f  

This helps to ignore the given errors and continue the validation of templates.



- which are ignored by the script running the validation (to not block the 
gate, bug 1492942)


[Manickam, Kanagaraj]  once blueprint [3] is implemented, this tool could be 
updated as mentioned above, which gives more validation control over existing 
logic.


Thus for example the check that properties of the resources are confirming to 
the schema of a particular resource is not performed, and we might be having 
faulty templates (e.g. with typos) in the repo. I hoped to fix this with 
mapping all resources to OS::Heat::None, but it turned out this would not be 
really helpful, as the None-resource has any property and attribute.

[Manickam, Kanagaraj] For unsupported resource types (not part of 
global-requirments.txt), we are currently masking with None resource.  for 
other resource types which does not have keystone endpoint in the gate, I think 
we ignore it in the tool. [4]

So I propose that heat-templates repo can configure its environment itself by 
using the "post_test_hook" facilities provided and supported by gate setup. We 
need that to better control the environment the tests are being run in. In 
particular, I'd like to add some fake service endpoints to Keystone, so 
service-based exposure is out of the validation way.

Thereby I ask Heat and Infra team to take a look at these two patches:
- [0] in heat-templates and
- [1] in project-config (depends on [0]).

Though these are simply moving couple of bash lines from project-config to 
heat-templates, we want to be sure they work so that we do not break the gate. 
Unfortunately I can not prove my further patches [2] are working as it seems 
Depend-On does not work for referencing project-config changes.

[0] https://review.openstack.org/#/c/252515/
[1] https://review.openstack.org/#/c/252523/
[2] 
https://review.openstack.org/#/q/status:open+project:openstack/heat-templates+branch:master+topic:bug/1492942,n,z
[3]  
https://blueprints.launchpad.net/heat/+spec/heat-template-validate-improvements
[4] 
https://github.com/openstack/heat-templates/blob/master/tools/validate-templates#L41

Best regards,
--
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

[Ryota Mibu]

Hi Ifat,


> > One approach we can take, is that you configure aodh to pass each row
> > event (e.g. each VM downed) wrapped in alarm notification to vitrage,
> > then do some operation (e.g. deducing, aggregating) and store
> > resource- level alarm without any alarm_actions, so that users can see
> > the alarms in horizon view. This may not require alarm evaluation, so
> > we can forget the problem I raised (cache refresh interval).
> 
> Let me see if I got this right: are you suggesting that we create on-the-fly 
> alarm definitions with no alarm_actions,
> for every deduced alarm that we want to raise? And this will spare us the 
> extra alarm evaluation in AODH?

Yes. But, please note that could be the first step. The next step would be make 
vitrage to send out alarm event to ceilometer/aodh the pre-configured event 
alarm will recognize the alarm and fire the alarm notification to another 
service or an end user. Eventually, we should have relevant alarm type and 
evaluator to proxy evaluation in vitrage, I think.


> My next question is how exactly we should create these resource-level alarms. 
> Can we create an alarm definition with
> no rule, no actions, and initial state set to "alarm"? (I'm not sure it can 
> be done in the current AODH API)

You can. This is not proper way of using aodh though. But, this is easy to 
create an alarm entry to show it in horizon.


> Another question is our need to get alarms from other sources, like Nagios, 
> zabbix, ganglia, etc. We thought that
> Vitrage would query these Alarms from each source directly, and then create 
> alarms in AODH in the same way as our
> deduced alarms: for example create nagios_ovs_vswitchd alarm if nagios 
> check_ovs_vswitchd test failed.
> An alternative could be to integrate nagios directly with AODH.
> What do you think?

Hmm, I don't have clear view on this. If the source can includes OpenStack IDs 
and can be generate relevant meter/sample, it should be useful to integrate 
with ceilometer. But if you want to do some operations (like correlation), then 
it is reasonable to integrate with vitrage.


> > BTW, is it useful to have on-the-fly evaluation of combination alarm
> > with event alarms for alarm aggregation or other cases?
> 
> I'm not sure I understand. Can you give a detailed example?

OK. The 'combination' type alarm enables you to aggregate multiple alarm to one 
alarm. This can be used when you want to receive alarm when the both of 
physical NIC ports are downed to recognize logical connection unavailability if 
the ports are teamed for redundancy. Now, the combination alarms are evaluated 
periodically that means you can receive combination alarm not on-the-fly while 
you are using event alarms as source of combination alarm though.

> > Horizon view is the different topic. Maybe we can reduce the number of
> > alarms listed in user view by creating raw alarms in admin space that
> > is not visible from end user, or using relevant severity or tag so
> > that user can filter out uninterested alarms.
> 
> Referring to this[1] blueprint, do you have specific concerns regarding the 
> usability/performance of Horizon view
> when there are many alarms?
> I think that your ideas make sense, and we can implement them if there is a 
> need.

Sorry, I'm not familiar with horizon these days... But, if you need change in 
aodh side, I can help you.


> In addition, in Vitrage we plan to handle alarm aggregation by creating 
> aggregation rule templates, for example based
> on the RCA information.
> The user will be able to see only the root cause alarms, and then drill down 
> to all specific alarms. But I doubt if
> this will be done for Mitaka.

I think 'the RCA information' means information for RCA. I mean vitrage will 
use the resource topologies or relationship in aggregation, rather than result 
of RCA. Am I right?


Best regards,
Ryota

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Thierry Carrez]

Armando M. wrote:
> On 2 December 2015 at 01:16, Thierry Carrez  > wrote:
>> Armando M. wrote:
>> >> One solution is, like you mentioned, to make some (or all) of them
>> >> full-fledged project teams. Be aware that this means the TC would 
>> judge
>> >> those new project teams individually and might reject them if we feel
>> >> the requirements are not met. We might want to clarify what happens
>> >> then.
>> >
>> > That's a good point. Do we have existing examples of this or would we 
>> be
>> > sailing in uncharted waters?
>> 
>> It's been pretty common that we rejected/delayed applications for
>> projects where we felt they needed more alignment. In such cases, the
>> immediate result for those projects if they are out of the Neutron
>> "stadium" is that they would fall from the list of official projects.
>> Again, I'm fine with that outcome, but I want to set expectations
>> clearly :)
> 
> Understood. It sounds to me that the outcome would be that those
> projects (that may end up being rejected) would show nowhere on [1], but
> would still be hosted and can rely on the support and services of the
> OpenStack community, right?
> 
> [1] http://governance.openstack.org/reference/projects/

Yes they would still be hosted on OpenStack development infrastructure.
Contributions would no longer count toward ATC status, so people who
only contribute to those projects would no longer be able to vote in the
Technical Committee election. They would not have "official" design
summit space either -- they can still camp in the hallway though :)

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Dropping python2.6 compatibility

[Evgeniy L]

Hi,

During Fuel master migration to CentOS7 there was found a problem that tests
get failed [0] for python2.6

As far as I can see it's a common practise to drop python2.6 compatibility
[1],
shouldn't we switch tests to work with python2.7 instead of python2.6?

It looks like fuelclient will be an exception, because clients continue
supporting
python2.6 [1]

Thanks,

[0] https://review.openstack.org/#/c/251120/
[1]
https://wiki.openstack.org/wiki/Python3#Python_2:_Python_2.6_support_dropped.2C_Python_2.7_only
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

[P. Ramanjaneya Reddy]

>From paste logs..

2015-11-13 18:07:00.926 INFO neutron.manager [-] Loading Plugin:
*networking_sfc.services.sfc.plugin.SFCPlugin*
2015-11-13 18:07:00.974 INFO
n*etworking_sfc.services.sfc.driver_manager* [-] Configured portchain
driver names: ['dummy']
2015-11-13 18:07:00.975 ERROR stevedore.extension [-] Could not load
'dummy': No module named portchain.drivers.dummy



networking_sfc.services.sfc.plugin.SFCPlugin

==> it should be networking_sfc.services.sfc.plugin.SfcPlugin


n*etworking_sfc.services.sfc.driver_manager ==> wrong path specified.*



*It seems driver changes are not been latest and also check serivce
plugin path.*

*Before run devstack, please merge all pacthes(cli/driver..) changes
on master networking-sfc*

Thanks & Regards,

Ramanji.


On Tue, Nov 17, 2015 at 12:03 AM, Duarte Cardoso, Igor <
igor.duarte.card...@intel.com> wrote:

> Hi networking-sfc folks,
>
>
>
> I can’t seem to be able to deploy the current networking-sfc using
> DevStack and my hint is that the latest review stack is dependent on
> previous patches that have not been updated/rebased yet ([1] and [2]) – and
> are depending on outdated patches.
>
>
>
> In [3] you can see the output of q-svc after a clean DevStack installation
> (based on master) with the local.conf specified in [4].
>
> I have pointed /opt/stack/networking-sfc to the last patch in the
> networking-sfc review stack, [5].
>
>
>
> Please advise on how to proceed in order to get networking-sfc to work.
>
>
>
> [1] https://review.openstack.org/#/c/227285
>
> [2] https://review.openstack.org/#/c/227100
>
> [3] http://paste.openstack.org/show/479020/
>
> [4] http://paste.openstack.org/show/479021/
>
> [5] https://review.openstack.org/#/c/238428/
>
>
>
> Best regards,
>
>
>
> [image: intel]
>
>
>
> *Igor Duarte Cardoso*
>
> Software Engineer
>
> +353 61 777 858
>
> SIE1-2-170
>
> Intel Shannon Ltd.
>
> Dromore House, East Park
>
> Shannon, Co. Clare
>
> IRELAND
>
>
>
> --
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). Any review or distribution by others
> is strictly prohibited. If you are not the intended recipient, please
> contact the sender and delete all copies.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Li, Xiaoyan]

Thank you, Ben. I agree with you, and just to clear the cinder operations which 
needs to decrypt volumes in following.

On Dec 3, 2015 05:01, Ben Swartzlander wrote:
> On 11/30/2015 09:04 AM, Coffman, Joel M. wrote:
>> 
>> 
>> On 11/25/15, 11:33 AM, "Ben Swartzlander" > > wrote:
>> 
>> On 11/24/2015 03:27 PM, Nathan Reller wrote:
>> the cinder admin and the nova admin are ALWAYS the same
>> people
>> 
>> 
>> There is interest in hybrid clouds where the Nova and Cinder
>> services are managed by different providers. The customer would
>> place higher trust in Nova because you must trust the compute
>> service, and the customer would place less trust in Cinder. One
>> way to achieve this would be to have all encryption done by
>> Nova. Cinder would simply see encrypted data and provide a good
>> cheap storage solution for data.
>> 
>> Consider a company with sensitive data. They can run the
>> compute nodes themselves and offload Cinder service to some
>> third-party service. This way they are the only ones who can
>> manage the machines that see the plaintext.
>> 
>> If you have that level of paranoia, I suggest running LUKS inside
>> the guest VM and not relying on OpenStack to handle your
>> encryption. Then you don't have to worry about whether nova is
>> sharing your keys with cinder because even nova won't have them.
>> That approach isn't actually more secure - anyone with root access to
>> the compute host can dump the VM's memory to extract the encryption
> keys.
> 
> I agree, however in the above case there was implied trust in the compute
> infrastructure -- at least more so than in the storage infrastructure. If you
> don't trust your hypervisor admin to not read your VM memory and steal
> encryption keys, then relying on your hypervisor admin (or nova) to
> perform the encryption is kind of silly.
> In every case, the hypervisor admin can see the plaintext and the keys.
> 
> The suggestion was a way to achieve the goal of doing encryption
> WITHOUT trusting the storage admin and WITHOUT CHANGING ANY CODE.
> I assert that any attempt to implement encryption at the nova level and not
> sharing keys with cinder will break the existing model. There are 2
> solutions I can see:
> 1) don't break it (see above)
> 2) you break it, you fix it (nova takes over responsibility for all the
> operations cinder currently performs that involve plaintext).
> 
>> Trying to design a system where we expect nova to do data
>> encryption but not cinder will not work in the long run. The
>> eventual result will be that nova will have to take on most of the
>> functionality of cinder and we'll be back to the nova-volume days.
>> Could you explain further what you mean by "nova will have to take on
>> most of the functionality of cinder"? In the current design, Nova is
>> still passing data blocks to Cinder for storage - they're just
>> encrypted instead of plaintext. That doesn't seem to subvert the
>> functionality of Cinder or reimplement it.
> 
> I think Duncan covered it, but the data operations cinder currently
> performs, which require Cinder to touch plaintext data are:
> 1) Create volume from glance image
> 2) Create glance image from volume
> 3) Backup volume
> 4) Restore volume

Just to clear the data operations cinder needs to touch plaintext data are:
 1) Create volume from glance image
 2) Create glance image from volume
 3) Retype encrypted volumes. That is to change a volume from unencrypted to 
encrypted, or vice visa.

Backup/Restore doesn't need to decrypt data.

> 
> I'm not claiming that we can't redefine or alter the above operations to
> deal with encryption, but someone needs to propose how they should work
> differently or work at all when the volume isn't storing plaintext data.
> 
>> Also in case it's not obvious, if you use different providers for
>> compute and storage, your performance is going to be absolutely
>> terrible.
>> The general idea is probably separation of duties, which contradicts
>> the original statement that "the cinder admin and the nova admin are
>> ALWAYS the same people." Is there an operational reason that these
>> admins must be the same person, or is that just typical?
> 
> My assertion was to try to combat confusion about the roles of the "storage
> admin". Many people who don't deal with storage all the time tend to
> forgot that cinder is a management tool that's separate from actual
> hardware which stores bits. It's common to have a "storage admin"
> who is responsible for configuration and management of storage hardware
> and software but to have Cinder run by an "openstack admin" who is a
> customer/client of the storage admin.
> 
> My belief is that it's FAR more common for cinder to be installed and run
> by the same guy (or group) who installs/runs 

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

[Li, Xiaoyan]

From: Coffman, Joel M. [mailto:joel.coff...@jhuapl.edu]
Sent: Thursday, December 3, 2015 2:07 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick


From: "duncan.tho...@gmail.com" 
>
Reply-To: 
"openstack-dev@lists.openstack.org" 
>
Date: Monday, November 30, 2015 at 9:13 AM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

On 30 November 2015 at 16:04, Coffman, Joel M. 
> wrote:
On 11/25/15, 11:33 AM, "Ben Swartzlander" 
> wrote:

On 11/24/2015 03:27 PM, Nathan Reller wrote:
Trying to design a system where we expect nova to do data encryption but
not cinder will not work in the long run. The eventual result will be
that nova will have to take on most of the functionality of cinder and
we'll be back to the nova-volume days.
Could you explain further what you mean by "nova will have to take on most of 
the functionality of cinder"? In the current design, Nova is still passing data 
blocks to Cinder for storage – they're just encrypted instead of plaintext. 
That doesn't seem to subvert the functionality of Cinder or reimplement it.

The functionality of cinder is more than blindly storing blocks - in particular 
it has create-from/upload-to image, backup, and retype, all of which do some 
degree of manipulation of the data and/or volume encryption metadata.
From a security perspective, it is advantageous for users to be able to upload 
an encrypted image, copy that image to a volume, and boot from that volume 
without decrypting the image until it is booted.

This is not efficient, and user friendly.

We are suffering from somewhat incompatible requirements with encryption 
between those who want fully functional cinder and encryption on disk (the 
common case I think), and those who have enhanced security requirements.
The original design supports this distinction: there is a "control-location" 
parameter that indicates where encryption is to be performed (see 
http://docs.openstack.org/user-guide-admin/dashboard_manage_volumes.html).

It seems that it differentiates from Nova/Cinder and back-end block storage.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][ceilometer]Meter for security group

[492445...@qq.com]

Hi everyone:

I want to meter security group.
And I want to get those metric for ceilometer.
1. totle packets for vm/container through security group.
2. drop packets for vm/container through security group.
 And I want get the from iptables.

Could somebody give me some comments.
Thanks very much.



492445...@qq.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Bug deputy process

[Rossella Sblendido]

Hi Armando,

On 12/02/2015 07:49 PM, Armando M. wrote:

Hi neutrinos,

It's been a couple of months that the Bug deputy process has been in
place [1,2]. Since the beginning of Mitaka we have collected the
following statistics (for neutron and neutronclient):

Total bug reports: 373

  * Fix committed: 144
  * Unassigned: 73
  o New: 17
  o Incomplete: 20
  o Confirmed: 27
  o Triaged: 6


At first, it is clear that we do not fix issues nearly as fast as they
come in, but at least we managed to keep the number of
unassigned/unvetted bugs relatively small, so kudos to you all who
participated in this experiment. I don't have data based on older
releases, so I can't see whether we've improved or worsened, and I'd
like to ask for feedback from the people who played with this first
hand, especially on the amount of time that has taken them to do deputy
duty for their assigned week.


my feedback is very positive. I think the new process is good, thanks 
for setting it up! During my week I was looking at newly filed bugs 
every day and triaged them. This took around 1 or 2 hours a day. But it 
was a quiet week...so the load was not super high.


cheers,

Rossella



  * ihrachys
  * regXboi
  * markmcclain
  * mestery
  * mangelajo
  * garyk
  * rossella_s
  * dougwig

Many thanks,
Armando

[1] https://wiki.openstack.org/wiki/Network/Meetings#Bug_deputy
[2]
http://docs.openstack.org/developer/neutron/policies/bugs.html#neutron-bug-deputy



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0

[Oleg Gelbukh]

Roman,

Thank you. This is great research.

Could we have a conversation to discuss this? I'm especially interested in
idempotency problems of the fuel-library modules and the common way to
provide serialised data to the deployment.

--
Best regards,
Oleg Gelbukh
Mirantis Inc


On Tue, Dec 1, 2015 at 6:38 PM, Roman Sokolkov 
wrote:

> Hello, folks.
>
> We need any kind of CM for Fuel 7.0. Otherwise new project with 800+ nodes
> will be near impossible to support. Customer always wants to change
> something.
>
> In our opinion, there are two major approaches for CM:
>
> #1 Independent CM (Puppet master, Chef, Ansible, whatever)
> #2 Fuel-based CM
>
> Solution for #2
> --
>
> Fuel has all info about configuration. So we've tried to
> unlock "Settings" [0] and push "deploy" button.
>
> Major findings:
>
> * Task idem-potency. Looks like most of the tasks are idempotent.
> We've skipped 3 tasks on controller and were able to get NO downtime
> for Horizon and "nova list". BTW deeper QA required.
>
> * Standard changes. Operator can change parameters via WebUI, CLI or API.
> For example, i was able to deploy Sahara. Unfortunately there is not
> foolproof.
> I mean some changes can lead to broken cloud...
>
> * Non-standard changes. Any other changes can be done with plugins.
> We can modify plugin tasks and scripts (all except UI flags). And then just
> do "--update" + "--sync". BTW, we can change UI for particular env via API
> by modifying "clusters/X/attributes".
>
> Conclusion
> --
>
> - This works (We have service under cron that runs tasks) [1]
> - NOT ready for production (in current state)
> - This requires much deeper testing
>
>
> I want to hear thoughts about approach above?
> What is the current status/plans for CM? I saw this discussion [2]
>
> References
> --
>
> [0]
> https://github.com/rsokolkov/fuel-web/commit/366daaa2eb874c8e54c2d39be475223937cd317d
> [1]
> https://docs.google.com/presentation/d/12kkh1hu4ZrY9S6XXsY_HWaesFwESfxbl5czUwde8isM/edit#slide=id.p
> [2] https://etherpad.openstack.org/p/lcm-use-cases
>
> --
> Roman Sokolkov,
> Deployment Engineer,
> Mirantis, Inc.
> Skype rsokolkov,
> rsokol...@mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] Using docker container to run COE daemons

[Michal Rostecki]

On 11/28/2015 01:01 AM, Egor Guz wrote:

Have you tested slave/agent inside container? I was under impression that it 
doesn’t work until somebody from Kolla team pointed me to the 
https://hub.docker.com/u/mesoscloud/.
Also I belive you can try your approach without any changes at existing 
template, because it’s just start services and adding configurations. So you 
can build image which has  the same services as Docker containers with
volumes mapped to config folders at host.



Hi Egor,

Yes, I can confirm that containerized Mesos works fine and it becomes 
the often recommended way of deploying Mesos. For now, we at 
Kolla-mesos, are using images from mesoscloud @ hub.docker that you linked.


But if you're planning to make some dockerfiles maintained by Magnum 
community, I'm +1 for it and I think that Kolla-mesos could consider 
switching to them and helping in development and/or maintenance.


Cheers,
Michal

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] Mesos Conductor

[Bharath Thiruveedula]

Hi Jay,

Sorry I just saw your mail. I have pushed the patches for json-file support
for client[1] and backend[2].  If the team accepts the support the json
file support for container-create, I can link the client patch to your
blueprint and you can add patches for other features you mentioned, if you
don't mind. And we can discuss about the backend support patch in the
meeting.

[1]https://review.openstack.org/#/c/252775/
[2]https://review.openstack.org/#/c/252789/
Regards
Bharath T

On Thu, Dec 3, 2015 at 9:38 AM, Jay Lau  wrote:

> Hi Bharath,
>
> Actually I have already filed a bp here:
> https://blueprints.launchpad.net/magnum/+spec/unify-coe-api ,sorry for
> the late notify.
>
> We may need some discussion for this in next Week's meeting. I will attend
> next week's meeting and we can have discussion with team then, hope it is
> OK. ;-)
>
> Thanks!
>
> On Wed, Dec 2, 2015 at 8:48 AM, bharath thiruveedula <
> bharath_...@hotmail.com> wrote:
>
>> Hi,
>>
>> Sorry I was off for some days because of health issues.
>>
>> So I think the work items for this BP[1] are:
>>
>> 1)Add support to accept json file in container-create command
>> 2)Handle JSON input in docker_conductor
>> 3)Implement mesos conductor for container create,delete and list.
>>
>> Correct me if I am wrong. And let me know the process for implementing BP
>> in magnum. I think we need approval for this BP and then implementation?
>>
>>  [1]https://blueprints.launchpad.net/magnum/+spec/mesos-conductor
>>
>> Regards
>> Bharath T(tbh)
>>
>>
>> --
>> Date: Fri, 20 Nov 2015 07:44:49 +0800
>> From: jay.lau@gmail.com
>> To: openstack-dev@lists.openstack.org
>>
>> Subject: Re: [openstack-dev] [magnum] Mesos Conductor
>>
>> It's great that we come to some agreement on unifying the client call ;-)
>>
>> As i proposed in previous thread, I think that "magnum app-create" may be
>> better than "magnum create", I want to use "magnum app-create" to
>> distinguish with "magnum container-create". The "app-create" may also not a
>> good name as the k8s also have concept of service which is actually not an
>> app. comments?
>>
>> I think we can file a bp for this and it will be a great feature in M
>> release!
>>
>> On Fri, Nov 20, 2015 at 4:59 AM, Egor Guz  wrote:
>>
>> +1, I found that 'kubectl create -f FILENAME’ (
>> https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_create.md)
>> works very well for different type of objects and I think we should try to
>> use it.
>>
>> but I think we should support two use-cases
>>  - 'magnum container-create’, with simple list of options which work for
>> Swarm/Mesos/Kub. it will be good option for users who just wants to try
>> containers.
>>  - 'magnum create ’, with file which has Swarm/Mesos/Kub specific payload.
>>
>> —
>> Egor
>>
>> From: Adrian Otto  adrian.o...@rackspace.com>>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org> openstack-dev@lists.openstack.org>>
>> Date: Thursday, November 19, 2015 at 10:36
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org> openstack-dev@lists.openstack.org>>
>> Subject: Re: [openstack-dev] [magnum] Mesos Conductor
>>
>> I’m open to allowing magnum to pass a blob of data (such as a lump of
>> JSON or YAML) to the Bay's native API. That approach strikes a balance
>> that’s appropriate.
>>
>> Adrian
>>
>> On Nov 19, 2015, at 10:01 AM, bharath thiruveedula <
>> bharath_...@hotmail.com> wrote:
>>
>> Hi,
>>
>> At the present scenario, we can have mesos conductor with existing
>> attributes[1]. Or we can add  extra options like 'portMappings',
>> 'instances', 'uris'[2]. And the other options is to take json file as input
>> to 'magnum container-create' and dispatch it to corresponding conductor.
>> And the conductor will handle the json input. Let me know your opinions.
>>
>>
>> Regards
>> Bharath T
>>
>>
>>
>>
>> [1]https://goo.gl/f46b4H
>> [2]https://mesosphere.github.io/marathon/docs/application-basics.html
>> 
>> To: openstack-dev@lists.openstack.org> openstack-dev@lists.openstack.org>
>> From: wk...@cn.ibm.com
>> Date: Thu, 19 Nov 2015 10:47:33 +0800
>> Subject: Re: [openstack-dev] [magnum] Mesos Conductor
>>
>> @bharath,
>>
>> 1) actually, if you mean use container-create(delete) to do on mesos bay
>> for apps. I am not sure how different the interface between docker
>> interface and mesos interface. One point that when you introduce that
>> feature, please not make docker container interface more complicated than
>> now. I worried that because it would confuse end-users a lot than the
>> unified benefits. (maybe as optional parameter to pass one json file to
>> create containers in mesos)
>>
>> 2) For the unified interface, I 

Re: [openstack-dev] [midonet] What repos to migrate to OpenStack infrastructure

[Takashi Yamamoto]

hi,

On Wed, Dec 2, 2015 at 4:05 PM, Sandro Mathys  wrote:
> Hi all,
>
> Trying to prepare moving our repos to the OpenStack infrastructure, I
> got reminded just how many repos we have in our GitHub organization
> [1] - and how many of those seem to be deprecated or tangential.
>
> Now, do we still want to migrate them? Pretty sure the answer is "no"
> for the deprecated ones but I wonder about the tangential ones. Well,
> to be honest, I also wonder which are actually deprecated/tangential
> and which are considered "important".
>
> First of all, I think repos that are not set up on GerritHub, don't
> need to be migrated. Partially because they don't seem important
> enough, and partially because migration would force Gerrit upon them
> (i.e. Gerrit is the main repo for a project in OpenStack, the others
> are just mirrors). But the list of midonet repos on GerritHub [2] is
> still very long.
>
> Of those, I figure these are deprecated and shouldn't be migrated:
> * arrakis
> * midostack
>
> Also, I'm only looking at what repos to migrate under the "midonet"
> umbrella. These repos should probably be migrated under a different
> umbrella, if at all:
> * ansible-* (-> ansible-openstack)
> * puppet-* (-> puppet-openstack)
> * zephyr (-> zephyr)
>
> Furthermore, these seem to be forks that should (no longer) see
> downstream commits, right?
> * python-midonetclient

this is a mirror of a part of midonet tree.

i tend to think it should be its own project.
but it's probably a separate discussion.

> * python-neutronclient

this seems like a fork to add a few cli sub commands.
if it is, it should be re-implemented in networking-midonet repo.
joe, do you have any idea?

>
> Last but not least, we have repos that have only a single contributor
> and should probably not be part of the midonet organization anyway -
> and repos with (virtually) no commits:
> * bees
> * docker-openvpn-client
> * docker-zk-web
> * orizuru
> * toscana
> * ubuntu-integration
>
> Alright, this leaves us with 11 repos - much better number!
>
> These, I think we should migrate:
> * mdts
> * midonet
> * midonet-docs
> * midonet-sandbox
>
> These, we could migrate but they are low priority and might actually
> go away so let's defer:
> * midonethomepage
> * planet-midonet
>
> However, I have no idea about these - are they still needed? Do they
> belong under the midonet umbrella?
> * jmx_exporter
> * midonet-charms
> * midonet-dockerfile
> * tempest-add

this is additional tempest scenarios.  no need to move.

> * zktimemachine
>
> Please share your thoughts - did I exclude some that should be
> included in the migration? Should some be included that are not
> currently configured on GerritHub? And what about those 5 repos in the
> last list?
>
> Note, that all repos we want to migrate under the midonet umbrella
> probably need to have a "midonet-" in front, so it would need to be
> added to those who don't have it. (Well, planet-midonet will become
> midonet-planet and midonethomepage gain a dash).
>
> Thanks,
> Sandro
>
> PS. the "when" and "how" will be discussed later - let's focus on the
> "what" in this thread, please.
>
> [1] https://github.com/midonet
> [2] https://review.gerrithub.io/#/admin/projects/?filter=midonet%252F
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

[Andreas Jaeger]

On 2015-12-03 11:21, Evgeniy L wrote:

Hi,

During Fuel master migration to CentOS7 there was found a problem that tests
get failed [0] for python2.6

As far as I can see it's a common practise to drop python2.6
compatibility [1],
shouldn't we switch tests to work with python2.7 instead of python2.6?

It looks like fuelclient will be an exception, because clients continue
supporting
python2.6 [1]


Clients are not supporting python 2.6 with Juno EOL anymore. Fuelclient 
has no 2.6 gates anymore since yesterday.


As mentioned already, we're disabling python 2.6 everywhere.

Patch to remove it from nearly all repos including fuel is at 
https://review.openstack.org/#/c/252448/


Andreas


Thanks,

[0] https://review.openstack.org/#/c/251120/
[1]
https://wiki.openstack.org/wiki/Python3#Python_2:_Python_2.6_support_dropped.2C_Python_2.7_only


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][midonet] networking-midonet weekly irc meeting

[Sandro Mathys]

On Thu, Dec 3, 2015 at 1:07 PM, Takashi Yamamoto  wrote:
> On Mon, Nov 30, 2015 at 12:52 PM, Takashi Yamamoto
>  wrote:
>> hi,
>>
>> we are going to migrate networking-midonet meeting from slack to irc.
>> the plan is to have it 7:00 UTC on every Tuesdays.
>> if you are interested but have a different time preference,
>> please speak up.
>> thank you.
>
> it will be held from the next week.
> http://eavesdrop.openstack.org/#Networking_Midonet_meeting

I imported the ICS file, but the only event in it is a "Neutron
Distributed Virtual Router Meeting"...?

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

[Julien Danjou]

On Thu, Dec 03 2015, AFEK, Ifat (Ifat) wrote:

> Another question is our need to get alarms from other sources, like 
> Nagios, zabbix, ganglia, etc. We thought that Vitrage would query these 
> Alarms from each source directly, and then create alarms in AODH in the 
> same way as our deduced alarms: for example create nagios_ovs_vswitchd 
> alarm if nagios check_ovs_vswitchd test failed. 
> An alternative could be to integrate nagios directly with AODH. 
> What do you think?

I think I'd like to be able to answer this question, but I kind of lack
the bigger picture of what you need these alarms for, and what you would
like them to do with?

I think we don't have everything right now in Ceilometer/Gnocchi/Aodh to
replace something like Nagios _but_ we have a base framework that should
be more powerful and way more scalable. That could be leveraged to built
something better that Nagios, while staying compatible.

What Nagios does is polling, storing state, and doing action based on
that state. Which is more or less what Ceilometer does (polling),
Gnocchi does (storing things) and Aodh does (triggering action based on
the state). Obviously there's more to that (e.g. dependencies) that are
not handled currently, and that could be added later – maybe in some
parts of the current telemetry projects, or maybe in Vitrage.

So how fitting such tools (Nagios, Zabbix, whatever) in those projects
is an interesting problem. But I'm not clear on the first steps and
how/why you want to leverage alarms first. :)

-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Murano] How to debug a failed deployment?

[Ekaterina Chernova]

Hi!

Murano agent doesn't involved in the deployment of hot packages, that's why
this setting doesn't help.

Please attach agent logs and heat logs also (check if heat stack is created
or not).

Regards, Kate.


Regards,
Kate.


On Thu, Dec 3, 2015 at 11:44 AM, Dmytro Dovbii  wrote:

> Hi Vahid,
>
> Could you provide your logs anyway? Please publish them to
> http://paste.openstack.org/ for example
>
> 2015-12-02 23:08 GMT+02:00 Vahid S Hashemian :
>
>> Hello,
>>
>> I am trying to deploy a hello world HOT package in murano but the
>> deployment runs forever and does not stop (does not succeed or fail).
>> Stan advised me to modify the config setting below to set a timeout:
>>
>> # Time for waiting for a response from murano agent during the
>> # deployment (integer value)
>> agent_timeout = 300
>>
>> As you see I set the timeout to 300 seconds and restarted murano API, but
>> even after 15 minutes my deployment is still going.
>> I think my environment is not configured correctly for this to happen.
>>
>> I have devstack running on a VM, and my murano development is done on a
>> separate VM.
>> I bring up murano API and UI on my dev VM that successfully connect to my
>> devstack VM.
>>
>> I am able to deploy the HOT yaml using heat without an issue.
>> From what I can see it seems that murano is not able to talk to heat,
>> because I don't see any stack being created as a result of my deployment.
>>
>> I have also enabled murano logging in the config file as below:
>>
>> # (Optional) Name of log file to output to. If no default is set,
>> # logging will go to stdout. (string value)
>> # Deprecated group/name - [DEFAULT]/logfile
>> log_file = /opt/stack/logs/murano.log
>>
>> But no error  is reported while the deployment is in progress.
>>
>> Any tips on how to force the timeout, and also on how to resolve the
>> deployment problem is appreciated.
>>
>> Regards,
>> --Vahid
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][midonet] networking-midonet weekly irc meeting

[Thierry Carrez]

Sandro Mathys wrote:
> On Thu, Dec 3, 2015 at 1:07 PM, Takashi Yamamoto  
> wrote:
>> On Mon, Nov 30, 2015 at 12:52 PM, Takashi Yamamoto
>>  wrote:
>>> hi,
>>>
>>> we are going to migrate networking-midonet meeting from slack to irc.
>>> the plan is to have it 7:00 UTC on every Tuesdays.
>>> if you are interested but have a different time preference,
>>> please speak up.
>>> thank you.
>>
>> it will be held from the next week.
>> http://eavesdrop.openstack.org/#Networking_Midonet_meeting
> 
> I imported the ICS file, but the only event in it is a "Neutron
> Distributed Virtual Router Meeting"...?

You must have clicked the wrong one. I just downloaded:
http://eavesdrop.openstack.org/calendars/networking-midonet.ics
http://eavesdrop.openstack.org/irc-meetings.ical

and Midonet's meeting appears in both.
Cheers,

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] jsonschema for scheduler hints

[Alex Xu]

2015-12-02 23:12 GMT+08:00 Sylvain Bauza :

>
>
> Le 02/12/2015 15:23, Sean Dague a écrit :
>
>> We have previously agreed that scheduler hints in Nova are an open ended
>> thing. It's expected for sites to have additional scheduler filters
>> which expose new hints. The way we handle that with our strict
>> jsonschema is that we allow additional properties -
>>
>> https://github.com/openstack/nova/blob/1734ce7101982dd95f8fab1ab4815bd258a33744/nova/api/openstack/compute/schemas/scheduler_hints.py#L65
>>
>> This means that if you specify some garbage hint, you don't get feedback
>> that it was garbage in your environment. That lost a couple of days
>> building multinode tests in the gate. Having gotten used to the hints
>> that "you've given us bad stuff", this was a stark change back to the
>> old world.
>>
>> Would it be possible to make it so that the schema could be explicitly
>> extended (instead of implicitly extended). So that additional
>> properties=False, but a mechanism for a scheduler filter to register
>> it's jsonschema in?
>>
>
> I'm pretty +1 for that because we want to have in-tree filters clear for
> the UX they provide when asking for scheduler hints.
>

+1 also, and we should have capability API for discovering what hints
supported by current deployment.


>
> For the moment, it's possible to have 2 different filters asking for the
> same hint without providing a way to explain the semantics so I would want
> to make sure that one in-tree filter could just have the same behaviour for
> *all the OpenStack deployments.*
>
> That said, I remember some discussion we had about that in the past, and
> the implementation details we discussed about having the Nova API knowing
> the list of filters and fitering by those.
> To be clear, I want to make sure that we could not leak the deployment by
> providing a 401 if a filter is not deployed, but rather just make sure that
> all our in-tree filters are like checked, even if they aren't deployed.
>

There isn't any other Nova API return 401. So if you return 401, then
everybody will know that is the only 401 in the nova, so I think there
isn't any different. As we have capability API, it's fine let the user to
know what is supported in the deployment.


>
> That leaves the out-of-tree discussion about custom filters and how we
> could have a consistent behaviour given that. Should we accept something in
> a specific deployment while another deployment could 401 against it ? Mmm,
> bad to me IMHO.
>

We can have code to check the out-of-tree filters didn't expose any same
hints with in-tree filter.


>
>
> -Sylvain
>
> -Sean
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] specs process for ironic-inspector

[Dmitry Tantsur]

FYI: the process is in effect now.

Please submit specs to https://github.com/openstack/ironic-inspector-specs/
Approved specs will appear on 
http://specs.openstack.org/openstack/ironic-inspector-specs/


On 11/19/2015 02:19 PM, Dmitry Tantsur wrote:

Hi folks!

I've been dodging subj for some time (mostly due to my laziness), but
now it seems like the time has come. We're discussing 2 big features:
autodiscovery and HA that I would like us to have a proper consensus on.

I'd like to get your opinion on one of the options:
1. Do not have specs, only blueprints are enough for us.
2. Reuse ironic-specs repo, create our own subdirectory with our own
template
3. Create a new ironic-inspector-specs repo.

I vote for #2, as sharing a repo with the remaining ironic would
increase visibility of large inspector changes (i.e. those deserving a
spec). We would probably use [inspector] tag in the commit summary, so
that people explicitly NOT wanting to review them can quickly ignore.

Also note that I still see #1 (use only blueprints) as a way to go for
simple features.

WDYT?

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

[Adam Young]

On 12/03/2015 07:51 AM, Morgan Fainberg wrote:


Chunked Encoding is a bad idea with mod_wsgi in general. While 
enabling it like that is fine, you are not guaranteed to get 100% 
consistent results simply because the wsgi spec did not/does not 
support it. Not all versions of mod_wsgi can enable it.


So, in short, officially keystone does not support chunked encoding. 
If radosgw cannot work without it, it is a bug against radosgw or 
something RDO itself is doing with radosgw.




RDO is not doing Keystone in HTTPD by default yet, and I have not come 
across the radosgw module at all.  Didn't think it was a real issue, but 
want to track if it is.



--morgan

On Dec 2, 2015 23:00, "Adam Young" > wrote:


On 12/01/2015 03:50 PM, Fox, Kevin M wrote:

I just upgraded to keystone liberty for one of my production
clouds, and went with apache since eventlet was listed as
deprecated. It was pretty easy. Just ran into one issue.
RadosGW wouldn't work against it until I added
"WSGIChunkedRequest On'" in the config. otherwise, the config
as shipped with RDO worked fine. I am running giant radosgw,
so future versions may not require that.


Thanks for the note.  Should this be bug?


Thanks,
Kevin

From: Sean Dague [s...@dague.net ]
Sent: Tuesday, December 01, 2015 4:05 AM
To: openstack-dev@lists.openstack.org

Subject: Re: [openstack-dev] [Openstack-operators] [keystone]
Removing functionality that was deprecated in Kilo and
upcoming deprecated functionality in Mitaka

On 12/01/2015 01:57 AM, Steve Martinelli wrote:

Trying to summarize here...

- There isn't much interest in keeping eventlet around.
- Folks are OK with running keystone in a WSGI server, but
feel they are
constrained by Apache.

 From an interop perspective, this concerns me a bit. My
understanding is
that Apache is specifically needed for Federation. Federation
is the
norm that we want for environments in the future.

I'd hate to go down a path where the reference architecture we
put out
there doesn't support this. It's going to be all the pain of
cells /
non-cells that Nova's or nova-net / neutron bifurcation.

Whatever the reference architecture is, it should support
Federation. A
non federation capable keystone should be the exception.

- uWSGI could help to support multiple web servers.


--
Sean Dague
http://dague.net


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Using existing ceph pools

[Sam Yaple]

This is a planned feature from the beginning, but not implemented.

I have done this locally, but I have not submitted a patchset. You can
expect this available and working by mitaka-2.
On Dec 1, 2015 6:08 AM, "OpenStack Mailing List Archive" 
wrote:

> Link: https://openstack.nimeyo.com/67172/?show=67172#q67172
> From: kunciil 
>
> I am planning to use an existing Ceph pool, the question is how to avoid
> [storage] group creating new Ceph pool with 'enable*ceph: "yes"' and how
> to pass existing Ceph values (rbd*user,libvirt*images*rbd_pool etc...) to
> Nova, Glance and Cinder config files?
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Documentation containing external resource links & privacy breaches

[Thomas Goirand]

Hi,

On many occasion, I've seen our docs containing external links, with
images containing src=foo.com/bar. In Debian, I am packaging these
documentation, and lintian (the packaging linter for Debian) yells that
there are privacy breaches. Below is an example with oslo.context. But
that's only a single example. There's many which I have to manually
patch out in Debian, which is both time consuming and quite frustrating.

Another good example is our openstackdocstheme including references to
Google Analytics. While I am already a bit annoyed to see that we're
giving (for free) all of our data to google (sic!), this means that all
docs we're generating for absolutely all projects will contain such
Google Analytics javascript. This also is a security issue: we're
allowing not only google, but anyone doing a man-in-the-middle to
replace the google analytics ga.js by anything (remember: when browsing
the doc locally on your computer, you're not using HTTPS, and then, the
ga.js is fetch without TLS). This is not just theory, we've seen real
life examples of country-wide firewall (no, no no no, I wont name
China...) playing with these.

I've filed a bug against our docs theme, but it was marked as wontfix,
and the patch which I started, was reviewed negatively. I've been told
that we use Google Analytics for the openstack.org site, which I don't
think is the right answer. I do believe we should think twice here.
There are many alternative options to google analytics, such as web log
analysis (webalizer, and such), and others involving local javascript of
the same type as google analytics but without the privacy breach.
There's ways to serve website-wide footers too (mod_footer for Apache
for example). So I do believe there's better approaches to "we want
statistic for openstack.org" than just Google Analytics.

So, could we have a general policy that we stop having such external
resources in our documentations? What's the broader view of the
community on this issue?

Cheers,

Thomas Goirand (zigo)

P.S: Here's the output of lintian when generating the
python-oslo.context-doc package:

X: python-oslo.context-doc: privacy-breach-generic
usr/share/doc/python-oslo.context-doc/html/index.html
(https://img.shields.io/pypi/v/oslo.context.svg)
N:
N:This package creates a potential privacy breach by fetching data
from an
N:external website at runtime. Please remove these scripts or external
N:HTML resources.
N:
N:Please replace any scripts, images, or other remote resources with
N:non-remote resources. It is preferable to replace them with text and
N:links but local copies of the remote resources are also acceptable as
N:long as they don't also make calls to remote services. Please ensure
N:that the remote resources are suitable for Debian main before making
N:local copies of them.
N:
N:Severity: important, Certainty: wild-guess
N:
N:Check: files, Type: binary, udeb
N:
N:This tag is marked experimental, which means that the code that
N:generates it is not as well-tested as the rest of Lintian and might
N:still give surprising results. Feel free to ignore experimental tags
N:that do not seem to make sense, though of course bug reports are
always
N:welcome.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0

[Roman Sokolkov]

Folks,

little bit more research done in regards #2 usability.

I've selected 13 real-world tasks from customer (i.e. update flag X in
nova.conf):
- 6/13 require fuel-library patching (or is #2 unusable)
- 3/13 are OK and can be done with #2
- 4/13 can be done with some limitations.

If needed i'll provide details.

Rough statistics is that *only ~20-25% of use cases can be done with #2*.

Let me give a very popular use case that will fail with #2. Assume we'r
executing whole task graph every two hours.
We want to change nova.conf "DEFAULT/amqp_durable_queues" from False to
True.

There is no parameter in hiera for "amqp_durable_queues". We have two
solutions here (both are bad):
1) Redefine "DEFAULT/amqp_durable_queues" = True in plugin task. What will
happen on the node. amqp_durable_queues will continue changing value
between True and False on every execution. We shouldn't do it this way.
2) Patch fuel-library. Value for amqp_durable_queues should be taken from
hiera. This is also one way ticket.

Thanks





On Thu, Dec 3, 2015 at 11:28 AM, Oleg Gelbukh  wrote:

> Roman,
>
> Thank you. This is great research.
>
> Could we have a conversation to discuss this? I'm especially interested in
> idempotency problems of the fuel-library modules and the common way to
> provide serialised data to the deployment.
>
> --
> Best regards,
> Oleg Gelbukh
> Mirantis Inc
>
>
> On Tue, Dec 1, 2015 at 6:38 PM, Roman Sokolkov 
> wrote:
>
>> Hello, folks.
>>
>> We need any kind of CM for Fuel 7.0. Otherwise new project with 800+ nodes
>> will be near impossible to support. Customer always wants to change
>> something.
>>
>> In our opinion, there are two major approaches for CM:
>>
>> #1 Independent CM (Puppet master, Chef, Ansible, whatever)
>> #2 Fuel-based CM
>>
>> Solution for #2
>> --
>>
>> Fuel has all info about configuration. So we've tried to
>> unlock "Settings" [0] and push "deploy" button.
>>
>> Major findings:
>>
>> * Task idem-potency. Looks like most of the tasks are idempotent.
>> We've skipped 3 tasks on controller and were able to get NO downtime
>> for Horizon and "nova list". BTW deeper QA required.
>>
>> * Standard changes. Operator can change parameters via WebUI, CLI or API.
>> For example, i was able to deploy Sahara. Unfortunately there is not
>> foolproof.
>> I mean some changes can lead to broken cloud...
>>
>> * Non-standard changes. Any other changes can be done with plugins.
>> We can modify plugin tasks and scripts (all except UI flags). And then
>> just
>> do "--update" + "--sync". BTW, we can change UI for particular env via API
>> by modifying "clusters/X/attributes".
>>
>> Conclusion
>> --
>>
>> - This works (We have service under cron that runs tasks) [1]
>> - NOT ready for production (in current state)
>> - This requires much deeper testing
>>
>>
>> I want to hear thoughts about approach above?
>> What is the current status/plans for CM? I saw this discussion [2]
>>
>> References
>> --
>>
>> [0]
>> https://github.com/rsokolkov/fuel-web/commit/366daaa2eb874c8e54c2d39be475223937cd317d
>> [1]
>> https://docs.google.com/presentation/d/12kkh1hu4ZrY9S6XXsY_HWaesFwESfxbl5czUwde8isM/edit#slide=id.p
>> [2] https://etherpad.openstack.org/p/lcm-use-cases
>>
>> --
>> Roman Sokolkov,
>> Deployment Engineer,
>> Mirantis, Inc.
>> Skype rsokolkov,
>> rsokol...@mirantis.com
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Roman Sokolkov,
Deployment Engineer,
Mirantis, Inc.
Skype rsokolkov,
rsokol...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] How to check changes waiting for review

[Esra Celik]

Hi, 




I wonder how you follow changes waiting for review. openstack-docs offers a 
Documentation Program Dashboard for this purpose . 

Inspired by that dashboard I prepared a link for Nova as well: 
http://goo.gl/Msq4Lb 




As I am quite new with the open source world, just to get used to with github, 
I added a project that simply creates a review dashboard link from a filter 
file: https://github.com/esracelik/openstack-review-dashboard 




Any comments are wellcome, 

Regards, 

Esra ÇELİK 
www.bilgem.tubitak.gov.tr 
celik.e...@tubitak.gov.tr 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon]

[Timur Sufiev]

Please take a look at
https://blueprints.launchpad.net/horizon/+spec/horizon-glance-large-image-upload

On Thu, Dec 3, 2015 at 5:21 PM Kyrylo Galanov  wrote:

> Hello,
>
> When a file is uploaded to Glance, Swift through Horizon it is stored
> locally in a temporary directory in Horizon server. This is inefficient
> approach especially for big files.
>
> I would suggest to implement 'proxy' upload to Glance, Swift using chunk
> buffer instead of storing a file locally. It would eliminate such drawbacks
> as potential free space exhaustion.
>
> It would be awesome to add upload progress bar as well.
>
> I look forward to your constructive replies.
>
> Best regards,
> Kyrylo
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][tripleo] User Initiated Rollback

[Steven Hardy]

On Thu, Dec 03, 2015 at 08:11:41AM -0500, Dan Prince wrote:
> On Wed, 2015-12-02 at 16:02 +, Steven Hardy wrote:
> > So, chatting with Giulio today about https://bugs.launchpad.net/heat/
> > +bug/1521944
> > has be thinking about $subject.
> > 
> > The root case of that issue is essentially a corner case of a stack-
> > update,
> > combined with some coupling within the Neutron API which prevents the
> > update traversal from working.
> > 
> > But it raises the broader question of what a "rollback" actually is,
> > and
> > how a user can potentially use it to get out of the kind of mess
> > described
> > in that bug (where, otherwise, your only option is to delete the
> > entire
> > stack).
> > 
> > Currently, we treat rollback as a special type of update, where, if
> > an
> > in-progress update fails, we then try to update again, to the
> > previous
> > stack definition[1], but as Giulio has discovered, there are times
> > when
> > that doesn't work, because what you actually want is to recover the
> > existing resource from the backup stack, not create a new one with
> > the same
> > properties.
> 
> Is there more information about this case (a bug perhaps)? Presumably
> it is an OpenStack resource you are talking about here... like a Nova
> Server or Neutron Network Port?

Well the bug is linked above (1521944), but there's no bug specific to
rollback.

As Zane has pointed out, heat is actually working as desired here, because
we aren't able to differentiate an attempt to delete a neutron port which
results in "not allowed, in use" with "500, I am broken".

I was hoping there was some way to make this easier via rollback, but
increasingly it seems the solution is not to tell Heat to do the wrong
thing (which is the root cause of this issue).

There are a few ways we can do that:

1. Stop defining default "noop" resources in
overcloud-resource-registry-puppet.yaml - it makes it too easy to
accidentally switch to a noop (destructive) implementation on update.

2. Improve heat stack update preview, so it handles nested stacks, then we
can easily have a pre-update validation step, which for example checks (and
warns, loudly) if any resources will be deleted (particularly network and
server resources..)  I'm working on this ref:

https://bugs.launchpad.net/heat/+bug/1521971

3. Implement a template annotation which allows you to say "don't update"
for certain resources, such as servers and network ports etc.  Rabi is
working on this, here's the (old) BP which didn't get implemented but I
think will help us:

https://github.com/openstack/heat-specs/blob/master/specs/kilo/stack-update-restrict.rst

> > Then, looking at convergence, we have a different definition of
> > rollback,
> > it's not yet clear to me how this should behave in a similar
> > scenario, e.g
> > when the resource we want to roll back to failed to get deleted but
> > still
> > exists (so, the resource is FAILED, but the underlying resource is
> > fine)?
> > 
> > Finally, the interface to rollback - atm you have to know before
> > something
> > fails that you'd like to enable rollback for a specific update.  This
> > seems
> > suboptimal, since invariably by the time you know you need rollback,
> > it's
> > too late.  Can we enable a user-initiated rollback from a FAILED
> > state, via
> > one of:
> > 
> >  - Introduce a new heat API that allows an explicit heat stack-
> > rollback?
> >  - (ab)use PATCH to trigger rollback on heat stack-update -x --
> > rollback=True?
> > 
> > The former approach fits better with the current stack.Stack
> > implementation, because the ROLLBACK stack state already exists.  The
> > latter has the advantage that it doesn't need a new API so might be
> > backportable.
> > 
> > Any thoughts on how we might proceed to make this situation better,
> > and
> > enable folks to roll back in the least destructive way possible when
> > they
> > end up in a FAILED state?
> 
> From a TripleO standpoint I would really like to end up in a place
> where we aren't thinking of Heat as a rollback tool and more of a make
> it so tool. I think there might be a small case for the
> "infrastructure" side where Heat is creating OpenStack objects for us
> (servers and ports). We'd like not to destroy/replace these when we
> update the "infrastructure" pieces of our stack and if things go badly
> on an update you just want to stay in the (hopefully still working)
> previous state.

Yeah, keeping the infrastructure and software configuration more cleanly
separated will help, but we still need much better pre-update validation.

> On the configuration (currently software deployments driving puppet) I
> would very much like to have Heat be a make-it so tool that does what
> we tell it. If I wanted to roll back the configuration I would prefer
> to simply do another heat stack-update with the previous
> parameters/manifests/etc. Or perhaps more drastically, delete the
> entire configuration stack and heat stack-create with the previous 

Re: [openstack-dev] [cloudkitty] Remove inactive contributors from cloudkitty-core

[Stéphane Albert]

Hi,

We didn't get your opinion Guillaume, are you approving it?

Cheers

- Forwarded message from Stéphane Albert  -

Date: Tue, 24 Nov 2015 11:51:42 +0100
From: Stéphane Albert 
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [cloudkitty] Remove inactive contributors from 
cloudkitty-core
User-Agent: Mutt/1.5.21 (2010-09-15)

Hi,

Some people in the cloudkitty-core group are not active anymore. They
haven't produced a single contribution during the last cycle. Here is
the list of the two people:

- Adrian Turjak
- François Magimel

I think we should remove them from the group. We've got new faces in the
project, let's get some space for them ready :).

Are you guys OK with this?

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

- End forwarded message -

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon]

[Kyrylo Galanov]

Hello,

When a file is uploaded to Glance, Swift through Horizon it is stored
locally in a temporary directory in Horizon server. This is inefficient
approach especially for big files.

I would suggest to implement 'proxy' upload to Glance, Swift using chunk
buffer instead of storing a file locally. It would eliminate such drawbacks
as potential free space exhaustion.

It would be awesome to add upload progress bar as well.

I look forward to your constructive replies.

Best regards,
Kyrylo
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

[Julien Danjou]

On Thu, Dec 03 2015, AFEK, Ifat (Ifat) wrote:

> One of Vitrage's goals is to gather information from different layers - 
> Physical, virtual and applicative - create a topology tree with the 
> Relations between the different entities in all layers, and perform 
> alarm analysis based on this topology.
>
> Currently, we can get alarms on the virtual layer from Ceilometer, and 
> alarms on the physical layer from Nagios for example. We can then try
> to correlate all these alarms, compute RCA, and optionally trigger other
> alarms, for example that an application might be running in suboptimal 
> state due to cpu threshold alarm on the instance.  

You can't really say that Nagios is for hardware and Ceilometer is for
virtual. This may be the way you view or deploy things, but this is not
a reality. We have plugins to check hardware (SNMP, IPMI…) in
Ceilometer, and I'm sure you can configure Nagios to check OpenStack
resources.

My point is that here is no hard line between the tools. They both
exists, and it's OK to use both of them – they do different things and
things differently – but how you make them work together isn't clear.

> We didn't suggest that Ceilometer will replace Nagios, rather that 
> Ceilometer might get Nagios test results as input/events, and trigger
> Corresponding alarms. Since right now Nagios and Ceilometer are not 
> connected, we thought that at the first stage we will query alarms 
> separately from Ceilometer and from Nagios. 
>
> Is it more clear?

Yes it is, thanks!.

I think that I would be more interested by connecting Nagios to
Ceilometer/Gnocchi/Aodh with maybe the long-term goal of replacing it by
that stack, which should be more scalable and dynamic.

That would make Vitrage only needing to build on top of telemetry
projects. It would also bring Nagios & co to telemetry not only for
Vitrage, but for the whole stack.

Maybe there's some good reasons you're going the way you do, I don't
have the pretension to have though about that as long as you probably
did. :-)

Though I think there's value in what you're trying to do, so it'd be
cool to be able to move your forward. That's why I'm trying to insist
that the current telemetry stuff should be able to solve as many problem
you have as we can!

Do you have something like a MVP based on Telemetry you target? I saw
you were already talking about Horizon, which to me is something that
(sh|c)ould be way further into the pipeline, so I'm worried. ;)

-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] get_reality implementation: default values, specified in config files

[Peter Razumovsky]

Hm... It's sounds reasonable, I will think about it.

2015-12-03 15:37 GMT+03:00 Thomas Herve :

>
>
> On Thu, Dec 3, 2015 at 1:00 PM, Peter Razumovsky  > wrote:
>
>>
>> Hello!
>>
>> During get_reality implementation next problem raised: if I don't specify
>> optional not update allowed property (like availabiliy_zone in
>> OS::Cinder::Volume), default value will be set for this property in entity.
>> This default value defined in configuration of entity's project (i.e. if I
>> create OS::Cinder::Volume without az, volume will be created with az =
>> default value, which defined in cinder.conf).
>>
>> So, if I want to get live state of entity, I get az with value, but in
>> template no value has been specified for az, and that's mean, stack will be
>> repalced during update, which is awful (e.g. if we have huge stack with
>> this problem for each resource, updating will be very slow).
>>
>> What I can do with such properties with default values, defined in config
>> options? I don't know any methods to get value from config of other project.
>>
>
> I haven't thought too much about it, but I'm sure getting config from
> other projects is not the right idea :). One possible solution would be to
> get the live state of the entity just after creation, so that we can fill
> those default properties right away. What do you think?
>
> --
> Thomas
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Peter Razumovsky
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

[Vitaly Kramskikh]

Igor,

BTW, Fuel UI is Javascript CTI
-compliant,
so we can also start moving UI tests (at least linting and unit tests) from
Fuel CI. But I think this should be done after moving Fuel UI to a separate
repo for simplicity.

2015-12-03 15:41 GMT+03:00 Igor Kalnitsky :

> > possible to have a working py26 CI for the duration
> > of Centos 7 migration (or keep it even after that)
>
> I'd prefer to drop py26 as well as py27 from Fuel CI. We have
> openstack gating, that should be more than enough. :)
>
> Fuel CI should be kept for running Fuel UI tests.
>
> On Thu, Dec 3, 2015 at 1:17 PM, Igor Belikov 
> wrote:
> > Just want to make a couple of things clear:
> >
> > 1. Openstack-Infra is dropping py26 jobs support, as Andreas said,
> > so once https://review.openstack.org/#/c/252448/ is merged all
> openstack projects
> > (including Fuel, of course) won’t have py26 gates.
> >
> > 2. We still run py26 tests on Fuel-CI side and don’t plan to drop them
> along with
> > OS-Infra folks, so it’s absolutely possible to have a working py26 CI
> for the duration
> > of Centos 7 migration (or keep it even after that).
> >
> >> On 03 Dec 2015, at 13:49, Igor Kalnitsky 
> wrote:
> >>
> >>> shouldn't we switch tests to work with python2.7 instead of python2.6?
> >>
> >> Currently we run tests using both py26 and py27, see the
> >>
> >> * gate-fuel-web-python27 (openstack infra)
> >> * verify-fuel-web-py27 (fuel infra)
> >>
> >> So the question is should we drop py26 jobs? I think yes, we should..
> >> but once CentOS 7 is merged.
> >>
> >> I want to notice that, the py26 gate has been removed from openstack
> >> infra in this patch [1] and due to this bug [2].
> >>
> >> Honestly, I have no idea why there were no discussions regarding this
> >> =/ it looks like Alex Kislitsky is issue reporter.
> >>
> >> [1] https://review.openstack.org/#/c/249242/
> >> [2] https://bugs.launchpad.net/fuel/+bug/1519371
> >>
> >> - I
> >>
> >> On Thu, Dec 3, 2015 at 12:35 PM, Andreas Jaeger  wrote:
> >>> On 2015-12-03 11:21, Evgeniy L wrote:
> 
>  Hi,
> 
>  During Fuel master migration to CentOS7 there was found a problem that
>  tests
>  get failed [0] for python2.6
> 
>  As far as I can see it's a common practise to drop python2.6
>  compatibility [1],
>  shouldn't we switch tests to work with python2.7 instead of python2.6?
> 
>  It looks like fuelclient will be an exception, because clients
> continue
>  supporting
>  python2.6 [1]
> >>>
> >>>
> >>> Clients are not supporting python 2.6 with Juno EOL anymore.
> Fuelclient has
> >>> no 2.6 gates anymore since yesterday.
> >>>
> >>> As mentioned already, we're disabling python 2.6 everywhere.
> >>>
> >>> Patch to remove it from nearly all repos including fuel is at
> >>> https://review.openstack.org/#/c/252448/
> >>>
> >>> Andreas
> >>>
>  Thanks,
> 
>  [0] https://review.openstack.org/#/c/251120/
>  [1]
> 
> 
> https://wiki.openstack.org/wiki/Python3#Python_2:_Python_2.6_support_dropped.2C_Python_2.7_only
> 
> 
> 
> __
>  OpenStack Development Mailing List (not for usage questions)
>  Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> >>>
> >>>
> >>> --
> >>> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> >>>  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> >>>   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> >>>   HRB 21284 (AG Nürnberg)
> >>>GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
> >>>
> >>>
> >>>
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] [FUEL] FFE request for erlang and rabbitmq-server packaged for centos7

[Vladimir Kuklin]

Andrey

I think this request is about updating RPM version of erlang which relates
only to master node here.

On Thu, Dec 3, 2015 at 3:48 PM, Andrey Sledzinskiy <
asledzins...@mirantis.com> wrote:

> Hi everybody,
> please, note that we faced next issue [0] during 7.0-MU1 testing and one
> of the possible solutions was to upgrade rabbitmq to 3.5.5.
> This issue is also present in 8.0 and affects at least one SWARM
> destructive test.
>
> [0] https://bugs.launchpad.net/fuel/+bug/1513511
>
> On Thu, Dec 3, 2015 at 1:32 AM, Mike Scherbakov 
> wrote:
>
>> Based on time of this request, you seem to be late to the party...
>> FF is in action. Formally it was requested before FF, but as I mentioned
>> in my email [1], we'd need at least a day for consider exception and assess
>> related risks. Filing it couple of hours before FF doesn't give a chance to
>> do it.
>>
>> Any other opinions?
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2015-December/080895.html
>>
>> On Wed, Dec 2, 2015 at 9:52 AM Artem Silenkov 
>> wrote:
>>
>>> Hello!
>>>
>>> We have got
>>> - erlang=18.1 https://review.fuel-infra.org/#/c/12896/
>>> - rabbitmq-server=3.5.6 https://review.fuel-infra.org/#/c/12901/
>>> packaged for ubuntu trusty in corresponding requests.
>>>
>>> Those requests are not merged yet but probably would today evening.
>>> We need some time to backport it for centos7 in order to keep versions
>>> synced.
>>>
>>> It is not rocket science to package it for centos7 and it could take not
>>> more then one working day.
>>> This work could be done as soon as ubuntu packages are landed.
>>>
>>> Regards,
>>> Artem Silenkov
>>> ---
>>> MOS~Packaging
>>> mirantis.com
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Thanks,
> Andrey Sledzinskiy
> QA Engineer,
> Mirantis, Kharkiv
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [FUEL] FFE request for erlang and rabbitmq-server packaged for centos7

[Artem Silenkov]

Hello!

Please note that we already have updated packages for centos7 as follows:

erlang=R16B03, rabbitmq-server=3.5.5

I'm just aware of version mismatch between ubuntu and centos in this case.

I have already prepared packages for centos7. We could merge it in FFE
time frame for centos7. AFAIK until 7 of Dec.

Regards,

Artem Silenkov

---

Mos~Packaging

mirantis.com


On Thu, Dec 3, 2015 at 3:48 PM, Andrey Sledzinskiy <
asledzins...@mirantis.com> wrote:

> Hi everybody,
> please, note that we faced next issue [0] during 7.0-MU1 testing and one
> of the possible solutions was to upgrade rabbitmq to 3.5.5.
> This issue is also present in 8.0 and affects at least one SWARM
> destructive test.
>
> [0] https://bugs.launchpad.net/fuel/+bug/1513511
>
> On Thu, Dec 3, 2015 at 1:32 AM, Mike Scherbakov 
> wrote:
>
>> Based on time of this request, you seem to be late to the party...
>> FF is in action. Formally it was requested before FF, but as I mentioned
>> in my email [1], we'd need at least a day for consider exception and assess
>> related risks. Filing it couple of hours before FF doesn't give a chance to
>> do it.
>>
>> Any other opinions?
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2015-December/080895.html
>>
>> On Wed, Dec 2, 2015 at 9:52 AM Artem Silenkov 
>> wrote:
>>
>>> Hello!
>>>
>>> We have got
>>> - erlang=18.1 https://review.fuel-infra.org/#/c/12896/
>>> - rabbitmq-server=3.5.6 https://review.fuel-infra.org/#/c/12901/
>>> packaged for ubuntu trusty in corresponding requests.
>>>
>>> Those requests are not merged yet but probably would today evening.
>>> We need some time to backport it for centos7 in order to keep versions
>>> synced.
>>>
>>> It is not rocket science to package it for centos7 and it could take not
>>> more then one working day.
>>> This work could be done as soon as ubuntu packages are landed.
>>>
>>> Regards,
>>> Artem Silenkov
>>> ---
>>> MOS~Packaging
>>> mirantis.com
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Thanks,
> Andrey Sledzinskiy
> QA Engineer,
> Mirantis, Kharkiv
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Config support for oslo.config.cfg.MultiStrOpt

[Clayton O'Neill]

For puppetlabs-inifile that’s a bigger question.  For our purposes the
answer is “whatever ConfigParser does”.

On Wed, Dec 2, 2015 at 10:32 PM, Cody Herriges  wrote:

> Martin,
>
> I see no reason this shouldn't just be pushed into puppetlabs-inifile.  I
> can't actually find a real "spec" for INI file and even the Wiki link[3]
> calls out that there is no actual spec.
>
> On Fri, Nov 27, 2015 at 5:04 AM, Martin Mágr  wrote:
>
>> Greetings,
>>
>>   I've submitted patch to puppet-openstacklib [1] which adds provider for
>> parsing INI files containing duplicated variables (a.k.a MultiStrOpt [2]).
>> Such parameters are used for example to set
>> service_providers/service_provider for Neutron LBaaSv2. There has been a
>> thought raised, that the patch should rather be submitted to
>> puppetlabs-inifile module instead. The reason I did not submitted the patch
>> to inifile module is that IMHO duplicate variables are not in the INI file
>> spec [3]. Thoughts?
>>
>> Regards,
>> Martin
>>
>>
>> [1] https://review.openstack.org/#/c/234727/
>> [2]
>> https://docs.openstack.org/developer/oslo.config/api/oslo.config.cfg.html#oslo.config.cfg.MultiStrOpt
>> [3] https://en.wikipedia.org/wiki/INI_file#Duplicate_names
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cloudkitty] Remove inactive contributors from cloudkitty-core

[Guillaume Espanel]

+1

--
Guillaume Espanel
Objectif Libre www.objectif-libre.com
Infrastructure et Formations Linux

Le 2015-12-03 14:45, Stéphane Albert a écrit :

Hi,

We didn't get your opinion Guillaume, are you approving it?

Cheers

- Forwarded message from Stéphane Albert 
 -


Date: Tue, 24 Nov 2015 11:51:42 +0100
From: Stéphane Albert 
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [cloudkitty] Remove inactive contributors
from cloudkitty-core
User-Agent: Mutt/1.5.21 (2010-09-15)

Hi,

Some people in the cloudkitty-core group are not active anymore. They
haven't produced a single contribution during the last cycle. Here is
the list of the two people:

- Adrian Turjak
- François Magimel

I think we should remove them from the group. We've got new faces in 
the

project, let's get some space for them ready :).

Are you guys OK with this?

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

- End forwarded message -


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Documentation containing external resource links & privacy breaches

[Cory Benfield]

> On 3 Dec 2015, at 13:37, Thomas Goirand  wrote:
> I've filed a bug against our docs theme, but it was marked as wontfix,
> and the patch which I started, was reviewed negatively. I've been told
> that we use Google Analytics for the openstack.org site, which I don't
> think is the right answer. I do believe we should think twice here.
> There are many alternative options to google analytics, such as web log
> analysis (webalizer, and such), and others involving local javascript of
> the same type as google analytics but without the privacy breach.
> There's ways to serve website-wide footers too (mod_footer for Apache
> for example). So I do believe there's better approaches to "we want
> statistic for openstack.org" than just Google Analytics.
> 
> So, could we have a general policy that we stop having such external
> resources in our documentations? What's the broader view of the
> community on this issue?

For Google Analytics, it’s entirely possible to make including the GA data 
conditional based on an environment variable. This would actually be a net-win, 
because it would ensure that the GA data accurately reflected the usage only on 
openstack.org. For example, the Alabaster sphinx theme does this based on 
configuration from conf.py, which could easily be set based on the 
presence/absence of an environment variable.

This would solve Debian’s problem with GA at the very least, while allowing 
openstack.org to continue to use the tool they choose to use to analyse their 
traffic.

Cory


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

[AFEK, Ifat (Ifat)]

Hi Julien,

> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: Thursday, December 03, 2015 10:53 AM
> 
> On Thu, Dec 03 2015, AFEK, Ifat (Ifat) wrote:
> 
> > Another question is our need to get alarms from other sources, like
> > Nagios, zabbix, ganglia, etc. We thought that Vitrage would query
> > these Alarms from each source directly, and then create alarms in
> AODH
> > in the same way as our deduced alarms: for example create
> > nagios_ovs_vswitchd alarm if nagios check_ovs_vswitchd test failed.
> > An alternative could be to integrate nagios directly with AODH.
> > What do you think?
> 
> I think I'd like to be able to answer this question, but I kind of lack
> the bigger picture of what you need these alarms for, and what you
> would like them to do with?
> 
> I think we don't have everything right now in Ceilometer/Gnocchi/Aodh
> to replace something like Nagios _but_ we have a base framework that
> should be more powerful and way more scalable. That could be leveraged
> to built something better that Nagios, while staying compatible.
> 
> What Nagios does is polling, storing state, and doing action based on
> that state. Which is more or less what Ceilometer does (polling),
> Gnocchi does (storing things) and Aodh does (triggering action based on
> the state). Obviously there's more to that (e.g. dependencies) that are
> not handled currently, and that could be added later – maybe in some
> parts of the current telemetry projects, or maybe in Vitrage.
> 
> So how fitting such tools (Nagios, Zabbix, whatever) in those projects
> is an interesting problem. But I'm not clear on the first steps and
> how/why you want to leverage alarms first. :)

One of Vitrage's goals is to gather information from different layers - 
Physical, virtual and applicative - create a topology tree with the 
Relations between the different entities in all layers, and perform 
alarm analysis based on this topology.

Currently, we can get alarms on the virtual layer from Ceilometer, and 
alarms on the physical layer from Nagios for example. We can then try
to correlate all these alarms, compute RCA, and optionally trigger other
alarms, for example that an application might be running in suboptimal 
state due to cpu threshold alarm on the instance.  

We didn't suggest that Ceilometer will replace Nagios, rather that 
Ceilometer might get Nagios test results as input/events, and trigger
Corresponding alarms. Since right now Nagios and Ceilometer are not 
connected, we thought that at the first stage we will query alarms 
separately from Ceilometer and from Nagios. 

Is it more clear?

Best Regards,
Ifat.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] stable/liberty branches are open

[Steven Hardy]

All,

After quite a long battle, the stable/liberty CI is now working, as of this
patch:

https://review.openstack.org/#/c/247694/

We still need to verify that CI works properly on all other repos, because
we had to go ahead and land what was ahead of that patch in the queue to
reach a working baseline.  Let me know if you see any issues.

There are a couple of outstanding items:

1. puppet-tripleo doesn't yet have a stable branch - I'll cut that this
week when we've verified all is working e.g what sha to cut it from.

2. Currently puppet modules are installed from o-p-m, e.g packages not
source, this means Depends-On:  won't work for stable
backport.  We'll have to fix this soon so we build tripleo-ci packages from
the puppet stable branches like we do for master.

But, other than those two caveats, stable/liberty branches are open -
please all feel free to propose/review.

Thanks for your patience while we got this all working, and thanks to those
(particularly derekh) who helped me out.

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][tripleo] User Initiated Rollback

[Dan Prince]

On Wed, 2015-12-02 at 16:02 +, Steven Hardy wrote:
> So, chatting with Giulio today about https://bugs.launchpad.net/heat/
> +bug/1521944
> has be thinking about $subject.
> 
> The root case of that issue is essentially a corner case of a stack-
> update,
> combined with some coupling within the Neutron API which prevents the
> update traversal from working.
> 
> But it raises the broader question of what a "rollback" actually is,
> and
> how a user can potentially use it to get out of the kind of mess
> described
> in that bug (where, otherwise, your only option is to delete the
> entire
> stack).
> 
> Currently, we treat rollback as a special type of update, where, if
> an
> in-progress update fails, we then try to update again, to the
> previous
> stack definition[1], but as Giulio has discovered, there are times
> when
> that doesn't work, because what you actually want is to recover the
> existing resource from the backup stack, not create a new one with
> the same
> properties.

Is there more information about this case (a bug perhaps)? Presumably
it is an OpenStack resource you are talking about here... like a Nova
Server or Neutron Network Port?


> 
> Then, looking at convergence, we have a different definition of
> rollback,
> it's not yet clear to me how this should behave in a similar
> scenario, e.g
> when the resource we want to roll back to failed to get deleted but
> still
> exists (so, the resource is FAILED, but the underlying resource is
> fine)?
> 
> Finally, the interface to rollback - atm you have to know before
> something
> fails that you'd like to enable rollback for a specific update.  This
> seems
> suboptimal, since invariably by the time you know you need rollback,
> it's
> too late.  Can we enable a user-initiated rollback from a FAILED
> state, via
> one of:
> 
>  - Introduce a new heat API that allows an explicit heat stack-
> rollback?
>  - (ab)use PATCH to trigger rollback on heat stack-update -x --
> rollback=True?
> 
> The former approach fits better with the current stack.Stack
> implementation, because the ROLLBACK stack state already exists.  The
> latter has the advantage that it doesn't need a new API so might be
> backportable.
> 
> Any thoughts on how we might proceed to make this situation better,
> and
> enable folks to roll back in the least destructive way possible when
> they
> end up in a FAILED state?

From a TripleO standpoint I would really like to end up in a place
where we aren't thinking of Heat as a rollback tool and more of a make
it so tool. I think there might be a small case for the
"infrastructure" side where Heat is creating OpenStack objects for us
(servers and ports). We'd like not to destroy/replace these when we
update the "infrastructure" pieces of our stack and if things go badly
on an update you just want to stay in the (hopefully still working)
previous state.

On the configuration (currently software deployments driving puppet) I
would very much like to have Heat be a make-it so tool that does what
we tell it. If I wanted to roll back the configuration I would prefer
to simply do another heat stack-update with the previous
parameters/manifests/etc. Or perhaps more drastically, delete the
entire configuration stack and heat stack-create with the previous one.
Puppet is meant to be idempotent so re-running a previously working
manifests might be just what you want. This wouldn't cover all cases
for rollback... and there are certainly things where you'd want a
custom ad-hoc puppet snippet or bash script to run before you did a
follow up heat stack-update to put things back like they were. For
these cases I think perhaps workflow tools to perhaps help drive our
Heat configuration orchestration could work well.

Dan

> 
> Steve
> 
> [1] https://github.com/openstack/heat/blob/master/heat/engine/stack.p
> y#L1331
> [2] https://github.com/openstack/heat/blob/master/heat/engine/stack.p
> y#L1143
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

[AFEK, Ifat (Ifat)]

Hi Ryota,

> From: Ryota Mibu [mailto:r-m...@cq.jp.nec.com]
> >
> > Let me see if I got this right: are you suggesting that we create
> > on-the-fly alarm definitions with no alarm_actions, for every deduced
> alarm that we want to raise? And this will spare us the extra alarm
> evaluation in AODH?
> 
> Yes. But, please note that could be the first step. The next step would
> be make vitrage to send out alarm event to ceilometer/aodh the pre-
> configured event alarm will recognize the alarm and fire the alarm
> notification to another service or an end user. Eventually, we should
> have relevant alarm type and evaluator to proxy evaluation in vitrage,
> I think.

The next step can happen if and when Aodh supports alarm templates. 
If Vitrage can handle about 30 alarm types, and there are 100 instances, 
we don't want to pre-configure 3000 alarms, which most likely will never 
be triggered.

> > Another question is our need to get alarms from other sources, like
> > Nagios, zabbix, ganglia, etc. We thought that Vitrage would query
> > these Alarms from each source directly, and then create alarms in
> AODH in the same way as our deduced alarms: for example create
> nagios_ovs_vswitchd alarm if nagios check_ovs_vswitchd test failed.
> > An alternative could be to integrate nagios directly with AODH.
> > What do you think?
> 
> Hmm, I don't have clear view on this. If the source can includes
> OpenStack IDs and can be generate relevant meter/sample, it should be
> useful to integrate with ceilometer. But if you want to do some
> operations (like correlation), then it is reasonable to integrate with
> vitrage.

The source may include alarms on resources that are not defined in 
OpenStack, like switches or ports. And the alarms are not necessarily 
related to meters, they can be test nagios failures for example.

> > > BTW, is it useful to have on-the-fly evaluation of combination
> alarm
> > > with event alarms for alarm aggregation or other cases?
> >
> > I'm not sure I understand. Can you give a detailed example?
> 
> OK. The 'combination' type alarm enables you to aggregate multiple
> alarm to one alarm. This can be used when you want to receive alarm
> when the both of physical NIC ports are downed to recognize logical
> connection unavailability if the ports are teamed for redundancy. Now,
> the combination alarms are evaluated periodically that means you can
> receive combination alarm not on-the-fly while you are using event
> alarms as source of combination alarm though.

I think I understand your point. It means that certain alarms will 
arrive to Vitrage in delay, due to your evaluation policy. I think we 
will have to address this issue at some point, but it won't change our
overall design.

> > In addition, in Vitrage we plan to handle alarm aggregation by
> > creating aggregation rule templates, for example based on the RCA
> information.
> > The user will be able to see only the root cause alarms, and then
> > drill down to all specific alarms. But I doubt if this will be done
> for Mitaka.
> 
> I think 'the RCA information' means information for RCA. I mean vitrage
> will use the resource topologies or relationship in aggregation, rather
> than result of RCA. Am I right?

The term "aggregation" is used in different contexts, which may be 
confusing. Our plan is to examine the already-computed RCA information,
and see, for example, that a switch failure alarm caused alarms on 100
related instances. In horizon, the result will be 101 alarms shown to 
the user in a flat list. 
By "alarm aggregation based on RCA" we mean that we will have 
an API to get root cause alarms, which will return only the switch 
alarm. The horizon user will see one alarm, and may then ask to expand 
the view and see all the other alarms that were caused by it. 

Best Regards,
Ifat.





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

[Thomas Goirand]

On 12/03/2015 11:21 AM, Evgeniy L wrote:
> Hi,
> 
> During Fuel master migration to CentOS7 there was found a problem that tests
> get failed [0] for python2.6
> 
> As far as I can see it's a common practise to drop python2.6
> compatibility [1],
> shouldn't we switch tests to work with python2.7 instead of python2.6?
> 
> It looks like fuelclient will be an exception, because clients continue
> supporting
> python2.6 [1]
> 
> Thanks,
> 
> [0] https://review.openstack.org/#/c/251120/
> [1] 
> https://wiki.openstack.org/wiki/Python3#Python_2:_Python_2.6_support_dropped.2C_Python_2.7_only

I believe [1] is obsolete already. Please *completely* remove Py2.6
support, including in fuelclient. This otherwise create issues on the
packaging level (like having to patch out modules like argparse and such).

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Bug deputy process

[Armando M.]

On 3 December 2015 at 07:58, Ihar Hrachyshka  wrote:

> Armando M.  wrote:
>
> Hi neutrinos,
>>
>> It's been a couple of months that the Bug deputy process has been in
>> place [1,2]. Since the beginning of Mitaka we have collected the following
>> statistics (for neutron and neutronclient):
>>
>> Total bug reports: 373
>> • Fix committed: 144
>> • Unassigned: 73
>> • New: 17
>> • Incomplete: 20
>> • Confirmed: 27
>> • Triaged: 6
>>
>> At first, it is clear that we do not fix issues nearly as fast as they
>> come in, but at least we managed to keep the number of unassigned/unvetted
>> bugs relatively small, so kudos to you all who participated in this
>> experiment. I don't have data based on older releases, so I can't see
>> whether we've improved or worsened, and I'd like to ask for feedback from
>> the people who played with this first hand, especially on the amount of
>> time that has taken them to do deputy duty for their assigned week.
>> • ihrachys
>> • regXboi
>> • markmcclain
>> • mestery
>> • mangelajo
>> • garyk
>> • rossella_s
>> • dougwig
>>
>
> My perspective, it is a success. We are better at disseminating
> information about ongoing reported issues.
>
> Timewise, it did not waste more than an hour per day for me, usually less.


Thanks not time wasted, is it? :)


> The trick I use is subscribing to all comments in all neutron bugs in LP.
> That way I don’t need to rely on UI to get the list of bugs reported during
> me on duty.
>
> The thing I would like us to see enhanced is making sure that tags set to
> bugs are actively tracked by corresponding teams. Hint: in my case, I have
> some recurrent todo on each Fri to walk thru all ‘oslo’ bugs. I may do the
> same if/once we get ‘upgrade’ tag. It would be great to be able to
> subscribe to just specific tag for emails, but I don’t know whether it’s
> possible in LP.
>

I think the trick is to provide a subscription name, and you can subscribe
just to a single tag. That's how I have the RFE bugs stand out in my pile.

Cheers,
Armando


>
> So kudos for setting the process and thanks everyone involved so far,
>
> Ihar
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] Auth_version from 'old style' URLs in the database

[Bunting, Niall]

Hi,

Currently glance will use an auth_url if in the database. Eg. 10.0.0.8:5000/v2.0

However glance currently takes the auth_version from the config
files. Therefore this can lead to a mismatch of keystone version to be used
between the url and the config files. This is problematic due to a different
resource id being required in different version of keystone (in keystone v2
it was /v2.0/tokens in keystone v3 it is /v3/auth/tokens).

Using a v2 url and config file with keystone v3:
10.0.0.8:5000/v2.0/auth/tokens -- Fails to authenticate the user,
and user can't download image.

See https://bugs.launchpad.net/glance-store/+bug/1507610 for a bug report
on this.

This means that the fix proposed by
https://review.openstack.org/#/c/238074/ parses the URL for an auth_version
and then if found will use the parsed value as the auth_version rather than
the one from the config files. Taking the url as the true source.
Therefore the image will still work as the auth_version used by glance is the
one defined in the URL meaning the correct resource id appended.

Whilst discussing it with Kairat it was proposed that we ignore the
keystone version in the URL and if it does not support the auth_version
in the configs, then the image would fail to be downloaded. This is due to a
preference to have a centralised auth_version value.

I am wondering what people would prefer to do, to support the 'old style' urls
and therefore parse the version from the url. Or to make the auth_version
common and potentially break the 'old style' database entries.

Thanks,
Niall Bunting


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][all] when can we drop XML support in neutronclient? Now?

[Armando M.]

On 3 December 2015 at 08:33, Ihar Hrachyshka  wrote:

> Akihiro Motoki  wrote:
>
> Hi,
>>
>> python-neutronclient still has XML support of Neutron API.
>> I would like to discuss when we drop XML support in neutronclient.
>>
>> Neutron API XML suppoort was marked as deprecated in Icehouse and Juno
>> and was dropped in Kilo. Juno is now EOL and we have no gate testing which
>> requires XML support. This is a minimum requirement.
>> From this point, we can drop XML support now.
>
>
>> Another point is users who are OpenStack clouds using Juno or older
>> versions
>> may use the latest python-neutronclient.
>> XML support in Neutron was deprecated since Icehouse, and if our
>> deprecation
>> notice works, XML API is used only in cloud deployed before Icehouse.
>> In addition, older versions of neutronclient are available from
>> various distributions and PyPI.
>> Do we need to continue XML support for users of such cloud?
>> Note that we no longer have a way to test XML API support is functional.
>>
>> Thanks,
>> Akihiro
>>
>
> Let’s not pretend anything ungated works in OpenStack world. If we don’t
> have infra to validate it, we should kill the support for it.


Kill it already! :)


>
>
> Ihar
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [os-client-config] Proposing Morgan Fainberg for core

[Ghe Rivero]

+1

Quoting Monty Taylor (2015-12-03 17:44:13)
> Hey all,
>
> I'd like to propose that we include Morgan Fainberg as core on
> os-client-config. He's in the over/under on matching other active
> reviewers on the project, and he's got a good understanding of the
> related problem space. Also, he's interested and active, which for a
> low-volume project like occ is a godsend.
>
> Monty
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [tripleo] stop maintaining puppet-tuskar

[Emilien Macchi]

I would love TripleO support on this topic

On 12/03/2015 11:07 AM, arkady_kanev...@dell.com wrote:
> Emilien,
> 
> So what is the statement we (OpenStack) wants to provide about UI for OOO?

AFIK, Tuskar won't be continued to be the TripleO UI but I might have
misunderstood something.

> If we will not provide it people outside our community and compatitors
> to OpenStack will fill the void.
> 
> Thanks,
> 
> Arkady
> 
> -Original Message-
> From: Emilien Macchi [mailto:emil...@redhat.com]
> Sent: Wednesday, December 02, 2015 10:38 AM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [puppet] [tripleo] stop maintaining puppet-tuskar
> 
> Hi,
> 
> I don't find any official statement on the Internet, but I've heard
> Tuskar is not going to be maintained anymore (tell me if I'm wrong).
> 
> If I'm not wrong, I suggest we stop maintaining puppet-tuskar, and
> stable/liberty would be the latest release that we have maintained. I
> would also drop all the code in master and update the README explaining
> the module is not maintained anymore.
> 
> Thanks for your help,
> --
> Emilien Macchi
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Emilien Macchi



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] specs process for ironic-inspector

[Pavlo Shchelokovskyy]

Hi Dmitry,

should we also configure Launchpad to have blueprints references there (for
release/milestone targeting etc)? Or is it not needed?

Cheers,

On Thu, Dec 3, 2015 at 4:00 PM Dmitry Tantsur  wrote:

> FYI: the process is in effect now.
>
> Please submit specs to
> https://github.com/openstack/ironic-inspector-specs/
> Approved specs will appear on
> http://specs.openstack.org/openstack/ironic-inspector-specs/
>
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][TaaS] Query regarding TaaS API

[Fawad Khaliq]

Hi Reedip,

I believe TaaS API will go through a round of reviews when the spec is
introduced. It will be good to discuss these points there.

Fawad Khaliq


On Wed, Nov 25, 2015 at 12:45 PM, reedip banerjee 
wrote:

> Dear Members of Neutron-TaaS community,
> I have a few queries related to the TaaS API, and would like to know a bit
> more details about them.
>
> a) Currently Tap Service and Tap flow Endpoints are listed under
> /v2_0/taas/
>
> For example:
> http://111.000.222.115:9696/v2.0/taas/tap-services.json
> http://111.000.222.115:9696/v2.0/taas/tap-flows.json
>
> Is it necessary to list the endpoints under /taas/?
> Can we keep them under v2_0 like most of the other Neutron Extensions?
> i.e.
>
> http://111.000.222.115:9696/v2.0/taas/tap-services.json  -->
> http://111.000.222.115:9696/v2.0/tap-services.json
>
> b) Currently TaaS has 2 different ports:
> - Tap Service uses port_id to specify ports
> - Tap Flow uses source_port to specify ports.
> As both of these attributes are under different end points, can we use
> ´port´ instead of port_id and source_port?
> From my understanding, port makes bit of a sense, and it is also an known
> attribute in Neutron.
>
>
>
> --
> Thanks and Regards,
> Reedip Banerjee
> irc:reedip
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [tripleo] stop maintaining puppet-tuskar

[Arkady_Kanevsky]

Emilien,
So what is the statement we (OpenStack) wants to provide about UI for OOO?
If we will not provide it people outside our community and compatitors to 
OpenStack will fill the void.
Thanks,
Arkady

-Original Message-
From: Emilien Macchi [mailto:emil...@redhat.com]
Sent: Wednesday, December 02, 2015 10:38 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [puppet] [tripleo] stop maintaining puppet-tuskar

Hi,

I don't find any official statement on the Internet, but I've heard Tuskar is 
not going to be maintained anymore (tell me if I'm wrong).

If I'm not wrong, I suggest we stop maintaining puppet-tuskar, and 
stable/liberty would be the latest release that we have maintained. I would 
also drop all the code in master and update the README explaining the module is 
not maintained anymore.

Thanks for your help,
--
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][all] when can we drop XML support in neutronclient? Now?

[Kyle Mestery]

On Thu, Dec 3, 2015 at 7:59 AM, Akihiro Motoki  wrote:

> Hi,
>
> python-neutronclient still has XML support of Neutron API.
> I would like to discuss when we drop XML support in neutronclient.
>
> Neutron API XML suppoort was marked as deprecated in Icehouse and Juno
> and was dropped in Kilo. Juno is now EOL and we have no gate testing which
> requires XML support. This is a minimum requirement.
> From this point, we can drop XML support now.
>
> Another point is users who are OpenStack clouds using Juno or older
> versions
> may use the latest python-neutronclient.
> XML support in Neutron was deprecated since Icehouse, and if our
> deprecation
> notice works, XML API is used only in cloud deployed before Icehouse.
> In addition, older versions of neutronclient are available from
> various distributions and PyPI.
> Do we need to continue XML support for users of such cloud?
> Note that we no longer have a way to test XML API support is functional.
>
>
I'm in favor of dropping XML support.


> Thanks,
> Akihiro
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matt Riedemann]

On 11/20/2015 10:37 AM, Matt Riedemann wrote:



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:

https://gist.github.com/mdbooth/163f5fdf47ab45d7addd

It obviously overlaps considerably with host-servers-migrate, which is
supposed to do the same thing. Users seem to have been appreciative, so
I'd be interested to see it merged in some form.

Matt

On Thu, Nov 19, 2015 at 6:18 PM, Matt Riedemann
> wrote:

We've been talking about doing a 3.0 release for novaclient for
awhile so we can make some backward incompatible changes, like:

1. Removing the novaclient.v1_1 module
2. Dropping py26 support (if there is any explicit py26 support in
there)

What else are people aware of?

Monty was talking about doing a thing with auth:

https://review.openstack.org/#/c/245200/

But it sounds like that is not really needed now?

I'd say let's target mitaka-2 for a 3.0 release and get these
flushed out.

--

Thanks,

Matt Riedemann



__


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe


http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



That's not a backward compatible change, so not really necessary for a
major version release. We'd need a blueprint at least for it though
since it's adding a new CLI that does some orchestration. I commented in
the repo, there is a similar version in another repo, so yeah, people
are doing this and it'd be good if we could decide if it's something
that should live in tree and be maintained officially.

A functional test would be sweet, but given it deals with migration and
the novaclient functional tests are assuming a single node devstack,
that's probably not going to fly. We could ask sdague about that though.



Sorry, that's not a backward *incompatible* change.



Just an update, we've merged the changes to drop the novaclient.v1_1 
module and the change to drop py26 support.


We're waiting on https://review.openstack.org/#/c/245200/ which should 
be ready next week.


So that means we hope to release python-novaclient 3.0 next week sometime.

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [os-client-config][infra] Proposing adding infra-core to core

[Ghe Rivero]

I'm ok with that. The current core group is small and the project is critical
enough to have them as backup.

Ghe Rivero

Quoting Monty Taylor (2015-12-03 17:50:17)
> Hey all,
>
> os-client-config is now in the critical path for Infra's Nodepool,
> meaning that there are some places where a bug surfacing in it can take
> down the entire CI infrastructure. Infra also uses many more of the
> advanced features in clouds.yaml than most other people, so the surface
> area that could be tickled is higher than day-to-day use via
> openstackclient.
>
> While this is unlikely to happen, because it's not a high-volume
> changing project, it would still be nice to have a safety valve.
>
> For that reason, and because the os-client-config core group is small in
> the first place, I'd like to add the infra-core group as a subgroup to
> to os-client-config-core.
>
> Monty
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Bug deputy process

[Armando M.]

On 2 December 2015 at 17:38, Sean M. Collins  wrote:

> I was not a deputy - but I had been subscribed to launchpad bugs for
> years, but had a procmail filter set so it went into a folder that prior
> to this new initiative, had remained unread for years. As part of this
> new effort I try and spend at least 15 minutes a day checking the folder
> and working on bugs where I think I can contribute productively.
>
> So - I think it has been effective. It's made me pay attention to it. :)
>

Let's hope you continue to do so, your input is very valuable!


>
> --
> Sean M. Collins
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][all] when can we drop XML support in neutronclient? Now?

[Ihar Hrachyshka]

Akihiro Motoki  wrote:


Hi,

python-neutronclient still has XML support of Neutron API.
I would like to discuss when we drop XML support in neutronclient.

Neutron API XML suppoort was marked as deprecated in Icehouse and Juno
and was dropped in Kilo. Juno is now EOL and we have no gate testing which
requires XML support. This is a minimum requirement.
From this point, we can drop XML support now.

Another point is users who are OpenStack clouds using Juno or older  
versions

may use the latest python-neutronclient.
XML support in Neutron was deprecated since Icehouse, and if our  
deprecation

notice works, XML API is used only in cloud deployed before Icehouse.
In addition, older versions of neutronclient are available from
various distributions and PyPI.
Do we need to continue XML support for users of such cloud?
Note that we no longer have a way to test XML API support is functional.

Thanks,
Akihiro


Let’s not pretend anything ungated works in OpenStack world. If we don’t  
have infra to validate it, we should kill the support for it.


Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Sender Auth Failure] Re: [neutron] How could an L2 agent extension access agent methods ?

[Johnston, Nate]

Ihar,

This is brilliant.  The complexity of doing graceful CRUD on the OVS flow table 
especially when other features are active is so complex, that abstracting the 
management of it into functionality optimized for that task is an incredibly 
good idea, especially for those of us like me who are not experts in OVS, and 
thus have a hard time seeing the edge cases.

Thanks very much for this.

—N.

> On Dec 3, 2015, at 10:46 AM, Ihar Hrachyshka  wrote:
> 
> Hi,
> 
> Small update on the RFE. It was approved for Mitaka, assuming we come up with 
> proper details upfront thru neutron-specs process.
> 
> In the meantime, we have found more use cases for flow management among 
> features in development: QoS DSCP, also the new OF based firewall driver. 
> Both authors for those new features independently realized that agent does 
> not currently play nice with flows set by external code due to its graceful 
> restart behaviour when rules with unknown cookies are cleaned up. [The agent 
> uses a random session uuid() to mark rules that belong to its current run.]
> 
> Before I proceed, full disclosure: I know almost nothing about OpenFlow 
> capabilities, so some pieces below may make no sense. I tried to come up with 
> high level model first and then try to map it to available OF features. 
> Please don’t hesitate to comment, I like to learn new stuff! ;)
> 
> I am thinking lately on the use cases we collected so far. One common need 
> for all features that were seen to be interested in proper integration with 
> Open vSwitch agent is to be able to manage feature specific flows on br-int 
> and br-tun. There are other things that projects may need, like patch ports, 
> though I am still struggling with the question of whether it may be postponed 
> or avoided for phase 1.
> 
> There are several specific operation 'kinds' that we should cover for the RFE:
> - managing flows that modify frames in-place;
> - managing flows that redirect frames.
> 
> There are some things that should be considered to make features cooperate 
> with the agent and other extensions:
> - feature flows should have proper priorities based on their ‘kind’ (f.e. 
> in-place modification probably go before redirections);
> - feature flows should survive flow reset that may be triggered by the agent;
> - feature flows should survive flow reset without data plane disruption 
> (=they should support graceful restart: 
> https://review.openstack.org/#/c/182920).
> 
> With that in mind, I see the following high level design for the flow tables:
> 
> - table 0 serves as a dispatcher for specific features;
> - each feature gets one or more tables, one per flow ‘kind’ needed;
> - for each feature table, a new flow entry is added to table 0 that would 
> redirect to feature specific table; the rule will be triggered only if OF 
> metadata is not updated inside the feature table (see the next bullet); the 
> rule will have priority that is defined for the ‘kind’ of the operation that 
> is implemented by the table it redirects to;
> -  each feature table will have default actions that will 1) mark OF metadata 
> for the frame as processed by the feature; 2) redirect back to table 0;
> - all feature specific flow rules (except dispatcher rules) belong to feature 
> tables;
> 
> Now, the workflow for extensions that are interested in setting flows would 
> be:
> - on initialize() call, extension defines feature tables it will need; it 
> passes the name of the feature table and the ‘kind’ of the actions it will 
> execute; with that, the following is initialized by the agent: 1) table 0 
> dispatcher entry to redirect frames into feature table; the entry has the 
> priority according to the ‘kind’ of the table; 2) the actual feature table 
> with two default rules (update metadata and push back to table 0);
> - whenever extension needs to add a new flow rule, it passes the following 
> into the agent: 1) table name; 2) flow specific parameters (actions, 
> priority, ...)
> 
> Since the agent will manage setting flows for extensions, it will be able to 
> use the active agent cookie for all feature flows; next time the agent is 
> restarted, it should be able to respin extension flows with no data plane 
> disruption. [Note: we should make sure that on agent restart, we call to 
> extensions *before* we clean up stale flow rules.]
> 
> That design will hopefully allow us to abstract interaction with flows from 
> extensions into management code inside the agent. It should guarantee 
> extensions cooperate properly assuming they properly define their priorities 
> thru ‘kinds’ of tables they have.
> 
> It is also assumed that existing flow based features integrated into the 
> agent (dvr? anti-spoofing?) will eventually move to the new flow table 
> management model.
> 
> I understand that the model does not reflect how do feature processing for 
> existing OF based features in the agent. It may require some smart 
> workarounds 

Re: [openstack-dev] [Fuel] CentOS7: merge freeze announcement

[Andrew Maksimov]

All,

Just an update: we successfully passed *Decision point 3* in Centos7 merge
plan [1], QA didn't find significant regressions after yesterday's merge
party.
The latest SWARM pass rate - 73% so we decided to proceed with merging
CentOS7 commits on Fri Dec 4.

Please note that any other commits (not related to Centos7) should be
delayed till further announcement. We expect to unfreeze fuel repos on Sun
or Mon if everything goes as planned.

[1] -
http://lists.openstack.org/pipermail/openstack-dev/2015-December/081026.html

Regards,
Andrey Maximov,
Fuel Project Manager

On Thu, Dec 3, 2015 at 3:11 PM, Andrew Maksimov 
wrote:

> Hi All,
>
> 1. According to CentOS7 Merging plan [1] we assessed list of
> FF exceptions and decided to  integrate remaining commits into CentOS7
> merge plan. So if your patch was listed in FF exceptions list please
> contact Dmitry Teselkin to add it in our merge plan.
> 2. We are freezing all git repositories that go into Fuel ISO, the only
> exception is patch for bugfix [2] (BVT blocker).
> 3. Dmitry Teselkin's team will spend the rest of the day rebasing and
> cleaning up the rest of the CentOS7 commits to make sure they're all in
> mergeable state by the end of the day.
>
> PS.
>  This decision was made with Igor Marnat and Nastya Urlapova.
>
> [1] -
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081026.html
> [2] - https://bugs.launchpad.net/fuel/+bug/1516993
>
> Regards,
> Andrey Maximov,
> Fuel Project Manager
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [os-client-config][infra] Proposing adding infra-core to core

[Terry Howe]

Sounds like a great idea.

On Thu, Dec 3, 2015 at 9:50 AM, Monty Taylor  wrote:

> Hey all,
>
> os-client-config is now in the critical path for Infra's Nodepool, meaning
> that there are some places where a bug surfacing in it can take down the
> entire CI infrastructure. Infra also uses many more of the advanced
> features in clouds.yaml than most other people, so the surface area that
> could be tickled is higher than day-to-day use via openstackclient.
>
> While this is unlikely to happen, because it's not a high-volume changing
> project, it would still be nice to have a safety valve.
>
> For that reason, and because the os-client-config core group is small in
> the first place, I'd like to add the infra-core group as a subgroup to to
> os-client-config-core.
>
> Monty
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Bug deputy process

[Armando M.]

On 3 December 2015 at 01:42, Rossella Sblendido  wrote:

> Hi Armando,
>
> On 12/02/2015 07:49 PM, Armando M. wrote:
>
>> Hi neutrinos,
>>
>> It's been a couple of months that the Bug deputy process has been in
>> place [1,2]. Since the beginning of Mitaka we have collected the
>> following statistics (for neutron and neutronclient):
>>
>> Total bug reports: 373
>>
>>   * Fix committed: 144
>>   * Unassigned: 73
>>   o New: 17
>>   o Incomplete: 20
>>   o Confirmed: 27
>>   o Triaged: 6
>>
>>
>> At first, it is clear that we do not fix issues nearly as fast as they
>> come in, but at least we managed to keep the number of
>> unassigned/unvetted bugs relatively small, so kudos to you all who
>> participated in this experiment. I don't have data based on older
>> releases, so I can't see whether we've improved or worsened, and I'd
>> like to ask for feedback from the people who played with this first
>> hand, especially on the amount of time that has taken them to do deputy
>> duty for their assigned week.
>>
>
> my feedback is very positive. I think the new process is good, thanks for
> setting it up! During my week I was looking at newly filed bugs every day
> and triaged them. This took around 1 or 2 hours a day. But it was a quiet
> week...so the load was not super high.
>

I wonder if the 'needs-attention' tag has been useful as a tool to draw
attention on bugs that have been aging, unassigned and unconfirmed for a
while.


>
> cheers,
>
> Rossella
>
>
>>   * ihrachys
>>   * regXboi
>>   * markmcclain
>>   * mestery
>>   * mangelajo
>>   * garyk
>>   * rossella_s
>>   * dougwig
>>
>> Many thanks,
>> Armando
>>
>> [1] https://wiki.openstack.org/wiki/Network/Meetings#Bug_deputy
>> [2]
>>
>> http://docs.openstack.org/developer/neutron/policies/bugs.html#neutron-bug-deputy
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [os-client-config] Proposing Morgan Fainberg for core

[Monty Taylor]

Hey all,

I'd like to propose that we include Morgan Fainberg as core on 
os-client-config. He's in the over/under on matching other active 
reviewers on the project, and he's got a good understanding of the 
related problem space. Also, he's interested and active, which for a 
low-volume project like occ is a godsend.


Monty

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [os-client-config][infra] Proposing adding infra-core to core

[Monty Taylor]

Hey all,

os-client-config is now in the critical path for Infra's Nodepool, 
meaning that there are some places where a bug surfacing in it can take 
down the entire CI infrastructure. Infra also uses many more of the 
advanced features in clouds.yaml than most other people, so the surface 
area that could be tickled is higher than day-to-day use via 
openstackclient.


While this is unlikely to happen, because it's not a high-volume 
changing project, it would still be nice to have a safety valve.


For that reason, and because the os-client-config core group is small in 
the first place, I'd like to add the infra-core group as a subgroup to 
to os-client-config-core.


Monty

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] making project_id optional in API URLs

[Sean Dague]

For folks that don't know, we've got an effort under way to look at some
of what's happened with the service catalogue, how it's organically grown,
and do some pruning and tuning to make sure it's going to support what
we want to do with OpenStack for the next 5 years (wiki page to dive
deeper here - https://wiki.openstack.org/wiki/ServiceCatalogTNG).

One of the items which came up is removing project_id from API urls.
Today there is a very odd linkage between keystone service catalog
entries and project_ids. For instance in Nova every single project has a
different API endpoint.

https://nova.api.server/v2.1/$project_id

That has implications for caching, and exposing this anonymously, and
having to carry around the whole service catalog in your oslo.context
(which means putting it over the RPC bus a lot).

For Nova, this was almost entirely ignored. It turned out to be a pretty
simple functional change to have a set of routes which don't need them -
https://review.openstack.org/#/c/233076/6  (it's more involved to have
comprehensive testing, but we'll ignore that for now).

Projects that spawned from Nova: Cinder, Glance, Ironic, Manila, Magnum,
I'm hoping this is just as much of a surface integration that optionally
dropping it shouldn't be a big deal. However, for any projects that have
it, if folks could speak up, that would be great. It would also be good
to know which projects are up for making this kind of change this cycle,
as certain future work is inhibited until we get this in. We'll be
landing this in Nova this cycle.

Swift is a different story, the project_id is a core concept in the
resources. That's fine, but when we expose a new resource for the
service catalog tng, we won't be doing the magic substitution on the
server side. New clients, consuming the new interface, will need to
construct the urls themselves.

So, for Cinder, Glance, Ironic, Manila, Magnum (and others I might have
missed) where are you standing on this one? And are there volunteers in
those projects to help move this forward?

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [reno] using 'releasenotes' directive in documents for released tarball (without git info)

[Akihiro Motoki]

Hi,

python-neutronclient recently added reno support and
I added the reno directive " . release-notes::" to the neutronclient
documentation.
As a result, this prevents users from building the documentation from
released tarballs
using 'python setup.py build_sphinx' because the reno module expects a
git tree [1].

What is the recommended way now?

The easiest way we can do now seems not to include our release notes
(release-notes directive) in our documentation and instead point the
url http://docs.openstack.org/releasenotes/ instead.

Of course, reno (or other tool chains) can be improved to generate release notes
during "python setup.py sdist" or similar process so that the
documentation which
contains 'releasenotes' sphinx directive can be generated even out of git tree.

[1] https://bugs.launchpad.net/python-neutronclient/+bug/1520096

Akihiro

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Bug deputy process

[Ihar Hrachyshka]

Armando M.  wrote:


Hi neutrinos,

It's been a couple of months that the Bug deputy process has been in  
place [1,2]. Since the beginning of Mitaka we have collected the  
following statistics (for neutron and neutronclient):


Total bug reports: 373
• Fix committed: 144
• Unassigned: 73
• New: 17
• Incomplete: 20
• Confirmed: 27
• Triaged: 6

At first, it is clear that we do not fix issues nearly as fast as they  
come in, but at least we managed to keep the number of  
unassigned/unvetted bugs relatively small, so kudos to you all who  
participated in this experiment. I don't have data based on older  
releases, so I can't see whether we've improved or worsened, and I'd like  
to ask for feedback from the people who played with this first hand,  
especially on the amount of time that has taken them to do deputy duty  
for their assigned week.

• ihrachys
• regXboi
• markmcclain
• mestery
• mangelajo
• garyk
• rossella_s
• dougwig


My perspective, it is a success. We are better at disseminating information  
about ongoing reported issues.


Timewise, it did not waste more than an hour per day for me, usually less.  
The trick I use is subscribing to all comments in all neutron bugs in LP.  
That way I don’t need to rely on UI to get the list of bugs reported during  
me on duty.


The thing I would like us to see enhanced is making sure that tags set to  
bugs are actively tracked by corresponding teams. Hint: in my case, I have  
some recurrent todo on each Fri to walk thru all ‘oslo’ bugs. I may do the  
same if/once we get ‘upgrade’ tag. It would be great to be able to  
subscribe to just specific tag for emails, but I don’t know whether it’s  
possible in LP.


So kudos for setting the process and thanks everyone involved so far,

Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Looking to contribute

[Markus Zoeller]

Lisa Jenkins  wrote on 11/02/2015 08:06:57 PM:

> From: Lisa Jenkins 
> To: openstack-dev@lists.openstack.org
> Date: 11/02/2015 08:11 PM
> Subject: [openstack-dev] Looking to contribute
> 
> Hi new dev looking to contribute and am open to anything.  Which 
> projects need resources and have some low level bugs or something 
> similar for a newbie to get started?
> Thanks,
> Lisa

Hi Lisa,

if you are still looking for a way to contribute, I would need
some help in the area of Nova's config options. Here is the 
call for that:
http://lists.openstack.org/pipermail/openstack-dev/2015-December/081271.html

Regards, Markus Zoeller (markus_z)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Bug deputy process

[Armando M.]

On 2 December 2015 at 11:02, Salvatore Orlando 
wrote:

> I only have some historical, anecdotal, and rapidly waning memory of
> previous releases.
> Nevertheless my feeling is that the process has been a success so far.
> In past times it would not have been a surprise if a bug fell under the
> radar until that well known brownish matter hit the proverbial fan.
>
> Also, only 17 bugs are in "new" status out of 373. Which means that - at
> worst - only 4.6% of reported bugs have not yet been analysed by the team.
> I reckon these numbers are rather impressive. Kudos to both the deputies
> and most importantly to Armando who set up the process.
>

Do I hear that you would like to be deputy for one of the forthcoming
weeks? :)


>
> Salvatore
>
>
> On 2 December 2015 at 19:49, Armando M.  wrote:
>
>> Hi neutrinos,
>>
>> It's been a couple of months that the Bug deputy process has been in
>> place [1,2]. Since the beginning of Mitaka we have collected the following
>> statistics (for neutron and neutronclient):
>>
>> Total bug reports: 373
>>
>>- Fix committed: 144
>>- Unassigned: 73
>>   - New: 17
>>   - Incomplete: 20
>>   - Confirmed: 27
>>   - Triaged: 6
>>
>>
>> At first, it is clear that we do not fix issues nearly as fast as they
>> come in, but at least we managed to keep the number of unassigned/unvetted
>> bugs relatively small, so kudos to you all who participated in this
>> experiment. I don't have data based on older releases, so I can't see
>> whether we've improved or worsened, and I'd like to ask for feedback from
>> the people who played with this first hand, especially on the amount of
>> time that has taken them to do deputy duty for their assigned week.
>>
>>- ihrachys
>>- regXboi
>>- markmcclain
>>- mestery
>>- mangelajo
>>- garyk
>>- rossella_s
>>- dougwig
>>
>> Many thanks,
>> Armando
>>
>> [1] https://wiki.openstack.org/wiki/Network/Meetings#Bug_deputy
>> [2]
>> http://docs.openstack.org/developer/neutron/policies/bugs.html#neutron-bug-deputy
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Testing concerns around boot from UEFI spec

[Matt Riedemann]

The boot from UEFI spec [1] is stalled a bit on testing concerns. I've 
asked that there is integration testing (either upstream or Intel hosts 
a 3rd party job for it), or we log a warning when it's used saying it's 
untested and therefore considered experimental.


I think we also want to point out UEFI boot support in the hypervisor 
support matrix for this change, which leads me to what I think are the 
three options:


1. Don't test it; this is the easy short term answer. We log the warning 
that it's not tested and considered experimental. This is easy and 
side-steps the quality issue, but also goes against our direction as a 
project. [2][3]


2. Require Intel to provide a 3rd party CI job to test this. It sounds 
like this might be a possibility, but I'm not entirely sure if it's 
necessary given the last option.


3. Get this working in devstack and add a flag to Tempest for it, then 
we can run it in the normal gate-tempest-dsvm-full job. I think the 
steps (at a high level) to make this work are:


a) install ovmf (this is in ubuntu 14.04)
b) setup an image with the proper uefi image metadata
c) configure tempest with the uefi image id (if None, it means boot from 
uefi is not supported for the given env)

d) add a test to boot from uefi using the given uefi image id

I think before we can know how feasible #3 is, someone has to test that 
out (not it!). But given the spec freeze deadline is today, how do we 
proceed?


We could say in the spec #1 is the short term plan, but emphasize that 
#3 will be investigated (but not required for the code to land in mitaka).


Unless of course people want to make 2 or 3 required for the code to land.

I'll add this to the nova meeting agenda for today.

[1] https://review.openstack.org/#/c/235983/
[2] https://review.openstack.org/#/c/252543/
[3] https://review.openstack.org/#/c/215664/9/doc/source/test_strategy.rst

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon]

[Kyrylo Galanov]

Looks great. What is the estimated date / release for this feature to be
delivered?

On Thu, Dec 3, 2015 at 4:40 PM, Timur Sufiev  wrote:

> Please take a look at
> https://blueprints.launchpad.net/horizon/+spec/horizon-glance-large-image-upload
>
> On Thu, Dec 3, 2015 at 5:21 PM Kyrylo Galanov 
> wrote:
>
>> Hello,
>>
>> When a file is uploaded to Glance, Swift through Horizon it is stored
>> locally in a temporary directory in Horizon server. This is inefficient
>> approach especially for big files.
>>
>> I would suggest to implement 'proxy' upload to Glance, Swift using chunk
>> buffer instead of storing a file locally. It would eliminate such drawbacks
>> as potential free space exhaustion.
>>
>> It would be awesome to add upload progress bar as well.
>>
>> I look forward to your constructive replies.
>>
>> Best regards,
>> Kyrylo
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Scaling our testing needs

[Ihar Hrachyshka]

Armando M.  wrote:


Hi Neutrinos,

I would like to share a proposal with you on how we could scale our  
ever-growing testing needs, and at the same time, provide guidance to the  
developers who care about the quality of the work they produce, and how  
they can protect it from the dreadful regressions!


In [1] you will see a Decision Tree: the objective is to guide us in  
deciding what is the best testing strategy for a feature, and what type  
of support to expect from our CI engine. In a nutshell we have the  
following basic options we can choose from:

• Unit testing
• Functional testing
• API testing (*)
• Fullstack testing
• Scenario testing (**)
The bottom line is: we should tap into our existing infrastructure as  
much as we can to try to minimize the amount of CI moving parts that  
allow us to test the numerous features that Neutron has. Some work has to  
happen (as highlighted below) before we can make this decision process as  
smooth as possible. In particular:


(*) The API testing framework allows us to execute tempest-style API  
tests against a Neutron live server. Assaf and I are working to address  
the overlap between Tempest and this framework, and to ensure that  
there's a clear demarcation to what test belongs to Tempest and what test  
belongs to Neutron codebases respectively. More will follow in another  
thread, so stay tuned. On the other hand, there's some work that needs to  
go into this testing framework to make the server load up non-default  
extensions.




I think we already load up "non-default" extensions as needed (think QoS or  
LBaaS):

https://github.com/openstack/neutron/blob/master/neutron/tests/contrib/gate_hook.sh#L25

(**) This is something that Ihar started in [2]. I am still unclear on  
how we intend to leverage this job and yet keep scenario-like tests for  
hardcore Neutron features in the Neutron tree. Ihar is thinking QoS, I  
may be thinking dpdk, someone else might be thinking to something yet  
again different (don't get bogged down on the actual examples). We'll  
iterate on [2], but I see it as an integral part of our end-to-end  
testing strategy. More to follow.




Side note: I don’t believe dpdk job would need tempest in the first place  
since it does not touch API in any way, so could and should be covered with  
functional/fullstack just fine. So let’s better talk e.g. ‘flavors’ here if  
we need another example in addition to QoS.


As for new additional jobs that may come and go: I believe that we have  
to revisit our approach to introduce experimental and non-voting jobs,  
and how we make them stable and ultimately running as gate jobs and, long  
term, having the features they tests supplant the ones they are meant to  
supersede (think pecan, or dvr). I have an idea on how to address the  
non-voting neglect conundrum, but I'll tackle it in another thread.


Finally, a word about projects that need testing with Neutron, advanced  
services and beyond. The same way the neutron-lib initiative is tackling  
the python side of the Neutron codebase as of now, we'll have to work to  
identify the common pieces of functionality that will allow the reuse of  
the testing machinery across multiple project, in a modular and decouple  
fashion, so that when Neutron related projects want to integrate with the  
Neutron CI engine, they will do so using good patterns rather than bad  
ones; I believe that [3] is one of them, and that's why I have been  
pushing back.




Apart from in-neutron work on common testing infrastructure, we need to  
think of how we manage gate jobs for all stadium projects. F.e. most of  
them are forced into adopting a huge hack-around called  
tools/tox_install.sh that would install proper neutron for them. Instead of  
reimplementing the script for every subproject, we better work with infra  
to define common job macros that would manage neutron installation for us.  
It would simplify our lives a lot if only we would not need to maintain the  
script in each and every stadium repo.



Feedback welcome, as I am sure I may overlooked something.

Cheers,
Armando

[1] https://wiki.openstack.org/wiki/Network/Testing
[2] https://review.openstack.org/#/c/247697/
[3] https://review.openstack.org/#/c/242925/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][all] when can we drop XML support in neutronclient? Now?

[Akihiro Motoki]

Hi,

python-neutronclient still has XML support of Neutron API.
I would like to discuss when we drop XML support in neutronclient.

Neutron API XML suppoort was marked as deprecated in Icehouse and Juno
and was dropped in Kilo. Juno is now EOL and we have no gate testing which
requires XML support. This is a minimum requirement.
>From this point, we can drop XML support now.

Another point is users who are OpenStack clouds using Juno or older versions
may use the latest python-neutronclient.
XML support in Neutron was deprecated since Icehouse, and if our deprecation
notice works, XML API is used only in cloud deployed before Icehouse.
In addition, older versions of neutronclient are available from
various distributions and PyPI.
Do we need to continue XML support for users of such cloud?
Note that we no longer have a way to test XML API support is functional.

Thanks,
Akihiro

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][all] when can we drop XML support in neutronclient? Now?

[Fawad Khaliq]

On Thu, Dec 3, 2015 at 8:59 PM, Akihiro Motoki  wrote:

> Hi,
>
> python-neutronclient still has XML support of Neutron API.
> I would like to discuss when we drop XML support in neutronclient.
>
> Neutron API XML suppoort was marked as deprecated in Icehouse and Juno
> and was dropped in Kilo. Juno is now EOL and we have no gate testing which
> requires XML support. This is a minimum requirement.
> From this point, we can drop XML support now.
>
+1

>
> Another point is users who are OpenStack clouds using Juno or older
> versions
> may use the latest python-neutronclient.
> XML support in Neutron was deprecated since Icehouse, and if our
> deprecation
> notice works, XML API is used only in cloud deployed before Icehouse.
> In addition, older versions of neutronclient are available from
> various distributions and PyPI.
> Do we need to continue XML support for users of such cloud?
> Note that we no longer have a way to test XML API support is functional.
>
> Thanks,
> Akihiro
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] [openstack-operators] Tools to move instances between projects?

[Andrew Laski]

On 12/02/15 at 10:30pm, Clint Byrum wrote:

Excerpts from Kris G. Lindgren's message of 2015-12-02 15:43:13 -0800:

I can describe our specific uses cases, not sure our same limitations apply to 
everyone.

Every developer in our company has a project created for them (user-username) 
they are allowed to spinup 5 vm's in this project to do dev/test/POC whatever.  
These projects are not tied into show back or usage that is done internally for 
orgs.  It's simply done to allow any dev to have immediate access to servers so 
that they cant test out ideas/try something ect ect.  Actual applications/teams 
create projects.  Resources used in these projects are done as show back model 
to allow us to move fake money around to help purchase capacity for the cloud.  
We are moving to a lease model for for user- projects, where we we 
automatically, unless action is taken by the user, reclaiming those resources 
after x number of days.  Additionally, every so often we cleanup projects that 
are tied to users that are no longer with the company.  It's during these 
actions that we usually find people asking if we can transfer vm's from one 
project to another project.  Only the employee has access to the

i

r user- project within openstack.


For us - we don't allow snapshots in our private cloud.  We encourage all of 
our devs to be able to rebuild any vm that is running in cloud at any time.  
Which is the line we have been toting for these requests.  However, we would 
still like to be able to support their requests.  Additionally, all of our vm's 
are joined to a domain (both linux and windows), taking a snapshot of the 
server and trying to spin it up a replacement is problematic with servers 
joined to the domain - specifically windows.  It also doesn't take care of 
floating ip's or applied security group rules, volumes that are mapped ect ect.

Taking a snapshot of the vm, making it public, booting another vm from that 
snapshot, deleting the old vm and the snapshot is pretty heavy handed... when 
we really just need to update in nova with which project the vm falls under.



I know it seems counter-intuitive, but I think having to consider the
project ID as being dynamic throughout Nova is quite a bit more heavy
handed than the process you outline above. Try and figure out how many
caches will have to be invalidated, and how complicated the accounting
process will be to transfer quota usage.


Not just Nova but every project that provides resources for the 
instance.  And then there's the question of what to do with resources 
generated by the instance that aren't tied to the instance, like volume 
and image snapshots.


This request comes up enough that ultimately I do think it will be worth 
tackling, but to me it feels like we're a long way off from being able 
to accomplish it in anything close to a reliable way.





We have also had people who didn't pay attention to which project they created 
vm's under and asked us later if we could move the vm from tenant x to tenant y.

We try to have cattle, but people, apparently, really like cows as pets.



One way to convince people to have cattle is to make pets expensive. If
they use good orchestration for resource allocation, config automation,
and save/restore state to/from object storage, then their VM doesn't have
to be moved, they just need to spin up new ones in their new project.
Otherwise, they have to wait for the snapshot transfer process.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [congress]role in Congress

[Tim Hinrichs]

Hi Yali,

To support the kind of collaboration you describe, we have multiple
policies.  (By "policy" here I mean a collection of rules.)  One reasonable
workflow is to designate some policy (e.g. "library") to be where people
define predicates and complicated relations that are useful for writing
policy in general, and then have everyone else use the tables defined in
"library".  I'd imagine we could do the same kind of workflow in the UI.

By the way, your original patch never got merged (it's got a -1 on review
and a -1 on tests), so before looking into adding new features it'd be
great if we could finish off your original patch.  Let us know if you want
help.

Tim


On Mon, Nov 30, 2015 at 2:20 AM Masahito MUROI 
wrote:

> Hi Yali,
>
> I'm not sure which your concern is about UI by Horizon or for a policy
> in Congress.
>
> On 2015/11/30 16:27, zhangyali (D) wrote:
> > Hi Tim,
> >
> > In the implementation of Congress UI, I have realized that we need to
> > add role assignment. In many systems and cases, RBAC (Role-Based Access
> > Control) is an vital function which are beneficial to the division of
> work.
> >
> > I think we should have “admin” and “tenant” user at least.  The admin
> > user could define predicates or complicated relations used in the
> > violations, and tenant user could just use the predicates defined by
> > admin user.
> >
> > A typical example is that, the owner of network connected to VM should
> > be in the same group with the owner of this VM. In this example,
> > same_group is a predicates or complicated relations. It should be
> I think this depends on how admin writes policy and what service works
> as Congress datasource. If admin want to adopt the policy to specific
> tenant, user or group, admin writes an additional policy to affect them
> by the policy.
>
>
> > defined by admin user. And this predicate could be used by any tenant
> > user. In this way, some typical or common predicates could be defined in
> > a individual admin board, and other tenant user could choose which one
> > to use.
> On the other hand, this mentions about which user has permission to edit
> and to see a policy by Horizon.
>
> best regard,
> Masahito
>
> >
> > Yali
> >
> > *发件人:*Tim Hinrichs [mailto:t...@styra.com]
> > *发送时间:*2015年11月30日10:37
> > *收件人:*zhangyali (D); OpenStack Development Mailing List (not for
> > usage questions)
> > *主题:*Re: [openstack-dev][congress]role in Congress
> >
> > Hi Yali,
> >
> > We didn't discuss role assignment for service users in Tokyo.  Could you
> > explain a bit more what you need?
> >
> > Tim
> >
> > On Sun, Nov 29, 2015 at 7:33 PM zhangyali (D)  > > wrote:
> >
> > Hi Tim and All,
> >
> > I remember there is a topic named “role assignment for service
> > users”in the Tokyo Summit. Since I have not heard any message of
> > this topic. Does anyone could contribute some information for me? I
> > think it is vital for my design of Congress UI in horizon. Thanks a
> lot!
> >
> > Best Regards,
> >
> > Yali
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> 室井 雅仁(Masahito MUROI)
> Software Innovation Center, NTT
> Tel: +81-422-59-4539，FAX: +81-422-59-2699
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Ihar Hrachyshka]

Hi,

Small update on the RFE. It was approved for Mitaka, assuming we come up  
with proper details upfront thru neutron-specs process.


In the meantime, we have found more use cases for flow management among  
features in development: QoS DSCP, also the new OF based firewall driver.  
Both authors for those new features independently realized that agent does  
not currently play nice with flows set by external code due to its graceful  
restart behaviour when rules with unknown cookies are cleaned up. [The  
agent uses a random session uuid() to mark rules that belong to its current  
run.]


Before I proceed, full disclosure: I know almost nothing about OpenFlow  
capabilities, so some pieces below may make no sense. I tried to come up  
with high level model first and then try to map it to available OF  
features. Please don’t hesitate to comment, I like to learn new stuff! ;)


I am thinking lately on the use cases we collected so far. One common need  
for all features that were seen to be interested in proper integration with  
Open vSwitch agent is to be able to manage feature specific flows on br-int  
and br-tun. There are other things that projects may need, like patch  
ports, though I am still struggling with the question of whether it may be  
postponed or avoided for phase 1.


There are several specific operation 'kinds' that we should cover for the  
RFE:

- managing flows that modify frames in-place;
- managing flows that redirect frames.

There are some things that should be considered to make features cooperate  
with the agent and other extensions:
- feature flows should have proper priorities based on their ‘kind’ (f.e.  
in-place modification probably go before redirections);

- feature flows should survive flow reset that may be triggered by the agent;
- feature flows should survive flow reset without data plane disruption  
(=they should support graceful restart:  
https://review.openstack.org/#/c/182920).


With that in mind, I see the following high level design for the flow tables:

- table 0 serves as a dispatcher for specific features;
- each feature gets one or more tables, one per flow ‘kind’ needed;
- for each feature table, a new flow entry is added to table 0 that would  
redirect to feature specific table; the rule will be triggered only if OF  
metadata is not updated inside the feature table (see the next bullet); the  
rule will have priority that is defined for the ‘kind’ of the operation  
that is implemented by the table it redirects to;
-  each feature table will have default actions that will 1) mark OF  
metadata for the frame as processed by the feature; 2) redirect back to  
table 0;
- all feature specific flow rules (except dispatcher rules) belong to  
feature tables;


Now, the workflow for extensions that are interested in setting flows would  
be:
- on initialize() call, extension defines feature tables it will need; it  
passes the name of the feature table and the ‘kind’ of the actions it will  
execute; with that, the following is initialized by the agent: 1) table 0  
dispatcher entry to redirect frames into feature table; the entry has the  
priority according to the ‘kind’ of the table; 2) the actual feature table  
with two default rules (update metadata and push back to table 0);
- whenever extension needs to add a new flow rule, it passes the following  
into the agent: 1) table name; 2) flow specific parameters (actions,  
priority, ...)


Since the agent will manage setting flows for extensions, it will be able  
to use the active agent cookie for all feature flows; next time the agent  
is restarted, it should be able to respin extension flows with no data  
plane disruption. [Note: we should make sure that on agent restart, we call  
to extensions *before* we clean up stale flow rules.]


That design will hopefully allow us to abstract interaction with flows from  
extensions into management code inside the agent. It should guarantee  
extensions cooperate properly assuming they properly define their  
priorities thru ‘kinds’ of tables they have.


It is also assumed that existing flow based features integrated into the  
agent (dvr? anti-spoofing?) will eventually move to the new flow table  
management model.


I understand that the model does not reflect how do feature processing for  
existing OF based features in the agent. It may require some smart  
workarounds to allow non-disruptive migration to new flow table setup.


It would be great to see the design bashed hard before I start to put it  
into spec format. Especially if it’s not sane. :)


Ihar

Mathieu Rohon  wrote:


Thanks ihar!

On Thu, Nov 19, 2015 at 2:32 PM, Ihar Hrachyshka   
wrote:
UPD: now that we have some understanding what’s needed from l2 agent  
extension mechanism to cater for interested subprojects (and now that we  
see that probably the agent in focus right now is OVS only), we may move  
to RFE step. I reported 

[openstack-dev] [nova] Contribution to improve Nova's config option space

[Markus Zoeller]

Who
===
If you are a new contributor and are still searching for a way to
contribute to Nova, this mail is for you. If you are not a newbie
but have a bit bandwidth available, you're welcome too :)

Why
===
Why you should bother?
* It's an easy way to start contributing
* I can offer you to help with:
* pushing patches, 
* debugging the gate,
* dealing with reviews
* and learning the general workflow
* you will learn about different functional areas and can give back
  to the community

What

There is effort ongoing to improve the way Nova offers its configuration
options to the operators [1]. In short, you have to read and understand 
code and describe the impact of config options as a black box so that the 
operators don't have to read code to understand what they are configuring.
At the end it will look like these two patches:
* https://review.openstack.org/#/c/244177/
* https://review.openstack.org/#/c/246465/

How
===
The organization is done with an etherpad [2] which contains:
* what needs to be done
* how it has to be done

Just ping me (markus_z) in the #openstack-nova channel (I'm in the
UTC+1 timezone) or grab something out of the etherpad [2] and give
it a try.

References
==
[1] blueprint "centralize config options":

http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/centralize-config-options.html
[2] https://etherpad.openstack.org/p/config-options

Regards, Markus Zoeller (markus_z)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sajeesh Cimson Sasi]

I have been working in Nova Quotas for more than a year, and  I also think that 
Nova Quota sub-team is a good idea. Let us form the team and work together.
  best 
regards
 sajeesh

From: Vilobh Meshram [vilobhmeshram.openst...@gmail.com]
Sent: 02 December 2015 01:15:31
To: OpenStack Development Mailing List (not for usage questions); OpenStack 
Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova]New Quota Subteam on Nova

I am highly supportive for the idea of Nova Quota sub-team, for something as 
complex as Quota, as it helps to move quickly on reviews and changes.

Agree with John, a test framework to test quotas will be helpful and can be one 
of the first task the Nova Quota sub team can focus on as that will lay the 
foundation for whether the bugs mentioned here http://bit.ly/1Pbr8YL are valid 
or not.

Having worked in the area of Quotas for a while now by introducing features 
like Cinder Nested Quota Driver [1] [2] I strongly feel that something like a 
Nova Quota sub-team will definitely help. Mentioning about Cinder Quota driver 
since it was accepted in Mitaka design summit that Nova Nested Quota Driver[3] 
would like to pursue the route taken by Cinder.  Since Nested quota is a one 
part of Quota subsystem and working in small team helped to iterate quickly for 
Nested Quota patches[4][5][6][7] so IMHO forming a Nova quota subteam will help.

Melanie,

If you can share the details of the bug that Joe mentioned, to reproduce quota 
bugs locally, it would be helpful.

-Vilobh (irc: vilobhmm)

[1] Code : https://review.openstack.org/#/c/205369/
[2] Blueprint : 
https://blueprints.launchpad.net/cinder/+spec/cinder-nested-quota-driver
[3] Nova Nested Quota Spec : https://review.openstack.org/#/c/209969/
[4] https://review.openstack.org/#/c/242568/
[5] https://review.openstack.org/#/c/242500/
[6] https://review.openstack.org/#/c/242514/
[7] https://review.openstack.org/#/c/242626/


On Mon, Nov 30, 2015 at 10:59 AM, melanie witt 
> wrote:
On Nov 26, 2015, at 9:36, John Garbutt 
> wrote:

> A suggestion in the past, that I like, is creating a nova functional
> test that stress tests the quota code.
>
> Hopefully that will be able to help reproduce the error.
> That should help prove if any proposed fix actually works.

+1, I think it's wise to get some data on the current state of quotas before 
choosing a redesign. IIRC, Joe Gordon described a test scenario he used to use 
to reproduce quota bugs locally, in one of the launchpad bugs. If we could 
automate something like that, we could use it to demonstrate how quotas 
currently behave during parallel requests and try things like disabling 
reservations. I also like the idea of being able to verify the effects of 
proposed fixes.

-melanie (irc: melwitt)






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev