[openstack-dev] [heat] Presence at PTG, Atlanta

[Rabi Mishra]

Hi All,

As you would probably know, the first Project Teams Gathering(PTG) will
happen in Atlanta from Feb 20-24, 2017.

Organizers are working on the event space layout and have asked all project
teams on their plans to join the event and whether they would require/use a
separate room.

As this is expected to be a substitute for the 'design summit' plus
'mid-cycle meet up' (I'm not sure if we had one before), I assume most the
contributors would be planning to attend it.


We can respond with one of the options below on 'Whether the project team
is planning to gather for the event?'

1. Yes, Absolutely
2. Maybe, Still Considering it
3. No Certainly Not

I think for us it's '1'. However, please let us know if you have different
idea/opinion on this. We can also discuss about it in the team meeting this
week.


-- 
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] [Horizon] End of week wrap-up

[Richard Jones]

Hi folks,

Congratulations to all contributors to the Newton release - a release we
can all be proud of:

  http://docs.openstack.org/releasenotes/horizon/newton.html

Thanks to Rob Cresswell for his leadership through the Newton release. I'm
looking forward to seeing what we can achieve in Ocata.

In our meeting this week[1] we covered a few topics, notably:

- the schedule for Horizon sessions is now available[2]
- whether we as a team wish to participate in the Project Teams Gathering
(yes)
- a discussion regarding how to progress the incorporation of the Profiler
panel

Catch you next week in #openstack-horizon


 Richard

[1] https://wiki.openstack.org/wiki/Meetings/Horizon
[2]
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Horizon%3A
__
OpenStack Development Mailing 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] What's Up, Doc? Newton Edition!

[Lana Brindley]

Hi everyone,

First of all, Newton docs are live on http://docs.openstack.org/  \o/

Thank you to our release managers, Olena and Alex, who have put in the hard 
yards over the past few weeks to get us in good shape. Thanks also to Andreas 
and Kato-san, for everything that they do, and to our speciality team leads and 
cross project liaisons. And thanks to Christian and Matt for the last minute 
assistance.

Of course, every release belongs to all of you who have written, tested, 
reviewed, updated, triaged, and edited over the last six months. Well done on 
another successful release :)

Don't forget that you can still use "#success" before a  message in any 
OpenStack IRC channel to call out wins, they are gathered here: 
https://wiki.openstack.org/wiki/Successes

== Progress towards Newton ==

Newton has been released unto the world. We fixed 479 bugs this cycle, and 
completed 15 blueprints. 

We'll begin planning for Ocata over the next couple of weeks, culminating in 
the Barcelona Summit 25-28 October, where we'll develop our Ocata deliverables 
list. Stay tuned! 

== The Road to Barcelona ==

Our docs schedule is now available here: 
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Documentation%3A

We are also hoping to have a docs session in the Ops track. I'll get back to 
you with more information on that as soon as I have it.

I've requested a docs track at the PTG in Atlanta next February, which will be 
used for Ocata review and Pike planning. Please let me know if you intend to 
participate.

== Core Team Reviews ==

Just a quick note that we won't be holding a core team review in November, as 
it conflicts with Summit. We'll resume these in December for the Ocata cycle.

== Doc team meeting ==

We will take a short break and resume the normal meeting schedule after Summit. 
In the meantime, you can catch most of us in #openstack-doc in a variety of 
timezones, so feel free to drop in and ask questions any time.

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#7_October_2016

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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

Re: [openstack-dev] [all] Ocata Design Summit: Couple of empty slots up for grabs

[Zhipeng Huang]

Hi Theiry,

Nomad team would also like to see if one of the slots would be available :)
either one would work fine for us

On Thu, Oct 6, 2016 at 1:56 AM,  wrote:

> Hi everyone,
>>
>> The UX team PTL just released his two allocated design summit slots:
>>
>> - One fishbowl session in a 73-seat room on Wednesday at 3:05pm
>>
> If possible - the storlets team would love to have this slot,
> particularly, as it does not conflict with a Swift  design session.
>
> Thanks very much,
> Eran
>
>
>
> __
> OpenStack Development Mailing 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] [OpenStack-docs] Admin guide in-tree?

[Lana Brindley]

(Adding the dev list to cc, as I think this conversation deserves a wider 
audience)

Thanks for this feedback. I'm really glad that the new Install Guide model is 
working out well for people!

Since our new Install Guides have only just been published, at this stage I'm 
intending to gather some data on how projects and users are using the 
project-specific Install Guides during the next cycle. I'm also intending to 
spend some time in the Ocata cycle on improving that index page. It's pretty 
ugly right now, and I think there's some  serious UX improvements to be done. 
Since Ocata is a short cycle, I'm also conscious of how much the docs team 
might realistically be able to achieve.

All that said, you are certainly not the first to ask if this model can be 
extended! I think it's something that the docs community would like to see, and 
it seems as though it has broad support amongst developers and projects as 
well. So, in short, I think this is a thing that will happen, but probably not 
in Ocata. I'm tentatively willing to tell you that Pike is a possibility though 
;)

Lana

On 07/10/16 12:43, Steve Martinelli wrote:
> FWIW, the keystone team would also be interested in this model
> 
> On Thu, Oct 6, 2016 at 11:40 AM, Jay Faulkner  > wrote:
> 
> Hi all,
> 
> For those of you who don't know me, I'm Jay Faulkner and I work on Ironic 
> as the Docs liaison as one of my hats.
> 
> Ironic launched our install-guide right after newton closed, and 
> backported it, thanks to the changes to make the install-guide available in 
> tree. We're a huge fan of this model, and I'm curious if there's any plans to 
> make this happen for the admin-guide. If not, can someone help me understand 
> the scope of work, presuming it's something that the docs group is interested 
> in.
> 
> If we can get the technical infrastructure in place to do admin-guide in 
> tree, I'd expect Ironic to quickly adopt it, like we did for the install 
> guide.
> 
> Thanks,
> Jay Faulkner
> OSIC
> 
> 
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs 
> 
> 
> 
> 
> 
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
> 

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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

[openstack-dev] [release] RDO Newton packages released

[Alan Pevec]

The RDO community is pleased to announce the general availability of
the RDO build for OpenStack Newton for RPM-based distributions -
CentOS Linux 7 and Red Hat Enterprise Linux. RDO is suitable for
building private, public, and hybrid clouds. Newton is the 14th
release from the OpenStack project ( http://openstack.org ), which is
the work of more than 2700 contributors from around the world.
(Source http://stackalytics.com/ )

The RDO community project ( https://www.rdoproject.org/ ) curates,
packages, builds, tests, and maintains a complete OpenStack component
set for RHEL and CentOS Linux and is a member of the CentOS Cloud
Infrastructure SIG (
https://wiki.centos.org/SpecialInterestGroup/Cloud ). The Cloud
Infrastructure SIG focuses on delivering a great user experience for
CentOS Linux users looking to build and maintain their own on-premise,
public or hybrid clouds. At latest count, RDO contains 1157 packages (
https://www.rdoproject.org/documentation/package-list/ ).

All work on RDO, and on the downstream release, Red Hat OpenStack
Platform, is 100% open source, with all code changes going upstream
first.


Getting Started

There are three ways to get started with RDO.

To spin up a proof of concept cloud, quickly, and on limited hardware,
try the  RDO QuickStart ( http://rdoproject.org/Quickstart )  You can
run RDO on a single node to get a feel for how it works.

For a production deployment of RDO, use the TripleO Quickstart (
https://www.rdoproject.org/tripleo/ ) and you'll be running a
production cloud in short order.

Finally, if you want to try out OpenStack, but don't have the time or
hardware to run it yourself, visit  TryStack ( http://trystack.org/ ),
where you can use a free public OpenStack instance, running RDO
packages, to experiment with the OpenStack management interface and
API, launch instances, configure networks, and generally familiarize
yourself with OpenStack


Getting Help

The RDO Project participates in a Q service at ask.openstack.org (
http://ask.openstack.org ), for more developer oriented content we
recommend joining the rdo-list mailing list (
https://www.redhat.com/mailman/listinfo/rdo-list ). Remember to post a
brief introduction about yourself and your RDO story. You can also
find extensive documentation on the RDO docs site (
https://www.rdoproject.org/documentation ).

The #rdo channel on Freenode IRC is also an excellent place to find
help and give help.

We also welcome comments and requests on the CentOS Mailing lists (
https://lists.centos.org/ ) and the CentOS IRC Channels (#centos, and
#centos-devel, on irc.freenode.net), however we have a more focused
audience in the RDO venues.


Getting Involved

To get involved in the OpenStack RPM packaging effort, see the RDO
community pages ( https://www.rdoproject.org/community/ ) and the
CentOS Cloud SIG page (
https://wiki.centos.org/SpecialInterestGroup/Cloud ). See also the RDO
packaging documentation ( https://www.rdoproject.org/packaging/ ).

Join us in #rdo on the Freenode IRC network, and follow us at
@RDOCommunity ( http://twitter.com/rdocommunity ) on Twitter. If you
prefer Facebook, we're there too ( http://facebook.com/rdocommunity ),
and also Google+ ( http://tm3.org/rdogplus ).

And, if you're going to be in Barcelona for the OpenStack Summit (
http://openstack.org/summit/ ) two weeks from now, join us on Tuesday
evening at the Barcelona Princess, 5pm - 8pm, for an evening with the
RDO and Ceph communities. If you can't make it in person, we'll be
streaming it on YouTube ( https://www.youtube.com/watch?v=ji-WqEXZRTY
).


Cheers,
Alan

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

Re: [openstack-dev] [puppet] [tripleo] our CI is now deploying OpenStack Ocata

[Jason Rist]

On 10/06/2016 06:30 AM, Emilien Macchi wrote:
> Quick FYI about TripleO and Puppet CI.
> We bumped RDO to start building OpenStack Ocata packages, and
> successfully made the switch in the TripleO and Puppet gates.
>
> So both CI deploy OpenStack from trunk again, and not Newton.
> Stable gates (newton) are deploying latest Newton packages though.
>
> Thanks for the people who were involved in that process, big kudos here.
>
Thanks Emilien!

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

__
OpenStack Development Mailing 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: ping to gateway in instance fails leading to failure in internet connectivity

[kamalakannan sanjeevan]

Hello All,

I am using liberty on ubuntu 14.04.5. I have create a external network with
flat provider . I am able to ssh into the instance. The connectivity
through gateway fails and not able to connect to internet. Below are the
logs. Can anyone help me out?


root@scm:/opt/Openstack_liberty_scripts# neutron net-list
+--++--+
| id   | name   | subnets
   |
+--++--+
| 5b2d3934-d07f-4d19-9ffc-6be5ed83c7ca | public-br-p4p1 |
edc648f9-e6dc-47b2-bb44-cdfe0e8125ae 10.0.1.0/24 |
+--++--+


root@scm:/opt/Openstack_liberty_scripts# neutron net-show
5b2d3934-d07f-4d19-9ffc-6be5ed83c7ca
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| id| 5b2d3934-d07f-4d19-9ffc-6be5ed83c7ca |
| mtu   | 0|
| name  | public-br-p4p1   |
| port_security_enabled | True |
|* provider:network_type | flat |*
*| provider:physical_network | public   |*
| provider:segmentation_id  |  |
|* router:external   | True |*
| shared| True |
| status| ACTIVE   |
| subnets   | edc648f9-e6dc-47b2-bb44-cdfe0e8125ae |
| tenant_id | 541ac2769dc1487d92ac2f5c45952d51 |
+---+--+

root@scm:/opt/Openstack_liberty_scripts# neutron subnet-show
edc648f9-e6dc-47b2-bb44-cdfe0e8125ae
+---+--+
| Field | Value|
+---+--+
| allocation_pools  | {"start": "10.0.1.129", "end": "10.0.1.253"} |
| cidr  | 10.0.1.0/24  |
| dns_nameservers   | 192.168.0.1  |
| enable_dhcp   | True |
|* gateway_ip| 10.0.1.1 |*
| host_routes   |  |
| id| edc648f9-e6dc-47b2-bb44-cdfe0e8125ae |
| ip_version| 4|
| ipv6_address_mode |  |
| ipv6_ra_mode  |  |
| name  |  |
| network_id| 5b2d3934-d07f-4d19-9ffc-6be5ed83c7ca |
| subnetpool_id |  |
| tenant_id | 541ac2769dc1487d92ac2f5c45952d51 |
+---+--+


root@scm:/opt/Openstack_liberty_scripts# neutron net-gateway-list
404 Not Found

The resource could not be found.


root@scm:/var/log/neutron# neutron security-group-rule-list
+--++---+---+---+--+
| id   | security_group | direction |
ethertype | protocol/port | remote   |
+--++---+---+---+--+
| 123bbf22-7167-4851-a567-dd3425a8eb58 | default| egress| IPv4
 | any   | any  |
| 2d685879-89c5-4b06-bf81-8f7a2a7d293f | default| egress| IPv6
 | any   | any  |
| 485dd762-fa50-47ab-ab5d-2309c543232d | default| ingress   | IPv6
 | any   | default (group)  |
| a29aec70-30c8-48cc-9c09-1a92b8dbe81a | default| ingress   | IPv4
 | any   | default (group)  |
| a80f593d-145b-47c1-97be-ccf6fc66d7fb | default| ingress   | IPv4
 | 22/tcp| 0.0.0.0/0 (CIDR) |
| a85eb9c3-1600-46cb-a03c-1a29d901164d | default| egress| IPv4
 | any   | any  |
| af6b71fb-c6f1-4a7b-9f84-d55d4692435a | default| ingress   | IPv4
 | any   | default (group)  |
| b3eead61-4aed-4cb2-9dbb-d1aa4f2faada | default| ingress   | IPv6
 | any   | default (group)  |
| ced0f8bd-2ea8-4f06-b972-9c5c3aaa82a2 | default| 

Re: [openstack-dev] [nova] FYI, nova plans to have a room at the PTG in February

[Doug Hellmann]

Excerpts from Matt Riedemann's message of 2016-10-06 13:52:09 -0500:
> On 10/6/2016 12:23 PM, Clint Byrum wrote:
> > Excerpts from Matt Riedemann's message of 2016-10-06 11:33:35 -0500:
> >> This is just a follow up email to the discussion about nova's
> >> participation in the Project Team Gathering (PTG) in February right
> >> after the Ocata release.
> >>
> >> I had asked because the OpenStack Foundation is getting early feedback
> >> on which teams are planning to attend. Several people said they planned
> >> on attending the PTG during the Nova meeting so I've submitted the form
> >> saying we'll have a room for Nova.
> >>
> >> Remember at a high level that the PTG is the replacement for the
> >> midcycle meetups, except it's centrally located and organized by the
> >> foundation, and it's at the release boundaries rather than the middle.
> >>
> >> The traditional summit that we're used to is now in the middle of the
> >> release and is more for the marketing stuff that happens at the summit
> >> whereas the PTG is supposed to be strictly technical and for
> >> development, like the design summit.
> >>
> >
> > That's a bit different than the way I understood it. My understanding
> > was that it was more like the fishbowls still happen, at the PTG, and the
> > work rooms at the end of the week at the PTG would replace the mid-cycles.
> >
> > If we don't have fishbowls anymore, we are going to end up siloing even
> > harder than we already do.
> >
> >> Personally if you care more about development discussions and would have
> >> to pick between going to the PTG or the summit, the PTG is the thing you
> >> want to try and get to now, but that's my opinion.
> >>
> >
> > I care about cross project, and that's not going to work if it's just
> > the nova devs in a room with their own agenda and I have to sit there
> > all day to get to the 2 or 3 topics that affect my efforts.
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> Sorry yeah I screwed that up. I re-read the PTG email and the first two 
> days are cross-project things, and Wed-Fri are meetup style at the PTG, 
> it's not time-boxed sessions like the design summit, unless again I'm 
> screwing this up and this is just a thing that's not explainable to mere 
> mortals until we actually experience one.

It's not fully time-boxed, but as Clint pointed out it might be
useful to establish some sort of estimated schedule so cross-team
discussions can be coordinated.

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

Re: [openstack-dev] [all][i18n] Translation of releasenotes

[Doug Hellmann]

Excerpts from Andreas Jaeger's message of 2016-10-06 21:05:41 +0200:
> All repositories that have translations enabled, are pushing their
> releasenotes to our translation server and we have currently
> translations for 19 of these repositories.
> 
> I've worked with the i18n team on publishing these translations and  
> Akihiro Motoki found today the missing link why the translations do not
> work: releasenotes/source/conf.py misses a locale_dir entry ;(
> 
> Instead of pushing this only to the 80+ repositories that currently have
> translations enabled, I'm pushing the change now to *all* repositories
> with releasenotes - in case you want to set up translation for a repo
> later. That way we don't need to check this later.
> Topic for my change is "releasenote-translation".
> 
> If a repo won't ever get translated, feel free to -1 and I'll abandon
> the change.
> 
> For repositories with translation sync set up, I'd like to see the
> change get merged soonish.
> 
> thanks,
> Andreas

Thank you both for figuring this out and fixing it!

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

Re: [openstack-dev] [neutron][networking-vpp]Introducing networking-vpp

[Naveen Joy (najoy)]

Was not comaparing it in the way you imply below. My point was that
eventhough they are fundamentally different systems, they play
a similar role in the way we use them - the primary purpose being
to facilitate communications between the components of a distributed
system. 
We have found etcd to be simpler and a better fit for what we
are trying to accomplish.

Regards,
Naveen 


On 10/6/16, 10:43 AM, "Jay Pipes"  wrote:

>On 10/06/2016 11:58 AM, Naveen Joy (najoy) wrote:
>> It¹s primarliy because we have seen better stability and scalability
>> with etcd over rabbitmq.
>
>Well, that's kind of comparing apples to oranges. :)
>
>One is a distributed k/v store. The other is a message queue broker.
>
>The way that we (IMHO) over-use the peer-to-peer RPC communication
>paradigm in Nova and Neutron has resulted in a number of design choices
>and awkward code in places like oslo.messaging because of the use of
>broker-based message queue systems as the underlying transport
>mechanism. It's not that RabbitMQ or AMQP isn't scalable or reliable.
>It's that we're using it in ways that don't necessarily fit well.
>
>One might argue that in using etcd and etcd watches in the way you are
>in networking-vpp, that you are essentially using those tools to create
>a simplified pub-sub messaging system and that isn't really what etcd
>was built for and you will end up running into similar fitness issues
>long-term. But, who knows? It might end up being a genius implementation.
>:)
>
>I'm happy to see innovation flourish here and encourage new designs and
>strategies. Let's just make sure we compare apples to apples when making
>statements about performance or reliability.
>
>All the best,
>-jay
>
>__
>OpenStack Development Mailing 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] [telemetry][gnocchi] benchmarking gnocchi v3

[gordon chung]

hi folks,

as announced recently, we released Gnocchi v3[1][2]! this marked a major 
change in how we process and store data in Gnocchi as we worked on 
building a truly open source time-series service.

as we were building it, i've been benchmarking the results and feeding 
it back into our development. now that we have a release, i thought i'd 
share the results of my last benchmarks in some fancy powerpoint[3]. if 
you don't want a backstory to some of the design changes just jump to 
slide 15[4] for some comparisons on Gnocchi v2 vs Gnocchi v3.

the slides focus only on the performance aspect of Gnocchi but we added 
other stuff as well to improve the flexibility of the service.

feel free to ask me questions on my experience.

[1] https://julien.danjou.info/blog/2016/gnocchi-3.0-release
[2] 
http://lists.openstack.org/pipermail/openstack-announce/2016-September/001649.html
[3] http://www.slideshare.net/GordonChung/gnocchi-v3
[4] http://www.slideshare.net/GordonChung/gnocchi-v3/15

cheers,

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

[openstack-dev] [new] nova_powervm 3.0.0 release (newton)

[no-reply]

We are delighted to announce the release of:

nova_powervm 3.0.0: PowerVM driver for OpenStack Nova.

This release is part of the newton stable release series.

For more details, please see below.




__
OpenStack Development Mailing 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] [new] networking-powervm 3.0.0 release (newton)

[no-reply]

We are enthusiastic to announce the release of:

networking-powervm 3.0.0: PowerVM Neutron ML2 Agent for OpenStack
Neutron.

This release is part of the newton stable release series.

For more details, please see below.




__
OpenStack Development Mailing 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] [new][telemetry] ceilometer-powervm 3.0.0 release (newton)

[no-reply]

We are grateful to announce the release of:

ceilometer-powervm 3.0.0: PowerVM Ceilometer Inspector for OpenStack
Ceilometer.

This release is part of the newton stable release series.

For more details, please see below.




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

[openstack-dev] [all][i18n] Translation of releasenotes

[Andreas Jaeger]

All repositories that have translations enabled, are pushing their
releasenotes to our translation server and we have currently
translations for 19 of these repositories.

I've worked with the i18n team on publishing these translations and 
Akihiro Motoki found today the missing link why the translations do not
work: releasenotes/source/conf.py misses a locale_dir entry ;(

Instead of pushing this only to the 80+ repositories that currently have
translations enabled, I'm pushing the change now to *all* repositories
with releasenotes - in case you want to set up translation for a repo
later. That way we don't need to check this later.
Topic for my change is "releasenote-translation".

If a repo won't ever get translated, feel free to -1 and I'll abandon
the change.

For repositories with translation sync set up, I'd like to see the
change get merged soonish.

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


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

Re: [openstack-dev] [nova] FYI, nova plans to have a room at the PTG in February

[Matt Riedemann]

On 10/6/2016 12:23 PM, Clint Byrum wrote:

Excerpts from Matt Riedemann's message of 2016-10-06 11:33:35 -0500:

This is just a follow up email to the discussion about nova's
participation in the Project Team Gathering (PTG) in February right
after the Ocata release.

I had asked because the OpenStack Foundation is getting early feedback
on which teams are planning to attend. Several people said they planned
on attending the PTG during the Nova meeting so I've submitted the form
saying we'll have a room for Nova.

Remember at a high level that the PTG is the replacement for the
midcycle meetups, except it's centrally located and organized by the
foundation, and it's at the release boundaries rather than the middle.

The traditional summit that we're used to is now in the middle of the
release and is more for the marketing stuff that happens at the summit
whereas the PTG is supposed to be strictly technical and for
development, like the design summit.



That's a bit different than the way I understood it. My understanding
was that it was more like the fishbowls still happen, at the PTG, and the
work rooms at the end of the week at the PTG would replace the mid-cycles.

If we don't have fishbowls anymore, we are going to end up siloing even
harder than we already do.


Personally if you care more about development discussions and would have
to pick between going to the PTG or the summit, the PTG is the thing you
want to try and get to now, but that's my opinion.



I care about cross project, and that's not going to work if it's just
the nova devs in a room with their own agenda and I have to sit there
all day to get to the 2 or 3 topics that affect my efforts.

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



Sorry yeah I screwed that up. I re-read the PTG email and the first two 
days are cross-project things, and Wed-Fri are meetup style at the PTG, 
it's not time-boxed sessions like the design summit, unless again I'm 
screwing this up and this is just a thing that's not explainable to mere 
mortals until we actually experience one.


--

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-dev] Release countdown for week R+1, 10-14 Oct

[Doug Hellmann]

The main portion of the Newton release is complete. Thank you all
for the hard work you put into the release this cycle!

Focus
-

All project teams should be preparing for the summit in Barcelona.

General Notes
-

Stable and independent releases will resume on 10 Oct. Let the
release team know of any critical bug fixes that need to be released
sooner.

The release automation was mostly error-free. The few issues we did
have were restricted to announcement emails, and did not affect the
contents of any releases as far as we can tell. If you spot issues
with any of the released deliverables, please let us know.

Release Actions
---

Project teams following the cycle-trailing release model should be
wrapping up changes to make their projects compatible with the
existing Newton releases.

PTLs, this is a good time to clean up core team memberships and
remove inactive members.

Important Dates
---

Newton cycle-trailing deadline, 27 Oct.

Newton release schedule: http://releases.openstack.org/newton/schedule.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] [neutron][networking-vpp]Introducing networking-vpp

[Jay Pipes]

On 10/06/2016 11:58 AM, Naveen Joy (najoy) wrote:

It’s primarliy because we have seen better stability and scalability
with etcd over rabbitmq.


Well, that's kind of comparing apples to oranges. :)

One is a distributed k/v store. The other is a message queue broker.

The way that we (IMHO) over-use the peer-to-peer RPC communication 
paradigm in Nova and Neutron has resulted in a number of design choices 
and awkward code in places like oslo.messaging because of the use of 
broker-based message queue systems as the underlying transport 
mechanism. It's not that RabbitMQ or AMQP isn't scalable or reliable. 
It's that we're using it in ways that don't necessarily fit well.


One might argue that in using etcd and etcd watches in the way you are 
in networking-vpp, that you are essentially using those tools to create 
a simplified pub-sub messaging system and that isn't really what etcd 
was built for and you will end up running into similar fitness issues 
long-term. But, who knows? It might end up being a genius implementation. :)


I'm happy to see innovation flourish here and encourage new designs and 
strategies. Let's just make sure we compare apples to apples when making 
statements about performance or reliability.


All the best,
-jay

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

Re: [openstack-dev] [neutron][networking-vpp]Introducing networking-vpp

[Jay Pipes]

On 10/06/2016 11:39 AM, Neil Jerram wrote:

On Thu, Oct 6, 2016 at 3:44 PM Jay Pipes > wrote:

On 10/06/2016 03:46 AM, Jerome Tollet (jtollet) wrote:
> Hey Kevin,
>
> Thanks for your interest in this project.
>
> We found etcd very convenient to store desired states as well as
> operational states. It made the design easy to provide production
grade
> features (e.g. agent restart, mechanical driver restart, …) in a very
> concise code. In addition to that, debugging is simple to do using
> simple “etcdwatch” commands. Please note that etcd is not an
alternative
> to rabbitmq even though communication protocol is HTTP/JSON.

It's probably worth mentioning that the etcd code used in networking-vpp
came from networking-calico?


When I chatted with Ian about this, I actually asked the same question
and Ian told me the code came from networking-calico pretty much as-is.


To clarify (or check my own understanding of!) that statement: it's
certainly true that networking-calico also uses etcd as its mechanism
for communicating between the ML2 driver and the agents.  However, from
a quick look at the networking-vpp code, it appears to me that it
doesn't use any detailed etcd handling code from networking-calico, or
use the same etcd data model as Calico (i.e. the definition of how
information is structured and named in the etcd tree).  So I think the
statement above just means that networking-vpp uses a similar
architecture as networking-calico, in particular as regards using etcd
for communication.

Happy to be corrected if that's not quite right, of course!


We can discuss at length about using etcd as the state data store
instead of the Neutron database and using etcd watches as the mechanism
for state change communication, but that will likely end up in lots of
bike-shedding. There's certainly advantages and disadvantages to each
approach.


Another clarification here, I think you should say 'as the transport
instead of Neutron RPC', not 'as the state data store instead of the
Neutron database'.  With networking-calico the Neutron DB is still the
primary source of truth, and the etcd DB is just a mapping of that; and
I would guess (tentatively) that that is true for networking-vpp as well.


Sorry, no, I was definitely referring to the data store for state change 
in networking-vpp, which deliberately sidesteps the Neutron DB as the 
state store.


From the README.rst file, under the "How does it implement binding 
section?":


"etcd then contains the desired state of each host agent, and the agents 
monitor etcd for changes relevant to them and update their state."


and under the "Why didn't you use the ML2 agent framework for this 
driver?" section:


"Neutron's agent framework is based on communicating via RabbitMQ. This 
can lead to issues of scale when there are more than a few compute hosts 
involved, and RabbitMQ is not as robust as it could be, plus RabbitMQ is 
trying to be a fully reliable messaging system - all of which work 
against a robust and scalable SDN control system.


We didn't want to start down that path, so instead we've taken a 
different approach, that of a 'desired state' database with change 
listeners. etcd stores the data of how the network should be and the 
agents try to achieve that (and also report their status back via etcd)"


Best,
-jay

__
OpenStack Development Mailing 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] Project name DB length

[Morgan Fainberg]

On Thu, Oct 6, 2016 at 7:06 AM, gordon chung  wrote:

>
>
> On 05/10/16 07:55 AM, Sean Dague wrote:
> > Except... the 64 char field in keystone isn't required to be a uuid4.
> > Which we ran into when attempting to remove it from the URLs in Nova.
> > There is no validation anywhere that requires that of keystone values.
> >
> > For instance, Rackspace uses ints.
>
> yeah, that's basically why we had to revert our attempt in Ceilometer.
> we tried to enforce uuid with some buffer and it was too difficult to
> track down every one we broke.
>
> >
> > Yes this is debt. And yes, a few things would be nicer if this was more
> > constrained, but as was recently stated on twitter, we've been calling
> > the 9th month the seventh month for 2000 years -
> > https://twitter.com/GonzoHacker/status/781890649444519937. Some times
> > the cost of fixing the thing really just isn't worth the potential
> > breaks to operators that were operating within the old constraints fine.
>
> i think this sums up my feeble attempt at initiating this as a cross
> project topic a while back. too many projects, too few participants, too
> little gain. we avoided the issue in Gnocchi and the original reason i
> brought it up became less important.
>
> it'd be nice if we could somehow enforce new attributes/columns to
> follow uuid standards in hopes that older stuff just eventually dies
> off. that said, i'm guessing stuff like user_id and project_id columns
> are sticking around for a while...
>
> cheers,
>
> --
> gord
>
>
The SHA256() rendering that does not conform to UUID is required to
identify federated identity users and easily map them to the correct
identity backend(s). It means that "UUID" standards cannot be used. Partly
this requirement comes from needing to be able to programmatically generate
the ID for external consumers since the ID is "Element of ID from IDP" and
"Domain ID" and SHA256() hash of these two data elements.

The older legacy information such as LDAP partial DNs should in the long
term eventually go away if the current path continues. Project IDs will
likewise become more and more consistent as long as Keystone's upstream
code is used as LDAP-stored projects no longer exists and Project IDs are
always generated by Keystone (cannot be user supplied).

In short, user_id is a little bit more flexible than project id with older
installations potentially having some legacy data. New installations
(barring custom driver code) should be much more consistent.

The original part of this thread talking about project name length, it is
largely historic and could be changed. 64 was convenient and fits nicely in
UI; there is no specific technical reason this was limited to 64. It falls
on Steve and the rest of the Keystone team to determine if the request for
longer project_names outweighs the design/usability of the current length.
__
OpenStack Development Mailing 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][API WG] How does one best express a time interval as an API filtering query?

[Jay Pipes]

On 10/06/2016 11:43 AM, Jeremy Stanley wrote:

On 2016-10-06 10:30:30 -0500 (-0500), Kevin L. Mitchell wrote:
[...]

Problem with that is that ':' is a valid character within an ISO date,
though I do like the 'between' prefix.  Now, '/' can be used if it's URL
encoded, but I agree that that is non-ideal.  How about a syntax
something like:


?finished_at=between:ISO_DATE_A@ISO_DATE_B_at=between:ISO_DATE_C@ISO_DATE_D


I'll admit I'm not up on the intricacies of URL expectations for
APIs, but why not just use a comma? That's not an unusual meaning
for it as punctuation (at least in English), and has the property
that it's not overloading a typical field separator within either
8601 or HTTP encodings. (Now I've fulfilled my bikeshed quota for
the month.)


Yup, ++ on a comma.

-jay

__
OpenStack Development Mailing 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] FYI, nova plans to have a room at the PTG in February

[Clint Byrum]

Excerpts from Matt Riedemann's message of 2016-10-06 11:33:35 -0500:
> This is just a follow up email to the discussion about nova's 
> participation in the Project Team Gathering (PTG) in February right 
> after the Ocata release.
> 
> I had asked because the OpenStack Foundation is getting early feedback 
> on which teams are planning to attend. Several people said they planned 
> on attending the PTG during the Nova meeting so I've submitted the form 
> saying we'll have a room for Nova.
> 
> Remember at a high level that the PTG is the replacement for the 
> midcycle meetups, except it's centrally located and organized by the 
> foundation, and it's at the release boundaries rather than the middle.
> 
> The traditional summit that we're used to is now in the middle of the 
> release and is more for the marketing stuff that happens at the summit 
> whereas the PTG is supposed to be strictly technical and for 
> development, like the design summit.
> 

That's a bit different than the way I understood it. My understanding
was that it was more like the fishbowls still happen, at the PTG, and the
work rooms at the end of the week at the PTG would replace the mid-cycles.

If we don't have fishbowls anymore, we are going to end up siloing even
harder than we already do.

> Personally if you care more about development discussions and would have 
> to pick between going to the PTG or the summit, the PTG is the thing you 
> want to try and get to now, but that's my opinion.
> 

I care about cross project, and that's not going to work if it's just
the nova devs in a room with their own agenda and I have to sit there
all day to get to the 2 or 3 topics that affect my efforts.

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

Re: [openstack-dev] [neutron][networking-vpp]Introducing networking-vpp

[Naveen Joy (najoy)]

The etcd handling code is unique to networking-vpp. In our model, the server 
code uses neutron DB to store port states and has journaling mechanisms to map 
this to the etcd DB. So even in our design (as it should be), the neutronDB as 
the primary source of truth.
When data is published to etcd, the corresponding compute agents receive a 
notification and they drop the vhostuser and tap interfaces into VPP and report 
the state back to the server. A return thread on the server watches for this 
state update from
the agents and sends port bound events to nova.

Regards,
Naveen

From: Neil Jerram >
Reply-To: openstack-dev 
>
Date: Thursday, October 6, 2016 at 8:39 AM
To: openstack-dev 
>
Subject: Re: [openstack-dev] [neutron][networking-vpp]Introducing networking-vpp

On Thu, Oct 6, 2016 at 3:44 PM Jay Pipes 
> wrote:
On 10/06/2016 03:46 AM, Jerome Tollet (jtollet) wrote:
> Hey Kevin,
>
> Thanks for your interest in this project.
>
> We found etcd very convenient to store desired states as well as
> operational states. It made the design easy to provide production grade
> features (e.g. agent restart, mechanical driver restart, ...) in a very
> concise code. In addition to that, debugging is simple to do using
> simple "etcdwatch" commands. Please note that etcd is not an alternative
> to rabbitmq even though communication protocol is HTTP/JSON.

It's probably worth mentioning that the etcd code used in networking-vpp
came from networking-calico?

When I chatted with Ian about this, I actually asked the same question
and Ian told me the code came from networking-calico pretty much as-is.

To clarify (or check my own understanding of!) that statement: it's certainly 
true that networking-calico also uses etcd as its mechanism for communicating 
between the ML2 driver and the agents.  However, from a quick look at the 
networking-vpp code, it appears to me that it doesn't use any detailed etcd 
handling code from networking-calico, or use the same etcd data model as Calico 
(i.e. the definition of how information is structured and named in the etcd 
tree).  So I think the statement above just means that networking-vpp uses a 
similar architecture as networking-calico, in particular as regards using etcd 
for communication.

Happy to be corrected if that's not quite right, of course!

We can discuss at length about using etcd as the state data store
instead of the Neutron database and using etcd watches as the mechanism
for state change communication, but that will likely end up in lots of
bike-shedding. There's certainly advantages and disadvantages to each
approach.

Another clarification here, I think you should say 'as the transport instead of 
Neutron RPC', not 'as the state data store instead of the Neutron database'.  
With networking-calico the Neutron DB is still the primary source of truth, and 
the etcd DB is just a mapping of that; and I would guess (tentatively) that 
that is true for networking-vpp as well.


Best,
-jay

Regards,
 Neil

__
OpenStack Development Mailing 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] Draft Ocata design summit schedule is up

[Matt Riedemann]

On 10/6/2016 9:13 AM, Dan Smith wrote:

Is there a particular reason we're only retrospecting on placement?


I think that we need to have a concrete topic that applied to newton and
will apply to ocata in order to be productive. I think there will be
specific things we can change in ocata that will have an actual impact
on major work for the cycle.


I suspect we can map many of the ideas and experiences from a
retrospective devoted to placement to more general concerns but I'd
hate for people who had no involvement in it but are concerned about
Nova to feel excluded.

[1] https://etherpad.openstack.org/p/nova-newton-retrospective


As has been demonstrated in that etherpad, if we try to retrospect every
aspect of newton, we'd need a week and wouldn't have time to have the
other sessions we need in order to plan for ocata. Picking two major
ongoing topics seems like the best way to frame a useful discussion to me.

--Dan

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



Yes Dan said what I was trying to say in the nova meeting today.

There are a lot of high-level topics in the etherpad that I think will 
tie into the cross-project session I proposed for Tuesday/Wednesday, 
which is getting project PTLs/cores together to discuss how they've 
dealt with review scaling and experiences with componentization. I 
wanted to have those discussions in a cross-project setting to get a 
perspective outside of Nova, and to help gauge how much of these issues 
are systemic to just Nova or if it's really not that different across 
the board in the community.


--

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] [QA][infra][all] Measuring code coverage in integration tests

[milanisko k]

čt 6. 10. 2016 v 16:41 odesílatel Andrea Frittoli 
napsal:

> The difficulty with integration testing is that the services under test
> run in processes separated from the test one(s).
>
> There is not obvious / existing mechanism to collect coverage data in this
> case. Several cycles back used to be a backdoor built into nova to enable
> coverage data collection during integration testing, but it has been
> removed long ago.
>
> andrea, AFAIK it is possible to create a hook like this[1]:

   path = os.path.join(sysconfig.get_python_lib(), 'hack.pth')
with open(path, 'w') as fd:
 fd.write("""
 import coverage; coverage.process_startup()
 """

to always enable instrumenting any python process.
This can get more fancy with white/black listing paths to consider.
The project I've referenced in the beginning of this thread used to enable
tracing this way (with some filtering applied).

Cheers,
milan

[1]
https://coverage.readthedocs.io/en/coverage-4.2/subprocess.html#configuring-python-for-sub-process-coverage


> andrea
>
> On Thu, Sep 29, 2016 at 12:12 PM Assaf Muller  wrote:
>
> On Thu, Sep 29, 2016 at 5:27 AM, milanisko k  wrote:
>
>
>
> út 27. 9. 2016 v 20:12 odesílatel Assaf Muller  napsal:
>
> On Tue, Sep 27, 2016 at 2:05 PM, Assaf Muller  wrote:
>
>
>
> On Tue, Sep 27, 2016 at 12:18 PM, Timur Nurlygayanov <
> tnurlygaya...@mirantis.com> wrote:
>
> Hi milan,
>
> we have measured the test coverage for OpenStack components with
> coverage.py tool [1]. It is very easy tool and it allows measure the
> coverage by lines of code and etc. (several metrics are available).
>
> [1] https://coverage.readthedocs.io/en/coverage-4.2/
>
>
> coverage also supports aggregating results from multiple runs, so you can
> measure results from combinations such as:
>
>
>
> 1) Unit tests
> 2) Functional tests
> 3) Integration tests
> 4) 1 + 2
> 5) 1 + 2 + 3
>
> To my eyes 3 and 4 make the most sense. Unit and functional tests are
> supposed to give you low level coverage, keeping in mind that 'functional
> tests' is an overloaded term and actually means something else in every
> community. Integration tests aren't about code coverage, they're about user
> facing flows, so it'd be interesting to measure coverage
> from integration tests,
>
>
> Sorry, replace integration with unit + functional.
>
>
> then comparing coverage coming from integration tests, and getting the set
> difference between the two: That's the area that needs more unit and
> functional tests.
>
>
> To reiterate:
>
> Run coverage from integration tests, let this be c
> Run coverage from unit and functional tests, let this be c'
>
> Let diff = c \ c'
>
> 'diff' is where you're missing unit and functional tests coverage.
>
>
> Assaf, the tool I linked is a monkey-patched coverage.py but the collector
> stores the stats in Redis --- gives the same accumulative collecting.
> Is there any interest/effort to collect coverage stats from selected jobs
> in CI, no matter the tool used?
>
>
> Some projects already collect coverage stats on their post-merge queue:
>
> http://logs.openstack.org/61/61af70a734b99e61e751cfb494ddc93a85eec394/post/nova-coverage-db-ubuntu-xenial/55210aa/
>
> It's invoked with 'tox -e cover' which you define in your project's
> tox.ini file, I imagine most projects if not all have it set up to gather
> coverage from a unit tests run.
>
>
>
>
>
>
>
>
>
> On Tue, Sep 27, 2016 at 1:06 PM, Jordan Pittier <
> jordan.pitt...@scality.com> wrote:
>
> Hi,
>
> On Tue, Sep 27, 2016 at 11:43 AM, milanisko k  wrote:
>
> Dear Stackers,
> I'd like to gather some overview on the $Sub: is there some infrastructure
> in place to gather such stats? Are there any groups interested in it? Any
> plans to establish such infrastructure?
>
> I am working on such a tool with mixed results so far. Here's my approach
> taking let's say Nova as an example:
>
> 1) Print all the routes known to nova (available as a python-routes
> object:  nova.api.openstack.compute.APIRouterV21())
> 2) "Normalize" the Nova routes
> 3) Take the logs produced by Tempest during a tempest run (in
> logs/tempest.txt.gz). Grep for what looks like a Nova URL (based on port
> 8774)
> 4) "Normalize" the tested-by-tempest Nova routes.
> 5) Compare the two sets of routes
> 6) 
> 7) Profit !!
>
> So the hard part is obviously the normalizing of the URLs. I am currently
> using a tons of regex :) That's not fun.
>
> I'll let you guys know if I have something to show.
>
> I think there's real interest on the topic (it comes up every year or so),
> but no definitive answer/tool.
>
> Cheers,
> Jordan
>
>
>
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

[openstack-dev] [all][api] POST /api-wg/news

[Chris Dent]

Greetings OpenStack community,

Today's meeting we welcomed back the long lost etoews. In addition to the usual 
checking up on pending guidelines (there's one newly frozen) we also discussed 
a posting made to the mailing list about how best to represent time intervals 
[7] and the need to follow up on what, if anything, will be happening at summit 
with regard to the API-WG.

The meeting logs are in the usual place [5]. If you find an issue with an 
existing guideline [3] or think of one that needs to exist, make a bug [4]. 
Also, please feel free to review the bugs that are there and if you think there 
is one you can resolve, please assign yourself and make it happen. If you have 
questions, ask in the #openstack-sdks IRC channel.

# New guidelines

No new guidelines have been merged this week.

# API guidelines that have been recently merged

Nothing new in the recent past.

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.

* add a warning about json expectations
  https://review.openstack.org/#/c/364460/

# Guidelines currently under review [6]

There are no new guidelines this week.

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working group 
about changes which would benefit from wider inspection by group members and 
liaisons. While the working group will attempt to address these reviews 
whenever possible, it is highly recommended that interested parties attend the 
API WG meetings [2] to promote communication surrounding their reviews.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [3].

Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
[6]: https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[7]: Thread starting at 
http://lists.openstack.org/pipermail/openstack-dev/2016-October/105198.html

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing 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] Deprecating the Ceilometer API

[Yarko Tymciurak]

On Tue, Oct 4, 2016 at 11:22 AM, gordon chung  wrote:

>
>
> On 04/10/2016 12:04 PM, Yarko Tymciurak wrote:
> > I won't be at Barcelona, but would like to participate in the telemetry
> > sessions, and particularly this one.
> > Are there plans to enable remote participants (beyond just etherpad),
> >  i.e. hangouts or skype, or something similar?
>
> we can try this. i know some other projects have done this. hangouts
> probably easiest choice (assuming we don't have more than 10 people)?
>
> i would definitely raise topics beforehand though. especially if we have
> morning sessions. i tried waking up for Europe time last year for
> virtual midcycle -- it sucks waking up at 3am.
>

Sounds good - sucks even more @ 2AM...

I'm central time (San Antonio), so 7 hours difference:
09AM - 05PM Barcelona ==
02AM - 10AM San Antonio (CDT)

Note:
01PM == 6AM
so, participation will be simplest for me for after lunch sessions.

Regardless, I plan to participate.
(If I really need to, I'll try sleeping 6PM - 2AM)

Thanks,
Yarko


> cheers,
> --
> 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
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] FYI, nova plans to have a room at the PTG in February

[Matt Riedemann]

This is just a follow up email to the discussion about nova's 
participation in the Project Team Gathering (PTG) in February right 
after the Ocata release.


I had asked because the OpenStack Foundation is getting early feedback 
on which teams are planning to attend. Several people said they planned 
on attending the PTG during the Nova meeting so I've submitted the form 
saying we'll have a room for Nova.


Remember at a high level that the PTG is the replacement for the 
midcycle meetups, except it's centrally located and organized by the 
foundation, and it's at the release boundaries rather than the middle.


The traditional summit that we're used to is now in the middle of the 
release and is more for the marketing stuff that happens at the summit 
whereas the PTG is supposed to be strictly technical and for 
development, like the design summit.


Personally if you care more about development discussions and would have 
to pick between going to the PTG or the summit, the PTG is the thing you 
want to try and get to now, but that's my opinion.


--

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] [all][API WG] How does one best express a time interval as an API filtering query?

[Everett Toews]

> On Oct 6, 2016, at 10:43 AM, Jeremy Stanley  wrote:
> 
> On 2016-10-06 10:30:30 -0500 (-0500), Kevin L. Mitchell wrote:
> [...]
>> Problem with that is that ':' is a valid character within an ISO date,
>> though I do like the 'between' prefix.  Now, '/' can be used if it's URL
>> encoded, but I agree that that is non-ideal.  How about a syntax
>> something like:
>> 
>>
>> ?finished_at=between:ISO_DATE_A@ISO_DATE_B_at=between:ISO_DATE_C@ISO_DATE_D
> 
> I'll admit I'm not up on the intricacies of URL expectations for
> APIs, but why not just use a comma? That's not an unusual meaning
> for it as punctuation (at least in English), and has the property
> that it's not overloading a typical field separator within either
> 8601 or HTTP encodings. (Now I've fulfilled my bikeshed quota for
> the month.)

We chatted about this at the API WG meeting today. This seems reasonable to us 
too.

?finished_at=between:ISO_DATE_A,ISO_DATE_B

@milanisko I encourage you to propose this change to the filtering guideline! 
[1]

Contributing is easy, same as any other OpenStack project. See #2 under How to 
Contribute. [2]

[1] 
https://github.com/openstack/api-wg/blob/master/guidelines/pagination_filter_sort.rst#filtering
[2] https://wiki.openstack.org/wiki/API_Working_Group#How_to_Contribute




__
OpenStack Development Mailing 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] [puppet] Presence at the PTG

[Alex Schultz]

Hi,

We chatted about this a bit in the last meeting[0], but I wanted to
send a note to the wider audience. Our initial thought was that the
puppet group will not have a specific presence at the upcoming PTG in
Atlanta.  We don't think we'll have any topics that we can't work
through via our traditional irc/email workflows. If anyone has any
topics or items that they would like to work through at the upcoming
PTG, please let us know and we can revisit this.

Thanks,
-Alex

[0] 
http://eavesdrop.openstack.org/meetings/puppet_openstack/2016/puppet_openstack.2016-04-19-15.00.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] [neutron][networking-vpp]Introducing networking-vpp

[Naveen Joy (najoy)]

It's primarliy because we have seen better stability and scalability with etcd 
over rabbitmq.

Thanks,
Naveen

From: Kevin Benton >
Reply-To: openstack-dev 
>
Date: Wednesday, October 5, 2016 at 3:27 PM
To: openstack-dev 
>
Subject: Re: [openstack-dev] [neutron][networking-vpp]Introducing networking-vpp

Cool. Always like to see more drivers.

I'm curious about the choice of etcd instead of rabbitmq as the communication 
mechanism between the mech driver and the agents since it introduces a new 
dependency into the deployment. Is this because the agent is written to work 
with other things like Kubernetes, Docker, etc as well?

On Wed, Oct 5, 2016 at 12:01 PM, Ian Wells 
> wrote:
We'd like to introduce the VPP mechanism driver, networking-vpp[1], to the 
developer community.

networking-vpp is an ML2 mechanism driver to control DPDK-based VPP user-space 
forwarders on OpenStack compute nodes.  The code does what mechanism drivers do 
- it connects VMs to each other and to other Neutron-provided network services 
like routers.  It also does it with care - we aim to make sure this is a robust 
design that can withstand common cloud problems and failures - and with clarity 
- so that it's straightforward to see what it's chosen to do and what it's 
thinking.

To give some background:

VPP is an open source network forwarder originally developed by Cisco and now 
part of the Linux Foundation FD.io project for fast dataplanes.  It's very very 
good at moving packets around, and has demonstrated performance up to and well 
beyond 10Gbps - of tiny packets: ten times the number of packets iperf uses to 
fill a 10Gbps link.  This makes it especially useful for NFV use cases.  It's a 
user space forwarder, which has other benefits versus kernel packet forwarding: 
it can be stopped and upgraded without rebooting the host, and (in the worst 
case) it can crash without bringing down the whole system.

networking-vpp is its driver for OpenStack.  We've written about 3,000 lines of 
code, consisting of a mechanism driver and an agent to program VPP through its 
Python API, and we use etcd to be a robust datastore and communication channel 
living between the two.


The code, at the moment, is in a fairly early stage, so please play with it and 
fix or report any problems you find.  It will move packets between VLANs and 
flat networks and VMs, and will connect to DHCP servers, routers and the 
metadata server in your cloud, so for basic uses it will work just the way you 
expect.  However, we certainly don't support every feature of Neutron just yet. 
 In particular, we haven't tested some things like LBaaS and VPNaaS with it - 
they should work, we just haven't tried - and, most obviously, security groups 
are not yet implemented - that's on the way.  However, we'd like to get it into 
your hands so that you can have a go with it, see what you like and don't like 
about it, and help us file down the rough edges if you feel like joining us.  
Enjoy!

[1]
https://github.com/openstack/networking-vpp for all your code needs
https://review.openstack.org/#/q/status:open+project:openstack/networking-vpp 
to help
https://launchpad.net/networking-vpp for bugs


__
OpenStack Development Mailing 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][API WG] How does one best express a time interval as an API filtering query?

[Jeremy Stanley]

On 2016-10-06 10:30:30 -0500 (-0500), Kevin L. Mitchell wrote:
[...]
> Problem with that is that ':' is a valid character within an ISO date,
> though I do like the 'between' prefix.  Now, '/' can be used if it's URL
> encoded, but I agree that that is non-ideal.  How about a syntax
> something like:
> 
> 
> ?finished_at=between:ISO_DATE_A@ISO_DATE_B_at=between:ISO_DATE_C@ISO_DATE_D

I'll admit I'm not up on the intricacies of URL expectations for
APIs, but why not just use a comma? That's not an unusual meaning
for it as punctuation (at least in English), and has the property
that it's not overloading a typical field separator within either
8601 or HTTP encodings. (Now I've fulfilled my bikeshed quota for
the month.)
-- 
Jeremy Stanley

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

Re: [openstack-dev] [neutron][networking-vpp]Introducing networking-vpp

[Neil Jerram]

On Thu, Oct 6, 2016 at 3:44 PM Jay Pipes  wrote:

> On 10/06/2016 03:46 AM, Jerome Tollet (jtollet) wrote:
> > Hey Kevin,
> >
> > Thanks for your interest in this project.
> >
> > We found etcd very convenient to store desired states as well as
> > operational states. It made the design easy to provide production grade
> > features (e.g. agent restart, mechanical driver restart, …) in a very
> > concise code. In addition to that, debugging is simple to do using
> > simple “etcdwatch” commands. Please note that etcd is not an alternative
> > to rabbitmq even though communication protocol is HTTP/JSON.
>
> It's probably worth mentioning that the etcd code used in networking-vpp
> came from networking-calico?
>

> When I chatted with Ian about this, I actually asked the same question
> and Ian told me the code came from networking-calico pretty much as-is.
>

To clarify (or check my own understanding of!) that statement: it's
certainly true that networking-calico also uses etcd as its mechanism for
communicating between the ML2 driver and the agents.  However, from a quick
look at the networking-vpp code, it appears to me that it doesn't use any
detailed etcd handling code from networking-calico, or use the same etcd
data model as Calico (i.e. the definition of how information is structured
and named in the etcd tree).  So I think the statement above just means
that networking-vpp uses a similar architecture as networking-calico, in
particular as regards using etcd for communication.

Happy to be corrected if that's not quite right, of course!


> We can discuss at length about using etcd as the state data store
> instead of the Neutron database and using etcd watches as the mechanism
> for state change communication, but that will likely end up in lots of
> bike-shedding. There's certainly advantages and disadvantages to each
> approach.
>

Another clarification here, I think you should say 'as the transport
instead of Neutron RPC', not 'as the state data store instead of the
Neutron database'.  With networking-calico the Neutron DB is still the
primary source of truth, and the etcd DB is just a mapping of that; and I
would guess (tentatively) that that is true for networking-vpp as well.


> Best,
> -jay
>

Regards,
 Neil
__
OpenStack Development Mailing 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][API WG] How does one best express a time interval as an API filtering query?

[Kevin L. Mitchell]

On Thu, 2016-10-06 at 10:59 -0400, Jay Pipes wrote:
> > Currently, we propose:
> >
> > ?finished_at=/_at=/&...
> 
> The issue I have with the is that it uses a / character to delimit the a 
> and b dates.
> 
> In keeping with the style of the API-WG filter operators, I would 
> propose something like this:
> 
> ?finished_at=between:ISO_DATE_A:ISO_DATE_B_at=between:ISO_DATE_C:ISO_DATE_D

Problem with that is that ':' is a valid character within an ISO date,
though I do like the 'between' prefix.  Now, '/' can be used if it's URL
encoded, but I agree that that is non-ideal.  How about a syntax
something like:


?finished_at=between:ISO_DATE_A@ISO_DATE_B_at=between:ISO_DATE_C@ISO_DATE_D
-- 
Kevin L. Mitchell 


signature.asc
Description: This is a digitally signed message part
__
OpenStack Development Mailing 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-announce] OpenStack Newton is officially released!

[Haïkel]

RDO Newton GA was ready for more than an hour ago, builds are currently running.
Formal publication should happen soon.

Good job to all projects and release mgmt team!

Regards,
H.

__
OpenStack Development Mailing 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] [libvirt] Debugging blockRebase() - "active block copy not ready for pivot"

[Kashyap Chamarthy]

On Thu, Oct 06, 2016 at 09:29:41AM -0500, Eric Blake wrote:
> On 10/06/2016 07:58 AM, Kashyap Chamarthy wrote:
> > On Thu, Oct 06, 2016 at 01:32:39AM +0200, Kashyap Chamarthy wrote:
> >> TL;DR
> >> -
> >>
> >> From the debug analysis of the log below, and discussion with Eric Blake
> >> of upstream QEMU / libvirt resulted in the below bug report:
> >>
> >>   https://bugzilla.redhat.com/show_bug.cgi?id=1382165 --
> >>   virDomainGetBlockJobInfo: Adjust job reporting based on QEMU stats & the
> >>   "ready" field of `query-block-jobs`
> > 
> > When I raised this on libvirt mailing list[0][1], one of the upstream
> > libvirt devs expressed an NACK in adjusting / "deliberately reporting
> > false data in block info structure".  Similar concern was also shared by
> > Matt Booth on #openstack-nova IRC.
> 
> I disagree with that sentiment. 

Interesting, I just noticed your argument here:

https://www.redhat.com/archives/libvir-list/2016-October/msg00249.html

> I think it is libvirt's responsibility to live up to libvirt's promise
> of virDomainGetBlockJobInfo() (namely, LIBVIRT documents that cur==end
> means the job is stable; and if qemu reports cur==end when the job is
> not stable, then it is libvirt that is lying to the upper user if it
> does NOT munge qemu's results to be accurate).
>
> As it is, we already patched libvirt to munge qemu's 0/0 into 0/1 when
> ready:false, so munging 123/123 into 122/123 when ready:false would just
> be another case of libvirt working around an infelicity of qemu.  There
> is NO INHERENT MEANING to the magnitude of cur and end, nor any
> requirement that end stays the same value across multiple calls to
> virDomainGetBlockJobInfo() - they are ONLY useful for a relative
> comparison of how much work remains to be done.  Munging the results IS
> appropriate.

Understood, this clarifies it, albeit a little messy. 

It indeed seems inconsistent to allow it in one case (like the one you
allude to above, fixed in 988218ca[1]) to adjust (& _not_ falsify, as
you accurately point out) libvirt reporting, but not the other case
(cur==end, "ready": false case when cur != 0).

So I re-opened the upstream libvirt bug[2] in light of your new
comments.
 

[1] http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=988218ca
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1382165 --
virDomainGetBlockJobInfo: Adjust job reporting based on QEMU stats &
the "ready" field of `query-block-jobs`

> That said, if you are going to work with existing libvirt that does
> not munge values, then yes, you either have to implement event
> handling or parse XML for the ready status, as existing libvirt's
> virDomainGetBlockJobInfo() is insufficient for the task.

Yep, noted.

Thanks for the great details, as usual.


-- 
/kashyap

__
OpenStack Development Mailing 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-announce] OpenStack Newton is officially released!

[Matthew Thode]

On 10/06/2016 09:34 AM, Anita Kuno wrote:
> On 16-10-06 10:04 AM, Doug Hellmann wrote:
>> Hello OpenStack community,
>>
>> I'm overjoyed to announce the final releases for the components of
>> OpenStack Newton, which conclude the 6-month Newton development
>> cycle.
>>
>> You will find a complete list of the deliverables for the 31 services
>> and ~130 other components and libraries that make up the Newton
>> release, their latest versions, and links to individual project
>> release notes documents listed on the release site:
>>
>>  https://releases.openstack.org/newton/
>>
>> Congratulations to all of the teams who have contributed to this
>> release!
>>
>> Our next production cycle, Ocata, has already started. We will meet
>> in Barcelona October 25-28 at the Ocata Design Summit to plan the
>> work for the upcoming cycle. I hope to see you there!
>>
>> Doug
>>
>> ___
>> OpenStack-announce mailing list
>> openstack-annou...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
> 
> Thank you Doug and everyone on the release management team.
> 
> Congratulations everyone, nice work on Newton.
> 
> Thank you,
> Anita.
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Awesome :D

Gentoo packages have been done for a few days with upgrades tested from
mitaka to newton (and on back from grizzly too).  Each release is
getting a little easier to package :D

-- 
-- Matthew Thode (prometheanfire)



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

Re: [openstack-dev] [all][API WG] How does one best express a time interval as an API filtering query?

[Jay Pipes]

Great question! My opinion inline...

On 10/06/2016 08:56 AM, milanisko k wrote:

Dear API WG,
We've got ourselves into a bike shedding situation[1] w/r the WG
filtering suggestion[2]. What we find difficult is to express the
ISO8601 time intervals[3][4] in accordance to the filtering suggestion.
We'd like to have support for specifying multiple time intervals a node
introspection can belong to as a filter criterion.

Currently, we propose:

?finished_at=/_at=/&...


The issue I have with the is that it uses a / character to delimit the a 
and b dates.


In keeping with the style of the API-WG filter operators, I would 
propose something like this:


?finished_at=between:ISO_DATE_A:ISO_DATE_B_at=between:ISO_DATE_C:ISO_DATE_D

Best,
-jay


denoting following Python condition:
  (ISOdate_a <= finished_at < ISOdate_b) or (ISOdate_c <=
finished_at < ISOdate_d) or...

How does one best express this query in accordance to the WG filtering
suggestion?

Thanks,
milan

[1]
https://review.openstack.org/#/c/375045/7/specs/list-introspection-statuses.rst
[2]
https://github.com/openstack/api-wg/blob/master/guidelines/pagination_filter_sort.rst#filtering

[3] https://en.wikipedia.org/wiki/ISO_8601#Time_intervals
[4] http://www.ukoln.ac.uk/metadata/dcmi/date-dccd-odrf


__
OpenStack Development Mailing 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][networking-vpp]Introducing networking-vpp

[Jay Pipes]

On 10/06/2016 03:46 AM, Jerome Tollet (jtollet) wrote:

Hey Kevin,

Thanks for your interest in this project.

We found etcd very convenient to store desired states as well as
operational states. It made the design easy to provide production grade
features (e.g. agent restart, mechanical driver restart, …) in a very
concise code. In addition to that, debugging is simple to do using
simple “etcdwatch” commands. Please note that etcd is not an alternative
to rabbitmq even though communication protocol is HTTP/JSON.


It's probably worth mentioning that the etcd code used in networking-vpp 
came from networking-calico?


When I chatted with Ian about this, I actually asked the same question 
and Ian told me the code came from networking-calico pretty much as-is.


We can discuss at length about using etcd as the state data store 
instead of the Neutron database and using etcd watches as the mechanism 
for state change communication, but that will likely end up in lots of 
bike-shedding. There's certainly advantages and disadvantages to each 
approach.


Best,
-jay

__
OpenStack Development Mailing 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] [libvirt] Debugging blockRebase() - "active block copy not ready for pivot"

[Eric Blake]

On 10/06/2016 07:58 AM, Kashyap Chamarthy wrote:
> On Thu, Oct 06, 2016 at 01:32:39AM +0200, Kashyap Chamarthy wrote:
>> TL;DR
>> -
>>
>> From the debug analysis of the log below, and discussion with Eric Blake
>> of upstream QEMU / libvirt resulted in the below bug report:
>>
>>   https://bugzilla.redhat.com/show_bug.cgi?id=1382165 --
>>   virDomainGetBlockJobInfo: Adjust job reporting based on QEMU stats & the
>>   "ready" field of `query-block-jobs`
> 
> When I raised this on libvirt mailing list[0][1], one of the upstream
> libvirt devs expressed an NACK in adjusting / "deliberately reporting
> false data in block info structure".  Similar concern was also shared by
> Matt Booth on #openstack-nova IRC.

I disagree with that sentiment.  I think it is libvirt's responsibility
to live up to libvirt's promise of virDomainGetBlockJobInfo() (namely,
LIBVIRT documents that cur==end means the job is stable; and if qemu
reports cur==end when the job is not stable, then it is libvirt that is
lying to the upper user if it does NOT munge qemu's results to be accurate).

As it is, we already patched libvirt to munge qemu's 0/0 into 0/1 when
ready:false, so munging 123/123 into 122/123 when ready:false would just
be another case of libvirt working around an infelicity of qemu.  There
is NO INHERENT MEANING to the magnitude of cur and end, nor any
requirement that end stays the same value across multiple calls to
virDomainGetBlockJobInfo() - they are ONLY useful for a relative
comparison of how much work remains to be done.  Munging the results IS
appropriate.

That said, if you are going to work with existing libvirt that does not
munge values, then yes, you either have to implement event handling or
parse XML for the ready status, as existing libvirt's
virDomainGetBlockJobInfo() is insufficient for the task.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



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

Re: [openstack-dev] [QA][infra][all] Measuring code coverage in integration tests

[Andrea Frittoli]

The difficulty with integration testing is that the services under test run
in processes separated from the test one(s).

There is not obvious / existing mechanism to collect coverage data in this
case. Several cycles back used to be a backdoor built into nova to enable
coverage data collection during integration testing, but it has been
removed long ago.

andrea

On Thu, Sep 29, 2016 at 12:12 PM Assaf Muller  wrote:

> On Thu, Sep 29, 2016 at 5:27 AM, milanisko k  wrote:
>
>
>
> út 27. 9. 2016 v 20:12 odesílatel Assaf Muller  napsal:
>
> On Tue, Sep 27, 2016 at 2:05 PM, Assaf Muller  wrote:
>
>
>
> On Tue, Sep 27, 2016 at 12:18 PM, Timur Nurlygayanov <
> tnurlygaya...@mirantis.com> wrote:
>
> Hi milan,
>
> we have measured the test coverage for OpenStack components with
> coverage.py tool [1]. It is very easy tool and it allows measure the
> coverage by lines of code and etc. (several metrics are available).
>
> [1] https://coverage.readthedocs.io/en/coverage-4.2/
>
>
> coverage also supports aggregating results from multiple runs, so you can
> measure results from combinations such as:
>
>
>
> 1) Unit tests
> 2) Functional tests
> 3) Integration tests
> 4) 1 + 2
> 5) 1 + 2 + 3
>
> To my eyes 3 and 4 make the most sense. Unit and functional tests are
> supposed to give you low level coverage, keeping in mind that 'functional
> tests' is an overloaded term and actually means something else in every
> community. Integration tests aren't about code coverage, they're about user
> facing flows, so it'd be interesting to measure coverage
> from integration tests,
>
>
> Sorry, replace integration with unit + functional.
>
>
> then comparing coverage coming from integration tests, and getting the set
> difference between the two: That's the area that needs more unit and
> functional tests.
>
>
> To reiterate:
>
> Run coverage from integration tests, let this be c
> Run coverage from unit and functional tests, let this be c'
>
> Let diff = c \ c'
>
> 'diff' is where you're missing unit and functional tests coverage.
>
>
> Assaf, the tool I linked is a monkey-patched coverage.py but the collector
> stores the stats in Redis --- gives the same accumulative collecting.
> Is there any interest/effort to collect coverage stats from selected jobs
> in CI, no matter the tool used?
>
>
> Some projects already collect coverage stats on their post-merge queue:
>
> http://logs.openstack.org/61/61af70a734b99e61e751cfb494ddc93a85eec394/post/nova-coverage-db-ubuntu-xenial/55210aa/
>
> It's invoked with 'tox -e cover' which you define in your project's
> tox.ini file, I imagine most projects if not all have it set up to gather
> coverage from a unit tests run.
>
>
>
>
>
>
>
>
>
> On Tue, Sep 27, 2016 at 1:06 PM, Jordan Pittier <
> jordan.pitt...@scality.com> wrote:
>
> Hi,
>
> On Tue, Sep 27, 2016 at 11:43 AM, milanisko k  wrote:
>
> Dear Stackers,
> I'd like to gather some overview on the $Sub: is there some infrastructure
> in place to gather such stats? Are there any groups interested in it? Any
> plans to establish such infrastructure?
>
> I am working on such a tool with mixed results so far. Here's my approach
> taking let's say Nova as an example:
>
> 1) Print all the routes known to nova (available as a python-routes
> object:  nova.api.openstack.compute.APIRouterV21())
> 2) "Normalize" the Nova routes
> 3) Take the logs produced by Tempest during a tempest run (in
> logs/tempest.txt.gz). Grep for what looks like a Nova URL (based on port
> 8774)
> 4) "Normalize" the tested-by-tempest Nova routes.
> 5) Compare the two sets of routes
> 6) 
> 7) Profit !!
>
> So the hard part is obviously the normalizing of the URLs. I am currently
> using a tons of regex :) That's not fun.
>
> I'll let you guys know if I have something to show.
>
> I think there's real interest on the topic (it comes up every year or so),
> but no definitive answer/tool.
>
> Cheers,
> Jordan
>
>
>
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
>
> Timur,
> Senior QA Manager
> OpenStack Projects
> Mirantis Inc
>
> __
> OpenStack Development Mailing 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
> 

Re: [openstack-dev] [openstack-announce] OpenStack Newton is officially released!

[Anita Kuno]

On 16-10-06 10:04 AM, Doug Hellmann wrote:

Hello OpenStack community,

I'm overjoyed to announce the final releases for the components of
OpenStack Newton, which conclude the 6-month Newton development
cycle.

You will find a complete list of the deliverables for the 31 services
and ~130 other components and libraries that make up the Newton
release, their latest versions, and links to individual project
release notes documents listed on the release site:

 https://releases.openstack.org/newton/

Congratulations to all of the teams who have contributed to this
release!

Our next production cycle, Ocata, has already started. We will meet
in Barcelona October 25-28 at the Ocata Design Summit to plan the
work for the upcoming cycle. I hope to see you there!

Doug

___
OpenStack-announce mailing list
openstack-annou...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce


Thank you Doug and everyone on the release management team.

Congratulations everyone, nice work on Newton.

Thank you,
Anita.

__
OpenStack Development Mailing 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] Draft Ocata design summit schedule is up

[Dan Smith]

> Is there a particular reason we're only retrospecting on placement?

I think that we need to have a concrete topic that applied to newton and
will apply to ocata in order to be productive. I think there will be
specific things we can change in ocata that will have an actual impact
on major work for the cycle.

> I suspect we can map many of the ideas and experiences from a
> retrospective devoted to placement to more general concerns but I'd
> hate for people who had no involvement in it but are concerned about
> Nova to feel excluded.
> 
> [1] https://etherpad.openstack.org/p/nova-newton-retrospective

As has been demonstrated in that etherpad, if we try to retrospect every
aspect of newton, we'd need a week and wouldn't have time to have the
other sessions we need in order to plan for ocata. Picking two major
ongoing topics seems like the best way to frame a useful discussion to me.

--Dan

__
OpenStack Development Mailing 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] Project name DB length

[gordon chung]

On 05/10/16 07:55 AM, Sean Dague wrote:
> Except... the 64 char field in keystone isn't required to be a uuid4.
> Which we ran into when attempting to remove it from the URLs in Nova.
> There is no validation anywhere that requires that of keystone values.
>
> For instance, Rackspace uses ints.

yeah, that's basically why we had to revert our attempt in Ceilometer. 
we tried to enforce uuid with some buffer and it was too difficult to 
track down every one we broke.

>
> Yes this is debt. And yes, a few things would be nicer if this was more
> constrained, but as was recently stated on twitter, we've been calling
> the 9th month the seventh month for 2000 years -
> https://twitter.com/GonzoHacker/status/781890649444519937. Some times
> the cost of fixing the thing really just isn't worth the potential
> breaks to operators that were operating within the old constraints fine.

i think this sums up my feeble attempt at initiating this as a cross 
project topic a while back. too many projects, too few participants, too 
little gain. we avoided the issue in Gnocchi and the original reason i 
brought it up became less important.

it'd be nice if we could somehow enforce new attributes/columns to 
follow uuid standards in hopes that older stuff just eventually dies 
off. that said, i'm guessing stuff like user_id and project_id columns 
are sticking around for a while...

cheers,

-- 
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] [nova] Draft Ocata design summit schedule is up

[Sylvain Bauza]

Le 06/10/2016 15:41, Chris Dent a écrit :

On Wed, 5 Oct 2016, Matt Riedemann wrote:


The draft design summit schedule for nova is here:

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



[snip]

If there are any questions or issues with this please speak up 
because this will more or less be official next week.


Is there a particular reason we're only retrospecting on placement?
Based on the etherpad[1] and conversations with other contributors a
lot of the questions and concerns about how things went with
placement are applicable to much of the rest of Nova; and, despite my
(well intentioned) moaning, I've been told that the experience on
placement (as a priority) was above average so it may not be
representative.

I suspect we can map many of the ideas and experiences from a
retrospective devoted to placement to more general concerns but I'd
hate for people who had no involvement in it but are concerned about
Nova to feel excluded.



The real problem I see with that is given all the bullets, it would take 
far more than just 40 mins just to be at least discussing about. That 
doesn't mean we shouldn't talk about the other mentioned points, just 
not by the time Matt proposed the session IMHO.


-Sylvain


[1] https://etherpad.openstack.org/p/nova-newton-retrospective



__
OpenStack Development Mailing 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] Draft Ocata design summit schedule is up

[Chris Dent]

On Wed, 5 Oct 2016, Matt Riedemann wrote:


The draft design summit schedule for nova is here:

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


[snip]

If there are any questions or issues with this please speak up because this 
will more or less be official next week.


Is there a particular reason we're only retrospecting on placement?
Based on the etherpad[1] and conversations with other contributors a
lot of the questions and concerns about how things went with
placement are applicable to much of the rest of Nova; and, despite my
(well intentioned) moaning, I've been told that the experience on
placement (as a priority) was above average so it may not be
representative.

I suspect we can map many of the ideas and experiences from a
retrospective devoted to placement to more general concerns but I'd
hate for people who had no involvement in it but are concerned about
Nova to feel excluded.

[1] https://etherpad.openstack.org/p/nova-newton-retrospective

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing 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]

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

__
OpenStack Development Mailing 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?

[Clint Byrum]

Excerpts from Renat Akhmerov's message of 2016-10-06 19:21:40 +0700:
> Hi,
> 
> As you likely know, the summit format will change after Barcelona. There will 
> be two events now: PTG (Project Team Gathering) for design sessions and 
> OpenStack Summit which is more customer/promotion oriented . The first will 
> take place in Atlanta on Feb 20-24, 2017 and the second one in May 2017 in 
> Boston. More about that at [1]. Please read it.

May 2017 is the OpenStack Conference, not a PTG. Teams are welcome to
schedule a mid-cycle coinciding with this event to take advantage of
contributors attending the conference, but it's not an "everyone together
in one place" event.

__
OpenStack Development Mailing 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] [libvirt] Debugging blockRebase() - "active block copy not ready for pivot"

[Kashyap Chamarthy]

On Thu, Oct 06, 2016 at 01:32:39AM +0200, Kashyap Chamarthy wrote:
> TL;DR
> -
> 
> From the debug analysis of the log below, and discussion with Eric Blake
> of upstream QEMU / libvirt resulted in the below bug report:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1382165 --
>   virDomainGetBlockJobInfo: Adjust job reporting based on QEMU stats & the
>   "ready" field of `query-block-jobs`

When I raised this on libvirt mailing list[0][1], one of the upstream
libvirt devs expressed an NACK in adjusting / "deliberately reporting
false data in block info structure".  Similar concern was also shared by
Matt Booth on #openstack-nova IRC.

Next, turns out the READY event is already exposed via the guest XML[1]:

-
We expose the state of the copy job in the XML and forward the READY
event from qemu to the users.

A running copy job exposes itself in the xml as:


  
  
  
  


  
  [...]


While the ready copy job is exposed as:


  
  
  
  


  
  [...]



Additionally we have anyncrhronous events that are emitted once qemu
notifies us that the block job has reached sync state or finished.
Libvirt uses the event to switch to the ready state.

The documentation suggests that block jobs should listen to the events
and act accordingly only after receiving the event.
-

So, Nova's is_job_complete() method & friends need to be reworked to
listen on the events for job readiness.

[0]
https://www.redhat.com/archives/libvir-list/2016-October/msg00217.html
[1] https://www.redhat.com/archives/libvir-list/2016-October/msg00229.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1382165#c3
 
> 
> Details
> ---
> 
> The code in Nova that's being executed is this part in _swap_volume()
> from libvirt/driver.py.
> 
> [...]
> # Start copy with VIR_DOMAIN_REBASE_REUSE_EXT flag to
> # allow writing to existing external volume file
> dev.rebase(new_path, copy=True, reuse_ext=True)
> 
> while not dev.is_job_complete():
> time.sleep(0.5)
>
> 
> dev.abort_job(pivot=True)
> [...]
> 

[...]

-- 
/kashyap

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

[openstack-dev] [all][API WG] How does one best express a time interval as an API filtering query?

[milanisko k]

Dear API WG,
We've got ourselves into a bike shedding situation[1] w/r the WG filtering
suggestion[2]. What we find difficult is to express the ISO8601 time
intervals[3][4] in accordance to the filtering suggestion. We'd like to
have support for specifying multiple time intervals a node introspection
can belong to as a filter criterion.

Currently, we propose:

?finished_at=/_at=/&...

denoting following Python condition:
  (ISOdate_a <= finished_at < ISOdate_b) or (ISOdate_c <= finished_at <
ISOdate_d) or...

How does one best express this query in accordance to the WG filtering
suggestion?

Thanks,
milan

[1]
https://review.openstack.org/#/c/375045/7/specs/list-introspection-statuses.rst
[2]
https://github.com/openstack/api-wg/blob/master/guidelines/pagination_filter_sort.rst#filtering

[3] https://en.wikipedia.org/wiki/ISO_8601#Time_intervals
[4] http://www.ukoln.ac.uk/metadata/dcmi/date-dccd-odrf
__
OpenStack Development Mailing 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] [puppet] [tripleo] our CI is now deploying OpenStack Ocata

[Emilien Macchi]

Quick FYI about TripleO and Puppet CI.
We bumped RDO to start building OpenStack Ocata packages, and
successfully made the switch in the TripleO and Puppet gates.

So both CI deploy OpenStack from trunk again, and not Newton.
Stable gates (newton) are deploying latest Newton packages though.

Thanks for the people who were involved in that process, big kudos 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

[openstack-dev] [mistral] Who's interested in attending PTG?

[Renat Akhmerov]

Hi,

As you likely know, the summit format will change after Barcelona. There will 
be two events now: PTG (Project Team Gathering) for design sessions and 
OpenStack Summit which is more customer/promotion oriented . The first will 
take place in Atlanta on Feb 20-24, 2017 and the second one in May 2017 in 
Boston. More about that at [1]. Please read it.

IMPORTANT: We need to express our intention about our presence at PTG in 
Atlanta before Oct 16th. I recognize that it’s a little bit early but please 
discuss it with your teams and try to decide who is going to this PTG. Based on 
that we’ll make a request to the organizers.

[1] http://www.openstack.org/ptg 

Thanks

Renat Akhmerov
@Nokia

__
OpenStack Development Mailing 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] Don't use Scheduler to run actions

[Renat Akhmerov]

Yes, I’ll come up with some additional info and a diagram.

Renat Akhmerov
@Nokia

> On 6 Oct 2016, at 05:29, Lingxian Kong  wrote:
> 
> Hi, Renat,
> 
> Thanks for raising it up!
> 
> Does that mean mistral-engine will do the RPC call directly to 
> mistral-executor after storing the calling information somewhere? I think a 
> flow chart would be better to explain current problem and your proposal, and 
> what's more, I personally think it deserves a spec since I see it as a 
> feature instead of a simple bug.
> 
> 
> Cheers,
> Lingxian Kong (Larry)
> 
> On Wed, Oct 5, 2016 at 11:14 PM, Renat Akhmerov  > wrote:
> Hi Team,
> 
> I posted a bug [1] at Launchpad that is pretty important for many reasons. I 
> tried to put all needed information into
> the bug description providing pros and cons of using Scheduler for running 
> actions. I short, I’d like to remove
> Scheduler from the chain that leads to running an action on executor for 
> performance reason (~30% difference
> on large workflows, from my experience). I decided to bring it up to a 
> discussion here because I may be
> missing something and am very interested in your opinions. Please let me know 
> if you have any additional
> arguments to those I provided in the bug.
> 
> [1] https://bugs.launchpad.net/mistral/+bug/1630508 
> 
> 
> Thanks
> 
> Renat Akhmerov
> @Nokia
> 
> 
> __
> OpenStack Development Mailing 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] [QA] The end-user test suite for OpenStack clusters

[Timur Nurlygayanov]

Ken, it is a good idea!

The plan is to develop os-faults as a library which will be able
to manage cluster nodes and OpenStack services on these nodes.
It is a good idea to add some Tempest tests which will use
os-faults library as well for some API tests.

The Stepler framework [1] will use os-faults to perform all destructive
actions in the clouds (the reboot of nodes, restart of OpenStack services,
enable/disable network interfaces or some firewall rules and etc).

We need to get +1 from you in [1] to create the repository with
advanced end-user scenario tests.

Thank you!

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

On Tue, Oct 4, 2016 at 8:53 PM, Yaroslav Lobankov 
wrote:

> Hi Ken,
>
> OS-Faults doesn't have any scenarios in the tree yet (the project is two
> months old), but you can find some examples of the use in the
> os-faults/examples directory.
>
> Regards,
> Yaroslav Lobankov.
>
> On Tue, Oct 4, 2016 at 8:02 PM, Ken'ichi Ohmichi 
> wrote:
>
>> Hi Timur,
>>
>> Thanks for your explanation.
>>
>> 2016-09-29 6:22 GMT-07:00 Timur Nurlygayanov > >:
>> >
>> >> I am guessing the above "restart nodes" is for verifying each
>> >> OpenStack service restarts successfully, right?
>> >
>> > Yes, this is right. And we also will check that HA logic for these
>> > services works correctly (for example, rescheduling of L3 Neutron
>> > agents for networks).
>> >
>> >> But these service scripts are provided by distributors, and Devstack
>> >> itself doesn't contain service scripts IIUC.
>> >> So I'd like to know how to verify it on Devstack clouds.
>> >
>> > Yes, DevStack doesn't support many scenarios which are actual
>> > and should be supported on the production clouds.
>> > It will be not possible to run all advanced test scenarios for DevStack
>> > clouds,
>> > just because DevStack can't deploy OpenStack cloud with 3 controllers
>> > now (so, probably it will be possible in the future).
>> >
>> > Of course, some advanced scenarios will support DevStack clouds,
>> > for example, some test scenarios which are based on customer-found
>> > issues from the real production clouds, like upload of the large images
>> > (100+ Gb)
>> > to Glance with Swift backend. Such cases are important for verification
>> of
>> > pre-production environments, but not very important for CI gate jobs.
>> >
>> > It is also important to note that in these advanced cases we are
>> targeting
>> > to check not only the logic of Python code, but also the correct
>> > configuration
>> > of all OpenStack components on some pre-production OpenStack clusters.
>>
>> I guessed some part of os-faults can be moved to Tempest if os-faults
>> contains API tests for enabling/disabling OpenStack services.
>> Then, os-faults would be able to concentrate on more destructive tests
>> like rebooting physical nodes, etc.
>> However, I could not find any actual scenarios on current os-faults
>> (https://github.com/openstack/os-faults).
>> That seems to just contain some abstraction layers and unit tests. Can
>> we see actual test scenarios of os-faults ?
>> Maybe I missed something.
>>
>> Thanks
>> Ken Ohmichi
>>
>> 
>> __
>> 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
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Timur,
Senior QA Manager
OpenStack Projects
Mirantis Inc
__
OpenStack Development Mailing 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] Adding ozamiatin to oslo-core

[Oleksii Zamiatin]

Thanks a lot for such a great honor! I’ll try to do my best.

> 3 окт. 2016 г., в 20:42, Joshua Harlow  написал(а):
> 
> Greetings all stackers,
> 
> I propose that we add Oleksii Zamiatin[1] to the oslo-core[2] team.
> 
> Oleksii has been actively contributing to oslo for a while now, both in
> helping make oslo better via code contribution(s) and by helping with the 
> review load when he can. He has provided quality reviews and is doing an 
> awesome job with the various oslo concepts and helping make oslo the best it 
> can be!
> 
> Overall I think he would make a great addition to the core review team.
> 
> Please respond with +1/-1.
> 
> Thanks much!
> 
> - Joshua Harlow
> 
> [1] https://launchpad.net/~ozamiatin
> [2] https://launchpad.net/oslo
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Openstack] Neutron: Internet not available in VM instances

[kamalakannan sanjeevan]

Hi Mattei,

I just have these lines active in l3agent.ini

interface_driver =neutron.agent.linux.interface.OVSInterfaceDriver
external_network_bridge =

Hope that looks fine. Do we need to specify the external_network_bridge. Do
we need any other parameters.

Regards
Kamal


On Thu, Oct 6, 2016 at 3:36 PM, Remo Mattei  wrote:

> what’s your l3agent.ini says about external?
>
> On Oct 6, 2016, at 06:16, kamalakannan sanjeevan <
> chirukamalakan...@gmail.com> wrote:
>
> Hello,
>
> I am not able to connect to internet in teh spawned VM's.
>
>
> Ethernet card details:
>
> *Eth1 bridged through OVS(mybridge)  - 172.27.10.76*
> *Eth3-
> 192.168.182.251*
>
> after executing the command
>
> iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
>
> iptables -t nat -A POSTROUTING -o mybridge -j MASQUERADE
>
> - I see teh connectivity to VM's from my host name  ie 172.27.10.76 also
> affected.
>
> root@VFSR1:~# ovs-vsctl show
> 37f38767-0a2b-45fd-9507-abef7fd2d5c9
> Bridge br-int
> fail_mode: secure
> Port "qr-2ff64ff8-b8"
> tag: 6
> Interface "qr-2ff64ff8-b8"
> type: internal
> Port patch-tun
> Interface patch-tun
> type: patch
> options: {peer=patch-int}
> Port "qvo310233a4-9f"
> tag: 6
> Interface "qvo310233a4-9f"
> Port br-int
> Interface br-int
> type: internal
> Port "tap6bc359b6-f0"
> tag: 6
> Interface "tap6bc359b6-f0"
> type: internal
> Port "qvo703c764e-23"
> tag: 5
> Interface "qvo703c764e-23"
> Port int-mybridge
> Interface int-mybridge
> type: patch
> options: {peer=phy-mybridge}
> Port "qg-333a2d2b-ca"
> tag: 5
> Interface "qg-333a2d2b-ca"
> type: internal
>
>
>
>
>
>
>
>
>
> * Bridge mybridgePort mybridgeInterface
> mybridgetype: internalPort "eth1"
> Interface "eth1"Port phy-mybridgeInterface
> phy-mybridgetype: patchoptions:
> {peer=int-mybridge}*
> Bridge br-tun
> fail_mode: secure
> Port br-tun
> Interface br-tun
> type: internal
> Port patch-int
> Interface patch-int
> type: patch
> options: {peer=patch-tun}
> ovs_version: "2.5.0"
>
>
> Below is my network and router details
>
> root@VFSR1:~# neutron net-list
> +--+-+--
> ---+
> | id   | name|
> subnets |
> +--+-+--
> ---+
> | 51739543-b7d1-414b-bec1-9b38c3e5d5d7 | public  |
> 0db9fa02-27eb-4f38-8693-200719fc1fbf 172.27.10.0/24 |
> | bf919707-b1eb-4d8f-90fe-5bcf0e07dce3 | private |
> 7fddc311-7938-44c4-abd4-e5095adba422 192.168.0.0/24 |
> +--+-+--
> ---+
> root@VFSR1:~# neutron router-list
> +--++---
> 
> 
> +---
> --+---+
> | id   | name   |
> external_gateway_info
>
>   |
> distributed | ha|
> +--++---
> 
> 
> +---
> --+---+
> | 323a6782-46aa-458e-ad76-f9462d8ad955 | router | {"network_id":
> "51739543-b7d1-414b-bec1-9b38c3e5d5d7", "enable_snat": true,
> "external_fixed_ips": [{"subnet_id": "0db9fa02-27eb-4f38-8693-200719fc1fbf",
> "ip_address": "172.27.10.101"}]} | False   | False |
> +--++---
> 
> 
> +---
> --+---+
>
> Below are my instances created
>
> root@VFSR1:~# nova list
> +--+++--
> --+-++
> | ID   | Name   | Status | Task State |
> Power State | Networks   |
> 

Re: [openstack-dev] [Openstack] Neutron: Internet not available in VM instances

[Remo Mattei]

what’s your l3agent.ini says about external? 
> On Oct 6, 2016, at 06:16, kamalakannan sanjeevan 
>  wrote:
> 
> Hello,
> 
> I am not able to connect to internet in teh spawned VM's.
> 
> 
> Ethernet card details:
> Eth1 bridged through OVS(mybridge)  - 172.27.10.76
> Eth3- 
> 192.168.182.251
> 
> after executing the command
> 
> iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE 
> 
> iptables -t nat -A POSTROUTING -o mybridge -j MASQUERADE
> 
> - I see teh connectivity to VM's from my host name  ie 172.27.10.76 also 
> affected.
> 
> root@VFSR1:~# ovs-vsctl show
> 37f38767-0a2b-45fd-9507-abef7fd2d5c9
> Bridge br-int
> fail_mode: secure
> Port "qr-2ff64ff8-b8"
> tag: 6
> Interface "qr-2ff64ff8-b8"
> type: internal
> Port patch-tun
> Interface patch-tun
> type: patch
> options: {peer=patch-int}
> Port "qvo310233a4-9f"
> tag: 6
> Interface "qvo310233a4-9f"
> Port br-int
> Interface br-int
> type: internal
> Port "tap6bc359b6-f0"
> tag: 6
> Interface "tap6bc359b6-f0"
> type: internal
> Port "qvo703c764e-23"
> tag: 5
> Interface "qvo703c764e-23"
> Port int-mybridge
> Interface int-mybridge
> type: patch
> options: {peer=phy-mybridge}
> Port "qg-333a2d2b-ca"
> tag: 5
> Interface "qg-333a2d2b-ca"
> type: internal
> Bridge mybridge
> Port mybridge
> Interface mybridge
> type: internal
> Port "eth1"
> Interface "eth1"
> Port phy-mybridge
> Interface phy-mybridge
> type: patch
> options: {peer=int-mybridge}
> Bridge br-tun
> fail_mode: secure
> Port br-tun
> Interface br-tun
> type: internal
> Port patch-int
> Interface patch-int
> type: patch
> options: {peer=patch-tun}
> ovs_version: "2.5.0"
> 
> 
> Below is my network and router details
> 
> root@VFSR1:~# neutron net-list
> +--+-+-+
> | id   | name| subnets
>  |
> +--+-+-+
> | 51739543-b7d1-414b-bec1-9b38c3e5d5d7 | public  | 
> 0db9fa02-27eb-4f38-8693-200719fc1fbf 172.27.10.0/24  |
> | bf919707-b1eb-4d8f-90fe-5bcf0e07dce3 | private | 
> 7fddc311-7938-44c4-abd4-e5095adba422 192.168.0.0/24  |
> +--+-+-+
> root@VFSR1:~# neutron router-list
> +--++---+-+---+
> | id   | name   | external_gateway_info   
>   
>   
>   | distributed | ha|
> +--++---+-+---+
> | 323a6782-46aa-458e-ad76-f9462d8ad955 | router | {"network_id": 
> "51739543-b7d1-414b-bec1-9b38c3e5d5d7", "enable_snat": true, 
> "external_fixed_ips": [{"subnet_id": "0db9fa02-27eb-4f38-8693-200719fc1fbf", 
> "ip_address": "172.27.10.101"}]} | False   | False |
> +--++---+-+---+
> 
> Below are my instances created 
> 
> root@VFSR1:~# nova list
> +--++++-++
> | ID   | Name   | Status | Task State | Power 
> State | Networks   |
> +--++++-++
> | b737645b-317e-46be-b06a-f1b94f378d95 | test   | ACTIVE | -  | 
> Running | public=172.27.10.100  

[openstack-dev] [all][Elections] Vote Vote Vote in the TC election!

[Tristan Cacqueray]

We are coming down to the last days for voting in the TC election.

Search your gerrit preferred email address[0] for the following subject:
Poll: OpenStack Technical Committee (TC) Election - October 2016

That is your ballot and links you to the voting application. Please
vote. If you have voted, please encourage your colleagues to vote.

Candidate statements are linked to the names of all confirmed candidates:
http://governance.openstack.org/election/#ocata-tc-candidates


What to do if you don't see the email and have a commit in at least one
of the official programs projects[1]:
  * check the trash of your gerrit Preferred Email address[0], in case
it went into trash or spam
  * wait a bit and check again, in case your email server is a bit slow
  * find the sha of at least one commit from the program project
repos[1] and email the election officials[2]. If we can confirm
that you are entitled to vote, we will add you to the voters list
and you will be emailed a ballot.

Please vote!

Thank you,
-Tristan

[0] Sign into review.openstack.org: Go to Settings > Contact
Information. Look at the email listed as your Preferred Email.
That is where the ballot has been sent.
[1]
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=sept-2016-elections
[2] http://governance.openstack.org/election/#election-officials




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

Re: [openstack-dev] [glance][cinder][nova] zip for raw Disk Format

[Chen CH Ji]

Thanks for the reply

the question is how can I distinguish the image in 'real' qcow2 format ? I
mean, considering cinder copy from image to volume case,
I need first download that image from glance, then copy contents to
volume ,'real' qcow2 will keep the image while I expect the qcow2
to be converted into raw format within the given command, without a
explicit format, how to decide whether the convent will be made or not?

Thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Eric Harney 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   10/05/2016 06:19 PM
Subject:Re: [openstack-dev] [glance][cinder][nova] zip for raw Disk
Format



On 10/05/2016 05:46 AM, Chen CH Ji wrote:
>
> From [1] we support a few common and vendor specific disk format, as use
> raw image sometimes will be very big and do we have existing any method
to
> consider zip the raw disk so the disk space might be saved as an option
to
> offer to end user and admin  ? so something like [2] could be enhanced to
> support zipped format?
> Thanks
>

The qcow2 format supports compression and is one of the most widely
supported image formats that can be used with OpenStack.

You can convert a raw image to qcow2 with:
 $ qemu-img convert -f raw -O qcow2 -c image.raw image.qcow2

And then upload image.qcow2 to Glance.

> [1] http://docs.openstack.org/developer/glance/formats.html
> [2]
>
https://github.com/openstack/cinder/blob/master/cinder/image/image_utils.py#L182

>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
> Phone: +86-10-82454158
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
> Beijing 100193, PRC
>


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


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

Re: [openstack-dev] [Congress] PTG planning

[Thierry Carrez]

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

-- 
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] [neutron][networking-vpp]Introducing networking-vpp

[Jerome Tollet (jtollet)]

Hey Kevin,
Thanks for your interest in this project.
We found etcd very convenient to store desired states as well as operational 
states. It made the design easy to provide production grade features (e.g. 
agent restart, mechanical driver restart, …) in a very concise code. In 
addition to that, debugging is simple to do using simple “etcdwatch” commands. 
Please note that etcd is not an alternative to rabbitmq even though 
communication protocol is HTTP/JSON.
Jerome

De : Kevin Benton 
Répondre à : "OpenStack Development Mailing List (not for usage questions)" 

Date : jeudi 6 octobre 2016 00:27
À : "OpenStack Development Mailing List (not for usage questions)" 

Objet : Re: [openstack-dev] [neutron][networking-vpp]Introducing networking-vpp

Cool. Always like to see more drivers.

I'm curious about the choice of etcd instead of rabbitmq as the communication 
mechanism between the mech driver and the agents since it introduces a new 
dependency into the deployment. Is this because the agent is written to work 
with other things like Kubernetes, Docker, etc as well?

On Wed, Oct 5, 2016 at 12:01 PM, Ian Wells 
> wrote:
We'd like to introduce the VPP mechanism driver, networking-vpp[1], to the 
developer community.

networking-vpp is an ML2 mechanism driver to control DPDK-based VPP user-space 
forwarders on OpenStack compute nodes.  The code does what mechanism drivers do 
- it connects VMs to each other and to other Neutron-provided network services 
like routers.  It also does it with care - we aim to make sure this is a robust 
design that can withstand common cloud problems and failures - and with clarity 
- so that it's straightforward to see what it's chosen to do and what it's 
thinking.

To give some background:

VPP is an open source network forwarder originally developed by Cisco and now 
part of the Linux Foundation FD.io project for fast dataplanes.  It's very very 
good at moving packets around, and has demonstrated performance up to and well 
beyond 10Gbps - of tiny packets: ten times the number of packets iperf uses to 
fill a 10Gbps link.  This makes it especially useful for NFV use cases.  It's a 
user space forwarder, which has other benefits versus kernel packet forwarding: 
it can be stopped and upgraded without rebooting the host, and (in the worst 
case) it can crash without bringing down the whole system.

networking-vpp is its driver for OpenStack.  We've written about 3,000 lines of 
code, consisting of a mechanism driver and an agent to program VPP through its 
Python API, and we use etcd to be a robust datastore and communication channel 
living between the two.


The code, at the moment, is in a fairly early stage, so please play with it and 
fix or report any problems you find.  It will move packets between VLANs and 
flat networks and VMs, and will connect to DHCP servers, routers and the 
metadata server in your cloud, so for basic uses it will work just the way you 
expect.  However, we certainly don't support every feature of Neutron just yet. 
 In particular, we haven't tested some things like LBaaS and VPNaaS with it - 
they should work, we just haven't tried - and, most obviously, security groups 
are not yet implemented - that's on the way.  However, we'd like to get it into 
your hands so that you can have a go with it, see what you like and don't like 
about it, and help us file down the rough edges if you feel like joining us.  
Enjoy!

[1]
https://github.com/openstack/networking-vpp for all your code needs
https://review.openstack.org/#/q/status:open+project:openstack/networking-vpp 
to help
https://launchpad.net/networking-vpp for bugs

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

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

[openstack-dev] [neutron][ipam] Pluggable API change

[Gary Kotton]

Hi,
The patch https://review.openstack.org/#/c/363206 is proposing to change the 
API’s. This may break pluggable drivers. What is the suggested approach here?
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev