Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[Zhipeng Huang]

+2

On Sat, Oct 15, 2016 at 10:56 AM, Henry Gessau  wrote:

> Thanks for organizing this Miguel!
> I plan to attend.
>
> Miguel Lavalle  wrote:
> > Dear Neutrinos,
> >
> > I am organizing a social event for the team on Thursday 27th at 19:30.
> After
> > doing some Google research, I am proposing Raco de la Vila, which is
> located
> > in Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here:
> > http://www.racodelavila.com/en/carta-racodelavila.htm
> >
> > It is easy to get there by subway from the Summit venue:
> > https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
> under
> > 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can
> get a
> > final count.
> >
> > Here's some reviews:
> > https://www.tripadvisor.com/Restaurant_Review-g187497-
> d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
> >
> > Cheers
> >
> > Miguel
>
>
> __
> 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
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] Neutron team social event in Barcelona

[Henry Gessau]

Thanks for organizing this Miguel!
I plan to attend.

Miguel Lavalle  wrote:
> Dear Neutrinos,
> 
> I am organizing a social event for the team on Thursday 27th at 19:30. After
> doing some Google research, I am proposing Raco de la Vila, which is located
> in Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here:
> http://www.racodelavila.com/en/carta-racodelavila.htm
> 
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under
> 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get a
> final count.
> 
> Here's some reviews:
> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
> 
> Cheers
> 
> Miguel


__
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] [tricircle] MUST TO HAVE patches for tricircle cleaning

[joehuang]

As suggested, it's better to put priority for each patch set, so patches are 
marked the the tags here according to our cleaning and splitting plan:

Urgent patches:
No urgent patch yet.

MUST TO HAVE patches to get merged before the end of Oct.19:
   MUST TO HAVE  1. central and local plugin for l3: 
https://review.openstack.org/#/c/378476/
   MUST TO HAVE  2. remove api gateway code: 
https://review.openstack.org/#/c/384182/
   MUST TO HAVE  3. security group support: 
https://review.openstack.org/#/c/380054/
   MUST TO HAVE, merged  4: Single Node installation: 
https://review.openstack.org/#/c/384872/
   MUST TO HAVE  5. Multi nodes installation:  
https://review.openstack.org/#/c/385306/

Good to have patches (not required to merge before Oct.19):
   Implement resource routing features: https://review.openstack.org/#/c/375976/
   other patches not listed here

Best Regards
Chaoyi Huang (joehuang)

From: joehuang
Sent: 12 October 2016 15:59
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [tricircle]Tricricle cleanning

Great, all patches are ready now for Tricircle cleaning:

Review and Merge order:

1.central and local plugin for l3: https://review.openstack.org/#/c/378476/
2. remove api gateway code: https://review.openstack.org/#/c/384182/
3.  security group support: https://review.openstack.org/#/c/380054/
4: Single Node installation: https://review.openstack.org/#/c/384872/
5. Multi nodes installation:  https://review.openstack.org/#/c/385306/

Best Regards
Chaoyi Huang (joehuang)

From: Vega Cai [luckyveg...@gmail.com]
Sent: 12 October 2016 15:52
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle]Tricricle cleanning

Hello, patch for installation guide update of multi-node deployment has just 
been submitted.  Here is the link:
https://review.openstack.org/#/c/385306/

BR
Zhiyuan

On Wed, 12 Oct 2016 at 10:17 joehuang 
> wrote:
Hello, Team,

Understand this period is keeping us quite busy, for the Tricircle cleaning is 
in parallel with newton release period. Fortunately we have made great progress 
for the Tricircle cleaning and Newton release is approaching completeness.

(https://etherpad.openstack.org/p/TricircleSplitting)


  *   DONE 1. update README: https://review.openstack.org/#/c/375218/

  *   DONE 1. local plugin spec: https://review.openstack.org/#/c/368529/

  *   DONE 1. local and central plugin: https://review.openstack.org/#/c/375281/

  *
  *   2.central and local plugin for l3: 
https://review.openstack.org/#/c/378476/

  *   2. remove api gateway code: https://review.openstack.org/#/c/384182/

  *   3.  security group support: https://review.openstack.org/#/c/380054/

  *   3. installation guide update(no api gateway):

  *   Part1: Single Node installation: https://review.openstack.org/#/c/384872/

  *   Part2: Multi nodes installation: WIP

  *

  *   - Try to get these above cleaning patches merged before Oct.19, 
before Barcelona summit.

Except the patch " Multi nodes installation", all other patches are in the 
queue of review for the Tricircle cleaning. After these patches get merged, we 
can have a first clean Tricircle baseline for networking automation, it's good 
to have a tagging for this baseline as a milestone.

Best Regards
Chaoyi Huang (joehuang)
__
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
--
BR
Zhiyuan
__
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] [daisycloud-core] Meeting minutes for IRC meeting 0800UTC Oct. 14 2016

[hu . zhijiang]

Meeting ended Fri Oct 14 08:58:52 2016 UTC.  Information about MeetBot at 
http://wiki.debian.org/MeetBot . (v 0.1.4) 
Minutes:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-14-08.02.html
 

Minutes (text): 
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-14-08.02.txt
 

Log:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-14-08.02.log.html
 



B.R.,
Zhijiang




发件人: HuZhiJiang180967/user/zte_ltd
收件人: openstack-dev@lists.openstack.org, 
日期:   2016-10-15 10:05
主题:   [openstack-dev] [daisycloud-core] Meeting minutes for IRC meeting 
0800UTC Oct. 14 2016



B.R.,
Zhijiang


__
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] [daisycloud-core] Meeting minutes for IRC meeting 0800UTC Oct. 14 2016

[hu . zhijiang]

B.R.,
Zhijiang


__
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] [tricircle]tricircle 2.0.2 release (newton)

[joehuang]

We are eager to announce the release of:  Tricircle 2.0.2,  this release is 
part of the newton stable release series, and it's the last release including 
both OpenStack API gateway and networking automation functionalities.

The splitting and cleaning for the Tricircle to only include networking 
automation is ongoing in the master branch, and coming soon.

The release notes is available from:


http://git.openstack.org/cgit/openstack/tricircle/tree/releasenotes/notes/initial-release-notes.yaml?h=2.0.2

The source is available from:

http://git.openstack.org/cgit/openstack/tricircle/tree/?h=2.0.2

Installation guide is here:

   
http://git.openstack.org/cgit/openstack/tricircle/tree/doc/source/installation.rst?h=2.0.2

Download the package from:


https://pypi.python.org/pypi/tricircle/2.0.2

Please report issues through launchpad ( OpenStack API gateway related bugs 
should be reported in Trio2o project ):

https://bugs.launchpad.net/tricircle

Best Regards
Chaoyi Huang (joehuang)
__
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] [all] running non-devstack jobs in Python projects aka "it works outside devstack"

[Brian Haley]

On 10/14/2016 05:53 PM, Clark Boylan wrote:

On Thu, Oct 13, 2016, at 05:47 PM, Emilien Macchi wrote:

Greetings OpenStack,

== Background

Since the beginning of OpenStack (or almost), devstack has been used
as a common tool to deploy OpenStack in CI environment. Most of
OpenStack projects (if not all) that are written in Python use it to
deploy the different components.
While devstack became popular and the reference in term of deployment
tool for continuous integration, devstack doesn't deploy OpenStack in
production (versus some tools like Kolla, Fuel, TripleO, Juju, etc).
It means things might (and did) break when deploying OpenStack outside
devstack, for different reasons. Some examples:

* until recently, SSL was not tested, and I believe some projects
still don't test with SSL enabled.
* IPv6 is not tested everywhere.




IPv6 testing likely means two different things to two different groups
of people. First is whether or not the cloud endpoints are hosted over
IPv6 and the other is whether or not instances launched by openstack are
assigned IPv6 addresses. The second thing has been tested for quite a
while now (tempest has had tests for it for almost 2 years though it
hasn't been enabled in the gate for that long). We should definitely
ensure that we are testing with openstack servers listening on IPv6
addresses as well.


The first item - IPv6 service endpoints, is actually covered by an experimental 
job (tempest-dsvm-neutron-serviceipv6), and devstack supports it in local.conf:


SERVICE_IP_VERSION=6

Last year it was working great, bug I've noticed there are failures now, I'll 
take a crack at getting it all working again.  Maybe it's something we could 
then promote to voting?


-Brian

__
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] Neutron team social event in Barcelona

[Doug Wiegley]

+1

Doug

> On Oct 14, 2016, at 6:24 PM, Kevin Benton  wrote:
> 
> +1
> 
> 
>> On Oct 14, 2016 1:33 PM, "Miguel Lavalle"  wrote:
>> Dear Neutrinos,
>> 
>> I am organizing a social event for the team on Thursday 27th at 19:30. After 
>> doing some Google research, I am proposing Raco de la Vila, which is located 
>> in Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here: 
>> http://www.racodelavila.com/en/carta-racodelavila.htm
>> 
>> It is easy to get there by subway from the Summit venue: 
>> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under 
>> 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get 
>> a final count.
>> 
>> Here's some reviews: 
>> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
>> 
>> Cheers
>> 
>> Miguel
>> 
>> __
>> 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] [mistral] Who's interested in attending PTG?

[Dmitri Zimine]

StackStorm is game for PGT: Winson will likely be there for Mistral F2F:
from what we see now it’s quite a few things where F2F get-together can
help  & accelerate.

So if Renat you’re in, we have 3 companies.


Cheers, Dmitri.



__
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] Neutron team social event in Barcelona

[Kevin Benton]

+1

On Oct 14, 2016 1:33 PM, "Miguel Lavalle"  wrote:

> Dear Neutrinos,
>
> I am organizing a social event for the team on Thursday 27th at 19:30.
> After doing some Google research, I am proposing Raco de la Vila, which is
> located in Poblenou: http://www.racodelavila.com/en/index.htm. The menu
> is here: http://www.racodelavila.com/en/carta-racodelavila.htm
>
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
> under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we
> can get a final count.
>
> Here's some reviews: https://www.tripadvisor.com/
> Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_
> Vila-Barcelona_Catalonia.html
>
> Cheers
>
> Miguel
>
> __
> 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] Event notification descriptors/schemas (? swagger ?)

[Joshua Harlow]

This is exactly what we are planning to do.  Work is ongoing to add 
to_json_schema
support for every VersionedObject field [1]. Then we would like to add a small
tool to nova that makes it possible to generate the json schemas for the 
versioned
notifications [2]. Meanwhile we continue to transform legacy notifications to a 
versioned
format [3].

As soon as you have json schema you can find (or create) tools that generate an 
object
model and a parser from the json schema of the notifications in any modern 
language.

I hope this work in nova will servers as an example for other OpenStack project 
and
in the end OpenStack will have well defined and easy to consume notifications.

Any feedback on our plans are highly appreciated.

Cheers,
gibi

[1] 
https://review.openstack.org/#/q/topic:bp/json-schema-for-versioned-object,n,z
[2] 
https://blueprints.launchpad.net/nova/+spec/json-schema-for-versioned-notifications
[3] https://vntburndown-gibi.rhcloud.com/index.html



Great! :)

Any thoughts on the ideas/burndown for the other projects that emit 
events (aka, going and doing similar changes, is there a list of other 
projects that need to have changes, ie glance, neutron, keystone (I think))?


-Josh

__
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] [all] running non-devstack jobs in Python projects aka "it works outside devstack"

[Clark Boylan]

On Thu, Oct 13, 2016, at 05:47 PM, Emilien Macchi wrote:
> Greetings OpenStack,
> 
> == Background
> 
> Since the beginning of OpenStack (or almost), devstack has been used
> as a common tool to deploy OpenStack in CI environment. Most of
> OpenStack projects (if not all) that are written in Python use it to
> deploy the different components.
> While devstack became popular and the reference in term of deployment
> tool for continuous integration, devstack doesn't deploy OpenStack in
> production (versus some tools like Kolla, Fuel, TripleO, Juju, etc).
> It means things might (and did) break when deploying OpenStack outside
> devstack, for different reasons. Some examples:
> 
> * until recently, SSL was not tested, and I believe some projects
> still don't test with SSL enabled.
> * IPv6 is not tested everywhere.
> * Production scenarios, with HA (HAproxy or/and Pacemaker) are not
> tested.
> 

I am a little late, but wanted to clarify some things here. You are
correct that SSL was not tested until very recently. However, any
project running the "base" neutron and nova net tempest jobs is now
being tested with the tls-proxy service enabled in devstack (for
>=ocata). There is also a growing list of other jobs that are adding
support for this. My hope is that during the ocata cycle we would enable
it by default in devstack and projects that explicitly do not work
disable it (rather than the current explicit enable where it functions).

IPv6 testing likely means two different things to two different groups
of people. First is whether or not the cloud endpoints are hosted over
IPv6 and the other is whether or not instances launched by openstack are
assigned IPv6 addresses. The second thing has been tested for quite a
while now (tempest has had tests for it for almost 2 years though it
hasn't been enabled in the gate for that long). We should definitely
ensure that we are testing with openstack servers listening on IPv6
addresses as well.

I mention this because I think these are both things that devstack
should support and test, and while experimental jobs to run other
deployment tests can only help they are not a substitute for fixing
these things in devstack.

With that out of the way I think having a diverse set of testing can
only help make OpenStack better especially for your more production like
scenarios. Devstack has very explicitly been a development tool so not
sure that those scenarios need to be supported by it.

Clark




__
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] [daisycloud-core] Kolla Mitaka requirements supported by CentOS

[Steven Dake (stdake)]

Haikel,

Apparently we are doing it wrong (according to apevec).  We should be using a 
different iscsi package.  So until we make the change, I guess epel will have 
to stay in our repos.

Regards
-steve


From: Haïkel 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, October 14, 2016 at 2:33 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [daisycloud-core] Kolla Mitaka requirements 
supported by CentOS


Le 12 oct. 2016 6:01 AM, "Steven Dake (stdake)" 
> a écrit :
>
> Haikel,
>
>
>
> We attempted removing EPEL from our repo lists.  We got build errors on 
> cinder-volume.  We have iscsi integration because vendors require it to work 
> with their third party plugins.  The package iscsi-target-utils is not in the 
> newton repos for RDO.
>
>
>
> The package that fails can be seen here:
>
> http://logs.openstack.org/04/385104/1/check/gate-kolla-dsvm-build-centos-source-centos-7-nv/f6cc1d8/console.html#_2016-10-11_19_34_40_662928
>
>
>
> If you could fix that up, it would be grand J
>
>

Sorry for the delay, it got in the wrong folder, I'll look into adding this 
package.

H.
>
> Thanks
>
> -steve
>
>
>
>
>>
>> From: Haïkel >
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>> >
>> Date: Saturday, July 2, 2016 at 2:14 PM
>>
>> To: "OpenStack Development Mailing List (not for usage questions)" 
>> >
>> Subject: Re: [openstack-dev] [daisycloud-core] Kolla Mitaka requirements 
>> supported by CentOS
>>
>>
>>
>> 2016-07-02 20:42 GMT+02:00 jason 
>> >:
>>>
>>> Pip Package Name Supported By Centos CentOS Name  Repo 
>>> Name
>>>
>>> ==
>>>
>>> ansible   yes
>>>
>>> ansible1.9.noarchepel
>>>
>>> docker-py  yes
>>>
>>> python-docker-py.noarchextras
>>>
>>> gitdb  yes
>>>
>>> python-gitdb.x86_64epel
>>>
>>> GitPython  yes
>>>
>>> GitPython.noarchepel
>>>
>>> oslo.config yes
>>>
>>> python2-oslo-config.noarch centos-openstack-mitaka
>>>
>>> pbryes
>>>
>>> python-pbr.noarch   epel
>>>
>>> setuptools yes
>>>
>>> python-setuptools.noarchbase
>>>
>>> six yes
>>>
>>> python-six.noarch base
>>>
>>> pycryptoyes
>>>
>>> python2-crypto  epel
>>>
>>> graphvizno
>>>
>>> Jinja2no (Note: Jinja2 2.7.2 will be installed as
>>>
>>> dependency by ansible)
>>>
>>>
>>
>>
>>
>> As one of RDO maintainer, I strongly invite kolla, not to use EPEL.
>>
>> It's proven very hard to prevent EPEL pushing broken updates, or push
>>
>> updates to fit OpenStack requirements.
>>
>>
>>
>> Actually, all the dependency above but ansible, docker and git python
>>
>> modules are in CentOS Cloud SIG repositories.
>>
>> If you are interested to work w/ CentOS Cloud SIG, we can add missing
>>
>> dependencies in our repositories.
>>
>>
>>
>>
>>>
>>>
>>>
>>> As above table shows, only two (graphviz and Jinja2) are not supported
>>>
>>> by centos currently. As those not supported packages are definitly not
>>>
>>> used by OpenStack as well as Daisy. So basicaly we can use pip to
>>>
>>> install them after installing other packages by yum. But note that
>>>
>>> Jinja2 2.7.2 will be installed as dependency while yum install
>>>
>>> ansible, so we need to using pip to install jinja2 2.8 after that to
>>>
>>> overide the old one. Also note that we must make sure pip is ONLY used
>>>
>>> for installing those two not supported packages.
>>>
>>>
>>>
>>> But before you trying to use pip, please consider these:
>>>
>>>
>>>
>>> 1) graphviz is just for saving image depend graph text file and is not
>>>
>>> used by default and only used in build process if it is configured to
>>>
>>> be used.
>>>
>>>
>>>
>>> 2) Jinja2 rpm can be found at
>>>
>>> http://koji.fedoraproject.org/koji/packageinfo?packageID=6506, which I
>>>
>>> think is suitable for CentOS. I have tested it.
>>>
>>>
>>>
>>> So, as far as Kolla deploy process concerned, there is no need to use
>>>
>>> pip to install graphviz and Jinja2. Further more, if we do not install
>>>
>>> Kolla either then we can get ride of pip totally!
>>>
>>>
>>>
>>> I encourage all of you to think about not using pip any more for
>>>
>>> Daisy+Kolla, because pip hase a lot of overlaps between yum/rpm, files

Re: [openstack-dev] [daisycloud-core] Kolla Mitaka requirements supported by CentOS

[Haïkel]

Le 12 oct. 2016 6:01 AM, "Steven Dake (stdake)"  a écrit :
>
> Haikel,
>
>
>
> We attempted removing EPEL from our repo lists.  We got build errors on
cinder-volume.  We have iscsi integration because vendors require it to
work with their third party plugins.  The package iscsi-target-utils is not
in the newton repos for RDO.
>
>
>
> The package that fails can be seen here:
>
>
http://logs.openstack.org/04/385104/1/check/gate-kolla-dsvm-build-centos-source-centos-7-nv/f6cc1d8/console.html#_2016-10-11_19_34_40_662928
>
>
>
> If you could fix that up, it would be grand J
>
>

Sorry for the delay, it got in the wrong folder, I'll look into adding this
package.

H.
>
> Thanks
>
> -steve
>
>
>
>
>>
>> From: Haïkel 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"

>> Date: Saturday, July 2, 2016 at 2:14 PM
>>
>> To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [daisycloud-core] Kolla Mitaka requirements
supported by CentOS
>>
>>
>>
>> 2016-07-02 20:42 GMT+02:00 jason :
>>>
>>> Pip Package Name Supported By Centos CentOS
Name  Repo Name
>>>
>>>
==
>>>
>>> ansible   yes
>>>
>>> ansible1.9.noarchepel
>>>
>>> docker-py  yes
>>>
>>> python-docker-py.noarchextras
>>>
>>> gitdb  yes
>>>
>>> python-gitdb.x86_64epel
>>>
>>> GitPython  yes
>>>
>>> GitPython.noarchepel
>>>
>>> oslo.config yes
>>>
>>> python2-oslo-config.noarch centos-openstack-mitaka
>>>
>>> pbryes
>>>
>>> python-pbr.noarch   epel
>>>
>>> setuptools yes
>>>
>>> python-setuptools.noarchbase
>>>
>>> six yes
>>>
>>> python-six.noarch base
>>>
>>> pycryptoyes
>>>
>>> python2-crypto  epel
>>>
>>> graphvizno
>>>
>>> Jinja2no (Note: Jinja2 2.7.2 will be installed as
>>>
>>> dependency by ansible)
>>>
>>>
>>
>>
>>
>> As one of RDO maintainer, I strongly invite kolla, not to use EPEL.
>>
>> It's proven very hard to prevent EPEL pushing broken updates, or push
>>
>> updates to fit OpenStack requirements.
>>
>>
>>
>> Actually, all the dependency above but ansible, docker and git python
>>
>> modules are in CentOS Cloud SIG repositories.
>>
>> If you are interested to work w/ CentOS Cloud SIG, we can add missing
>>
>> dependencies in our repositories.
>>
>>
>>
>>
>>>
>>>
>>>
>>> As above table shows, only two (graphviz and Jinja2) are not supported
>>>
>>> by centos currently. As those not supported packages are definitly not
>>>
>>> used by OpenStack as well as Daisy. So basicaly we can use pip to
>>>
>>> install them after installing other packages by yum. But note that
>>>
>>> Jinja2 2.7.2 will be installed as dependency while yum install
>>>
>>> ansible, so we need to using pip to install jinja2 2.8 after that to
>>>
>>> overide the old one. Also note that we must make sure pip is ONLY used
>>>
>>> for installing those two not supported packages.
>>>
>>>
>>>
>>> But before you trying to use pip, please consider these:
>>>
>>>
>>>
>>> 1) graphviz is just for saving image depend graph text file and is not
>>>
>>> used by default and only used in build process if it is configured to
>>>
>>> be used.
>>>
>>>
>>>
>>> 2) Jinja2 rpm can be found at
>>>
>>> http://koji.fedoraproject.org/koji/packageinfo?packageID=6506, which I
>>>
>>> think is suitable for CentOS. I have tested it.
>>>
>>>
>>>
>>> So, as far as Kolla deploy process concerned, there is no need to use
>>>
>>> pip to install graphviz and Jinja2. Further more, if we do not install
>>>
>>> Kolla either then we can get ride of pip totally!
>>>
>>>
>>>
>>> I encourage all of you to think about not using pip any more for
>>>
>>> Daisy+Kolla, because pip hase a lot of overlaps between yum/rpm, files
>>>
>>> may be overide back and force if not using them carefully. So not
>>>
>>> using pip will make things easier and make jump server more cleaner.
>>>
>>> Any ideas?
>>>
>>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Zhijiang
>>>
>>>
>>>
>>> --
>>>
>>> Yours,
>>>
>>> Jason
>>>
>>>
>>>
>>>
__
>>>
>>> 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] [nova][scheduler] Next Scheduler subteam meeting

[Ed Leafe]

The next meeting of the Nova Scheduler subteam will be on Monday, October 17 at 
1400 UTC in #openstack-meeting-alt
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20161017-T14

This will probably be a brief meeting, unless we start arguing about nested 
resource providers. I’d prefer to have those discussions in person at the 
summit. But if people are interested...

As always, the agenda is here: 
https://wiki.openstack.org/wiki/Meetings/NovaScheduler

Please add any items you’d like to discuss to the agenda before the meeting.


-- Ed Leafe






__
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] Neutron team social event in Barcelona

[Morales, Victor]

+1

From: Miguel Lavalle
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Friday, October 14, 2016 at 1:30 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron] Neutron team social event in Barcelona

Dear Neutrinos,

I am organizing a social event for the team on Thursday 27th at 19:30. After 
doing some Google research, I am proposing Raco de la Vila, which is located in 
Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here: 
http://www.racodelavila.com/en/carta-racodelavila.htm

It is easy to get there by subway from the Summit venue: 
https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under 
'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get a 
final count.

Here's some reviews: 
https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html

Cheers

Miguel
__
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] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

[Jay Pipes]

Alex, so sorry for the long delayed response! :( This just crept to
the back of my inbox unfortunately. Answer inline...

On 09/14/2016 07:24 PM, Bashmakov, Alexander wrote:

Glance and Keystone do not participate in a rolling upgrade,
because Keystone and Glance do not have a distributed component
architecture. Online data migrations will reduce total downtime
experienced during an *overall upgrade procedure* for an OpenStack
cloud, but Nova, Neutron and Cinder are the only parts of OpenStack
that are going to participate in a rolling upgrade because they are
the services that are distributed across all the many compute
nodes.


Hi Jay, I'd like to better understand why your definition of rolling
upgrades excludes Glance and Keystone? Granted they don't run
multiple disparate components over distributed systems, however, they
can still run the same service on multiple distributed nodes. So a
rolling upgrade can still be applied on a large cloud that has, for
instance 50 Glance nodes.


If you've seen a cloud with 50 Glance nodes, I would be astonished :) 
That said, the number 50 doesn't really have to do with my definition of 
rolling... lemme explain.


The primary thing that, to me at least, differentiates rolling upgrades 
of distributed software is that different nodes can contain multiple 
versions of the software and continue to communicate with other nodes in 
the system without issue.


In the case of Glance, you cannot have different versions of the Glance 
service running simultaneously within an environment, because those 
Glance services each directly interface with the Glance database and 
therefore expect the Glance DB schema to look a particular way for a 
specific version of the Glance service software.


In contrast, Nova's distributed service nodes -- the nova-compute 
services and (mostly) the nova-api services do *not* talk directly to 
the Nova database. If those services need to get or set data in the 
database, they communicate with the nova-conductor services which are 
responsible for translating (called back-versioning) the most updated 
object model schema that matches the Nova database to the schema that 
the calling node understands. This means that Nova deployers can update 
the Nova database schema and not have to at the same time update the 
software on the distributed compute nodes. In this way deployers can 
"roll out" an upgrade of the Nova software across many hundreds of 
compute nodes over an extended period of time without needing to 
restart/upgrade services all at once.


Hope this clarifies things.

Best,
-jay

p.s. I see various information on the web referring to "rolling updates" 
or "rolling releases" as simply the process of continuously applying new 
versions of software to a deployment. This is decidedly *not* what I 
refer to as a "rolling upgrade". Perhaps we should invent a different 
term from "rolling upgrade" to refer to the attributes involved in being 
able to run multiple versions of distributed software with no impact on 
the control plane? Is that what folks call a "partial upgrade"? Not sure...


 > In this case different versions of the

same service will run on different nodes simultaneously. Regards,
Alex




__
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] PTG planning

[Eric K]

Based on ML and IRC discussions and the feedback that almost all of us
expect to be able to make the PTG, I have put down our team for work
sessions at the PTG.

I'm looking forward to interacting with more project teams in Atlanta.

Thanks all!

On 10/7/16, 3:24 AM, "Masahito MUROI"  wrote:

>Thanks summarizing it, Eric.
>
>Combination of 1. and 2. looks good.
>
>Basically, we'll have work sessions in PTG for next release. Other teams
>and operator could come, so it's easy for Congress team to discuss
>anything with them.
>
>Then if needed, we can have unofficial work session of Congress team at
>summit instead of mid-cycle. We don't need to consider hosts and
>location. Additionally, we could meet Congress user who has a
>presentation and nice usecase but doesn't contribute actively.
>
>best regards,
>Masahito
>
>On 2016/10/06 16:53, Thierry Carrez wrote:
>> Good summary. It is true that for small-to-medium sized teams (which did
>> not routinely organize midcycles), there is a tough choice to make.
>>
>> See a couple of remarks inline:
>>
>> Eric K wrote:
>>> Here are some of our choices as a team, as well as some first thoughts
>>>on
>>> pros and cons:
>>>
>>> 1. Do work sessions at PTGs; no organized work sessions at summits.
>>> Pro: schedule lines up wit beginning of dev cycle
>>> Pro: work room available
>>> Pro: easy to collaborate with other teams
>>> Con: extra travel for those who will continue to attend summit.
>>
>> +Pro: PTGs are organized in cheaper locations and closer to the center
>> of mass of contributors, hopefully making it less costly to travel to
>> overall
>> +Pro: More team time (for Congress: 2-3 days instead 2-3 hours) for a
>> better return on travel investment
>>
>>> 2. Unofficial work session at summits; no work sessions at PTGs.
>>> Pro: For people who would be going to the summits anyway, this option
>>> reduces travel.
>>> Con: probably no official work room available.
>>> Con: happens at the middle of a dev cycle
>>>
>>> 3. Separately organize work sessions in the style of past mid-cycle
>>> sprints; no work sessions at any of the official openstack events.
>>> Pro: we can choose schedule and location
>>> Con: harder to collaborate with other teams
>>
>> +Con: extra travel for those who will continue to attend summit
>>
>
>
>-- 
>室井 雅仁(Masahito MUROI)
>Software Innovation Center, NTT
>Tel: +81-422-59-4539
>
>
>
>__
>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] Neutron team social event in Barcelona

[Trinath Somanchi]

+1


/Trinath


From: Miguel Lavalle 
Sent: Saturday, October 15, 2016 12:00:57 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron] Neutron team social event in Barcelona

Dear Neutrinos,

I am organizing a social event for the team on Thursday 27th at 19:30. After 
doing some Google research, I am proposing Raco de la Vila, which is located in 
Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here: 
http://www.racodelavila.com/en/carta-racodelavila.htm

It is easy to get there by subway from the Summit venue: 
https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under 
'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get a 
final count.

Here's some reviews: 
https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html

Cheers

Miguel
__
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] [keystone][qa] PCI-DSS (security compliance tests)

[Rodrigo Duarte]

On Fri, Oct 14, 2016 at 2:23 PM, Rodrigo Duarte 
wrote:

>
>
> On Fri, Oct 14, 2016 at 1:10 PM, Clark Boylan 
> wrote:
>
>> On Fri, Oct 14, 2016, at 08:21 AM, Rodrigo Duarte wrote:
>> > Hi all,
>> >
>> > Recently in keystone we got merged the PCI-DSS feature [1]. Basically,
>> we
>> > have new settings that enforce password security practices. For example,
>> > if
>> > we set the password history setting to 2, a user won't be able to update
>> > its password to one of the last 2 that have been set in the past.
>> >
>> > The issue is that, this settings, can break a couple of tests in
>> Tempest.
>> > Assuming the non-admin users in this tests don't affect any other test,
>> > I've inserted a "security_compliance" feature flag and skipped the
>> > portion
>> > of the tests that can break when the PCI-DSS settings are enabled [2].
>> >
>> > With that, I've pushed another patch that sets these settings upon
>> > DevStack
>> > deployment [3] and added the actual tests for the feature at [4]. So we
>> > have a "tempest -> devstack -> tempest" chain of patches dependencies.
>>
>> Curious why the tests for this wouldn't go into the keystone functional
>> job [5] which appear to run as a tempest plugin? Testing of these
>> features shouldn't require any other service, just keystone right
>> (though this job does start and run other services)? One big reason I
>> ask is it could help constrain the testing of non default behaviors of
>> keystone to a single job rather than needing to edit a bunch of other
>> jobs or create new jobs just to toggle the non default behavior.
>>
>
> That was the plan initially, but we considered two things:
>
> 1 - The users API is a pretty widely used API, so having it running in
> Tempest makes sense
> 2 - We need to add new settings in Tempest's config - I know that we can
> "inherit" the Tempest config's in the plugin, but looks strange having some
> stuff not actually used in Tempest but set there.
>
> But... If the both things above are acceptable, or even preferable, we can
> change the approach.
>

Turns out there were smarter ways to restore the user credentials after the
tests run, we won't need the first tempest patch after all.

Submitted the new changes at [4].


>
>
>>
>> >
>> > I want your feedback regarding this, if this approach is acceptable and,
>> > if
>> > not, what are the options.
>>
>> I don't really know which approach is more preferable but I think that
>> functional testing is an option too.
>
>
>> >
>> > Thanks!
>> >
>> > [1] https://blueprints.launchpad.net/keystone/+spec/pci-dss
>> > [2] https://review.openstack.org/#/c/382018/
>> > [3] https://review.openstack.org/#/c/377004/
>> > [4] https://review.openstack.org/#/c/378624/
>> >
>>
>> [5]
>> http://logs.openstack.org/56/371856/5/gate/gate-keystone-dsv
>> m-functional-ubuntu-xenial/c9f937c/
>>
>> Clark
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Rodrigo Duarte Sousa
> Senior Quality Engineer @ Red Hat
> MSc in Computer Science
> http://rodrigods.com
>



-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.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] [Infra] Third Party CI Question

[Pradeep Patra]

Hi all,

I was referring the CI system in OpenStack [1]. I was reading this approach
and its pretty good. One limitation I could find is the CI mechanism is
tightly coupled with git/geritt.

[snippet from [1]]
Zuul  is a tool
that determines what jobs are run when. Zuul listens to the Gerrit event
stream, and first tries to match each event to one or more pipelines.

Is there a way to make Zuul listen to Code Collaborator or other Code
review tools events and the source control system is SVN not git?

[1] http://docs.openstack.org/infra/system-config/third_party.html

Regards
Pradeep
__
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] [oslo] To PTG or not to be that is the question!

[Joshua Harlow]

Flavio Percoco wrote:

On 13/10/16 13:40 -0400, Doug Hellmann wrote:

Excerpts from Joshua Harlow's message of 2016-10-13 09:02:06 -0700:

Hi oslo folks,

It appears we also need to discuss and decide on whether oslo and its
associated folks want to try to go to the PTG (project team gathering)
or do folks in oslo not feel such a thing would be needed?

I personally could see either way being useful, but in person
discussions do seem nice though I'm also fine with async ones over
IRC to...

Thoughts from other oslo folks?

https://www.openstack.org/ptg/ (to be or not to be),

-Josh



We should try to reserve some space, even if we don't need a whole week
(or even a whole day). Given that a lot of folks on the team contribute
part time, initiatives can stall out a bit if they're not given the
bootstrapping that in-person meetings can produce.


Just wanted to +1 Doug's point here.
Flavio



Makes sense to me, I'll go ahead and ask for some PTG 'oslo' space :)

-Josh

__
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] [release] no meeting until 4 Nov

[Doug Hellmann]

As discussed in today's release team meeting, we have travel next week
and the summit the following week. We will skip holding our team meeting
until the week after the summit, 4 Nov.

Doug

__
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] Neutron team social event in Barcelona

[Miguel Lavalle]

Dear Neutrinos,

I am organizing a social event for the team on Thursday 27th at 19:30.
After doing some Google research, I am proposing Raco de la Vila, which is
located in Poblenou: http://www.racodelavila.com/en/index.htm. The menu is
here: http://www.racodelavila.com/en/carta-racodelavila.htm

It is easy to get there by subway from the Summit venue:
https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under
'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get
a final count.

Here's some reviews:
https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html

Cheers

Miguel
__
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] [telemetry] Telemetry presence at PTG in February

[gordon chung]

On 14/10/16 05:51 AM, Julien Danjou wrote:
> Therefore I did not ask for a space for our team at the next PTG.

did you request them to send the food+drinks to our homes instead? 
something to consider? :)

-- 
gord

__
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] [tripleo-ci] tripleo-quickstart-extras and tripleo third party ci

[Emilien Macchi]

On Fri, Oct 14, 2016 at 2:01 PM, Wesley Hayutin  wrote:
> Greetings,
>
> Hey everyone, I wanted to post a link to a blueprint I'm interested in
> discussing at summit with everyone.  Please share your thoughts and comments
> in the spec / gerrit review.
>
> https://blueprints.launchpad.net/tripleo/+spec/tripleo-third-party-ci-quickstart

The actual link of the spec is here:
https://review.openstack.org/#/c/386250/

Thanks, I'm really interested by the discussion we'll have around this topic.
-- 
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] [heat] Design Summit Schedule

[Zane Bitter]

On 14/10/16 09:31, Rabi Mishra wrote:

Hi All,

As agreed in the last team meeting, I've pushed the final design summit
schedule[1][2] for heat. Please have a look and let me know, if we need
to change anything (I assume, we can still make some changes in the last
week before summit).

Note: I've added some of us as moderators/chairs for few sessions
(mostly fishbowl ones).


If anybody out there more qualified than I wants to moderate the 
Convergence Phase 2 session (and it's a very low bar - having reviewed a 
single get_live_state patch would qualify) then you're welcome. If not 
I'll just show up and start making stuff up on the hoof as usual :)


- ZB


[1]
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Heat%3A

[2] https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Heat

--
Regards,
Rabi Misra



__
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] [tripleo-ci] tripleo-quickstart-extras and tripleo third party ci

[Wesley Hayutin]

Greetings,

Hey everyone, I wanted to post a link to a blueprint I'm interested in
discussing at summit with everyone.  Please share your thoughts and
comments in the spec / gerrit review.

https://blueprints.launchpad.net/tripleo/+spec/tripleo-third-party-ci-quickstart

Thank you!
__
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] [Trove] trove core team

[Peter Stachowski]

Hi Craig,

What?  Trove’s not considered ‘new technology’ anymore?!?  Wait, maybe that’s a 
good thing.  :D  It’s too bad you’re leaving as it’s been good working with 
you.  Good luck in your new projects and hopefully we’ll still bump into each 
other!

Later,
Peter

From: Craig Vyvial [mailto:cp16...@gmail.com]
Sent: October-07-16 11:23 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Trove] trove core team

Whats up yall.

So I've changed my focus over the last couple months to working on some new 
technology and do not have time to fulfill my duties as Trove Core any longer. 
I think its time to move on and step down from trove core.

I have been around for a while and seen the Trove community grow and seen great 
strides of development within Trove. I look forward to seeing the future of 
what Trove will offer within the OpenStack ecosystem. I've truly enjoyed my 
time hanging out, working with, and getting to know everyone. Feel free to 
contact me if you have wanna chat or just hang out if you around around the 
Austin area.
Thanks,
Craig Vyvial
__
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] [keystone][qa] PCI-DSS (security compliance tests)

[Rodrigo Duarte]

On Fri, Oct 14, 2016 at 1:10 PM, Clark Boylan  wrote:

> On Fri, Oct 14, 2016, at 08:21 AM, Rodrigo Duarte wrote:
> > Hi all,
> >
> > Recently in keystone we got merged the PCI-DSS feature [1]. Basically, we
> > have new settings that enforce password security practices. For example,
> > if
> > we set the password history setting to 2, a user won't be able to update
> > its password to one of the last 2 that have been set in the past.
> >
> > The issue is that, this settings, can break a couple of tests in Tempest.
> > Assuming the non-admin users in this tests don't affect any other test,
> > I've inserted a "security_compliance" feature flag and skipped the
> > portion
> > of the tests that can break when the PCI-DSS settings are enabled [2].
> >
> > With that, I've pushed another patch that sets these settings upon
> > DevStack
> > deployment [3] and added the actual tests for the feature at [4]. So we
> > have a "tempest -> devstack -> tempest" chain of patches dependencies.
>
> Curious why the tests for this wouldn't go into the keystone functional
> job [5] which appear to run as a tempest plugin? Testing of these
> features shouldn't require any other service, just keystone right
> (though this job does start and run other services)? One big reason I
> ask is it could help constrain the testing of non default behaviors of
> keystone to a single job rather than needing to edit a bunch of other
> jobs or create new jobs just to toggle the non default behavior.
>

That was the plan initially, but we considered two things:

1 - The users API is a pretty widely used API, so having it running in
Tempest makes sense
2 - We need to add new settings in Tempest's config - I know that we can
"inherit" the Tempest config's in the plugin, but looks strange having some
stuff not actually used in Tempest but set there.

But... If the both things above are acceptable, or even preferable, we can
change the approach.


>
> >
> > I want your feedback regarding this, if this approach is acceptable and,
> > if
> > not, what are the options.
>
> I don't really know which approach is more preferable but I think that
> functional testing is an option too.


> >
> > Thanks!
> >
> > [1] https://blueprints.launchpad.net/keystone/+spec/pci-dss
> > [2] https://review.openstack.org/#/c/382018/
> > [3] https://review.openstack.org/#/c/377004/
> > [4] https://review.openstack.org/#/c/378624/
> >
>
> [5]
> http://logs.openstack.org/56/371856/5/gate/gate-keystone-
> dsvm-functional-ubuntu-xenial/c9f937c/
>
> Clark
>
> __
> 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
>



-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.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] Barcelona Summit -- Monday -- openings in command-presence-workshop

[Paul Dardeau]

I attended this session in Austin and thought it was excellent. For anyone
who has uneasiness about getting up in front of others to defend their
point-of-view, I think it's time well spent.

-paul

On Fri, Oct 14, 2016 at 11:01 AM, Potter, Nathaniel <
nathaniel.pot...@intel.com> wrote:

> **Forwarding along a message from Malini Bhandaru**
>
>
>
> Hello Everyone!
>
>
>
> We have a few slots still available on Monday’s Command Presence workshop
> and are opening out to a broader audience. Please register if interested.
> Past attendees, despite their many skills and experience, vouched that they
> had learned a trick or two.
>
>
>
> https://www.openstack.org/summit/barcelona-2016/summit-
> schedule/events/16888/command-presence-workshop
>
>
>
> Regards,
>
> Malini
>
>
>
> __
> 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] PTG from the Ops Perspective - a few short notes

[Clint Byrum]

Excerpts from Eoghan Glynn's message of 2016-10-14 05:08:44 -0400:
> 
> > > > Excerpts from Jaesuk Ahn's message of 2016-10-12 15:08:24 +:
> > > >> It can be cheap if you are in the US. However, for Asia folks, it is 
> > > >> not
> > > >> that cheap considering it is all overseas travel. In addition,
> > > >> all-in-one
> > > >> event like the current summit makes us much easier to get the travel
> > > >> fund
> > > >> from the company, since the company only need to send everyone (tech,
> > > >> ops,
> > > >> business, strategy) to one event. Even as an ops or developers, doing
> > > >> presentation or a meeting with one or two important company can be very
> > > >> good excuse to get the travel money.
> > > >>
> > > >
> > > > This is definitely on the list of concerns I heard while the split was
> > > > being discussed.
> > > >
> > > > I think the concern is valid, and we'll have to see how it affects
> > > > attendance at PTG's and summits.
> > > >
> > > > However, I am not so sure the overseas cost is being accurately
> > > > characterized. Of course, the complications are higher with immigration
> > > > details, but ultimately hotels around international hub airports are
> > > > extremely cheap, and flights tend to be quite a bit less expensive and
> > > > more numerous to these locations. You'll find flights from Narita to
> > > > LAX for < $500 where as you'd be hard pressed to find Narita to Boston
> > > > for under $600, and they'll be less convenient, possibly requiring more
> > > > hotel days.
> > > 
> > > The bit about hotels contradicts my whole experience. I've never seen
> > > hotels in
> > > big busy hubs cheaper than in less popular and crowded cities. Following
> > > your
> > > logic, hotels e.g. in Paris should be cheaper than ones in e.g. Prague,
> > > which I
> > > promise you is far from being the case :)
> > > 
> > 
> > Sorry I communicated that horribly.
> > 
> > The hotels next to LAX, which are _ugly_ and _disgusting_ but perfectly
> > suitable for a PTG, are much cheaper than say, the ones in DT LA near the
> > convention center, or in Hollywood, or near Disneyland.
> > 
> > A better comparison than LAX might be Atlanta or Minneapolis, which
> > are cities that aren't such common end-destinations, but have tons of
> > flights in and out and generally affordable accommodations.
> > 
> > > >
> > > > Also worth considering is how cheap the space is for the PTG
> > > > vs. Summit. Without need for large expo halls, keynote speakers,
> > > > catered lunch and cocktail hours, we can rent a smaller, less impressive
> > > > space. That should mean either a cheaper ticket price (if there is one
> > > > at all) or more sponsored travel to the PTG. Either one of those should
> > > > help alleviate the concerns about travel budget.
> > > 
> > > For upstream developers ticker price was 0. Now it will be > 0, so for
> > > companies
> > > who send mostly developers, this is a clear budget increase.
> > > 
> > 
> > The nominal price of the PTG is expected to be something like $25 or
> > $50. This isn't to cover all the costs, but to ensure that people don't
> > just sign up "just in case I'm in the area" or anything like that.
> 
> Well, I've heard this concern about no-shows multiple times on this and
> other threads, and TBH it simply doesn't ring true to my ears.
> 
> Up to now, we've had a scenario where summit was effectively *free* to
> contributors. Did we have hoards of people sign up and then not show up?
> 

It has been free to a subset of contributors. The criteria for "ATC" has
gotten more and more amorphous as the community has grown and the system
has been gamed. The ticket was also considered more valuable, since you
get access to all the lavish parties and swag that comes with a big
conference. These things don't mean a ton to those who we want coming to
the PTG, but it did mean that the foundation was effectively writing off
$600/ATC.

The point of doing this differently is, I think, that we want to be able
to invite anybody who wants to participate on a project team to the PTG.
There, they can get involved with technical work and introduce themselves
face to face. We also just learned yesterday the price will in fact
cover some of the costs, so it's not entirely to prevent no-shows.

> And even if we did, surely it's not beyond our collective intelligence
> to simply account for that in the planning, based on historical trends.
> 
> Take a stab at it, say 20% no-shows or whatever rough rate we've seen for
> past summits. Scale the accommodation accordingly for ATL. Iterate that
> for the second PTG, based on the observed no-show rate at the first.
> 
> OTOH if the $100 in really intended to pay for the coffees and M, then
> let's just be upfront and say so. But let's not pretend that 100 bucks is
> cheaper than free.
> 

Indeed, I'm learning that it's a little different than my original
impressions had been. However, I'm still pretty sure it's going to solve
enough 

Re: [openstack-dev] PTG from the Ops Perspective - a few short notes

[Erin Disney]

Hey John- 

The plan for the Boston Summit is not fully worked out yet, but we can already 
assure you that full discount codes will be provided to all Atlanta PTG 
attendees. Will definitely keep everyone updated as additional information 
becomes available!

Erin Disney
OpenStack Marketing
e...@openstack.org 

> 
> From: John Davidge  >
> Date: Fri, Oct 14, 2016 at 4:18 AM
> Subject: Re: [openstack-dev] PTG from the Ops Perspective - a few short notes
> To: OpenStack Development Mailing List (not for usage questions) 
> >
> 
> 
> Hi Erin,
> 
> Thank you for the details. Can you tell us anything about how discount codes 
> for ATCs will change for Boston and onwards?
> 
> Thanks,
> 
> John
> 
> From: Erin Disney >
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> >
> Date: Thursday, October 13, 2016 at 10:34 PM
> To: "openstack-dev@lists.openstack.org 
> " 
> >
> 
> Subject: Re: [openstack-dev] PTG from the Ops Perspective - a few short notes
> 
> Hey everyone- wanted to introduce myself and answer a couple questions from 
> this thread. I’m Erin, part of the Foundation’s Marketing/Events team, and I 
> have been helping organize the inaugural PTG.
>  
> Here is what I can tell you from a logistics perspective: 
> The first PTG will be held February 20-24, 2017 in Atlanta, GA at the 
> downtown Sheraton Hotel 
> Our group rate for rooms is $185 a night (which includes a breakfast buffet)
> Registration will go live in the next couple of weeks and tickets will be 
> $100, which will help cover lunch/coffee every day and help us ensure 
> attendance for those that register 
> Horizontal/cross project teams will meet Monday and Tuesday, Vertical project 
> team meetings will be held Wednesday, Thursday and Friday 
> 
> For anyone going to the Summit in Barcelona later this month, Thierry and I 
> will be hosting an informational presentation on the PTG 
> 
>  and then answering questions in the Foundation Lounge (located near the main 
> entrance of the Convention Center near Registration) on Wednesday 10/26 
> during lunch from 1:05-1:35pm. Feel free to stop by to learn more or ask us 
> questions, and stay tuned for more information in the coming weeks. 
> 
> Erin Disney
> OpenStack Marketing
> e...@openstack.org 
> 
>> 
>> 
>> -- Forwarded message -
>> From: Clint Byrum >
>> Date: Thu, Oct 13, 2016 at 8:42 AM
>> Subject: Re: [openstack-dev] PTG from the Ops Perspective - a few short notes
>> To: openstack-dev > >
>> 
>> 
>> Excerpts from Dmitry Tantsur's message of 2016-10-13 10:30:44 +0200:
>> > On 10/12/2016 08:47 PM, Clint Byrum wrote:
>> > > Excerpts from Jaesuk Ahn's message of 2016-10-12 15:08:24 +:
>> > >> It can be cheap if you are in the US. However, for Asia folks, it is not
>> > >> that cheap considering it is all overseas travel. In addition, 
>> > >> all-in-one
>> > >> event like the current summit makes us much easier to get the travel 
>> > >> fund
>> > >> from the company, since the company only need to send everyone (tech, 
>> > >> ops,
>> > >> business, strategy) to one event. Even as an ops or developers, doing
>> > >> presentation or a meeting with one or two important company can be very
>> > >> good excuse to get the travel money.
>> > >>
>> > >
>> > > This is definitely on the list of concerns I heard while the split was
>> > > being discussed.
>> > >
>> > > I think the concern is valid, and we'll have to see how it affects
>> > > attendance at PTG's and summits.
>> > >
>> > > However, I am not so sure the overseas cost is being accurately
>> > > characterized. Of course, the complications are higher with immigration
>> > > details, but ultimately hotels around international hub airports are
>> > > extremely cheap, and flights tend to be quite a bit less expensive and
>> > > more numerous to these locations. You'll find flights from Narita to
>> > > LAX for < $500 where as you'd be hard pressed to find Narita to Boston
>> > > for under $600, and they'll be less convenient, possibly requiring more
>> > > hotel days.
>> >
>> > The bit about hotels contradicts my whole experience. I've never seen 
>> > hotels in
>> > big busy hubs cheaper than in less popular and crowded cities. Following 
>> > your
>> > logic, hotels e.g. in Paris should be cheaper than ones in e.g. Prague, 
>> > 

Re: [openstack-dev] [keystone][qa] PCI-DSS (security compliance tests)

[Clark Boylan]

On Fri, Oct 14, 2016, at 08:21 AM, Rodrigo Duarte wrote:
> Hi all,
> 
> Recently in keystone we got merged the PCI-DSS feature [1]. Basically, we
> have new settings that enforce password security practices. For example,
> if
> we set the password history setting to 2, a user won't be able to update
> its password to one of the last 2 that have been set in the past.
> 
> The issue is that, this settings, can break a couple of tests in Tempest.
> Assuming the non-admin users in this tests don't affect any other test,
> I've inserted a "security_compliance" feature flag and skipped the
> portion
> of the tests that can break when the PCI-DSS settings are enabled [2].
> 
> With that, I've pushed another patch that sets these settings upon
> DevStack
> deployment [3] and added the actual tests for the feature at [4]. So we
> have a "tempest -> devstack -> tempest" chain of patches dependencies.

Curious why the tests for this wouldn't go into the keystone functional
job [5] which appear to run as a tempest plugin? Testing of these
features shouldn't require any other service, just keystone right
(though this job does start and run other services)? One big reason I
ask is it could help constrain the testing of non default behaviors of
keystone to a single job rather than needing to edit a bunch of other
jobs or create new jobs just to toggle the non default behavior.

> 
> I want your feedback regarding this, if this approach is acceptable and,
> if
> not, what are the options.

I don't really know which approach is more preferable but I think that
functional testing is an option too.

> 
> Thanks!
> 
> [1] https://blueprints.launchpad.net/keystone/+spec/pci-dss
> [2] https://review.openstack.org/#/c/382018/
> [3] https://review.openstack.org/#/c/377004/
> [4] https://review.openstack.org/#/c/378624/
> 

[5]
http://logs.openstack.org/56/371856/5/gate/gate-keystone-dsvm-functional-ubuntu-xenial/c9f937c/

Clark

__
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] Barcelona Summit -- Monday -- openings in command-presence-workshop

[Potter, Nathaniel]

*Forwarding along a message from Malini Bhandaru*

Hello Everyone!

We have a few slots still available on Monday's Command Presence workshop and 
are opening out to a broader audience. Please register if interested. Past 
attendees, despite their many skills and experience, vouched that they had 
learned a trick or two.

https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16888/command-presence-workshop

Regards,
Malini

__
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] [senlin] Proposed changes to senlin core team

[Will Zhou]

Hi Dongbing,

Congratulations!

On Fri, Oct 14, 2016 at 11:01 PM 吕冬兵  wrote:

> Thanks everyone, it's my pleasure! I'll try to do my best.
>
> Regards,
> Dongbing
>
>
> -- Original --
> *From: * "Qiming Teng";
> *Date: * Fri, Oct 14, 2016 10:04 PM
> *To: * "openstack-dev";
> *Subject: * Re: [openstack-dev] [senlin] Proposed changes to senlin core
> team
>
> We have got enough votes for this nomination. Thanks everyone, and
> welcome on board lvdongbing and XueFeng Liu.
>
> Regards,
>   Qiming
>
> On Thu, Oct 13, 2016 at 08:27:34PM +0800, Qiming Teng wrote:
> > As the project keeps growing and maturing, we are happily seeing more
> > eyes on it, more hands on it. Among the many contributors, the following
> > two are outstanding:
> >
> > lvdongbing 
> > Involved in OpenStack for a few years now. His contribution is not
> > limited to senlin, but also other projects such as heat, nova, solum
> > etc. His experience and passion would be a great help to our team.
> >
> > ref:
> >
> http://stackalytics.com/?module=senlin-group=commits_id=dbcocle=all
> >
> > XueFeng Liu 
> > Both a user and a developer of senlin. His recent contribution has shown
> > that he has a good understanding of the project's mission and
> > implementation. His commits and reviews are all of good quality.
> >
> > ref:
> >
> http://stackalytics.com/?module=senlin-group=commits=all_id=jonnary-liu
> >
> > With this email, I'm formally inviting these two developers to join
> > senlin core team. Please cast your votes by replying this email, core
> > team. Thank you.
> >
> > Regards,
> >   Qiming
> >
> >
> >
> __
> > 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
>
-- 

-
​
周正喜
Mobile: 13701280947
​WeChat: 472174291
__
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] [keystone][qa] PCI-DSS (security compliance tests)

[Rodrigo Duarte]

Hi all,

Recently in keystone we got merged the PCI-DSS feature [1]. Basically, we
have new settings that enforce password security practices. For example, if
we set the password history setting to 2, a user won't be able to update
its password to one of the last 2 that have been set in the past.

The issue is that, this settings, can break a couple of tests in Tempest.
Assuming the non-admin users in this tests don't affect any other test,
I've inserted a "security_compliance" feature flag and skipped the portion
of the tests that can break when the PCI-DSS settings are enabled [2].

With that, I've pushed another patch that sets these settings upon DevStack
deployment [3] and added the actual tests for the feature at [4]. So we
have a "tempest -> devstack -> tempest" chain of patches dependencies.

I want your feedback regarding this, if this approach is acceptable and, if
not, what are the options.

Thanks!

[1] https://blueprints.launchpad.net/keystone/+spec/pci-dss
[2] https://review.openstack.org/#/c/382018/
[3] https://review.openstack.org/#/c/377004/
[4] https://review.openstack.org/#/c/378624/

-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.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] Fwd: Questions regardin https://review.openstack.org/#/c/289595/11/tools/database-migration-from-v1-to-v2.py

[Anna Taraday]

Hi!

I guess you hit https://bugs.launchpad.net/neutron/+bug/1503342, seems we
need to reopen it.

I can only suggest to create migration manually   "neutron-db-manage
--config-file /etc/neutron/neutron.conf revision -m "description of
revision" --contact/expand.
Then you will see path to file which was generated, you can edit this file
and add operation that you need.


On Thu, Sep 29, 2016 at 12:19 PM Alex Stafeyev  wrote:

> Hi
>
> I am trying to execute the lbaas db upgrade procedure but I have several
> question regarding this.
>
> From the patch:
>
> I moved to /neutron-lbaas/neutron_lbaas/db/migration
>
>
>  - Create a revision file
> I executed "neutron-db-manage revision -m "description of revision"
> --autogenerate"
>
> At this point I saw an error:
> ERROR [alembic.util.messaging] Multiple heads are present; please specify
> the head revision on which the new revision should be based, or perform a
> merge.
>   FAILED: Multiple heads are present; please specify the head revision on
> which the new revision should be based, or perform a merge.
> [
>  but checking history and migration  ( neutron-db-manage check_migration
> and neutron-db-manage history) I saw no error.
>
> No files seemed to be generated.
>
>  - Edit the created file and fill the content properly with this file
> This step is not clear to me ^
>  - Run alembic upgrade head
> What is the commend for that? (neutron-db-manage upgrade ? Did , fails)
>
>  - Run the migration upgrade code
> what is the best way to execute the command? ( python the_script.py?)
>
> Kind regards
> __
> 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
>
-- 
Regards,
Ann Taraday
__
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] [senlin] Proposed changes to senlin core team

[吕冬兵]

Thanks everyone, it's my pleasure! I'll try to do my best.


Regards,
Dongbing
 
 
-- Original --
From:  "Qiming Teng";
Date:  Fri, Oct 14, 2016 10:04 PM
To:  "openstack-dev"; 

Subject:  Re: [openstack-dev] [senlin] Proposed changes to senlin core team

 
We have got enough votes for this nomination. Thanks everyone, and
welcome on board lvdongbing and XueFeng Liu.

Regards,
  Qiming

On Thu, Oct 13, 2016 at 08:27:34PM +0800, Qiming Teng wrote:
> As the project keeps growing and maturing, we are happily seeing more
> eyes on it, more hands on it. Among the many contributors, the following
> two are outstanding:
> 
> lvdongbing 
> Involved in OpenStack for a few years now. His contribution is not
> limited to senlin, but also other projects such as heat, nova, solum
> etc. His experience and passion would be a great help to our team.
> 
> ref:
> http://stackalytics.com/?module=senlin-group=commits_id=dbcocle=all
> 
> XueFeng Liu 
> Both a user and a developer of senlin. His recent contribution has shown
> that he has a good understanding of the project's mission and
> implementation. His commits and reviews are all of good quality.
> 
> ref:
> http://stackalytics.com/?module=senlin-group=commits=all_id=jonnary-liu
> 
> With this email, I'm formally inviting these two developers to join
> senlin core team. Please cast your votes by replying this email, core
> team. Thank you.
> 
> Regards,
>   Qiming
> 
> 
> __
> 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] [nova] How to handle hw_pointer_model image meta?

[Matt Riedemann]

On 10/13/2016 2:18 PM, Matt Riedemann wrote:

On 10/13/2016 12:30 PM, Matt Riedemann wrote:

In Newton we replaced the CONF.libvirt.use_usb_tablet option with
CONF.pointer_model, both default to creating a usb tablet input device
for HVM guests in the libvirt driver.

To straddle backward compatibility with use_usb_tablet=False, we added
None and ps2mouse as options for the pointer_model config option, which
basically mean if you specify those you get whatever default input
device there is (ps2mouse for libvirt x86).

The hw_pointer_model image metadata takes precedence over the config
option in nova.

I noticed today that the hw_pointer_model ImageMeta object property is
using a field with a single enum, 'usbtablet'. So while the config
option lets you set None/ps2mouse/usbtablet, the image meta value can
only be usbtablet if it's set.

This is important because we don't have hw_pointer_model defined in the
glance libvirt image metadefs:

https://github.com/openstack/glance/blob/13.0.0/etc/metadefs/compute-libvirt-image.json



I'd like to add it but the only value you can have for it is 'usbtablet'
right now. Having a single enum value seems kind of weird, but maybe
that's fine. I only found 3 other image metadefs in glance that had
'None' as possible enum values.

So would we define 'ps2mouse' as a hw_pointer_model option in nova or
just add hw_pointer_model to glance and it has a single enum value for
setting it, which is usbtablet? If you don't want usbtablet then you
don't add hw_pointer_model to your image - HOWEVER - given we default
CONF.pointer_model='usbtablet' we're still going to try and set it when
creating the guest, which may or may not fail depending on your other
config for that compute host (e.g. any non-kvm/qemu virt_type will fail).

Alternatively we could change the default value of CONF.pointer_model to
be None and then it's purely an opt-in behavior, but it would be a
change in default behavior for guests on kvm/qemu hosts.



FWIW this is what the proposed metadef change looks like:

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



FWIW I think sahid and I figured out the right path forward. Before 
newton and the pointer_model option the use_usb_tablet option was only 
considered if the other dependent configs allowed it, so VNC or SPICE 
and HVM. If those failed, then we didn't try to force usbtablet on the 
guest and we didn't fail.


So we're going to do that same behavior but only if the image meta 
doesn't have hw_pointer_model='usbtablet'. So if the user specifically 
requests that behavior and we can't satisfy it, we fail and reschedule 
the build to another host. But don't break by default on environments 
like lxc/uml/xen/virtuozzo.


--

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] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services

[Ihar Hrachyshka]

Alex Schultz  wrote:

On Thu, Oct 13, 2016 at 3:27 AM, Thomas Bechtold   
wrote:

On Tue, Oct 11, 2016 at 12:32:40PM -0600, Alex Schultz wrote:
On Tue, Oct 11, 2016 at 1:39 AM, Thomas Bechtold   
wrote:

Hi,

On Mon, Oct 10, 2016 at 10:07:05AM -0600, Alex Schultz wrote:
On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold   
wrote:

Hi,

in the rpm-packaging project we started to package the services and  
are

currently discussing a possible schema for configuration files and
snippets used by the systemd .service files (but this would also  
affect

OCF resource agents).
This affects packagers, endusers and config management systems (Chef,
Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on
the list.


This also affects deployment tools so you may want to include tripleo,
kolla, fuel as they are downstream consumers and may have their own
assumptions about how services are launched.


Done.


Most services (at least for SUSE and RDO) are using a single config
(e.g. /etc/nova/nova.conf) when starting the service. Some services
(e.g. neutron services like neutron-l3-agent) use multiple config  
files.


There are multiple problems with that approach:
- when using a config-mgmt-system, users may want to override a config
option (for a feature that is not yet supported) but the
config-mgmt-system will override the config later again.


Just to chime in here from a puppet standpoint, this is not a problem
because we provide a way for a user to add any extra options they wish
using the provider so it always ends up in the correct configuration
file.


Does that also work if you need extra configuration files for 3rd party
plugins (e.g. neutron plugins) ? I guess you could just copy the 3rd
party config file content to the needed neutron config but that's ugly  
imo.


Plugins also have their own .ini files and are handled differently.
They get weird but we put the service configs in
/etc/neutron/neutron.conf and agent configs get put in .ini files.


So you put the config sections from the plugins into the neutron conf
and mix things, right?


Specifically for neutron, yes the service configs for plugins get put
in neutron.conf but I believe they are in their own section.  It seems
not to have an issue with this.


Each third party component for neutron may ship its config file to load  
into neutron-server when the component is used. You cannot handle the use  
case of those plugins shipping their own config files without some  
config-dir based mechanism. The use case is not going away any time soon,  
because of decisions made by neutron team respective to pluggability;  
decisions that are drastically different from what some other projects,  
like nova, made, which makes solutions working for nova not necessarily  
applying for neutron.


The third party config file loading complexity is the original reason why  
--config-dir options were added to RDO neutron-server systemd unit files.


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] [heat]Delete trust with exception when deleting a stack?

[Thomas Herve]

On Fri, Oct 14, 2016 at 4:39 PM, zhu4236926  wrote:
> Hi guys,
>1. I set the conifg deferred_auth_method with value trusts, so a trust
> record will be created in keystone when creating a stack, and heat save the
> trust result  to db.
>2. Delete the stack, if all resources has been deleted successfully, heat
> will delete the trust record in keytstone, then clean the db record in heat,
> if an exception occrured when deleting the trust in keystone, heat just
> print a error log and ignore the exception, then set the state of stack to
> DELETE FAILED, but the db record in heat has been deleted,  though the trust
> record is still in keystone.
>3. Delete the stack again, because all resource and trust record in heat
> has beened deleted, the stack delete successfully this time,  the trust in
> keystone created by the stack is still exsit.
>
>   My heat version is Mitaka, I think this may be a BUG,  if it's just a
> correct desigin in heat, could any one help me?

Hi,

We've had issues around that area, so it's possible there is a bug,
but what you describe looks mostly like correct behavior. Unless the
keystone error was transient, and we're meant to retry. What kind of
errors do you get exactly?

-- 
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] [tripleo] TripleO RC3

[Emilien Macchi]

On Thu, Oct 13, 2016 at 9:20 PM, Emilien Macchi  wrote:
> Team,
>
> We'll propose TripleO Newton RC3 on Friday 11am (eastern time).

Schedule changed again, since we still have a bunch of blockers.
Since hard deadline for RC is Tuesday 18th, let's give us 3 more days
and propose RC3 by Monday evening or Tuesday early morning.

> List of actions:
> - Keep reviewing 
> https://review.openstack.org/#/q/topic:tripleo/rc3+status:open
> - Keep backporting bugfixes into stable/newton if required.
> - Use ocata-1 milestone for new bugs, with newton-backport-potential
> tag if backport is relevant.
>
> After the release, I'll move RC3 bugs to Ocata-1 with the
> newton-backport-potential tag.
> We still have 5 days until the hard freeze, so still able to push for
> a new tag next week, that would be our final Newton release.
>
> I also would like to thank everyone, we did an outstanding job over
> the last weeks to respect this schedule. Big kudos to the team here
> :-)
>
> On Fri, Oct 7, 2016 at 3:45 PM, Emilien Macchi  wrote:
>> Please read Doug's email:
>> http://lists.openstack.org/pipermail/openstack-dev/2016-October/105266.html
>>
>> I think it makes sense for us to relax a bit on the RC3 and continue
>> to work on blockers we wanted fixed in stable/newton.
>> We already did amazing work to solve most of them, my hope is that we
>> can release during the next 2 weeks.
>>
>> AFIK people are still testing upgrades from Mitaka, I"m pretty sure
>> we'll have more patches to backport.
>>
>> Actions needed:
>> - Keep RC3 bugs in https://launchpad.net/tripleo/+milestone/newton-rc3
>> - they remain our current highest priority to finish.
>> - Bugs moved from Newton to Ocata-1 stay at this milestone bug can
>> have newton-backport-potential launchpad tag.
>> - New bugs are ocata-1 and can have newton-backport-potential if
>> critical bugfix or upgrade thing.
>> - Once the bug merged in master, please submit the backport into 
>> stable/newton.
>>
>> People can still continue to use:
>> https://review.openstack.org/#/q/topic:tripleo/rc3+status:open
>> To make reviews easier.
>>
>> Let me know if any question or feedback,
>>
>> Thanks and happy week-end!
>>
>> On Thu, Oct 6, 2016 at 9:08 AM, Emilien Macchi  wrote:
>>> Last reminder before RC3 release that will be proposed on Friday
>>> morning (eastern time):
>>>
>>> - use tripleo/rc3 Gerrit topic
>>> - please backport rc3 bugfixes merged in master into stable/newton
>>> - please let me know any blocker
>>>
>>> Thanks,
>>>
>>> On Fri, Sep 30, 2016 at 10:47 AM, Emilien Macchi  wrote:
 We have been granted to release a last release candidate (RC3) by next
 Friday (October 7th).

 Please use this milestone for the bugs targeted for Newton.
 https://launchpad.net/tripleo/+milestone/newton-rc3

 Some reminders:
 - assign the bug if you're working on it.
 - update it when you can, we need to know bug status before final RC.
 - use tripleo/rc3 Gerrit topic to help in reviews:
 https://review.openstack.org/#/q/topic:tripleo/rc3+status:open
 - don't forget to backport patches from master to stable/newton branch
 otherwise they'll not be part of the release.

 By next Friday, we'll proceed to final RC, any question or feedback is
 welcome, please let me or shardy know any critical blockers we might
 have missed.

 Thanks,
 --
 Emilien Macchi
>>>
>>>
>>>
>>> --
>>> Emilien Macchi
>>
>>
>>
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
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

[openstack-dev] [heat]Delete trust with exception when deleting a stack?

[zhu4236926]

Hi guys,
   1. I set the conifg deferred_auth_method with value trusts, so a trust 
record will be created in keystone when creating a stack, and heat save the 
trust result  to db.
   2. Delete the stack, if all resources has been deleted successfully, heat 
will delete the trust record in keytstone, then clean the db record in heat, if 
an exception occrured when deleting the trust in keystone, heat just print a 
error log and ignore the exception, then set the state of stack to DELETE 
FAILED, but the db record in heat has been deleted,  though the trust record is 
still in keystone.
   3. Delete the stack again, because all resource and trust record in heat has 
beened deleted, the stack delete successfully this time,  the trust in keystone 
created by the stack is still exsit.


  My heat version is Mitaka, I think this may be a BUG,  if it's just a correct 
desigin in heat, could any one help me?


Best Regards,
Sylvernass




 





 





 





 





 





 





 





 __
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] [all] running non-devstack jobs in Python projects aka "it works outside devstack"

[Miles Gould]

On 14/10/16 12:33, Sean Dague wrote:

I kind of wonder if that hints to a better model here instead of the
deployments running services from master. Instead running periodics and
moving forward reference hashes every day if tests pass, and not if they
fail. That would let deployment tools automatically move forward, quite
close to master, but not get tightly coupled into every change.


+1. This would also make debugging gate failures easier: when the only 
thing that has changed is the project under test (and not every other 
service it depends on), the source of the breakage is much more likely 
to be the patch being tested.


Miles

__
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] [senlin] Proposed changes to senlin core team

[Qiming Teng]

We have got enough votes for this nomination. Thanks everyone, and
welcome on board lvdongbing and XueFeng Liu.

Regards,
  Qiming

On Thu, Oct 13, 2016 at 08:27:34PM +0800, Qiming Teng wrote:
> As the project keeps growing and maturing, we are happily seeing more
> eyes on it, more hands on it. Among the many contributors, the following
> two are outstanding:
> 
> lvdongbing 
> Involved in OpenStack for a few years now. His contribution is not
> limited to senlin, but also other projects such as heat, nova, solum
> etc. His experience and passion would be a great help to our team.
> 
> ref:
> http://stackalytics.com/?module=senlin-group=commits_id=dbcocle=all
> 
> XueFeng Liu 
> Both a user and a developer of senlin. His recent contribution has shown
> that he has a good understanding of the project's mission and
> implementation. His commits and reviews are all of good quality.
> 
> ref:
> http://stackalytics.com/?module=senlin-group=commits=all_id=jonnary-liu
> 
> With this email, I'm formally inviting these two developers to join
> senlin core team. Please cast your votes by replying this email, core
> team. Thank you.
> 
> Regards,
>   Qiming
> 
> 
> __
> 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] [heat] Design Summit Schedule

[Rabi Mishra]

Hi All,

As agreed in the last team meeting, I've pushed the final design summit
schedule[1][2] for heat. Please have a look and let me know, if we need to
change anything (I assume, we can still make some changes in the last week
before summit).

Note: I've added some of us as moderators/chairs for few sessions (mostly
fishbowl ones).

[1]
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Heat%3A
[2] https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Heat

-- 
Regards,
Rabi Misra
__
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][stable] support phase transition for stable/* branches

[Ihar Hrachyshka]

Hi,

a friendly reminder that with the following releases shipped:

https://review.openstack.org/#/c/383781/ (mitaka)
https://review.openstack.org/#/c/383789/ (liberty)

we switch support phases for stable branches, as per [1]:

- stable/liberty is now phase III, meaning only CVE fixes are allowed (you  
should abandon any other types of patches you see proposed for the branch  
with the explanation);
- stable/mitaka moves into phase II, meaning, 'Only critical bugfixes and  
security patches are acceptable’, which we traditionally define High+  
importance bugs, plus CVEs.


This is true for all neutron stadium projects, including f.e.  
networking-sfc or ocatavia, not just openstack/neutron.*


Please keep that info in mind when approving patches for the branches;  
otherwise we may need to revert some of them later before next releases.


[1]  
http://docs.openstack.org/project-team-guide/stable-branches.html#support-phases


Thanks,
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] [oslo] To PTG or not to be that is the question!

[Flavio Percoco]

On 13/10/16 13:40 -0400, Doug Hellmann wrote:

Excerpts from Joshua Harlow's message of 2016-10-13 09:02:06 -0700:

Hi oslo folks,

It appears we also need to discuss and decide on whether oslo and its
associated folks want to try to go to the PTG (project team gathering)
or do folks in oslo not feel such a thing would be needed?

I personally could see either way being useful, but in person
discussions do seem nice though I'm also fine with async ones over IRC to...

Thoughts from other oslo folks?

https://www.openstack.org/ptg/ (to be or not to be),

-Josh



We should try to reserve some space, even if we don't need a whole week
(or even a whole day). Given that a lot of folks on the team contribute
part time, initiatives can stall out a bit if they're not given the
bootstrapping that in-person meetings can produce.


Just wanted to +1 Doug's point here.
Flavio

--
@flaper87
Flavio Percoco


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] [all] running non-devstack jobs in Python projects aka "it works outside devstack"

[Jesse Pretorius]

On 10/14/16, 12:33 PM, "Sean Dague"  wrote:

> I kind of wonder if that hints to a better model here instead of the
> deployments running services from master. Instead running periodics and
> moving forward reference hashes every day if tests pass, and not if they
> fail. That would let deployment tools automatically move forward, quite
> close to master, but not get tightly coupled into every change.

FWIW That’s pretty much what OpenStack-Ansible does for our ‘integrated build’.

We have the ‘production style’ deployment pinned to upstream SHA’s which Are 
updated once every two weeks. This allows us to get on with our own development 
instead of being disrupted every time something causes a break upstream. We 
then only have to deal with upstream-related issues when we update SHA pins.

However we do also do more focused, slightly less complex builds on a per role 
(per upstream service) basis which build directly from the upstream branch. 
These have a broader testing spectrum (more platforms, more backends) and due 
to the lower level of complexity in the number of components used in the builds 
they are generally successful unless our own patch is bad.

From my own standpoint I think that if production-type build tests (with 
functional testing) are executed using deployment projects there would need to 
be:

1. A good track record of the builds succeeding without failures due to 
circumstances that are specific to the deployment tool project. Ie The builds 
must be at least as successful as DevStack in its results with as few false 
negatives as possible.
2. Each project using these tests would need a designated liaison to the 
deployment project in order to expedite the triage of issues that arise from 
the tests. The service project person understands the service and the 
deployment project liaison understands the deployment project. Effectively they 
should pair up to quickly triage and resolve any check failures that arise.
3. The tests should not just be a deployment test – they should have some level 
of functional testing too. If this is not the case then all that’s happening is 
that the deployment tooling is being tested – not the effect of the patch to 
the service project.

J



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
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] [manila][mitaka]Where is config options for endpoint_type?

[Valeriy Ponomaryov]

Hello Igor,

I tested it and confirm that it just cannot be set and filed bug [1].

Bugfix is easy, but it is not fixed yet.

[1] https://bugs.launchpad.net/manila/+bug/1633454

Valeriy

On Fri, Oct 14, 2016 at 1:25 PM, Igor Gajsin  wrote:

> Hi folk,
>
> I've noticed that options
> cinder_catalog_info' default='volume:cinder:publicURL'
> and
> nova_catalog_info', default='compute:nova:publicURL'
> where removed from manila since mitaka.
>
> And I don't have seen any replacement for them.
> Please tell me what is new options for that?
>
> __
> 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
>
>


-- 
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@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] [tripleo] (action required) Summit schedule

[Flavio Percoco]

On 13/10/16 12:17 -0400, Emilien Macchi wrote:

Team,

I just finished a first draft of TripleO schedule for Barcelona Summit:
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=TripleO%3A

Please review it and let me know ASAP your schedule constraints if you
have some.
If you're chair, I sent you a email in private to make sure your
session is well prepared: what problem we need to solve, what outcome
do we expect.
Please take some time to finish it as soon as you can before the
Summit: https://etherpad.openstack.org/p/ocata-tripleo

Any question or feedback is welcome,


Just wanted to ack and say that there doesn't seem to be conflicts for me.

Thanks,
Flavio

--
@flaper87
Flavio Percoco


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] [all] running non-devstack jobs in Python projects aka "it works outside devstack"

[Emilien Macchi]

On Thu, Oct 13, 2016 at 10:30 PM, Davanum Srinivas  wrote:
> Please see below:
>
> On Thu, Oct 13, 2016 at 9:33 PM, Matt Riedemann
>  wrote:
>> On 10/13/2016 7:47 PM, Emilien Macchi wrote:
>>>
>>> Greetings OpenStack,
>>>
>>> == Background
>>>
>>> Since the beginning of OpenStack (or almost), devstack has been used
>>> as a common tool to deploy OpenStack in CI environment. Most of
>>> OpenStack projects (if not all) that are written in Python use it to
>>> deploy the different components.
>>> While devstack became popular and the reference in term of deployment
>>> tool for continuous integration, devstack doesn't deploy OpenStack in
>>> production (versus some tools like Kolla, Fuel, TripleO, Juju, etc).
>>> It means things might (and did) break when deploying OpenStack outside
>>> devstack, for different reasons. Some examples:
>>>
>>> * until recently, SSL was not tested, and I believe some projects
>>> still don't test with SSL enabled.
>>> * IPv6 is not tested everywhere.
>>> * Production scenarios, with HA (HAproxy or/and Pacemaker) are not tested.
>>>
>>> My point here, is that devstack has been doing very good job for its
>>> simplicity (written in bash) and its large adoption by projects to
>>> make CI, though we might consider adding more coverage to make sure it
>>> works outside devstack.
>>> As an example, Puppet OpenStack modules CI is using a devstack-like
>>> job (with 3 scenarios), called puppet-openstack-integration [1] but we
>>> also run TripleO and Fuel CI jobs, to increase coverage and give a
>>> better feedback on testing.
>>>
>>>
>>> == Proposal
>>>
>>> This is not about removing devstack! The idea is to add more coverage
>>> in an iterative way, with some other tools.
>>> We started some months ago by running TripleO CI jobs in Ironic and
>>> Heat gates (experimental pipeline) because TripleO is high consumer of
>>> Ironic and Heat.
>>> Also, we recently added our TripleO multinode job in Nova experimental
>>> pipeline (doc here [2]).
>>> Now, we are moving forward with python-openstackclient and osc-lib.
>>>
>>> I started to draft a document about how we could increase coverage in
>>> different projects:
>>>
>>> https://docs.google.com/spreadsheets/d/1bLg-uEGrQXyRZ-FuR6pf1WT4XN0-6MrlfqEShI7xMxg/edit#gid=0
>>>
>>> (feel free to add your project and give your opinion directly in the
>>> spreadsheet).
>>>
>>> The intention here is to discuss with teams interested by such CI
>>> coverage. We don't want to slow down or break your gate (example with
>>> TripleO, our jobs are non-voting outside TripleO and take ~45 min);
>>> but reduce the feedback loop between developers and deployment tools
>>> used in production.
>>> We don't expect developers to investigate why new CI jobs would fail
>>> (ex: a Nova developer to look at TripleO CI job), it would be unfair.
>>> Just some horizontal communication would be enough, IRC or email, to
>>> inform that a patch might break a CI job outside devstack.
>>> I also want to mention that the proposal is not only about TripleO. I
>>> used this tool in my examples because I'm working on it but obviously
>>> this proposal should be open to Big Tent projects that also deploy
>>> OpenStack.
>>>
>>> Please give any feedback, and let's make OpenStack testing stronger!
>>> Thanks for reading so far,
>>>
>>> [1] https://github.com/openstack/puppet-openstack-integration
>>> [2] https://review.openstack.org/#/c/381838/
>>>
>>
>> I don't really have a problem with wanting to run non-devstack deployment
>> tool jobs against project changes on-demand (experimental queue job). That's
>> why I approved the change to add that TripleO job to nova's experimental
>> queue.
>>
>> The experimental queue is only on-demand though, so reviewers have to be
>> conscious of running it and even then people don't think to check the
>> results, or a failure might not be obvious as to what caused it (my patch,
>> or is this job always broken and is thus in the experimental queue, like the
>> nova-lxc job?).
>>
>> For better or worse devstack is at least universally used and it's THE
>> default thing we point newcomers to when getting started if they want to
>> quickly and easily get a development environment with a running openstack on
>> a single-node up and running to kick the tires. I can't say the same for the
>> plethora of other deployment projects out there like kolla, ansible, salt,
>> puppet, chef, tripleo/packstack/rdo, fuel, etc, etc. I think that's what's
>> really caused the lack of universal adoption of anything besides devstack in
>> our CI environment. And love it or hate it, I think anyone that's been
>> around for awhile and tries to debug gate failures is at least used to
>> hacking on devstack and knows how it works to a certain extent.
>>
>> Anyway, as I said, I've got no problem with getting some additional optional
>> non-voting coverage in other projects besides devstack to at least try and
>> prevent breaking 

Re: [openstack-dev] [all] running non-devstack jobs in Python projects aka "it works outside devstack"

[Emilien Macchi]

On Thu, Oct 13, 2016 at 11:59 PM, Steve Martinelli
 wrote:
> On Thu, Oct 13, 2016 at 10:30 PM, Davanum Srinivas 
> wrote:
>>
>>
>> Matt, Emilien,
>>
>> there's one more option, run jobs daily and add the output to the
>> openstack health dashboard.
>> example -
>> http://status.openstack.org/openstack-health/#/g/build_name/periodic-ironic-py35-with-oslo-master
>
>
> But that only runs against what is merged on master right? I think Emilien
> wants to catch changes that break before they are merged.

Exactly.

> Emilien, I think it's also worth noting which projects you intend to make
> these changes to? Just "core" projects + projects that tripleO uses (heat +
> ironic) + projects that have burned you in the past (OSC)? Or do you plan on
> covering all projects?

Not all projects, but those in which we had some breakages over the
last 6 months. We think installers can bring useful feedback to these
projects.

> Finding a balance between not enough testing, and overusing infra resources
> is tricky, we should only aim for high value targets like the ones listed
> above. I can't imagine this being run on all check jobs everywhere.

Right, we don't want to waste Infra resources, that's why I started
this discussion to see if it's really worth it and get the feedback
from our community.

Thanks,
-- 
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] [all] running non-devstack jobs in Python projects aka "it works outside devstack"

[Emilien Macchi]

On Fri, Oct 14, 2016 at 7:33 AM, Sean Dague  wrote:
> On 10/13/2016 11:59 PM, Steve Martinelli wrote:
>>
>> On Thu, Oct 13, 2016 at 10:30 PM, Davanum Srinivas > > wrote:
>>
>>
>> Matt, Emilien,
>>
>> there's one more option, run jobs daily and add the output to the
>> openstack health dashboard.
>> example -
>>
>> http://status.openstack.org/openstack-health/#/g/build_name/periodic-ironic-py35-with-oslo-master
>>
>> 
>>
>>
>> But that only runs against what is merged on master right? I think
>> Emilien wants to catch changes that break before they are merged.
>>
>> Emilien, I think it's also worth noting which projects you intend to
>> make these changes to? Just "core" projects + projects that tripleO uses
>> (heat + ironic) + projects that have burned you in the past (OSC)? Or do
>> you plan on covering all projects?
>>
>> Finding a balance between not enough testing, and overusing infra
>> resources is tricky, we should only aim for high value targets like the
>> ones listed above. I can't imagine this being run on all check jobs
>> everywhere.
>
>
> It's not just overuse of infra resources. Anything that's more complicated
> than unit tests has > 0% chance of failure. So every new complex full stack
> test is going to -1 some set of good patches.
>
> The best thing to do when there is a break is to figure out what the root
> cause was, and push testing back as low in the stack as possible. Was there
> a good unit test that could have prevented it? That's super cheap, and helps
> a ton going forward. Or realize that projects are using undefined behavior
> of other tools, and we need to define that behavior.
>
> The deployment teams are releasing their final version of things weeks after
> the newton release hits. By nature there is some following time.
>
> I kind of wonder if that hints to a better model here instead of the
> deployments running services from master. Instead running periodics and
> moving forward reference hashes every day if tests pass, and not if they
> fail. That would let deployment tools automatically move forward, quite
> close to master, but not get tightly coupled into every change.
>
> Because I do get concerned for deciding that every developer needs to
> understand tripleo, and ansible, and fuel and the configuration decisions
> they made, the bugs they have, the way their services are deployed, to be
> able to land any patches. Because I think that will further reduce the pool
> of developers that can contribute.

I explicitly mentioned the opposite in the proposal, let me copy/paste it again:

"We don't expect developers to investigate why new CI jobs would fail
(ex: a Nova developer to look at TripleO CI job), it would be unfair.
Just some horizontal communication would be enough, IRC or email, to
inform that a patch might break a CI job outside devstack."

If a CI job is breaking because of a patch, deployment tools folks
would look at the CI job and tell to the project why it fails, who
would decide if whether or not it's a blocker (ie: indeed, the patch
is breaking backward compatibility, or no, the patch is good,
installer has to be updated, etc).

I hope it's clear that we don't expect project to spend time on this
thing and of course we don't want to reduce the pool of devs here.

-- 
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] [nova][barbican][security] Ocata design summit session change

[Dave McCowan (dmccowan)]

Thanks Matt.
Cross-project CI testing is something the Barbican team is very interested
in.
I'll make sure we have representation.

On 10/13/16, 4:15 PM, "Matt Riedemann"  wrote:

>I've changed the nova design summit session on docs needed for newton to
>now be a session to cover the various security-related specs up for
>review:
>
>https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/169
>77/nova-security-specs-and-testing
>
>And to also talk about getting a CI job going which will test some of
>these features, like with barbican as the key manager and using signed
>images.
>
>I've tagged this session with 'barbican' although I see that the
>barbican team is having another session at the same time. There was one
>other slot that I could have moved for nova but barbican had a conflict
>then too, so I've just left this where it is and if anyone from barbican
>can show up all the better, but I don't think it's necessarily a
>requirement.
>
>-- 
>
>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

Re: [openstack-dev] [all] running non-devstack jobs in Python projects aka "it works outside devstack"

[Sean Dague]

On 10/13/2016 11:59 PM, Steve Martinelli wrote:

On Thu, Oct 13, 2016 at 10:30 PM, Davanum Srinivas > wrote:


Matt, Emilien,

there's one more option, run jobs daily and add the output to the
openstack health dashboard.
example -

http://status.openstack.org/openstack-health/#/g/build_name/periodic-ironic-py35-with-oslo-master




But that only runs against what is merged on master right? I think
Emilien wants to catch changes that break before they are merged.

Emilien, I think it's also worth noting which projects you intend to
make these changes to? Just "core" projects + projects that tripleO uses
(heat + ironic) + projects that have burned you in the past (OSC)? Or do
you plan on covering all projects?

Finding a balance between not enough testing, and overusing infra
resources is tricky, we should only aim for high value targets like the
ones listed above. I can't imagine this being run on all check jobs
everywhere.


It's not just overuse of infra resources. Anything that's more 
complicated than unit tests has > 0% chance of failure. So every new 
complex full stack test is going to -1 some set of good patches.


The best thing to do when there is a break is to figure out what the 
root cause was, and push testing back as low in the stack as possible. 
Was there a good unit test that could have prevented it? That's super 
cheap, and helps a ton going forward. Or realize that projects are using 
undefined behavior of other tools, and we need to define that behavior.


The deployment teams are releasing their final version of things weeks 
after the newton release hits. By nature there is some following time.


I kind of wonder if that hints to a better model here instead of the 
deployments running services from master. Instead running periodics and 
moving forward reference hashes every day if tests pass, and not if they 
fail. That would let deployment tools automatically move forward, quite 
close to master, but not get tightly coupled into every change.


Because I do get concerned for deciding that every developer needs to 
understand tripleo, and ansible, and fuel and the configuration 
decisions they made, the bugs they have, the way their services are 
deployed, to be able to land any patches. Because I think that will 
further reduce the pool of developers that can contribute.


-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] [manila][mitaka]Where is config options for endpoint_type?

[Igor Gajsin]

Hi folk,

I've noticed that options
cinder_catalog_info' default='volume:cinder:publicURL'
and
nova_catalog_info', default='compute:nova:publicURL'
where removed from manila since mitaka.

And I don't have seen any replacement for them.
Please tell me what is new options for that?
__
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] 答复: Re: [vitrage][aodh] about aodh notifier to create a event alarm

[Julien Danjou]

On Fri, Oct 14 2016, dong.wenj...@zte.com.cn wrote:

> Is there any record about the discussion between Aodh and Vitrage?

The notes are in the Etherpad:

  https://etherpad.openstack.org/p/newton-telemetry-vitrage
  
-- 
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] [telemetry] Telemetry presence at PTG in February

[Julien Danjou]

On Thu, Oct 13 2016, gordon chung wrote:

> to be honest, i probably could be there but it's very much dependent on 
> what the topics are. i imagine considering the vast majority of our 
> contributors are not from North America, this will be a very empty room.
>
> if North America wants to step up, that'd be cool. that or if we have 
> cross-project topics.
>
> if it's just to go hang out and pat each other on the back well that 
> will be a hard sell, with or without budget.

That's also what I thought. We love to meet each others face to face,
but we really don't need that to work on our projects. :-)

Therefore I did not ask for a space for our team at the next PTG.

-- 
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] [keystone] keystoneclient.client.v3.Client: extract identity endpoint

[Johannes Grassler]

Hello,

On 10/14/2016 02:27 AM, Jamie Lennox wrote:

On 13 October 2016 at 23:19, Johannes Grassler  wrote:

[Is there a canonical way to extract the identity URL being used by 
python-keystoneclient?]
[...]

  keystone_service=client.services.list(type='identity')[0]
  client.endpoints.list(service=keystone_service,
interface='admin',
region=client.region_name)

...but that feels rather dirty since it independently looks up the
admin endpoint rather than plucking the identity endpoint from the
keystone client instance.

[...]

From the session you can do:

session.get_endpoint(service_type='identity', interface='admin',
region='region')

to get the URL from the catalog.


Ok, that is at least a little more elegant. Thank you!

Cheers,

Johannes

--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany

__
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] [tripleo] PTG space request

[Eoghan Glynn]

- Original Message -
> 
> > > > >>> I would like to request for some space dedicated to TripleO project
> > > > >>> for the first OpenStack PTG.
> > > > >>>
> > > > >>> https://www.openstack.org/ptg/
> > > > >>>
> > > > >>> The event will happen in February 2017 during the next PTG in
> > > > >>> Atlanta.
> > > > >>> Any feedback is welcome,
> > > > >>
> > > > >> Just a quick note: as you can imagine we have finite space at the
> > > > >> event,
> > > > >> and the OpenStack Foundation wants to give priority to teams which
> > > > >> have
> > > > >> a diverse affiliation (or which are not tagged "single-vendor").
> > > > >> Depending on which teams decide to take advantage of the event and
> > > > >> which
> > > > >> don't, we may or may not be able to offer space to single-vendor
> > > > >> projects -- and TripleO is currently tagged single-vendor.
> > > > > 
> > > > > Thanks for the feedback Thierry, I can understand the need to somehow
> > > > > keep
> > > > > PTG space requirements bounded, but I would agree with Emilien and
> > > > > Eoghan
> > > > > that perhaps the single-vendor tag is too coarse a metric with which
> > > > > to
> > > > > judge all projects (it really doesn't capture cross-project
> > > > > collaboration
> > > > > at all IMO).
> > > > > 
> > > > > One of the main goals of TripleO is using OpenStack projects where
> > > > > possible, and as such we have a very broad range of cross project
> > > > > collaboration happening, and clearly the PTG is the ideal forum for
> > > > > such
> > > > > discussions.
> > > > 
> > > > Indeed, I totally agree.
> > > > 
> > > > While at this stage we can't *guarantee* space for TripleO, I really
> > > > hope that we'll be able to provide space. One interesting factor is
> > > > that
> > > > there should be less tension for space in the "horizontal" part of the
> > > > week than in the "vertical" part of the week**. TripleO's cross-cutting
> > > > nature makes it a good fit for the "horizontal" segment, so I'm hopeful
> > > > we can make that work. We should know very soon, once we collect the
> > > > results of the PTL survey. Stay tuned!
> > > > 
> > > > ** The PTG week is split between horizontal team meetings
> > > > (Monday/Tuesday) and vertical team meetings (Wednesday-Friday). As we
> > > > have more vertical teams than horizontal teams (and the space is the
> > > > same size), we /should/ have more flexibility to add horizontal stuff.
> > > 
> > > This split in the PTG week raises an obvious question ...
> > > 
> > > Do we expect the horizontal folks to skip town by mid-week, or to hang
> > > around without a home-room in order to talk to the vertical folks who
> > > put the "project" in "cross-project"?
> > > 
> > > Conversely, do we expect the vertical teams to turn up on the Monday in
> > > order to collaborate with the horizontal teams? (similarly without a
> > > project room for the first 2 days?)
> > > 
> > > Cheers,
> > > Eoghan
> > > 
> > 
> > We expect the "horizontal folks" and "vertical teams" to be the same
> > people, focusing on different things on different days of the week. We
> > *hope* to enable more contributions to horizontal teams as a result.
> 
> OK, that assumption could be at least partially true, especially for say
> horizontal efforts such as release-mgmt, VMT, upgrades, API-WG & such,
> and in general the type of concerns that are generally aired on the cross-
> project track at summit.
> 
> However it misses the fact that TripleO, as well as having many touch-points
> with other projects, also has its own vertical personality as an individual
> project, and so will also need space to have discussions about issues more
> internal to the project.
> 
> For such a project, assigning it to the horizontal bucket (Wed-Fri) feels

Now I've gone and confused myself ... I meant the *vertical bucket (Wed-FRi).

> more appropriate. I'd expect joint sessions between projects (e.g.TripleO/
> Ironic or Nova/Cinder) would still be help during the "vertical" portion
> of the week, especially if there's a trend towards some project-specific
> contributors limiting their attendance to those 3 days.
> 
> Cheers,
> Eoghan
> 
> 
> 
> __
> 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] [tripleo] PTG space request

[Eoghan Glynn]

> > > >>> I would like to request for some space dedicated to TripleO project
> > > >>> for the first OpenStack PTG.
> > > >>>
> > > >>> https://www.openstack.org/ptg/
> > > >>>
> > > >>> The event will happen in February 2017 during the next PTG in
> > > >>> Atlanta.
> > > >>> Any feedback is welcome,
> > > >>
> > > >> Just a quick note: as you can imagine we have finite space at the
> > > >> event,
> > > >> and the OpenStack Foundation wants to give priority to teams which
> > > >> have
> > > >> a diverse affiliation (or which are not tagged "single-vendor").
> > > >> Depending on which teams decide to take advantage of the event and
> > > >> which
> > > >> don't, we may or may not be able to offer space to single-vendor
> > > >> projects -- and TripleO is currently tagged single-vendor.
> > > > 
> > > > Thanks for the feedback Thierry, I can understand the need to somehow
> > > > keep
> > > > PTG space requirements bounded, but I would agree with Emilien and
> > > > Eoghan
> > > > that perhaps the single-vendor tag is too coarse a metric with which to
> > > > judge all projects (it really doesn't capture cross-project
> > > > collaboration
> > > > at all IMO).
> > > > 
> > > > One of the main goals of TripleO is using OpenStack projects where
> > > > possible, and as such we have a very broad range of cross project
> > > > collaboration happening, and clearly the PTG is the ideal forum for
> > > > such
> > > > discussions.
> > > 
> > > Indeed, I totally agree.
> > > 
> > > While at this stage we can't *guarantee* space for TripleO, I really
> > > hope that we'll be able to provide space. One interesting factor is that
> > > there should be less tension for space in the "horizontal" part of the
> > > week than in the "vertical" part of the week**. TripleO's cross-cutting
> > > nature makes it a good fit for the "horizontal" segment, so I'm hopeful
> > > we can make that work. We should know very soon, once we collect the
> > > results of the PTL survey. Stay tuned!
> > > 
> > > ** The PTG week is split between horizontal team meetings
> > > (Monday/Tuesday) and vertical team meetings (Wednesday-Friday). As we
> > > have more vertical teams than horizontal teams (and the space is the
> > > same size), we /should/ have more flexibility to add horizontal stuff.
> > 
> > This split in the PTG week raises an obvious question ...
> > 
> > Do we expect the horizontal folks to skip town by mid-week, or to hang
> > around without a home-room in order to talk to the vertical folks who
> > put the "project" in "cross-project"?
> > 
> > Conversely, do we expect the vertical teams to turn up on the Monday in
> > order to collaborate with the horizontal teams? (similarly without a
> > project room for the first 2 days?)
> > 
> > Cheers,
> > Eoghan
> > 
> 
> We expect the "horizontal folks" and "vertical teams" to be the same
> people, focusing on different things on different days of the week. We
> *hope* to enable more contributions to horizontal teams as a result.

OK, that assumption could be at least partially true, especially for say
horizontal efforts such as release-mgmt, VMT, upgrades, API-WG & such,
and in general the type of concerns that are generally aired on the cross-
project track at summit.

However it misses the fact that TripleO, as well as having many touch-points
with other projects, also has its own vertical personality as an individual
project, and so will also need space to have discussions about issues more
internal to the project.

For such a project, assigning it to the horizontal bucket (Wed-Fri) feels
more appropriate. I'd expect joint sessions between projects (e.g.TripleO/
Ironic or Nova/Cinder) would still be help during the "vertical" portion
of the week, especially if there's a trend towards some project-specific
contributors limiting their attendance to those 3 days.

Cheers,
Eoghan



__
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] Manila TripleO Mitaka

[Charles Short]

Hi Marios,

I have just deployed Tripleo Newton (stable) and I can see that the 
Manila templates are now present.
Can I deploy Manila yet with TripleO Newton , or is the implementation 
still incomplete?


Thanks

Charles

On 07/07/2016 17:14, Marios Andreou wrote:

On 07/07/16 14:25, Charles Short wrote:

Hi,

Hi Charles,


I am deploying TripleO Mitaka stable and want to include the NetApp
Manila driver referenced here -

http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/deploy_manila.html



thanks for pointing those docs out - to be honest I don't know why we
landed those since the manila integration itself is still in progress. I
went looking for the gerrit review but gave up - found the commit at
https://github.com/openstack/tripleo-docs/commit/01ee4f59356b7d7df572d021931a4c7fa1e07cd9
... in any case I think we need to mark these WIP and I'm doing that at
https://review.openstack.org/339109



I cannot see either templates available in the Undercloud.

Digging a bit it looks like there are some hurdles to overcome -

http://lists.openstack.org/pipermail/openstack-dev/2016-May/096126.html

Does anyone have an update on progress, especially for the NetApp driver?


Currently I am aware of three reviews related to Manila. One is the
'main' patch to land manila-generic backend and the other two are for
netap and gluster integration respectively.

 https://review.openstack.org/#/c/188137/ “Enable Manila integration
- as a composable controller service”

 https://review.openstack.org/#/c/188138/ “Add integration with
NetApp Manila driver”

 https://review.openstack.org/#/c/230936/ “Add Gluster integration to
Manila”


The Manila integration as a composable service needs to land first. The
Netapp and Gluster reviews I've not had any involvement in at all; they
will also need to tlc to get landed, but they both depend on the 'main'
manila integration patch.


Hope that helps clarify the situation somewhat,

thanks, marios




Many thanks

Charles



__
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


--
Charles Short
Cloud Engineer
Virtualization and Cloud Team
European Bioinformatics Institute (EMBL-EBI)
Tel: +44 (0)1223 494205


__
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] PTG from the Ops Perspective - a few short notes

[John Davidge]

Hi Erin,

Thank you for the details. Can you tell us anything about how discount codes 
for ATCs will change for Boston and onwards?

Thanks,

John

From: Erin Disney >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, October 13, 2016 at 10:34 PM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: Re: [openstack-dev] PTG from the Ops Perspective - a few short notes

Hey everyone- wanted to introduce myself and answer a couple questions from 
this thread. I’m Erin, part of the Foundation’s Marketing/Events team, and I 
have been helping organize the inaugural PTG.

Here is what I can tell you from a logistics perspective:

  *   The first PTG will be held February 20-24, 2017 in Atlanta, GA at the 
downtown Sheraton Hotel
  *   Our group rate for rooms is $185 a night (which includes a breakfast 
buffet)
  *   Registration will go live in the next couple of weeks and tickets will be 
$100, which will help cover lunch/coffee every day and help us ensure 
attendance for those that register
  *   Horizontal/cross project teams will meet Monday and Tuesday, Vertical 
project team meetings will be held Wednesday, Thursday and Friday

For anyone going to the Summit in Barcelona later this month, Thierry and I 
will be hosting an informational presentation on the 
PTG
 and then answering questions in the Foundation Lounge (located near the main 
entrance of the Convention Center near Registration) on Wednesday 10/26 during 
lunch from 1:05-1:35pm. Feel free to stop by to learn more or ask us questions, 
and stay tuned for more information in the coming weeks.

Erin Disney
OpenStack Marketing
e...@openstack.org



-- Forwarded message -
From: Clint Byrum >
Date: Thu, Oct 13, 2016 at 8:42 AM
Subject: Re: [openstack-dev] PTG from the Ops Perspective - a few short notes
To: openstack-dev 
>


Excerpts from Dmitry Tantsur's message of 2016-10-13 10:30:44 +0200:
> On 10/12/2016 08:47 PM, Clint Byrum wrote:
> > Excerpts from Jaesuk Ahn's message of 2016-10-12 15:08:24 +:
> >> It can be cheap if you are in the US. However, for Asia folks, it is not
> >> that cheap considering it is all overseas travel. In addition, all-in-one
> >> event like the current summit makes us much easier to get the travel fund
> >> from the company, since the company only need to send everyone (tech, ops,
> >> business, strategy) to one event. Even as an ops or developers, doing
> >> presentation or a meeting with one or two important company can be very
> >> good excuse to get the travel money.
> >>
> >
> > This is definitely on the list of concerns I heard while the split was
> > being discussed.
> >
> > I think the concern is valid, and we'll have to see how it affects
> > attendance at PTG's and summits.
> >
> > However, I am not so sure the overseas cost is being accurately
> > characterized. Of course, the complications are higher with immigration
> > details, but ultimately hotels around international hub airports are
> > extremely cheap, and flights tend to be quite a bit less expensive and
> > more numerous to these locations. You'll find flights from Narita to
> > LAX for < $500 where as you'd be hard pressed to find Narita to Boston
> > for under $600, and they'll be less convenient, possibly requiring more
> > hotel days.
>
> The bit about hotels contradicts my whole experience. I've never seen hotels 
> in
> big busy hubs cheaper than in less popular and crowded cities. Following your
> logic, hotels e.g. in Paris should be cheaper than ones in e.g. Prague, which 
> I
> promise you is far from being the case :)
>

Sorry I communicated that horribly.

The hotels next to LAX, which are _ugly_ and _disgusting_ but perfectly
suitable for a PTG, are much cheaper than say, the ones in DT LA near the
convention center, or in Hollywood, or near Disneyland.

A better comparison than LAX might be Atlanta or Minneapolis, which
are cities that aren't such common end-destinations, but have tons of
flights in and out and generally affordable accommodations.

> >
> > Also worth considering is how cheap the space is for the PTG
> > vs. Summit. Without need for large expo halls, keynote speakers,
> > catered lunch and cocktail hours, we can rent a smaller, less impressive
> > space. That should mean either a cheaper ticket price (if there is one
> > at all) or more sponsored travel to the PTG. Either one of those should
> > help alleviate the concerns about travel budget.
>
> For upstream developers 

[openstack-dev] [all][tc][ptl] Next PTL/TC elections timeframes

[Thierry Carrez]

Hi everyone,

At the last TC meeting, the newly-elected (and continuing) TC members
has been discussing the future election periods. With the Design Summit
functions being split between the OpenStack Summit and the Project Teams
Gathering, the current wording in the TC charter around election (which
uses "Design Summit" and "Summit" interchangeably) is no longer valid
and requires a change.

As a result of that discussion a proposal was made, with a focus on
limiting the impact of the change, avoid the need to modify Foundation
bylaws, and introduce some flexibility in vote organization.

See: https://review.openstack.org/#/c/385951/

The TL;DR: is that PTL elections would continue to be organized around
development cycle boundaries, while TC elections would continue to be
organized relative to OpenStack Summit dates. The net effect is that TC
elections would now be organized separately from PTL elections (rather
than run just the week after).

Another consequence is that since we'd continue to elect PTLs around
development cycles (and Ocata being a short cycle), the Ocata PTLs would
be renewed early (vote early February).

Please read more and comment on the review.

-- 
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] PTG from the Ops Perspective - a few short notes

[Eoghan Glynn]

> > > Excerpts from Jaesuk Ahn's message of 2016-10-12 15:08:24 +:
> > >> It can be cheap if you are in the US. However, for Asia folks, it is not
> > >> that cheap considering it is all overseas travel. In addition,
> > >> all-in-one
> > >> event like the current summit makes us much easier to get the travel
> > >> fund
> > >> from the company, since the company only need to send everyone (tech,
> > >> ops,
> > >> business, strategy) to one event. Even as an ops or developers, doing
> > >> presentation or a meeting with one or two important company can be very
> > >> good excuse to get the travel money.
> > >>
> > >
> > > This is definitely on the list of concerns I heard while the split was
> > > being discussed.
> > >
> > > I think the concern is valid, and we'll have to see how it affects
> > > attendance at PTG's and summits.
> > >
> > > However, I am not so sure the overseas cost is being accurately
> > > characterized. Of course, the complications are higher with immigration
> > > details, but ultimately hotels around international hub airports are
> > > extremely cheap, and flights tend to be quite a bit less expensive and
> > > more numerous to these locations. You'll find flights from Narita to
> > > LAX for < $500 where as you'd be hard pressed to find Narita to Boston
> > > for under $600, and they'll be less convenient, possibly requiring more
> > > hotel days.
> > 
> > The bit about hotels contradicts my whole experience. I've never seen
> > hotels in
> > big busy hubs cheaper than in less popular and crowded cities. Following
> > your
> > logic, hotels e.g. in Paris should be cheaper than ones in e.g. Prague,
> > which I
> > promise you is far from being the case :)
> > 
> 
> Sorry I communicated that horribly.
> 
> The hotels next to LAX, which are _ugly_ and _disgusting_ but perfectly
> suitable for a PTG, are much cheaper than say, the ones in DT LA near the
> convention center, or in Hollywood, or near Disneyland.
> 
> A better comparison than LAX might be Atlanta or Minneapolis, which
> are cities that aren't such common end-destinations, but have tons of
> flights in and out and generally affordable accommodations.
> 
> > >
> > > Also worth considering is how cheap the space is for the PTG
> > > vs. Summit. Without need for large expo halls, keynote speakers,
> > > catered lunch and cocktail hours, we can rent a smaller, less impressive
> > > space. That should mean either a cheaper ticket price (if there is one
> > > at all) or more sponsored travel to the PTG. Either one of those should
> > > help alleviate the concerns about travel budget.
> > 
> > For upstream developers ticker price was 0. Now it will be > 0, so for
> > companies
> > who send mostly developers, this is a clear budget increase.
> > 
> 
> The nominal price of the PTG is expected to be something like $25 or
> $50. This isn't to cover all the costs, but to ensure that people don't
> just sign up "just in case I'm in the area" or anything like that.

Well, I've heard this concern about no-shows multiple times on this and
other threads, and TBH it simply doesn't ring true to my ears.

Up to now, we've had a scenario where summit was effectively *free* to
contributors. Did we have hoards of people sign up and then not show up?

And even if we did, surely it's not beyond our collective intelligence
to simply account for that in the planning, based on historical trends.

Take a stab at it, say 20% no-shows or whatever rough rate we've seen for
past summits. Scale the accommodation accordingly for ATL. Iterate that
for the second PTG, based on the observed no-show rate at the first.

OTOH if the $100 in really intended to pay for the coffees and M, then
let's just be upfront and say so. But let's not pretend that 100 bucks is
cheaper than free.

Cheers,
Eoghan
 

__
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] [charms] master branches open for development

[James Page]

Hi All

Following on from yesterdays charm release (see [0]), master branches are
now open for general development across the OpenStack Charms.

Thanks again to everyone who contributed to the 16.10 charm release!

Cheers

James

[0] http://docs.openstack.org/developer/charm-guide/1610.html
__
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] Event notification descriptors/schemas (? swagger ?)

[Balázs Gibizer]

> -Original Message-
> From: Joshua Harlow [mailto:harlo...@fastmail.com]
> Sent: October 11, 2016 22:36
> 
> Chris Dent wrote:
> > On Tue, 11 Oct 2016, Joshua Harlow wrote:
> >
> >> Damn, that's crazy that the projects emitting events don't want to
> >> own the formats and versions (and schemas) that they emit. That is
> >> ummm, like ummm, what the, ha, words can't describe... And the fact
> >> that nothing much has changed since kilo, ya, also a what the...
> >
> > Nova started with versioning and schematizing notifications with this
> > blueprint:
> >
> > https://blueprints.launchpad.net/nova/+spec/versioned-notification-api
> >
> > That's sort of in the realm of what's being discussed here, but
> > centralized in nova for now.
> >
> > I agree that siloing the stuff in the code is bad in the long term,
> > but I guess it is good that it has started somewhere.
> >
> 
> Thanks for sharing, didn't recall that work being done.
> 
>  From glancing at it, it seems to be nova versioning its notifications (which 
> is
> good) but I'm unclear what the objectification of those notifications means to
> the outside world (the actual consumers of notifications). Said outside world
> uses more than just python so it feels like some other intermediary format
> should be exposed to consumers as the schema that various python and
> non-python languages can consume (either via auto-generation of code or
> other).
> 
> Perhaps just jsonschema is enough (though it doesn't feel like it)? Has
> anyone tried 'to_json_schema' on those objects and outputting that schema
> into a nova/schema/notifications folder (or equivalent)?

This is exactly what we are planning to do.  Work is ongoing to add 
to_json_schema
support for every VersionedObject field [1]. Then we would like to add a small
tool to nova that makes it possible to generate the json schemas for the 
versioned
notifications [2]. Meanwhile we continue to transform legacy notifications to a 
versioned
format [3].

As soon as you have json schema you can find (or create) tools that generate an 
object
model and a parser from the json schema of the notifications in any modern 
language.

I hope this work in nova will servers as an example for other OpenStack project 
and
in the end OpenStack will have well defined and easy to consume notifications.

Any feedback on our plans are highly appreciated. 

Cheers,
gibi

[1] 
https://review.openstack.org/#/q/topic:bp/json-schema-for-versioned-object,n,z 
[2] 
https://blueprints.launchpad.net/nova/+spec/json-schema-for-versioned-notifications
 
[3] https://vntburndown-gibi.rhcloud.com/index.html 

> 
> -Josh
> 
> __
> 
> 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] [vmt][security][barbican] Threat Analysis for OpenStack Projects

[Rob C]

Hi Guys,

We've put together a session to go over TA and how we should apply what
we've built moving forward.

https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/17017

-Rob
__
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][nova] Port unbound from active VM

[Kevin Benton]

I suggest filing a bug against nova for this.

On Thu, Oct 13, 2016 at 9:44 AM, Ajay Kalambur (akalambu) <
akala...@cisco.com> wrote:

> Any comments/input on this?
> Ajay
>
>
> From: Ajay Kalambur 
> Date: Monday, October 10, 2016 at 6:31 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: [openstack][nova] Port unbound from active VM
>
> Hi
> There seems to be a corner case bug in nova code. Steps to reproduce it are
>
>1. Create a neutron port
>2. Create a VM and launch instance with this port
>3. Shutdown nova compute and network agent on compute node
>4. Unbind port from VM and delete the VM (offline delete)
>5. Now create a VM with same port but on a different compute node
>6. Bring up nova compute on old node
>
> It basically runs the reap for deleted instances and cleanes up VM from
> libvirt. In the process it unbinds the pre-existing ports and ends up
> unbinding the port from an active VM on a different compute node
> Reason nova simply sends a blind port-update with binding_host: “” even if
> that port is bound to a different instance
>
>
> So following fix seemed to help any suggestions on a better fix
>
> In nova/network/neutronv2/api.py. So basically when neutron sees no ports
> for this instance don’t attempt an unbind
> In this case
> data = neutron.list_ports(**search_opts)
> Call in deallocate_for_instance returns empty ports
>
>
>
>   # Reset device_id and device_owner for the ports that are skipped
>
> if data.get('ports', []):
>
> self._unbind_ports(context, ports_to_skip, neutron)
>
> else:
>
> LOG.debug("Neutron sees a different view of this port hence
> skipping unbind”)
>
>
>
> Ajay
>
>
>
> __
> 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][barbican][security] Ocata design summit session change

[Rob C]

Thanks for the heads up, I'll do my best to attend and I'll encourage other
security folks to do likewise.

It looks like there's a good deal of security enforcing functionality in
these specs, I knew we've discussed getting Octa through threat analysis,
lets try to find a good time to schedule that too.

Cheers
-Rob

On Thu, Oct 13, 2016 at 9:15 PM, Matt Riedemann 
wrote:

> I've changed the nova design summit session on docs needed for newton to
> now be a session to cover the various security-related specs up for review:
>
> https://www.openstack.org/summit/barcelona-2016/summit-sched
> ule/events/16977/nova-security-specs-and-testing
>
> And to also talk about getting a CI job going which will test some of
> these features, like with barbican as the key manager and using signed
> images.
>
> I've tagged this session with 'barbican' although I see that the barbican
> team is having another session at the same time. There was one other slot
> that I could have moved for nova but barbican had a conflict then too, so
> I've just left this where it is and if anyone from barbican can show up all
> the better, but I don't think it's necessarily a requirement.
>
> --
>
> 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

[openstack-dev] [senlin] Proposed changes to senlin core team

[Xinhui Li]

+1. Good contribution to Senlin!
Xinhui Li
2016-10-13 20:27 GMT+08:00 Qiming Teng http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>:

>* As the project keeps growing and maturing, we are happily seeing more
*>* eyes on it, more hands on it. Among the many contributors, the following
*>* two are outstanding:
*>>* lvdongbing http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>
*>* Involved in OpenStack for a few years now. His contribution is not
*>* limited to senlin, but also other projects such as heat, nova, solum
*>* etc. His experience and passion would be a great help to our team.
*>>* ref:
*>* http://stackalytics.com/?module=senlin-group=

*>* commits_id=dbcocle=all
*>>* XueFeng Liu http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>
*>* Both a user and a developer of senlin. His recent contribution has shown
*>* that he has a good understanding of the project's mission and
*>* implementation. His commits and reviews are all of good quality.
*>>* ref:
*>* http://stackalytics.com/?module=senlin-group=

*>* commits=all_id=jonnary-liu
*>>* With this email, I'm formally inviting these two developers to join
*>* senlin core team. Please cast your votes by replying this email, core
*>* team. Thank you.
*>>* Regards,
*>*   Qiming
*>>>* __
*>* OpenStack Development Mailing List (not for usage questions)
*>* Unsubscribe: OpenStack-dev-request at lists.openstack.org
?subject:unsubscribe
*>* http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

*>



-- 
yours sincerely, xin hui
  |\  _,,,---,,_
ZZZzz /,`.-'`'-.  ;-;;,_
 |,4-  ) )-,_. ,\ (  `'-'
'---''(_/--'  `-'\_) fL
__
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] [senlin] Proposed changes to senlin core team

[Haiwei Xu]

+1 for both. Glad to see the team is growing up.

Regards,
xuhaiwei
-Original Message-
From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com] 
Sent: Thursday, October 13, 2016 9:28 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [senlin] Proposed changes to senlin core team

As the project keeps growing and maturing, we are happily seeing more eyes on 
it, more hands on it. Among the many contributors, the following two are 
outstanding:

lvdongbing  Involved in OpenStack for a few years 
now. His contribution is not limited to senlin, but also other projects such as 
heat, nova, solum etc. His experience and passion would be a great help to our 
team.

ref:
http://stackalytics.com/?module=senlin-group=commits_id=dbcocle=all

XueFeng Liu 
Both a user and a developer of senlin. His recent contribution has shown that 
he has a good understanding of the project's mission and implementation. His 
commits and reviews are all of good quality.

ref:
http://stackalytics.com/?module=senlin-group=commits=all_id=jonnary-liu

With this email, I'm formally inviting these two developers to join senlin core 
team. Please cast your votes by replying this email, core team. Thank you.

Regards,
  Qiming


__
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