date:20170417

Re: [openstack-dev] Emails for OpenStack R Release Name voting going out - please be patient

2017-04-17 Thread Eduardo Gonzalez

Hi all,
is there any new about the mailing issue? Still not received mine.

Regards

On Thu, Apr 13, 2017, 1:51 AM Sean McGinnis  wrote:

> On Wed, Apr 12, 2017 at 05:27:13PM -0500, Jay S Bryant wrote:
> > I also didn't receive an e-mail.  :-(
> >
> I don't think we need to perpetuate this thread for everybody
> that didn't get it. I think it's safe to see that a large number
> of folks have not recieved the email. (Me included) :)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Proposing Florian Fuchs for tripleo-validations core

2017-04-17 Thread Jiri Tomasek


+1!


On 6.4.2017 11:53, Martin André wrote:

Hellooo,

I'd like to propose we extend Florian Fuchs +2 powers to the
tripleo-validations project. Florian is already core on tripleo-ui
(well, tripleo technically so this means there is no changes to make
to gerrit groups).

Florian took over many of the stalled patches in tripleo-validations
and is now the principal contributor in the project [1]. He has built
a good expertise over the last months and I think it's time he has
officially the right to approve changes in tripleo-validations.

Consider this my +1 vote.

Martin

[1] 
http://stackalytics.com/?module=tripleo-validations&metric=patches&release=pike

__
OpenStack Development Mailing 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] [Ironic] Buildroot deploy image POC ready for testing

2017-04-17 Thread Chris Smart

Hi all,

Over the last couple of months I have been working on creating a
smaller, more flexible deploy image for Ironic. It is now ready for
testing, if anyone is interested.

For this proof of concept I chose Buildroot [1], a well regarded, simple
to use tool for building embedded Linux images. The builds are done as a
regular non-root user and it has a menuconfig system (like the Linux
kernel) for customising the build. It supports caching of downloads and
ccache for builds.

With the current default configuration:

* Linux kernel is ~2MB
* Compressed initramfs image is ~25MB
* Bootable ISO image ~26MB
* Passing the OpenStack Ironic gating tests [2]
* Highly customisable (thanks to Buildroot)

All of the source code for building the image is up on my GitHub account
in the ipa-buildroot repository. [3]

I have also written up documentation which should walk you through the
whole build and customisation process. [4]

The ipa-buildroot repository contains the IPA specific Buildroot
configurations and tracks upstream Buildroot in a Git submodule
(actually I'm carrying one patch on top of Buildroot for now, but the
goal is to use pristine upstream Buildroot).

*In addition to this* I also have patches for ironic-python-agent on my
GitHub account that adds support for Buildroot to imagebuild. [5]

This will handle the dependencies, customisation and build of the
Buildroot Ironic image using make (like we do with tinyipa and coreos).

Using the ironic-python-agent repo is as simple as:

$ git clone https://github.com/csmart/ironic-python-agent.git
$ cd ironic-python-agent/imagebuild/buildroot
$ make help
$ # or
$ ./build-buildroot.sh --help

Buildroot will compile the kernel and initramfs, then post build scripts
clone the Ironic Python Agent repository (which defaults to upstream but
you can specify the repo and commit) and creates Python wheels to
install into the target.

Customising the build is pretty easy, too:

$ make menuconfig
$ # do buildroot changes
$ make

I created the kernel config from scratch (using tinyconfig) and
deliberately tried to balance size and functionality. It should boot on
most Intel based machines (BIOS and UEFI), however hardware support like
hard disk and ethernet controllers is deliberately limited (see kernel
config [6]). The goal was to start small and add more support as needed.

Customising the Linux kernel is also pretty easy, though:

$ make linux-menuconfig
$ # do kernel changes
$ make

Each time you run make, it'll pick up where you left off and re-create
your images.

Really happy for anyone to test it out and answer any questions you
have.

Many thanks!
Chris

[1] https://buildroot.uclibc.org/
[2] https://review.openstack.org/#/c/445763/
[3] https://github.com/csmart/ipa-buildroot
[4]
https://github.com/csmart/ipa-buildroot#openstack-ironic-python-agent
[5]
https://github.com/csmart/ironic-python-agent/tree/buildroot/imagebuild/buildroot
[6]
https://github.com/csmart/ipa-buildroot/blob/master/buildroot-ipa/board/openstack/ipa/linux-4.10.6.config

__
OpenStack Development Mailing 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] [Glare][Mistral][Murano] Glare client was added to global requirements

2017-04-17 Thread Ренат Ахмеров

Awesome, thanks Mike!

Looking forward to implementing Mistral/Glare integration.

Renat Akhmerov
@Nokia

On 17 Apr 2017, 23:06 +0700, Mikhail Fedosin , wrote:
> Hello!
>
> I'm happy to announce that recently glare client was added to openstack's 
> global requirements. Current version (0.3) contains 'glareclient' library, 
> plugin to openstack client - 'openstack artifact', and a standalone cli - 
> 'glare'.
>
> Now I'm finishing writing the documentation about cli commands and I hope it 
> will be published this week. It means that soon projects like murano and 
> mistral may begin the experimental integration with glare v1 api.
>
> If you have any questions - feel free to ask them in our irc channel 
> #openstack-glare
>
> Best regards,
> Mikhail Fedosin
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] New CI Job definitions

2017-04-17 Thread Ренат Ахмеров

Thanks Brad!

So kombu gate is now non-apache, right?

Thanks

Renat Akhmerov
@Nokia

On 17 Apr 2017, 22:17 +0700, Brad P. Crochet , wrote:
> Hi y'all...
>
> In the midst of trying to track down some errors being seen with tempest 
> tests whilst running under mod_wsgi/apache, I've made it so that the devstack 
> plugin is capable of also running with mod_wsgi/apache.[1]
>
> In doing so, It's become the default devstack job. I've also now created some 
> 'non-apache' jobs that basically are what the old jobs did, just renamed.
>
> Also, I've consolidated the job definitions (the original and the kombu) to 
> simplify and DRY out the jobs. You can see the infra review here.[2]
>
> The list of jobs will be:
> gate-mistral-devstack-dsvm-ubuntu-xenial-nv
> gate-mistral-devstack-dsvm-non-apache-ubuntu-xenial-nv
> gate-mistral-devstack-dsvm-kombu-ubuntu-xenial-nv
>
> Note that the trusty jobs have been eliminated.
>
> Essentially, I've added a '{special}' tag to the job definition, allowing us 
> to create special-cased devstack jobs. So, as you can see, I've migrated the 
> kombu job to be such a thing. It should also be possible to combine them.
>
> [1] https://review.openstack.org/#/c/454710/
> [2] https://review.openstack.org/#/c/457106/
> --
> Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
> Principal Software Engineer
> (c) 704.236.9385
>
> __
> OpenStack Development Mailing 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] [vitrage] use case repository

2017-04-17 Thread Yujun Zhang (ZTE)

Hi root causers,

Use case repository is considered as one of the very important subject to
work on in Pike release[1].

I wonder what kind of use cases we have deployed/validated in vitrage, no
matter in production or experimental, and where can I find related
information?

[1]: https://wiki.openstack.org/wiki/Vitrage/RoadMap#Very_important

-- 
Yujun Zhang
__
OpenStack Development Mailing 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] [ceilometer] Difference between publishers and dispatchers?

2017-04-17 Thread Hanxi Liu

Hi Andres,
Ceilometer has deprecated collector from Pike, so dispatchers will be no
longer used in the future. Data should be pushed from publisher to storage
backend(e.g. Gnocchi) and/or other outer system. Some dispatchers
were deprecated because there are corresponding developed publisher, for
example, file dispatcher to file publisher. Of course, If you still want to
use previous version, you could use dispatcher behind collector.

Best wishes,
Hanxi Liu

On Tue, Apr 18, 2017 at 9:40 AM, Andres Alvarez 
 wrote:

> Hi Julien
>
> Thanks for your response. So does this mean that dispatchers will also be
> deprecated (if not already deprecated) in favor of only using publishers?
>

> 
OpenStack Development Mailing 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] [Blazar] Meeting time slots in Boston

2017-04-17 Thread Masahito MUROI


Hi Blazar folks,

I created doodle[1] to decide our meeting time slots in Boston summit.  
Please check slots you can join the meeting by Thursday.  I'll decide  
the slots on this Friday.


Additionally, I'd like to ask you to write down how many hours we have  
the meeting in comments of the page.


1. http://doodle.com/poll/a7pccnhqsuk9tax7

best regards,
Masahito


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

Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

2017-04-17 Thread Michał Jastrzębski

So, while I agree that everyone should use images built locally, I
also see what is value of downloading dockerhub-hosted images (besides
speed). Images at dockerhub passed our gates and are CI tested. Which
means quality of these images is ensured by our CI. Not everyone can
afford to have CI/CD system in their infra, so for small/medium
installation this actually might be more stable than local builds.

Given that both local and dockerhub hosted images have valid
production use case, I'd like that we keep our tagging mechanism same
for both.
That makes revisions per se impossible to handle (4.0.0-3 on dockerhub
doesn't mean 4.0.0-3 locally). Also how often we push 4.0.0-x? Daily
for quickest update on security patches (preferably for me), that
would mean that our dockerhub registry would grow extremely fast if
we'd like to retain every revision. One idea would be to put a little
of this weight on users (sorry!). We could upload daily :ocata images
and delete old ones. I think not many people does daily openstack
upgrades (cool use case tho), that means they will have some stale
:ocata image locally. We can just put an expectation to backup your
images locally, ones that you actually use. Just tar.gz
/var/lib/docker/volumes/registry/_data and save it somewhere safe.
Then you can always come back to it.

Bottom line, my suggestion for now is to have schema like that:

image-name:4.0.0 -> corresponding docker tag and image built (pref
automatically) close to tagging date
image-name:ocata -> tip of ocata branch build daily - the freshest
code that past gates
image-name:master -> tip of master branch

To achieve fully repeatable builds, we would need to have 4.0.0 type
tagging (based on pbr+git tag), version manifesto generation (as
discussed on PTG) and mechanism to consume existing manifestos and
rebuild images with these exact versions (baring issues with repo
removing previous version...). That is quite a project in it's own...

Thoughts?

Cheers,
Michal

On 17 April 2017 at 19:43, Jeffrey Zhang  wrote:
> I think we have two topics and improvements here
>
> 1. images in https://hub.docker.com/r/kolla/
> 2. tag in end-user env.
>
> # images in hub.docker.com
>
> we are building kolla tag image and push them into hub.docker.com. After
> this,
> we do nothing for these images.
>
> The issue is
>
> 1. any security update is not included in these images.
>solution: I do not think use 4.0.0-1 4.0.0-2 in hub.docker.com is a good
> idea.
>if so, we need mark what 4.0.0-1 container and what's the difference with
> 4.0.0-2.
>This will make another chaos.
>And any prod env shouldn't depend on hub.docker.com's images, which is
> vulnerable
>to attack and is mutable.
>
> 2. branch images are not pushed.
>solution: we can add a job to push branch images into hub.docker.com like
> inc0
>said. For example:
>centos-source-nova-api:4.0.0
>centos-source-nova-api:ocata
>centos-source-nova-api:pike
>centos-source-nova-api:master
>But branch tag images is not stable ( even its name is stable/ocata ),
> users are
>not recommended to use these images
>
> # images in end-user env

> I recommended end user should build its own image rather then use
> hub.docker.com directly.
> in my env, I build images with following tag rule.
>
> when using 4.0.0 to build multi time, i use different tag name. For example
>1st: 4.0.0.1
>2nd: 4.0.0.2
>3rd: 4.0.0.3
>...
>
> The advantage in this way is: keep each tag as immutable ( never override )
>
> On Tue, Apr 18, 2017 at 6:46 AM, Steve Baker  wrote:
>>
>>
>>
>> On Tue, Apr 18, 2017 at 9:57 AM, Doug Hellmann 
>> wrote:
>>>
>>> Excerpts from Michał Jastrzębski's message of 2017-04-12 15:59:34 -0700:
>>> > My dear Kollegues,
>>> >
>>> > Today we had discussion about how to properly name/tag images being
>>> > pushed to dockerhub. That moved towards general discussion on revision
>>> > mgmt.
>>> >
>>> > Problem we're trying to solve is this:
>>> > If you build/push images today, your tag is 4.0
>>> > if you do it tomorrow, it's still 4.0, and will keep being 4.0 until
>>> > we tag new release.
>>> >
>>> > But image built today is not equal to image built tomorrow, so we
>>> > would like something like 4.0.0-1, 4.0.0-2.
>>> > While we can reasonably detect history of revisions in dockerhub,
>>> > local env will be extremely hard to do.
>>> >
>>> > I'd like to ask you for opinions on desired behavior and how we want
>>> > to deal with revision management in general.
>>> >
>>> > Cheers,
>>> > Michal
>>> >
>>>
>>> What's in the images, kolla? Other OpenStack components?
>>
>>
>> Yes, each image will typically contain all software required for one
>> OpenStack service, including dependencies from OpenStack projects or the
>> base OS. Installed via some combination of git, pip, rpm, deb.
>>
>>>
>>> Where does the
>>> 4.0.0 come from?
>>>
>>
>> Its the python version string from the kolla project itself, so ultimately
>>

Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

2017-04-17 Thread Jeffrey Zhang

I think we have two topics and improvements here

1. images in https://hub.docker.com/r/kolla/
2. tag in end-user env.

# images in hub.docker.com

we are building kolla tag image and push them into hub.docker.com. After
this,
we do nothing for these images.

The issue is

1. any security update is not included in these images.
   solution: I do not think use 4.0.0-1 4.0.0-2 in hub.docker.com is a good
idea.
   if so, we need mark what 4.0.0-1 container and what's the difference
with 4.0.0-2.
   This will make another chaos.
   And any prod env shouldn't depend on hub.docker.com's images, which is
vulnerable
   to attack and is mutable.

2. branch images are not pushed.
   solution: we can add a job to push branch images into hub.docker.com
like inc0
   said. For example:
   centos-source-nova-api:4.0.0
   centos-source-nova-api:ocata
   centos-source-nova-api:pike
   centos-source-nova-api:master
   But branch tag images is not stable ( even its name is stable/ocata ),
users are
   not recommended to use these images

# images in end-user env

I recommended end user should build its own image rather then use
hub.docker.com directly.
in my env, I build images with following tag rule.

when using 4.0.0 to build multi time, i use different tag name. For example
   1st: 4.0.0.1
   2nd: 4.0.0.2
   3rd: 4.0.0.3
   ...

The advantage in this way is: keep each tag as immutable ( never override )

On Tue, Apr 18, 2017 at 6:46 AM, Steve Baker  wrote:

>
>
> On Tue, Apr 18, 2017 at 9:57 AM, Doug Hellmann 
> wrote:
>
>> Excerpts from Michał Jastrzębski's message of 2017-04-12 15:59:34 -0700:
>> > My dear Kollegues,
>> >
>> > Today we had discussion about how to properly name/tag images being
>> > pushed to dockerhub. That moved towards general discussion on revision
>> > mgmt.
>> >
>> > Problem we're trying to solve is this:
>> > If you build/push images today, your tag is 4.0
>> > if you do it tomorrow, it's still 4.0, and will keep being 4.0 until
>> > we tag new release.
>> >
>> > But image built today is not equal to image built tomorrow, so we
>> > would like something like 4.0.0-1, 4.0.0-2.
>> > While we can reasonably detect history of revisions in dockerhub,
>> > local env will be extremely hard to do.
>> >
>> > I'd like to ask you for opinions on desired behavior and how we want
>> > to deal with revision management in general.
>> >
>> > Cheers,
>> > Michal
>> >
>>
>> What's in the images, kolla? Other OpenStack components?
>
>
> Yes, each image will typically contain all software required for one
> OpenStack service, including dependencies from OpenStack projects or the
> base OS. Installed via some combination of git, pip, rpm, deb.
>
>
>> Where does the
>> 4.0.0 come from?
>>
>>
> Its the python version string from the kolla project itself, so ultimately
> I think pbr. I'm suggesting that we switch to using the
> version.release_string[1] which will tag with the longer version we use for
> other dev packages.
>
> [1]https://review.openstack.org/#/c/448380/1/kolla/common/config.py
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
OpenStack Development Mailing 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] blog post about being PTL in OpenStack

2017-04-17 Thread ChangBo Guo

yeah, I read https://blog.flaper87.com/something-about-being-a-ptl.html
before I take the role , that really helps me a lot . I aslo share the blog
in some meetups.

Thanks Flavio and Emilien.  and I will attend https://www.openstack.org/summ
it/boston-2017/summit-schedule/events/18518/
2017-04-18 4:15 GMT+08:00 Flavio Percoco :

> On 17/04/17 13:39 -0500, Matt Riedemann wrote:
>
>> On 4/13/2017 7:22 PM, Emilien Macchi wrote:
>>
>>> Exceptionally, I'll self-promote a blog post that I wrote about my
>>> personal experience of being PTL in OpenStack.
>>>
>>> http://my1.fr/blog/my-journey-as-an-openstack-ptl/
>>>
>>> My hope is to engage some discussion about what our community thinks
>>> about this role and how we could bring more leaders in OpenStack.
>>> This blog post also explains why I won't run for PTL during the next
>>> cycle.
>>>
>>> Happy week-end,
>>>
>>>
>> Thanks Emilien. Coincidentally, stevemar, armax and I have a talk at the
>> upcoming Boston summit with a lot of the same content:
>>
>> https://www.openstack.org/summit/boston-2017/summit-schedule
>> /events/18518/
>>
>>
> alright, I'll throw mine in the mix as well. I wrote this one a couple of
> cycles
> ago, right before the PTL elections happened. I'm happy to talk about this
> and
> have further discussions.
>
> https://blog.flaper87.com/something-about-being-a-ptl.html
>
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
ChangBo Guo(gcb)
__
OpenStack Development Mailing 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][glance][ironic][octavia][nova]oslo.config 4.0 will break projects' unit test

2017-04-17 Thread ChangBo Guo

Thanks Michael Johnson for your fix !

  We plan to release oslo.config 4.0 when each project has a fix at least
in review , Latest updates:

  Nova:  https://review.openstack.org/457188  need review
  Keystone:  https://review.openstack.org/455391 wait for oslo.config 4.0
  Glance:  https://review.openstack.org/#/c/455522/ need review
  Octavia:  https://review.openstack.org/457356 need review
   Ironic:   talked with ironic liason curshil in oslo weekly meeting, will
dig into it.

2017-04-18 4:51 GMT+08:00 Michael Johnson :

> Thank you ChangBo, I have resolved the issues in octavia in this patch:
> https://review.openstack.org/457356 up for review.
>
>
>
> Michael
>
>
>
> *From:* ChangBo Guo [mailto:glongw...@gmail.com]
> *Sent:* Sunday, April 16, 2017 12:32 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [glance][ironic][octavia] oslo.config 4.0
> will break projects' unit test
>
>
>
> As I expect, there are some failures in periodic tasks recently [1] if we
> set enforce_type with True by default,  we'd better fix them before we
> release oslo.config 4.0.  Some guys had been working on this :
> Nova: https://review.openstack.org/455534 should fix failures
>
> tempest:  https://review.openstack.org/456445 fixed
>
> Keystone:  https://review.openstack.org/455391 wait for oslo.config 4.0
>
>
>
> We still need help from Glance/Ironic/Octavia
>
> Glance:  https://review.openstack.org/#/c/455522/ need review
>
> Ironic:  Need fix failure in http://logs.openstack.org/
> periodic/periodic-ironic-py27-with-oslo-master/680abfe/
> testr_results.html.gz
> Octavia: Need fix failure in http://logs.openstack.org/
> periodic/periodic-octavia-py35-with-oslo-master/80fee03/
> testr_results.html.gz
>
>
> [1] http://status.openstack.org/openstack-health/#/?groupKey=
> build_name&resolutionKey=hour&searchProject=-with-oslo
>
>
>
> 2017-04-04 0:01 GMT+08:00 ChangBo Guo :
>
> Hi ALL,
>
>
> oslo_config provides method CONF.set_override[1] , developers usually use
> it to change config option's value in tests. That's convenient . By
> default  parameter enforce_type=False,  it doesn't check any type or value
> of override. If set enforce_type=True , will check parameter override's
> type and value.  In production code(running time code),  oslo_config
> always checks  config option's value. In short, we test and run code in
> different ways. so there's  gap:  config option with wrong type or
> invalid value can pass tests when
>
> parameter enforce_type = False in consuming projects.  that means some
> invalid or wrong tests are in our code base.
>
>
> We began to warn user about the change since Sep, 2016 in [2]. This change
> will notify consuming project to write correct test cases with config
> options.
>
> We would make enforce_type = true by default in [3], that may break some
> projects' tests, that's also raise wrong unit tests. The failure is easy to
> fix, which
>
> is recommended.
>
>
>
> [1] https://github.com/openstack/oslo.config/blob/
> efb287a94645b15b634e8c344352696ff85c219f/oslo_config/cfg.py#L2613
> [2] https://review.openstack.org/#/c/365476/
> [3] https://review.openstack.org/328692
>
>
> --
>
> ChangBo Guo(gcb)
>
>
>
>
> --
>
> ChangBo Guo(gcb)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
ChangBo Guo(gcb)
__
OpenStack Development Mailing 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] [ceilometer] Difference between publishers and dispatchers?

2017-04-17 Thread Andres Alvarez

Hi Julien

Thanks for your response. So does this mean that dispatchers will also be
deprecated (if not already deprecated) in favor of only using publishers?

On Mon, Apr 17, 2017 at 5:49 PM, Julien Danjou  wrote:

> On Mon, Apr 17 2017, Andres Alvarez wrote:
>
> Hi Andres,
>
> > I am a bit confused on what is the difference between dispatchers and
> > publishers in Ceilometer. The documentation explains a bit about
> publishers
> > in the pipeline, but it does not mention much (if anything) about
> > dispatchers.
>
> Publishers are configured into the pipeline to indicate where to push
> samples data (e.g. to Gnocchi).
> One of the publisher is notifier:// which sends the samples to the (now
> deprecated) ceilometer-collector process.
>
> Ceilometer collector stores data into other system via a dispatcher
> mechanism (e.g. to Gnocchi). It's now deprecated as it's just, with
> current architecture, a unnecessary step: publishers can do the job
> directly.
>
> --
> Julien Danjou
> # Free Software hacker
> # https://julien.danjou.info
>
__
OpenStack Development Mailing 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] [api-wg] Question about 'OpenStack-API-Version' header

2017-04-17 Thread Qiming Teng

On Mon, Apr 17, 2017 at 10:22:16AM +0100, Chris Dent wrote:
> On Fri, 14 Apr 2017, Qiming Teng wrote:
> 
> >According to the microversion specification [1], the
> >'OpenStack-API-Version' header is optional. When it is omitted, the
> >server should act as if the minimum supported version was specified.
> 
> That's correct.
> 
> >Recently, we have received some complaints from users that for new APIs
> >added, we should state that the header is required. The new APIs are
> >valid only after a specific microversion. If the 'OpenStack-APi-Version'
> >header is missing, our server returns a 404 resource not found error.
> >It is confusing.
> 
> There's a bit of a circle here. If you're using microversions and you
> add a new feature at, for example, version 2.24 then yes, you must
> include the header with a microversion of 2.24 or beyond in order to
> use that feature. This is aligned with the "opt-in" nature of
> microversions and changes to the service.
> 
> If the new microversion is adding a new URL, then a 404 response is
> correct when that microversion has not been selected.
> 
> So, yes, it is the case that when adding a new URL to a service that
> is already supporting microversions, the header is required. That's
> pretty much how microversions work and the service documentation
> should indicate that.

This answered my question pretty well. Since we are using api-ref to
document the service API, each resource URL is documented separately.
For newly added URL, following micro-version guideline, we are supposed
to state that the micro-version header is required. This was the part
that is missing from the referenced guideline.

Thank you, Chris.

- Qiming
> Is there a different workflow that you (or the people complaining)
> have in mind that could work better? Is there something that could
> or should be clarified to make this more clear?
> 
> -- 
> 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


__
OpenStack Development Mailing 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] [Tacker][OSC] Command naming specs

2017-04-17 Thread Sridhar Ramaswamy

Hi Jay,

See inline ...

On Fri, Apr 14, 2017 at 12:25 PM, Jay Pipes  wrote:

> On 04/12/2017 03:08 AM, Trinath Somanchi wrote:
>
>> Hi OSC team-
>>
>> While  implementing tacker-cli commands as OSC plugins [1], We are
>> struck in command naming specifications.
>>
>> Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the
>> prefix.
>>
>
> It's not *all* of NFV, though.
>

I agree 'nfv' is an umbrella term and it has significance for other
projects as well (like nova).

>
> This problem, by the way, is an indication that Tacker might have too big
> a scope...and a scope that is very much tailored/purpose-built for
> Telcos/NFV. But whatever, I raised this concern during the project
> application as a member of the TC and folks ignored me, so it is what it is
> I guess.

Will stay away from this as we have thrashed this 'scope' question enough
in the TC discussions :)

However, one thing we are forcing ourselves is not use the 'network' as
initial keyword as it clearly belongs in the realm of neutron and its
associated features. What we are looking for is a term like "stack" that
indicates Orchestration (via Heat project) that we slide under.

>
> We were struck in naming the below commands while aligning with the OSC
>> naming specs.
>>
>> For the below commands, for readability, we have added ‘-‘ within the
>> command names.
>>
>> Like,
>>
>>   network-service,  vnf-forwarding-graph, service-function-chain,
>>
>> network-flow-classifier, network-forwarding-path.
>>
>
> I think what Dean and Akihiro were suggesting is to use "vnf" as the first
> "word" in the command list and then use space-delimited commands like so:
>
> openstack vnf network service create
>
> Or just leave off the "network" above, because, well, Tacker doesn't
> create any other type of service..., so:
>
> openstack vnf service create
>

I like this suggestion. Keyword 'vnf' is the closest to the unit of things
orchestrated by Tacker. Building on that we can have,

openstack vnf create - *create a single VNF based on TOSCA template*
openstack vnf service create - *create a service using a collection of VNFs*
openstack vnf graph create - *create a forwarding graph using a collection
of VNFs*
...

>
> and then
>
> openstack vnf forwardinggraph create
>
> and
>
> openstack vnf service function chain create
>
> but then, you'll hit on the obvious overlap with networking-sfc, which
> will bring in the obvious question of "what's the difference between
> Tacker's SFC and networking-sfc's SFC?" which again should lead folks to
> question the scope of Tacker in relation to other OpenStack projects...
>

It is not an overlap per-se, it is more at a different abstraction level.
The later is a general purpose, lower-level SFC API based on neutron ports.
Former is a higher level YAML (TOSCA) template based description of a SFC
specially geared for NFV use-cases - implemented using the lower-level
networking-sfc APIs. It is analogous to Heat OS::Nova::Server <-> Nova
Compute APIs.

- Sridhar

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

Re: [openstack-dev] [tc] [elections] Available time and top priority

2017-04-17 Thread Emilien Macchi

On Mon, Apr 10, 2017 at 4:40 PM, Matt Riedemann  wrote:
> On 4/10/2017 2:55 PM, Dean Troyer wrote:
>>
>>
>> The TC meetings are held in IRC and that may somewhat mitigate the
>> issue for non-native English speakers, but I've had problems myself
>> keeping up at times with the flurry of comments.  In any case, I think
>> it would be good to include language in the pile of concerns over
>> world-wide participation
>
>
> I don't attend many TC meetings, it's usually on accident, but yeah, when I
> do I always note the flurry of cross-talk chatter that just drowns
> everything out. I feel like there are usually at least 3 parallel
> conversations going on during a TC meeting and it's pretty frustrating to
> follow along, or get a thought in the mix. That has to be much worse for a
> non-native English speaker.

It is worse and one of the reasons why non-native or not-so-fluent
English speakers have hard time to interact during this meeting.

> So yeah, slow down folks. :)
>
> I'm not advocating splitting the meetings though. It's possible to have your
> cake and eat it to if done properly. For example, Alex Xu runs the Nova API
> subteam meeting and we have people from China, India, Japan, UK and USA and
> get through it fine, but it does involve slowing down to get an
> acknowledgement from people that they are OK with any decisions being made.

I'm personaly not in favor of taking decisions during the TC meeting
for the reasons you just mentioned: timezone & parallel discussions...
I would be in favor of pushing more in async rather than expecting a
lot from this meeting.

> This might also tie back in with what cdent was mentioning, and if the
> flurry of conversation during a TC meeting throws people off, maybe the
> minutes should be digested after the meeting in the mailing list. I know the
> meeting is logged, but it can be hard to read through that without one's
> eyes glazing over due to the cross-talk and locker-room towel whipping going
> on.
>
> --
>
> Thanks,
>
> Matt
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi

__
OpenStack Development Mailing 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][stable][ptls] Tagging mitaka as EOL

2017-04-17 Thread Tony Breeds

On Mon, Apr 17, 2017 at 09:55:51AM -0400, Brian Rosmaita wrote:
> On 4/12/17 2:47 AM, Tony Breeds wrote:
> > Hi all,
> > I'm late in sending this announement, but I'm glad to see several 
> > projects
> > have already requested EOL releases to make it trivial and obvious where to
> > apply the tag.
> > 
> > I'm proposing to EOL all projects ...
> 
> Hi Tony, just wanted to give you a glance update.
> 
> We need to backport a fix to stable/mitaka glance_store and cut a
> release before it gets EOL'd.  That will cascade back onto a need to cut
> a new glance in stable/mitaka with the updated requirement.  We should
> be able to get this done this week.

Okay, I'm a little worried that what you describe sounds like a minimum version
bump which isn't a thing we do on stable branches.  Do you have open reviews,
even if they're -W'd?

Yours Tony.


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

[openstack-dev] [neutron] keeping on top of neutron reviews

2017-04-17 Thread Kevin Benton

Hello Neutron reviewers,

Please keep an eye on the review links in
https://docs.openstack.org/developer/neutron/dashboards/index.html as part
of your review routine.

I went through and reviewed a lot of old patches over the weekend so if we
keep on top of that list it shouldn't get out of hand.

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

Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

2017-04-17 Thread Steve Baker

On Tue, Apr 18, 2017 at 9:57 AM, Doug Hellmann 
wrote:

> Excerpts from Michał Jastrzębski's message of 2017-04-12 15:59:34 -0700:
> > My dear Kollegues,
> >
> > Today we had discussion about how to properly name/tag images being
> > pushed to dockerhub. That moved towards general discussion on revision
> > mgmt.
> >
> > Problem we're trying to solve is this:
> > If you build/push images today, your tag is 4.0
> > if you do it tomorrow, it's still 4.0, and will keep being 4.0 until
> > we tag new release.
> >
> > But image built today is not equal to image built tomorrow, so we
> > would like something like 4.0.0-1, 4.0.0-2.
> > While we can reasonably detect history of revisions in dockerhub,
> > local env will be extremely hard to do.
> >
> > I'd like to ask you for opinions on desired behavior and how we want
> > to deal with revision management in general.
> >
> > Cheers,
> > Michal
> >
>
> What's in the images, kolla? Other OpenStack components?


Yes, each image will typically contain all software required for one
OpenStack service, including dependencies from OpenStack projects or the
base OS. Installed via some combination of git, pip, rpm, deb.


> Where does the
> 4.0.0 come from?
>
>
Its the python version string from the kolla project itself, so ultimately
I think pbr. I'm suggesting that we switch to using the
version.release_string[1] which will tag with the longer version we use for
other dev packages.

[1]https://review.openstack.org/#/c/448380/1/kolla/common/config.py
__
OpenStack Development Mailing 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] Release liaison needed

2017-04-17 Thread Dariusz Śmigiel

Hey folks,
Unfortunately, I'm not able to fulfill release liaison role anymore.
The same applies to being infra liaison. It means, that this very
important role needs YOU!


If you'll decide to join the army of release liaisons, you will be
responsible for:
* releases!
* communication with release team!
* glory!
* your name will be placed here [1]

If you're not convinced yet, you can read about liaison responsibilities [2].

Join now! Neutron needs YOU!


[1] https://wiki.openstack.org/wiki/CrossProjectLiaisons
[2] 
https://docs.openstack.org/project-team-guide/release-management.html#liaison-responsibilities

PS I should be around for some time. So, if any help is needed, I can
try to help.

Thanks,
Dariusz

__
OpenStack Development Mailing 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][gate] tempest slow - where do we execute them in gate?

2017-04-17 Thread Andrea Frittoli

On Mon, Apr 17, 2017 at 7:58 PM Ihar Hrachyshka  wrote:

> On Mon, Apr 17, 2017 at 9:35 AM, Jordan Pittier
>  wrote:
> > We don"t run slow tests because the QA team think that they don't bring
> > enough value to be executed, every time and everywhere. The idea is that
> if
> > some specific slow tests are of some interest to some specific openstack
> > projects, those projects can change the config of their jobs to enable
> these
> > tests.
>
>
> But since it's not executed anywhere in tempest gate, even as
> non-voting (?), it's effectively dead code that may be long broken
> without anyone knowing. Of course there are consumers of the tests
> downstream, but for those consumers it's a tough call to start
> depending on the tests if they are not sanity checked by tempest
> itself. Wouldn't it make sense to have some job in tempest gate that
> would execute those tests (maybe just them to speed up such a job?
> maybe non-voting?

We reduced the number of scenario tests we run in the main gate because
some of those tests are not so
critical for the integrated gate, and also because we had an unstable gate
we had to deal with to allow for
Pike development to happen.

The SUT was overloaded in the gate, due to a combination of effects: too
many services running, many
consuming more memory that it did in the past, as well as too many "heavy"
tests running in parallel.

As soon as removed scenario tests from the main gate we introduced a new
non-voting job against
Tempest, which runs *all* scenario tests against a multimode environment,
see for instance [0], so
we can ensure the code is not dead as long as it lives in Tempest.

I'm planning to add more "heavy/long" tests to that jobs, e.g. compute
migrate ones [1].

andreaf

[0]
http://logs.openstack.org/69/451769/2/check/gate-tempest-dsvm-neutron-scenario-multinode-ubuntu-xenial-nv/1f71416/

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

> maybe even as periodic? but there should be
> something that keeps it green in long run).
>
> Ihar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

2017-04-17 Thread Doug Hellmann

Excerpts from Michał Jastrzębski's message of 2017-04-12 15:59:34 -0700:
> My dear Kollegues,
> 
> Today we had discussion about how to properly name/tag images being
> pushed to dockerhub. That moved towards general discussion on revision
> mgmt.
> 
> Problem we're trying to solve is this:
> If you build/push images today, your tag is 4.0
> if you do it tomorrow, it's still 4.0, and will keep being 4.0 until
> we tag new release.
> 
> But image built today is not equal to image built tomorrow, so we
> would like something like 4.0.0-1, 4.0.0-2.
> While we can reasonably detect history of revisions in dockerhub,
> local env will be extremely hard to do.
> 
> I'd like to ask you for opinions on desired behavior and how we want
> to deal with revision management in general.
> 
> Cheers,
> Michal
> 

What's in the images, kolla? Other OpenStack components? Where does the
4.0.0 come from?

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] [gnocchi] new measures backlog scheduling

2017-04-17 Thread gordon chung



On 17/04/17 12:09 PM, gordon chung wrote:
> i tried also to implement jump hash[2], which improved distribution and
> is in theory, less memory intensive as it does not maintain a hash
> table. while better at distribution, it still is not completely uniform
> and similarly, the less sacks per worker, the worse the distribution.

hmm... may have spoke incorrectly on this one, it's better but i don't 
think we can use it to assign sacks to processing workers. i think it's 
only usable for assigning metrics into sacks.

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] [intel experimental ci] Is it actually checking anything?

2017-04-17 Thread Mikhail Medvedev

On Mon, Apr 17, 2017 at 12:31 PM, Jay Pipes  wrote:
> Please see the below output from the Intel Experimental CI (from
> https://review.openstack.org/414769):
>
> On 04/17/2017 01:28 PM, Intel Experimental CI (Code Review) wrote:
>>
>> Intel Experimental CI has posted comments on this change.
>>
>> Change subject: placement: SRIOV PF devices as child providers
>> ..
>>
>>
>> Patch Set 17:
>>
>> Build succeeded (check pipeline).
>>
>> - tempest-dsvm-full-nfv-xenial
>> http://intel-openstack-ci-logs.ovh/portland/2017-04-17/414769/17/check/tempest-dsvm-full-nfv-xenial/1bcdb64
>> : FAILURE in 38m 34s (non-voting)
>> - tempest-dsvm-intel-nfv-xenial
>> http://intel-openstack-ci-logs.ovh/portland/2017-04-17/414769/17/check/tempest-dsvm-intel-nfv-xenial/a21d879
>> : FAILURE in 40m 00s (non-voting)
>> - tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial
>> http://intel-openstack-ci-logs.ovh/portland/2017-04-17/414769/17/check/tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial/837e59d
>> : FAILURE in 47m 45s (non-voting)
>
>
> As you can see, it says the build succeeded, but all three jobs in the
> pipeline failed.

This would happen when CI is voting but all the jobs in a check are
non-voting. Zuul ignores non-voting job result, and as there isn't a
single voting job, it reports 'build succeeded'. Maybe it should be a
zuul bug?

>
> Is someone actively looking into this particular 3rd party CI system?

I do not see anything wrong with that CI (apart from misleading
comment due to zuul issue I mentioned above).

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

---
Mikhail Medvedev
IBM

__
OpenStack Development Mailing 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] [tc][elections]questions about one platform vision

2017-04-17 Thread Ildiko Vancsa

> On 2017. Apr 16., at 3:03, Neil Jerram  wrote:
> 
> FWIW, I think the Lego analogy is not actually helpful for another reason: it 
> has vastly too many ways of combining, and (hence) no sense at all of 
> consistency / interoperability between the different things that you can 
> construct with it. Whereas for OpenStack I believe you are also aiming for 
> some forms of consistency and interoperability. 

I see your point here and without being too biased by the Lego analogy I don’t 
fully agree.

On one hand, in my view we can go deep and associate to the new style Legos 
where you can build more realistic things and you have more specific pieces and 
not just the plain colored rectangular ones and can explore all the ways of 
putting them together, but I don’t think we want to do that when we are looking 
for some kind of an analogy to help people digest a new concept. We will not 
find anything that will be perfect, I think we only need a good enough one let 
that be Legos or something else.

On the other hand despite of the many ways to combine the Lego blocks you will 
still find matching things, like the ability of attaching the Lego figures for 
instance. In this sense I think we need to find the right level of 
consistency/interoperability here. Like for instance the characteristics and 
requirements of an HPC and a Telecom cloud are different and I don’t think 
there are many use cases to ever connect these two types of clouds or migrate 
workload between them, but there’s still a subset of functionality that both 
areas expect from their OpenStack based cloud, which are really the basics and 
not every small detail.

What the Lego analogy describes well is the consistency between the building 
blocks, which is a really important message in my opinion.

With that being said, if we can find a better one or decide not to use any 
analogies that also works for me. I don't think we should spend overly too much 
time with this, although if we can find a good enough one, I’m in favor to use 
it as it sometimes makes it much easier to get to know and accept a new(-ish) 
concept.

Thanks,
Ildikó

__
OpenStack Development Mailing 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][ironic][octavia] oslo.config 4.0 will break projects' unit test

2017-04-17 Thread Michael Johnson

Thank you ChangBo, I have resolved the issues in octavia in this patch: 
https://review.openstack.org/457356 up for review.

 

Michael

 

From: ChangBo Guo [mailto:glongw...@gmail.com] 
Sent: Sunday, April 16, 2017 12:32 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [glance][ironic][octavia] oslo.config 4.0 will 
break projects' unit test

 

As I expect, there are some failures in periodic tasks recently [1] if we set 
enforce_type with True by default,  we'd better fix them before we release 
oslo.config 4.0.  Some guys had been working on this :
Nova: https://review.openstack.org/455534 should fix failures

tempest:  https://review.openstack.org/456445 fixed

Keystone:  https://review.openstack.org/455391 wait for oslo.config 4.0

 

We still need help from Glance/Ironic/Octavia

Glance:  https://review.openstack.org/#/c/455522/ need review

Ironic:  Need fix failure in 
http://logs.openstack.org/periodic/periodic-ironic-py27-with-oslo-master/680abfe/testr_results.html.gz
Octavia: Need fix failure in 
http://logs.openstack.org/periodic/periodic-octavia-py35-with-oslo-master/80fee03/testr_results.html.gz


[1] http://status.openstack.org/openstack-health/#/?groupKey=build_name 

 &resolutionKey=hour&searchProject=-with-oslo

 

2017-04-04 0:01 GMT+08:00 ChangBo Guo mailto:glongw...@gmail.com> >:

Hi ALL,


oslo_config provides method CONF.set_override[1] , developers usually use it to 
change config option's value in tests. That's convenient . By default  
parameter enforce_type=False,  it doesn't check any type or value of override. 
If set enforce_type=True , will check parameter override's type and value.  In 
production code(running time code),  oslo_config  always checks  config 
option's value. In short, we test and run code in different ways. so there's  
gap:  config option with wrong type or invalid value can pass tests when

parameter enforce_type = False in consuming projects.  that means some invalid 
or wrong tests are in our code base. 


We began to warn user about the change since Sep, 2016 in [2]. This change will 
notify consuming project to write correct test cases with config options. 

We would make enforce_type = true by default in [3], that may break some 
projects' tests, that's also raise wrong unit tests. The failure is easy to 
fix, which

is recommended. 



[1] 
https://github.com/openstack/oslo.config/blob/efb287a94645b15b634e8c344352696ff85c219f/oslo_config/cfg.py#L2613
[2] https://review.openstack.org/#/c/365476/
[3] https://review.openstack.org/328692



-- 

ChangBo Guo(gcb)




-- 

ChangBo Guo(gcb)

__
OpenStack Development Mailing 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] [monasca][swift][storyboard] migration experience

2017-04-17 Thread John Dickinson

Moasca-teers

As the migration away from Launchpad and to Storyboard moves forward,
the Swift team has been considering making the move. Monasca has
already made the move, so I'd love to hear your thoughts on that
process.

1) How did you do the change? All at once or gradually? If you did it
over again, would you do it the same way?

2) Are you missing anything from the migration? How do you manage
security bugs that are embargoed?

3) How are you managing being "different" in the OpenStack community
for where to go file bugs or track work?

4) Have you had any negative impact from old links to Launchpad bugs?
What about links in commit messages? How did you manage links in
patches that were open at the time of migration?

5) What other thoughts do you have on the move?


Thank you for your time and thoughts,


John







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] blog post about being PTL in OpenStack

2017-04-17 Thread Flavio Percoco


On 17/04/17 13:39 -0500, Matt Riedemann wrote:

On 4/13/2017 7:22 PM, Emilien Macchi wrote:

Exceptionally, I'll self-promote a blog post that I wrote about my
personal experience of being PTL in OpenStack.

http://my1.fr/blog/my-journey-as-an-openstack-ptl/

My hope is to engage some discussion about what our community thinks
about this role and how we could bring more leaders in OpenStack.
This blog post also explains why I won't run for PTL during the next cycle.

Happy week-end,



Thanks Emilien. Coincidentally, stevemar, armax and I have a talk at 
the upcoming Boston summit with a lot of the same content:


https://www.openstack.org/summit/boston-2017/summit-schedule/events/18518/



alright, I'll throw mine in the mix as well. I wrote this one a couple of cycles
ago, right before the PTL elections happened. I'm happy to talk about this and
have further discussions.

https://blog.flaper87.com/something-about-being-a-ptl.html

Flavio

--
@flaper87
Flavio Percoco


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

[openstack-dev] [TripleO][CI] Bridging the production/CI workflow gap with large periodic CI jobs

2017-04-17 Thread Justin Kilpatrick

Because CI jobs tend to max out about 5 nodes there's a whole class of
minor bugs that make it into releases.

What happens is that they never show up in small clouds, then when
they do show up in larger testing clouds the people deploying those
simply work around the issue and get onto what they where supposed to
be testing. These workarounds do get documented/BZ'd but since they
don't block anyone and only show up in large environments they become
hard for developers to fix.

So the issue gets stuck in limbo, with nowhere to test a patchset and
no one owning the issue.

These issues pile up and pretty soon there is a significant difference
between the default documented workflow and the 'scale' workflow which
is filled with workarounds which may or may not be documented
upstream.

I'd like to propose getting these issues more visibility to having a
periodic upstream job that uses 20-30 ovb instances to do a larger
deployment. Maybe at 3am on a Sunday or some other time where there's
idle execution capability to exploit. The goal being to make these
sorts of issues more visible and hopefully get better at fixing them.

To be honest I'm not sure this is the best solution, but I'm seeing
this anti pattern across several issues and I think we should try and
come up with a solution.

__
OpenStack Development Mailing 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] placement/resource providers update 19

2017-04-17 Thread Matt Riedemann

On 4/14/2017 5:18 AM, Chris Dent wrote:

Here's the 19th placement and resource providers update. As usual,
if I've left anything out, please followup with that information.

# What Matters Most

Discussion continues on the spec for claims being done during
scheduling. Getting this worked out and implemented is a high
priority. Links below.

# What's Changed

The routes and handlers for adding and manipulating traits in the
placement API have now merged. This opens the door for starting to
report traits for compute-nodes and other resource providers and
filtering based on those traits (note that the added code does not
support that filtering, what's been added is the interface to CRUD
traits).

The spec for associating user and project information with
allocations and for being able to view usages based on those
characteristics has been merged. We had to go a few rounds as we
were so excited about this idea we missed some critical bits:

http://specs.openstack.org/openstack/nova-specs/specs/pike/approved/placement-project-user.html

The placement-api-ref gate job that checks the docs is now linking
the output. Here's a sample (which may have expired by the time you
are reading this message):

http://docs-draft.openstack.org/98/456198/1/check/gate-placement-api-ref-nv/deee665//placement-api-ref/build/html/

Cool, this looks nice.

More about docs below.

# Help Wanted

Areas where volunteers are needed.

* General attention to bugs tagged placement:
https://bugs.launchpad.net/nova/+bugs?field.tag=placement

* Helping to create api documentation for placement (see the Docs
section below).

* Helping to create and evaluate functional tests of the resource
tracker and the ways in which it and nova-scheduler use the
reporting client. For some info see
https://etherpad.openstack.org/p/nova-placement-functional
and talk to edleafe.

* Performance testing. If you have access to some nodes, some basic
benchmarking and profiling would be very useful. See the
performance section below.

# Main Themes

## Traits

The main API is in place, there's one patch left for a new command
to sync the os-traits library into the database:

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

There is a stack of changes to the os-traits library to add more traits
and also automate creating symbols associated with the trait
strings:

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

## Ironic/Custom Resource Classes

There's a blueprint for "custom resource classes in flavors" that
describes the stuff that will actually make use of custom resource
classes:

https://blueprints.launchpad.net/nova/+spec/custom-resource-classes-in-flavors

Due to the OSIC thing, Jay Pipes is going to pick this up now.

The spec has merged, but the implementation has not yet started.

Over in Ironic some functional and integration tests have started:

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

## Claims in the Scheduler

Progress has been made on the spec for claims in the scheduler:

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

Continued eyes and brains required. The current state is that more
detail is desired on why some particular design choices are being
made.

As of today's scheduler subteam meeting, the current most important
decision to be made is if conductor does the retries when a claim fails
due to conflict, or if the scheduler should. Related to the need for
performance testing at scale, it would really help to gather some data
on both approaches for retries here. Retrying in nova-conductor means
going back through the scheduler to pull all of the hosts fresh and
filtering/weighing them again, which would be more accurate but could be
inefficient. Retrying in the filter scheduler would be more efficient
since we have the hosts in an ordered list and don't need to refresh -
but that could mean they are stale now too. Maybe we can stub some scale
testing with fake compute nodes and the fake compute driver for this.
Having a 'test' in tree doesn't make a lot of sense though as it does
not really pass or fail, it's just there to compare against
alternatives. I was wondering if we could re-use some of Yingxin's
performance scale testing work that he presented at the Newton summit
[1]. Alex said Yingxin is working on Ceph now, but the tooling should be
on github somewhere.

Thinking about this stuff has also revealed some places where it's
possible for allocations to become wrong or orphaned:

https://bugs.launchpad.net/nova/+bug/1679750
https://bugs.launchpad.net/nova/+bug/1661312

## Shared Resource Providers

https://blueprints.launchpad.net/nova/+spec/shared-resources-pike

Progress on this will continue once traits and claims have moved forward.

## Nested Resource Providers

On hold while attention is given to traits and claims. There's a
stack of code waiting until all of that settles:

https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:

[openstack-dev] [os-upstream-institute] Meeting reminder

2017-04-17 Thread Ildiko Vancsa

Hi Team,

A quick reminder that our next meeting will take place in #openstack-meeting-3 
in 15 minutes (2000 UTC). See you there! :)

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

Re: [openstack-dev] [ironic] [third-party-ci] pkvmci ironic job breakage details

2017-04-17 Thread Michael Turek

On 04/17/2017 02:25 PM, Matt Riedemann wrote:

On 4/14/2017 10:51 AM, Michael Turek wrote:

Hey ironic-ers,

So our third party CI job for ironic has been, and remains, broken. I
was able to do some investigation today and here's a summary of what
we're seeing. I'm hoping someone might know the root of the problem.

For reference, please see this paste and the logs of the job that I was
working in:
http://paste.openstack.org/show/606564/
https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/ironic/25/454625/10/check-ironic/tempest-dsvm-ironic-agent_ipmitool/0520958/

I've redacted the credentials in the ironic node-show for obvious
reasons but rest assured they are properly set. These commands are run
while
'/opt/stack/new/ironic/devstack/lib/ironic:wait_for_nova_resources' is
looping.

Basically, the ironic hypervisor for the node doesn't appear. As well,
none of the node's properties make it to the hypervisor stats.

Some more strangeness is that the 'count' value from the 'openstack
hypervisor stats show'. Though no hypervisors appear, the count is still
1. Since the run was broken, I decided to delete node-0 (about 3-5
minutes before the run failed) and see if it updated the count. It did.

Does anyone have any clue what might be happening here? Any advice would
be appreciated!

Thanks,
mjturek

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

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

See:

http://lists.openstack.org/pipermail/openstack-dev/2017-April/115486.html

Thanks Matt,

Unfortunately doesn't seem to be the fix.

I did a quick test run of the job and ran "nova-manage cell_v2
discover_hosts --verbose" manually while ironic:wait_for_nova_resources
was looping (where we eventually fail). This fixes the issue of the
hypervisor not appearing, but the resources associated with the
hypervisor (vcpus, memory_mb, etc) remain 0.

mjturek

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

Re: [openstack-dev] [ironic] [third-party-ci] pkvmci ironic job breakage details

2017-04-17 Thread Rajini.Ram

Dell - Internal Use - Confidential
Hi Mike
I do see this problem this week. See logs.


https://stash.opencrowbar.org/logs/52/456952/2/check/dell-hw-tempest-dsvm-ironic-pxe_ipmitool/315bd85/



We were running 5 builds on a one node devstack-cloud and now made it 6 and 
started seeing this problem. The server must be running out of resources for 
the VMs.



Regards

Rajini


-Original Message-
From: Michael Turek [mailto:mjtu...@linux.vnet.ibm.com]
Sent: Friday, April 14, 2017 10:52 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [ironic] [third-party-ci] pkvmci ironic job breakage 
details

Hey ironic-ers,

So our third party CI job for ironic has been, and remains, broken. I was able 
to do some investigation today and here's a summary of what we're seeing. I'm 
hoping someone might know the root of the problem.

For reference, please see this paste and the logs of the job that I was working 
in:
http://paste.openstack.org/show/606564/
https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/ironic/25/454625/10/check-ironic/tempest-dsvm-ironic-agent_ipmitool/0520958/

I've redacted the credentials in the ironic node-show for obvious reasons but 
rest assured they are properly set. These commands are run while 
'/opt/stack/new/ironic/devstack/lib/ironic:wait_for_nova_resources' is looping.

Basically, the ironic hypervisor for the node doesn't appear. As well, none of 
the node's properties make it to the hypervisor stats.

Some more strangeness is that the 'count' value from the 'openstack hypervisor 
stats show'. Though no hypervisors appear, the count is still 1. Since the run 
was broken, I decided to delete node-0 (about 3-5 minutes before the run 
failed) and see if it updated the count. It did.

Does anyone have any clue what might be happening here? Any advice would be 
appreciated!

Thanks,
mjturek


__
OpenStack Development Mailing 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][gate] tempest slow - where do we execute them in gate?

2017-04-17 Thread Matthew Treinish

On Mon, Apr 17, 2017 at 11:55:28AM -0700, Ihar Hrachyshka wrote:
> On Mon, Apr 17, 2017 at 9:35 AM, Jordan Pittier
>  wrote:
> > We don"t run slow tests because the QA team think that they don't bring
> > enough value to be executed, every time and everywhere. The idea is that if
> > some specific slow tests are of some interest to some specific openstack
> > projects, those projects can change the config of their jobs to enable these
> > tests.
> 
> 
> But since it's not executed anywhere in tempest gate, even as
> non-voting (?), it's effectively dead code that may be long broken
> without anyone knowing. Of course there are consumers of the tests
> downstream, but for those consumers it's a tough call to start
> depending on the tests if they are not sanity checked by tempest
> itself. Wouldn't it make sense to have some job in tempest gate that
> would execute those tests (maybe just them to speed up such a job?
> maybe non-voting? maybe even as periodic? but there should be
> something that keeps it green in long run).
> 

In theory those tests are already supposed to be run as a periodic/experimental
job. The periodic-tempest-dsvm-all-master is setup to run all tests, including
those tagged as slow. However, the job has been broken for some time, I didn't
even notice until I looked just now. (openstack-health didn't show it because
it fails before subunit is generated) I'll pushed:

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

to fix the job. Once that lands lets see how far things have bitrotted in there.

-Matt Treinish


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

Re: [openstack-dev] [qa][gate] tempest slow - where do we execute them in gate?

2017-04-17 Thread Ihar Hrachyshka

On Mon, Apr 17, 2017 at 9:35 AM, Jordan Pittier
 wrote:
> We don"t run slow tests because the QA team think that they don't bring
> enough value to be executed, every time and everywhere. The idea is that if
> some specific slow tests are of some interest to some specific openstack
> projects, those projects can change the config of their jobs to enable these
> tests.

But since it's not executed anywhere in tempest gate, even as
non-voting (?), it's effectively dead code that may be long broken
without anyone knowing. Of course there are consumers of the tests
downstream, but for those consumers it's a tough call to start
depending on the tests if they are not sanity checked by tempest
itself. Wouldn't it make sense to have some job in tempest gate that
would execute those tests (maybe just them to speed up such a job?
maybe non-voting? maybe even as periodic? but there should be
something that keeps it green in long run).

Ihar

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

Re: [openstack-dev] [all] blog post about being PTL in OpenStack

2017-04-17 Thread Matt Riedemann


On 4/13/2017 7:22 PM, Emilien Macchi wrote:

Exceptionally, I'll self-promote a blog post that I wrote about my
personal experience of being PTL in OpenStack.

http://my1.fr/blog/my-journey-as-an-openstack-ptl/

My hope is to engage some discussion about what our community thinks
about this role and how we could bring more leaders in OpenStack.
This blog post also explains why I won't run for PTL during the next cycle.

Happy week-end,



Thanks Emilien. Coincidentally, stevemar, armax and I have a talk at the 
upcoming Boston summit with a lot of the same content:


https://www.openstack.org/summit/boston-2017/summit-schedule/events/18518/

--

Thanks,

Matt

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

Re: [openstack-dev] [ironic] [third-party-ci] pkvmci ironic job breakage details

2017-04-17 Thread Matt Riedemann

On 4/14/2017 10:51 AM, Michael Turek wrote:

Hey ironic-ers,

Basically, the ironic hypervisor for the node doesn't appear. As well,
none of the node's properties make it to the hypervisor stats.

Does anyone have any clue what might be happening here? Any advice would
be appreciated!

Thanks,
mjturek

See:

http://lists.openstack.org/pipermail/openstack-dev/2017-April/115486.html

Thanks,

Matt

Re: [openstack-dev] [Openstack-dev] [Designate]

2017-04-17 Thread Jordan Pittier

Hi,

On Mon, Apr 17, 2017 at 7:32 PM, Carmine Annunziata <
carmine.annunziat...@gmail.com> wrote:

> Hi guys,
> I'm trying to integrate designate in openstack by devstack, the standard
> procedure uses rejoin-stack.sh after the stack.sh but in the last release
> there isn't anymore. So what may i do alternatively?
>
You can "rejoin" your screen session using the "screen -r" command.

>
> Carmine
>
> __
> OpenStack Development Mailing 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] [Openstack-dev] [Designate]

2017-04-17 Thread Carmine Annunziata

Hi guys,
I'm trying to integrate designate in openstack by devstack, the standard
procedure uses rejoin-stack.sh after the stack.sh but in the last release
there isn't anymore. So what may i do alternatively?

Carmine
__
OpenStack Development Mailing 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] [intel experimental ci] Is it actually checking anything?

2017-04-17 Thread Jay Pipes

Please see the below output from the Intel Experimental CI (from 
https://review.openstack.org/414769):


On 04/17/2017 01:28 PM, Intel Experimental CI (Code Review) wrote:

Intel Experimental CI has posted comments on this change.

Change subject: placement: SRIOV PF devices as child providers
..


Patch Set 17:

Build succeeded (check pipeline).

- tempest-dsvm-full-nfv-xenial 
http://intel-openstack-ci-logs.ovh/portland/2017-04-17/414769/17/check/tempest-dsvm-full-nfv-xenial/1bcdb64
 : FAILURE in 38m 34s (non-voting)
- tempest-dsvm-intel-nfv-xenial 
http://intel-openstack-ci-logs.ovh/portland/2017-04-17/414769/17/check/tempest-dsvm-intel-nfv-xenial/a21d879
 : FAILURE in 40m 00s (non-voting)
- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial 
http://intel-openstack-ci-logs.ovh/portland/2017-04-17/414769/17/check/tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial/837e59d
 : FAILURE in 47m 45s (non-voting)


As you can see, it says the build succeeded, but all three jobs in the 
pipeline failed.


Is someone actively looking into this particular 3rd party CI system?

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] [all][stable][ptls] Tagging mitaka as EOL

2017-04-17 Thread Emilien Macchi

On Wed, Apr 12, 2017 at 2:47 AM, Tony Breeds  wrote:
> Hi all,
> I'm late in sending this announement, but I'm glad to see several projects
> have already requested EOL releases to make it trivial and obvious where to
> apply the tag.
>
> I'm proposing to EOL all projects that meet one or more of the following
> criteria:
>
> - The project is openstack-dev/devstack, openstack-dev/grenade or
>   openstack/requirements
> - The project has the 'check-requirements' job listed as a template in
>   project-config:zuul/layout.yaml
> - The project gates with either devstack or grenade jobs
> - The project is listed in governance:reference/projects.yaml and is tagged
>   with 'stable:follows-policy'.
>
> Some statistics:
> All Repos  : 1584 (covered in zuul/layout.yaml)
> Checked Repos  :  416 (match one or more of the above 
> criteria)
> Repos with mitaka branches :  409
> EOL Repos  :  199 (repos that match the criteria *and* 
> have
>a mitaka branch) [1]
> NOT EOL Repos  :  210 (repos with a mitaka branch but
>otherwise do not match) [2]
> DSVM Repos (staying)   :   68 (repos that use dsvm but don't have
>mitaka branches)
> Tagged Repos   :0
> Open Reviews   :  159 (reviews to close)
>
> Please look over both lists by 2017-04-17 00:00 UTC and let me know if:
> - A project is in list 1 and *really* *really* wants to opt *OUT* of EOLing 
> and
>   why.  Note doing this will amost certainly reduce the testing coverage you
>   have in the gate.
> - A project is in list 2 that would like to opt *IN* to tagging/EOLing
>
> Any projects that will be EOL'd will need all open reviews abandoned before it
> can be processed.  I'm very happy to do this, or if I don't have permissios to
> do it ask a gerrit admin to do it.

Please EOL stable/mitaka for:
- instack-undercloud (and featureV2/juno/kilo old branches)
- tripleo-heat-templates (and icehouse)
- tripleo-puppet-elements
- puppet-tripleo
- tripleo-image-elements (just featureV2)
- python-tripleoclient
- tripleo-common

Thanks,

> Yours Tony.
>
> [1] 
> https://gist.github.com/tbreeds/c99e62bf8da19380e4eb130be8783be7#file-mitaka_eol_data-txt-L1
> [2] 
> https://gist.github.com/tbreeds/c99e62bf8da19380e4eb130be8783be7#file-mitaka_eol_data-txt-L209
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Emilien Macchi

__
OpenStack Development Mailing 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] pingtest vs tempest

2017-04-17 Thread Justin Kilpatrick

On Mon, Apr 17, 2017 at 12:28 PM, Ben Nemec  wrote:
> Tempest isn't really either of those things.  According to another message
> in this thread it takes around 15 minutes to run just the smoke tests.
> That's unacceptable for a lot of our CI jobs.

Ben, is the issue merely the time it takes? Is it the affect that time
taken has on hardware availability?

Should we focus on how much testing we can get into N time period?
Then how do we decide an optimal N
for our constraints?

I've been working on a full up functional test for OpenStack CI builds
for a long time now, it works but takes
more than 10 hours. IF you're interested in results kick through to
Kibana here [0]. Let me know off list if you
have any issues, the presentation of this data is all experimental still.

[0] http://elk.browbeatproject.org:8080/goto/f264dea75e91469940e5ceb46444f8a3

On Mon, Apr 17, 2017 at 12:28 PM, Ben Nemec  wrote:
>
>
> On 04/17/2017 10:51 AM, Emilien Macchi wrote:
>>
>> We haven't got much feedback from TripleO core reviewers, who are
>> usually more involved on this topic. I'll give a chance to let them
>> talk because we take some actions based on the feedback brought in
>> this discussion.
>
>
> I started to write a response last week and realized I didn't have a
> coherent recommendation, but here are my semi-organized thoughts:
>
> The pingtest was created for two main reasons.  First, it's fast.  Less than
> three minutes in most CI jobs.  Second, it's simple.  We've added a bunch of
> stuff for resource cleanup and such, but in essence it's four commands:
> glance image-create, neutron net-create, neutron subnet-create, and heat
> stack-create.  It would be hard to come up with a useful test that is
> meaningfully simpler.
>
> Tempest isn't really either of those things.  According to another message
> in this thread it takes around 15 minutes to run just the smoke tests.
> That's unacceptable for a lot of our CI jobs.  It also tends to require a
> lot more configuration in my experience.
>
> All that said, the simplicity of the ping test means it isn't well suited to
> testing more complex things, and I don't think we should try to extend it to
> do so.  Tempest already provides an extensible, pluggable framework for
> complex testing.
>
> Personally I don't want to see the ping test go away completely.  I like
> having a stupid simple and fast way to sanity check a deployment.  If we
> deleted the ping test I would probably just maintain a script that does the
> same basic thing out of tree.
>
> However, if we're starting to duplicate Tempest functionality for scenario
> tests or advanced features then I do think we need to figure out how to
> integrate Tempest for that test coverage.  I will note that I don't think
> the requirement to have a Heat resource for things we test in TripleO is
> necessarily a bad thing, but I don't think that's the only reason this is
> being discussed so I'll leave it at that.
>
> There's also a separate issue of API coverage.  It's true that the ping test
> only provides a bare minimum of coverage for the services, but as I
> discussed above that's largely a function of job runtime.  We simply can't
> run full API tests in many of our CI jobs.  Maybe we could in the basic
> multinode jobs, but the updates, upgrades, and ovb jobs are all too long
> already.  In those the best we can hope to do is a minimal sanity check.
> I'm thinking one Tempest test per service, max.  Less than that if we can
> find tests that exercise multiple services in one (like the ping test does).
>
> That's my brain dump on this.  Do with it what you will. :-)
>
>
>>
>> Thanks,
>>
>> On Fri, Apr 7, 2017 at 4:26 AM, Ravi Sekhar Reddy Konda
>>  wrote:
>>>
>>> Hi Diarmuid,
>>>
>>> Even in our setup Sravanthi by mistake has deleted all the ports
>>> we are trying to bring up again, if it is done today wil ping you and
>>> schedule again
>>>
>>> Otherwise i will schedule for Monday
>>>
>>> Thanks,
>>> Ravi
>>> - Original Message -
>>> From: jtale...@redhat.com
>>> To: openstack-dev@lists.openstack.org, jkilp...@redhat.com
>>> Sent: Thursday, April 6, 2017 4:15:58 PM GMT +05:30 Chennai, Kolkata,
>>> Mumbai, New Delhi
>>> Subject: Re: [openstack-dev] [tripleo] pingtest vs tempest
>>>
>>> On Thu, Apr 6, 2017 at 5:32 AM, Sagi Shnaidman 
>>> wrote:

 HI,

 I think Rally or Browbeat and other performance oriented solutions won't
 serve our needs, because we run TripleO CI on virtualized environment
 with
 very limited resources. Actually we are pretty close to full utilizing
 these
 resources when deploying openstack, so very little is available for
 test.
 It's not a problem to run tempest API tests because they are cheap -
 take
 little time, little resources, but also gives little coverage. Scenario
 test
 are more interesting and gives us more coverage, but also takes a lot of
 resources (which we don't have sometimes).
>>>
>>>
>>> Sagi,
>>>

Re: [openstack-dev] [qa][gate] tempest slow - where do we execute them in gate?

2017-04-17 Thread Jordan Pittier

On Mon, Apr 17, 2017 at 6:50 AM, Ihar Hrachyshka 
wrote:

> Hi all,
>
> so I tried to inject a failure in a tempest test and was surprised
> that no gate job failed because of that:
> https://review.openstack.org/#/c/457102/1
>
> It turned out that the test is not executed because we always ignore
> all 'slow' tagged test cases:
> http://logs.openstack.org/02/457102/1/check/gate-tempest-
> dsvm-neutron-full-ubuntu-xenial/89a08cc/console.html#_
> 2017-04-17_01_43_39_115768

Indeed, we don't run slow tests. Many network scenarios are not run since
https://review.openstack.org/#/c/439698/


>
>
> Question: do we execute those tests anywhere in gate, and if so,
> where? (And if not, why, and how do we guarantee that they are not
> broken by new changes?)
>
We don"t run slow tests because the QA team think that they don't bring
enough value to be executed, every time and everywhere. The idea is that if
some specific slow tests are of some interest to some specific openstack
projects, those projects can change the config of their jobs to enable
these tests.



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

Re: [openstack-dev] [tripleo] pingtest vs tempest

2017-04-17 Thread Ben Nemec




On 04/17/2017 10:51 AM, Emilien Macchi wrote:

We haven't got much feedback from TripleO core reviewers, who are
usually more involved on this topic. I'll give a chance to let them
talk because we take some actions based on the feedback brought in
this discussion.


I started to write a response last week and realized I didn't have a 
coherent recommendation, but here are my semi-organized thoughts:


The pingtest was created for two main reasons.  First, it's fast.  Less 
than three minutes in most CI jobs.  Second, it's simple.  We've added a 
bunch of stuff for resource cleanup and such, but in essence it's four 
commands: glance image-create, neutron net-create, neutron 
subnet-create, and heat stack-create.  It would be hard to come up with 
a useful test that is meaningfully simpler.


Tempest isn't really either of those things.  According to another 
message in this thread it takes around 15 minutes to run just the smoke 
tests.  That's unacceptable for a lot of our CI jobs.  It also tends to 
require a lot more configuration in my experience.


All that said, the simplicity of the ping test means it isn't well 
suited to testing more complex things, and I don't think we should try 
to extend it to do so.  Tempest already provides an extensible, 
pluggable framework for complex testing.


Personally I don't want to see the ping test go away completely.  I like 
having a stupid simple and fast way to sanity check a deployment.  If we 
deleted the ping test I would probably just maintain a script that does 
the same basic thing out of tree.


However, if we're starting to duplicate Tempest functionality for 
scenario tests or advanced features then I do think we need to figure 
out how to integrate Tempest for that test coverage.  I will note that I 
don't think the requirement to have a Heat resource for things we test 
in TripleO is necessarily a bad thing, but I don't think that's the only 
reason this is being discussed so I'll leave it at that.


There's also a separate issue of API coverage.  It's true that the ping 
test only provides a bare minimum of coverage for the services, but as I 
discussed above that's largely a function of job runtime.  We simply 
can't run full API tests in many of our CI jobs.  Maybe we could in the 
basic multinode jobs, but the updates, upgrades, and ovb jobs are all 
too long already.  In those the best we can hope to do is a minimal 
sanity check.  I'm thinking one Tempest test per service, max.  Less 
than that if we can find tests that exercise multiple services in one 
(like the ping test does).


That's my brain dump on this.  Do with it what you will. :-)



Thanks,

On Fri, Apr 7, 2017 at 4:26 AM, Ravi Sekhar Reddy Konda
 wrote:

Hi Diarmuid,

Even in our setup Sravanthi by mistake has deleted all the ports
we are trying to bring up again, if it is done today wil ping you and schedule 
again

Otherwise i will schedule for Monday

Thanks,
Ravi
- Original Message -
From: jtale...@redhat.com
To: openstack-dev@lists.openstack.org, jkilp...@redhat.com
Sent: Thursday, April 6, 2017 4:15:58 PM GMT +05:30 Chennai, Kolkata, Mumbai, 
New Delhi
Subject: Re: [openstack-dev] [tripleo] pingtest vs tempest

On Thu, Apr 6, 2017 at 5:32 AM, Sagi Shnaidman  wrote:

HI,

I think Rally or Browbeat and other performance oriented solutions won't
serve our needs, because we run TripleO CI on virtualized environment with
very limited resources. Actually we are pretty close to full utilizing these
resources when deploying openstack, so very little is available for test.
It's not a problem to run tempest API tests because they are cheap - take
little time, little resources, but also gives little coverage. Scenario test
are more interesting and gives us more coverage, but also takes a lot of
resources (which we don't have sometimes).


Sagi,
In my original message I mentioned a "targeted" test, I should
explained that more. We could configure the specific scenario so that
the load on the virt overcloud would be minimal. Justin Kilpatrick
already have Browbeat integrated with TripleO Quickstart[1], so there
shouldn't be much work to try this proposed solution.



It may be useful to run a "limited edition" of API tests that maximize
coverage and don't duplicate, for example just to check service working
basically, without covering all its functionality. It will take very little
time (i.e. 5 tests for each service) and will give a general picture of
deployment success. It will cover fields that are not covered by pingtest as
well.

I think could be an option to develop a special scenario tempest tests for
TripleO which would fit our needs.


I haven't looked at Tempest in a long time, so maybe its functionality
has improved. I just saw the opportunity to integrate Browbeat/Rally
into CI to test the functionality of OpenStack services, while also
capturing performance metrics.

Joe

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_browbeat_tree

Re: [openstack-dev] [gnocchi] new measures backlog scheduling

2017-04-17 Thread gordon chung

hi,

i've started to implement multiple buckets and the initial tests look
promising. here's some things i've done:

- dropped the scheduler process and allow processing workers to figure
out tasks themselves
- each sack is now handled fully (not counting anything added after
processing worker)
- number of sacks are static

after the above, i've been testing it and it works pretty well, i'm able
to process 40K metrics, 60 points each, in 8-10mins with 54 workers when
it took significantly longer before.

the issues i've run into:

- dynamic sack size
making number of sacks dynamic is a concern. previously, we said to have
sack size in conf file. the concern is that changing that option
incorrectly actually 'corrupts' the db to a state that it cannot recover
from. it will have stray unprocessed measures constantly. if we change
the db path incorrectly, we don't actually corrupt anything, we just
lose data. we've said we don't want sack mappings in indexer so it seems
to me, the only safe solution is to make it sack size static and only
changeable by hacking?

- sack distribution
to distribute sacks across workers, i initially implemented consistent
hashing. the issue i noticed is that because hashring is inherently has
non-uniform distribution[1], i would have workers sitting idle because
it was given less sacks, while other workers were still working.

i tried also to implement jump hash[2], which improved distribution and
is in theory, less memory intensive as it does not maintain a hash
table. while better at distribution, it still is not completely uniform
and similarly, the less sacks per worker, the worse the distribution.

lastly, i tried just simple locking where each worker is completely
unaware of any other worker and handles all sacks. it will lock the sack
it is working on, so if another worker tries to work on it, it will just
skip. this will effectively cause an additional requirement on locking
system (in my case redis) as each worker will make x lock requests where
x is number of sacks. so if we have 50 workers and 2048 sacks, it will
be 102K requests per cycle. this is in addition to the n number of lock
requests per metric (10K-1M metrics?). this does guarantee if a worker
is free and there is work to be done, it will do it.

i guess the question i have is: by using a non-uniform hash, it seems we
gain possibly less load at the expense of efficiency/'speed'. the number
of sacks/tasks we have is stable, it won't really change. the number of
metricd workers may change but not constantly. lastly, the number of
sacks per worker will always be relatively low (10:1, 100:1 assuming max
number of sacks is 2048). given these conditions, do we need
consistent/jump hashing? is it better to just modulo sacks and ensure
'uniform' distribution and allow for 'larger' set of buckets to be
reshuffled when workers are added?

[1]
https://docs.google.com/spreadsheets/d/1flXw1lqao2tIc0p1baxVeJIXgzhy1Ksw3uFoiwyZkXk/edit?usp=sharing
[2] https://arxiv.org/pdf/1406.2294.pdf
[3] https://review.openstack.org/#/q/topic:buckets+project:openstack/gnocchi

--
gord

[openstack-dev] [Glare][Mistral][Murano] Glare client was added to global requirements

2017-04-17 Thread Mikhail Fedosin

Hello!

I'm happy to announce that recently glare client was added to openstack's
global requirements. Current version (0.3) contains 'glareclient' library,
plugin to openstack client - 'openstack artifact', and a standalone cli -
'glare'.

Now I'm finishing writing the documentation about cli commands and I hope
it will be published this week. It means that soon projects like murano and
mistral may begin the experimental integration with glare v1 api.

If you have any questions - feel free to ask them in our irc channel
#openstack-glare

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

Re: [openstack-dev] [cinder][stable] Deprecation notice: Cinder Driver for NetApp E-Series

2017-04-17 Thread Sean McGinnis

On Sat, Apr 15, 2017 at 03:25:09AM +, Ravi, Goutham wrote:
> 
> What is being deprecated: Cinder drivers for NetApp E-Series
> 
> Period of deprecation: E-Series drivers will be around in stable/pike and 
> will be removed in the Queens release (All milestones of this release)
> 

Thanks for clearly communicating the plan Goutham!


__
OpenStack Development Mailing 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] pingtest vs tempest

2017-04-17 Thread Emilien Macchi

We haven't got much feedback from TripleO core reviewers, who are
usually more involved on this topic. I'll give a chance to let them
talk because we take some actions based on the feedback brought in
this discussion.

Thanks,

On Fri, Apr 7, 2017 at 4:26 AM, Ravi Sekhar Reddy Konda
 wrote:
> Hi Diarmuid,
>
> Even in our setup Sravanthi by mistake has deleted all the ports
> we are trying to bring up again, if it is done today wil ping you and 
> schedule again
>
> Otherwise i will schedule for Monday
>
> Thanks,
> Ravi
> - Original Message -
> From: jtale...@redhat.com
> To: openstack-dev@lists.openstack.org, jkilp...@redhat.com
> Sent: Thursday, April 6, 2017 4:15:58 PM GMT +05:30 Chennai, Kolkata, Mumbai, 
> New Delhi
> Subject: Re: [openstack-dev] [tripleo] pingtest vs tempest
>
> On Thu, Apr 6, 2017 at 5:32 AM, Sagi Shnaidman  wrote:
>> HI,
>>
>> I think Rally or Browbeat and other performance oriented solutions won't
>> serve our needs, because we run TripleO CI on virtualized environment with
>> very limited resources. Actually we are pretty close to full utilizing these
>> resources when deploying openstack, so very little is available for test.
>> It's not a problem to run tempest API tests because they are cheap - take
>> little time, little resources, but also gives little coverage. Scenario test
>> are more interesting and gives us more coverage, but also takes a lot of
>> resources (which we don't have sometimes).
>
> Sagi,
> In my original message I mentioned a "targeted" test, I should
> explained that more. We could configure the specific scenario so that
> the load on the virt overcloud would be minimal. Justin Kilpatrick
> already have Browbeat integrated with TripleO Quickstart[1], so there
> shouldn't be much work to try this proposed solution.
>
>>
>> It may be useful to run a "limited edition" of API tests that maximize
>> coverage and don't duplicate, for example just to check service working
>> basically, without covering all its functionality. It will take very little
>> time (i.e. 5 tests for each service) and will give a general picture of
>> deployment success. It will cover fields that are not covered by pingtest as
>> well.
>>
>> I think could be an option to develop a special scenario tempest tests for
>> TripleO which would fit our needs.
>
> I haven't looked at Tempest in a long time, so maybe its functionality
> has improved. I just saw the opportunity to integrate Browbeat/Rally
> into CI to test the functionality of OpenStack services, while also
> capturing performance metrics.
>
> Joe
>
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_browbeat_tree_master_ci-2Dscripts&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=rFCQ76TW5HZUgA7b20ApVcXgXru6mvz4fvCm1_H6w1k&m=c7EeLf1PQSsV2XbWBhv6CWOzUFDRnDiIheN4lDKjyq8&s=Z0jGFw40ezDmSb3F6ns5SXRvacH6AgU0TK5dKBSRgEs&e=
>
>>
>> Thanks
>>
>>
>> On Wed, Apr 5, 2017 at 11:49 PM, Emilien Macchi  wrote:
>>>
>>> Greetings dear owls,
>>>
>>> I would like to bring back an old topic: running tempest in the gate.
>>>
>>> == Context
>>>
>>> Right now, TripleO gate is running something called pingtest to
>>> validate that the OpenStack cloud is working. It's an Heat stack, that
>>> deploys a Nova server, some volumes, a glance image, a neutron network
>>> and sometimes a little bit more.
>>> To deploy the pingtest, you obviously need Heat deployed in your
>>> overcloud.
>>>
>>> == Problems:
>>>
>>> Although pingtest has been very helpful over the last years:
>>> - easy to understand, it's an Heat template, like an OpenStack user
>>> would do to deploy their apps.
>>> - fast: the stack takes a few minutes to be created and validated
>>>
>>> It has some limitations:
>>> - Limitation to what Heat resources support (example: some OpenStack
>>> resources can't be managed from Heat)
>>> - Impossible to run a dynamic workflow (test a live migration for example)
>>>
>>> == Solutions
>>>
>>> 1) Switch pingtest to Tempest run on some specific tests, with feature
>>> parity of what we had with pingtest.
>>> For example, we could imagine to run the scenarios that deploys VM and
>>> boot from volume. It would test the same thing as pingtest (details
>>> can be discussed here).
>>> Each scenario would run more tests depending on the service that they
>>> run (scenario001 is telemetry, so it would run some tempest tests for
>>> Ceilometer, Aodh, Gnocchi, etc).
>>> We should work at making the tempest run as short as possible, and the
>>> close as possible from what we have with a pingtest.
>>>
>>> 2) Run custom scripts in TripleO CI tooling, called from the pingtest
>>> (heat template), that would run some validations commands (API calls,
>>> etc).
>>> It has been investigated in the past but never implemented AFIK.
>>>
>>> 3) ?
>>>
>>> I tried to make this text short and go straight to the point, please
>>> bring feedback now. I hope we can make progress on $topic during Pike,
>>> so we can increase our testing c

Re: [openstack-dev] [nova][deployment] FYI: changes to cells v2 setup guide (pike only)

2017-04-17 Thread Matt Riedemann


On 4/16/2017 10:35 PM, Alex Xu wrote:

Is it strange that the 'nova service-list' and 'nova host-list' return
the hosts which didn't have host mapping yet?


It's kind of strange yes. We could probably make GET /os-hypervisors 
work without requiring the host mappings, but it just doesn't today 
because of some targeted calls within each cell to fill the response.


So we could probably decouple things a bit internally in the API if we 
wanted to do this differently and not require a host mapping, but for 
now I knew we could get the same results by just using os-services and 
get Kolla unblocked (this came up Friday morning last week so I was 
rushing for a solution).




How the user to know whether a host was added to a cell or not?


A user doesn't need to know, but an operator would care. This actually 
came up in IRC last week [1] when Kevin Fox was asking similar 
questions, and I have a TODO to write some FAQs for cells v2.


We talked about how the "nova-manage cell_v2 discover_hosts" command is 
idempotent and if there are new unmapped hosts you could just run it and 
pick them up - the trick is knowing when to run it, unless you configure 
the scheduler to use "discover_hosts_in_cells_interval" for auto-discovery.


We also talked about the option of building on the "nova-manage cell_v2 
list_cells" command to also optionally dumping hosts per cell, or just 
run the "nova-manage host list" command pointed at your cell config.


At some point we might want to consider returning cell uuid out of the 
os-services API when listing services or hosts, something like that.


[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-04-10.log.html#t2017-04-10T20:25:47


--

Thanks,

Matt

__
OpenStack Development Mailing 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] New CI Job definitions

2017-04-17 Thread Brad P. Crochet

Hi y'all...

In the midst of trying to track down some errors being seen with tempest
tests whilst running under mod_wsgi/apache, I've made it so that the
devstack plugin is capable of also running with mod_wsgi/apache.[1]

In doing so, It's become the default devstack job. I've also now created
some 'non-apache' jobs that basically are what the old jobs did, just
renamed.

Also, I've consolidated the job definitions (the original and the kombu) to
simplify and DRY out the jobs. You can see the infra review here.[2]

The list of jobs will be:
gate-mistral-devstack-dsvm-ubuntu-xenial-nv
gate-mistral-devstack-dsvm-non-apache-ubuntu-xenial-nv
gate-mistral-devstack-dsvm-kombu-ubuntu-xenial-nv

Note that the trusty jobs have been eliminated.

Essentially, I've added a '{special}' tag to the job definition, allowing
us to create special-cased devstack jobs. So, as you can see, I've migrated
the kombu job to be such a thing. It should also be possible to combine
them.

[1] https://review.openstack.org/#/c/454710/
[2] https://review.openstack.org/#/c/457106/
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
OpenStack Development Mailing 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] Switching gate testing to use Ubuntu Cloud Archive

2017-04-17 Thread Simon Leinen

Ihar Hrachyshka writes:
> I just saw the plan merged in master:
> https://review.openstack.org/#/c/451492/ That's cool! Can we also
> backport the change to Ocata and maybe Newton so that we don't hit the
> same bug there? The backport is already up:
> https://review.openstack.org/#/c/456506/

For Ocata this makes sense, but note that the Newton UCA doesn't include
the libvirt-bin package.
-- 
Simon.

__
OpenStack Development Mailing 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] Usability question for the server migrations API

2017-04-17 Thread Matt Riedemann


On 4/17/2017 12:27 AM, Alex Xu wrote:

Also note that, we still have the API '/os-migrations', it will return
all the migration records in any status for all the VMs, and it supports
filters like 'instance_uuid', 'status', and 'migration_type' etc. I
can't remember clearly whether we said we will deprecated it, at least
for now, we didn't deprecate it yet. Want to figure whether it still
have some useful use-case for query multiple VMs' migration records.


Yeah that's a weird one. It's marked as "frozen" in the docs. The 
response is also different with microversion >= 2.23 such that after 
that point, the migration_type isn't in the response and is replaced 
with links to the server migration API if it's an in-progress live 
migration.


So I think this explains the response permutations based on microversion 
and type for /os-migrations:


1. microversion < 2.23:

Include all types of migrations in the response (assuming no filtering). 
Don't include the migration_type field in the response though.


2. microversion >= 2.23:

Include all types of migrations in the response.

a) If the migration is an in-progress live migration, then also return 
the migration_type in the response and provide links to the server 
migration: /servers/{server_id}/migrations/{migration_id}


b) If the migration is not for live migration or is not in progress, do 
not provide links but include migration_type in the response.


Needless to say, it gets a bit confusing. I have to read the code every 
time I think about this API (which is a sure sign it's bad). We also 
don't document the different responses based on type and microversion [1].


[1] https://bugs.launchpad.net/nova/+bug/1668747

--

Thanks,

Matt

__
OpenStack Development Mailing 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] Switching gate testing to use Ubuntu Cloud Archive

2017-04-17 Thread Ihar Hrachyshka

I just saw the plan merged in master:
https://review.openstack.org/#/c/451492/ That's cool! Can we also
backport the change to Ocata and maybe Newton so that we don't hit the
same bug there? The backport is already up:
https://review.openstack.org/#/c/456506/

Thanks,
Ihar

On Mon, Apr 3, 2017 at 4:06 PM, Clark Boylan  wrote:
> Hello,
>
> One of the major sets of issues currently affecting gate testing is
> Libvirt stability. Elastic-recheck is tracking Libvirt crashes for us
> and they happen frequently [0][1][2]. These issues appear to only affect
> Ubuntu Xenial (and not Trusty or CentOS or Fedora) and after talking in
> #openstack-nova it is clear that Libvirt isn't interested in debugging
> such an old version of Libvirt (1.3.1). And while it isn't entirely
> clear to me which exact version would be acceptable to them the Ubuntu
> Cloud Archive (UCA) does publish a much newer Libvirt (2.5.0).
>
> I have pushed a change to devstack [3] to enable using UCA which pulls
> in new Libvirt and mostly seems to work. I think we should consider
> switching to UCA as this may fix our Libvirt problems and if it doesn't,
> we will be closer to a version of Libvirt that upstream should be
> willing to fix.
>
> This isn't the most straightfoward switch as UCA has a different repo
> for each OpenStack release. libvirt-python is sensitve to the underlying
> library changing; it is backward compatible but libvirt-python built
> against older libvirt won't work against new libvirt. The result is a
> libvirt-python wheel built on our wheel mirror does not work with UCA.
> On the positive side both the OpenStack puppet modules and OpenStack
> Ansible are using UCA with their deployment tooling so this should get
> us closer to what people are using in the wild.
>
> After some thought I think my preferred method of rolling this out would
> be to blacklist libvirt-python from our wheel mirror building entirely
> and force installs to happen from source so that we are base Xenial and
> $UCA_version independent (local testing of these builds show it only
> takes a few seconds). Then have specific jobs (like devstack) explicitly
> opt into the UCA repo appropriate for them (if any). This last bit is
> from feedback from OpenStack Ansible that having the base images be
> fairly clean is desirable, but it would also be hard to know which
> version of UCA is appropriate for our Xenial images (this likely differs
> based on the job).
>
> Now its entirely possible that newer Libvirt will be worse than current
> (old) Libvirt; however, being closer to upstream should make getting
> fixes easier. Would be great if those with a better understanding of
> Libvirt could chime in on this if I am completely wrong here.
>
> Finally it is worth noting that we will get newer packages of other
> software as well, most notably openvswitch will be version 2.6.1 instead
> of 2.5.0.
>
> Any other thoughts or ideas?
>
> [0] http://status.openstack.org/elastic-recheck/#1646779
> [1] http://status.openstack.org/elastic-recheck/#1643911
> [2] http://status.openstack.org/elastic-recheck/#1638982
> [3] https://review.openstack.org/451492
>
> Thank you,
> Clark
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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][stable][ptls] Tagging mitaka as EOL

2017-04-17 Thread Brian Rosmaita

On 4/12/17 2:47 AM, Tony Breeds wrote:
> Hi all,
> I'm late in sending this announement, but I'm glad to see several projects
> have already requested EOL releases to make it trivial and obvious where to
> apply the tag.
> 
> I'm proposing to EOL all projects ...

Hi Tony, just wanted to give you a glance update.

We need to backport a fix to stable/mitaka glance_store and cut a
release before it gets EOL'd.  That will cascade back onto a need to cut
a new glance in stable/mitaka with the updated requirement.  We should
be able to get this done this week.

cheers,
brian

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

Re: [openstack-dev] [keystone] Integrate Identity with LDAP

2017-04-17 Thread Chason Chan

Yes, you are right, Кирилл! 

Thanks,

Chason
 
From: Кирилл Беспалов
Date: 2017-04-17 20:01
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] Integrate Identity with LDAP
Hi! Seems you are faced with the bug:
https://bugs.launchpad.net/keystone/+bug/1662762
Please make sure that Keystone already has the fix -
https://review.openstack.org/#/c/437402/
 
2017-04-17 6:56 GMT+03:00 Chason Chan :
> Hi team,
>
> I am trying to integrate Identity (Ocata Release) with LDAP. Afer I
> following  this page:
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/integrate_with_identity_service/sec-active-directory
>
> I failed to log in to the dashboard by entering their AD DS username and
> password.
>
> This is my "keystone.log" show: http://paste.openstack.org/show/606862/
>
> Please tell me how can I fix it.
>
> --
> Regards,
> Chason Chan
>
> __
> OpenStack Development Mailing 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] [keystone] Integrate Identity with LDAP

2017-04-17 Thread Кирилл Беспалов

Hi! Seems you are faced with the bug:
https://bugs.launchpad.net/keystone/+bug/1662762
Please make sure that Keystone already has the fix -
https://review.openstack.org/#/c/437402/

2017-04-17 6:56 GMT+03:00 Chason Chan :
> Hi team,
>
> I am trying to integrate Identity (Ocata Release) with LDAP. Afer I
> following  this page:
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/integrate_with_identity_service/sec-active-directory
>
> I failed to log in to the dashboard by entering their AD DS username and
> password.
>
> This is my "keystone.log" show: http://paste.openstack.org/show/606862/
>
> Please tell me how can I fix it.
>
> --
> Regards,
> Chason Chan
>
> __
> OpenStack Development Mailing 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] [ceilometer]

2017-04-17 Thread Julien Danjou

On Mon, Apr 17 2017, Andres Alvarez wrote:

> Hello everyone
>
> I am trying to get acquainted with the Ceilometer code base. I was reading
> through the Telemetry Admin Guide
> 
> regarding publishers and noticed that there are many deprecated publishers
> such as *direct*, *kafka*, and *database*. Yet on the source code's master
> branch
> 
> can still see some of these publishers there.
>
> Is there a reason for this?

Deprecated does not mean they are not shipped. That mean they should not
be configured and used. They'll be removed in a next version.
-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


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

Re: [openstack-dev] [telemetry] [ceilometer] Difference between publishers and dispatchers?

2017-04-17 Thread Julien Danjou

On Mon, Apr 17 2017, Andres Alvarez wrote:

Hi Andres,

> I am a bit confused on what is the difference between dispatchers and
> publishers in Ceilometer. The documentation explains a bit about publishers
> in the pipeline, but it does not mention much (if anything) about
> dispatchers.

Publishers are configured into the pipeline to indicate where to push
samples data (e.g. to Gnocchi).
One of the publisher is notifier:// which sends the samples to the (now
deprecated) ceilometer-collector process.

Ceilometer collector stores data into other system via a dispatcher
mechanism (e.g. to Gnocchi). It's now deprecated as it's just, with
current architecture, a unnecessary step: publishers can do the job
directly.

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

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

Re: [openstack-dev] [api-wg] Question about 'OpenStack-API-Version' header

2017-04-17 Thread Chris Dent


On Fri, 14 Apr 2017, Qiming Teng wrote:


According to the microversion specification [1], the
'OpenStack-API-Version' header is optional. When it is omitted, the
server should act as if the minimum supported version was specified.


That's correct.


Recently, we have received some complaints from users that for new APIs
added, we should state that the header is required. The new APIs are
valid only after a specific microversion. If the 'OpenStack-APi-Version'
header is missing, our server returns a 404 resource not found error.
It is confusing.


There's a bit of a circle here. If you're using microversions and you
add a new feature at, for example, version 2.24 then yes, you must
include the header with a microversion of 2.24 or beyond in order to
use that feature. This is aligned with the "opt-in" nature of
microversions and changes to the service.

If the new microversion is adding a new URL, then a 404 response is
correct when that microversion has not been selected.

So, yes, it is the case that when adding a new URL to a service that
is already supporting microversions, the header is required. That's
pretty much how microversions work and the service documentation
should indicate that.

Is there a different workflow that you (or the people complaining)
have in mind that could work better? Is there something that could
or should be clarified to make this more clear?

--
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] [libvirt] Whether kvm supports NVIDIA VGPU

2017-04-17 Thread Alex Xu

2017-04-15 3:03 GMT+08:00 Jay Pipes :

> On 04/12/2017 10:53 PM, 文峰sx-9149 wrote:
>
>> Will the openstack or libvirt (kvm) support NVIDIA VGPU?
>>  I am here
>> 
>> to see a mail introduction libvirt kvm support VGPU.
>>  But I do not know the current development situation of this feature.
>> Who can tell me about VGPU in Openstack?
>> Thanks.
>>
>
> A number of things need to happen before vGPU resources are a reality in
> OpenStack/Nova. In order, they are:
>
> 1) Completion of the "traits framework" for resource providers [1]. This
> should be completed in Pike.
>

yea, the traits API already merged, just left one patch
https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/resource-provider-traits


>
> 2) Completion of the "nested resource providers framework" [2]. This is
> critical because physical GPUs (or physical GPU *groups* in the case of
> XenServer) are child providers to the compute node resource provider and
> need to be tracked in a hierarchical relationship for resource accounting
> purposes. It is a stretch goal to get this work complete for Pike.
>
> 3) The spec for VGPU resources needs to be approved and merged [3]. This
> should happen today or Monday.
>
> 4) The os-traits library [4] needs to have GPU traits added to it.
> Jianghua from Citrix and myself are working on this.
>
> 5) The virt driver's get_inventory() methods [5] need to be reworked to
> account for physical GPUs (or physical GPU groups in the case of XenServer)
> having a set inventory of VGPU resources for each unique combination of max
> resolution size and other traits.
>
> 6) The flavor extra specs and image metadata need to be updated to allow
> an admin to configure and a user to request one or more VGPU resources from
> a VGPU resource provider having a set of required traits.
>

This spec https://review.openstack.org/#/c/351063/ is going to enable
configure the flavor include a set of required traits or preferred traits.
But it is abandoned by you, I'm not sure the reason yet, try to catch you
later.


>
> Best,
> -jay
>
> [1] https://blueprints.launchpad.net/nova/+spec/resource-provider-traits
> [2] https://blueprints.launchpad.net/nova/+spec/nested-resource-providers
> [3] https://review.openstack.org/#/c/450122/
> [4] https://github.com/openstack/os-traits
> [5] https://github.com/openstack/nova/blob/master/nova/virt/driver.py#L778
>
>
> __
> OpenStack Development Mailing 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] [ceilometer] Difference between publishers and dispatchers?

2017-04-17 Thread Andres Alvarez

Hi everyone

I am a bit confused on what is the difference between dispatchers and
publishers in Ceilometer. The documentation explains a bit about publishers
in the pipeline, but it does not mention much (if anything) about
dispatchers.

Would appreciate if someone can shed some light on this.

Thanks.
__
OpenStack Development Mailing 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] [Tacker][OSC] Command naming specs

2017-04-17 Thread Trinath Somanchi

Agree. Vnffg can be moved as 'vnf forwardinggraph'. Also, we are discussing to 
improve the command readability from an user perspective. 


Thanks,
Trinath Somanchi.

Digital Networking | NXP – Hyderabad – INDIA.
Email: trinath.soman...@nxp.com
Mobile: +91 9866235130 | Off: +91 4033504051


-Original Message-
From: Akihiro Motoki [mailto:amot...@gmail.com] 
Sent: Monday, April 17, 2017 12:32 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Tacker][OSC] Command naming specs

2017-04-15 12:44 GMT+09:00 Trinath Somanchi :
> Hi Jay-
>
> Thanks for the suggestions, we have improved this to an extent [1].
>
> For  'openstack vnf service function chain create' we agreed to go 
> with, 'openstack nfv chain create' or 'openstack vnf chain create'

I agree with Jay that NFV sounds too broad.
Even though tacker's scope can cover VNF-M and NFV-O, 'nfv' still sound too 
broad to me.
If a command belongs to VNF area, I would suggest to use 'vnf'.
If you have 'nfvo' related commands, you can explore an appropriate word.

VNFM and NFVO are different layers in ETSI and for example I am not sure 'VNF' 
forwarding graph can be called as 'NFV' forwarding graph.

> For ' openstack vnf forwardinggraph create' , you suggestion sounds 
> good. We are thinking on 'openstack vnffg create' in simple terms.

I don't think 'fg' is a common word. It is a bit long but 'forwarding graph' is 
much easier to understand.
'vnffg' is difficult to understand even though I think I know NFV to some 
extent.
Command line completion helps you. You should not think from the developer 
perspective.

Thanks,
Akihiro

> We have come up with a rule for certain commands which conflict with 
> other OpenStack projects,'nfv' is prefixed to differentiate the commands.
>
> The commands that may conflict include ``network-service``, 
> ``classifier``, ``nfp``, ``chain`` and ``event``.
>
> [1]
> https://review.openstack.org/#/c/455188/14/specs/pike/python-openstack
> client.rst
>
> Thanks,
>
> Trinath Somanchi.
>
>
>
> Digital Networking | NXP – Hyderabad – INDIA.
>
> Email: trinath.soman...@nxp.com
>
> Mobile: +91 9866235130 | Off: +91 4033504051
>
>
>
>
>
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Saturday, April 15, 2017 12:55 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Tacker][OSC] Command naming specs
>
>
>
> On 04/12/2017 03:08 AM, Trinath Somanchi wrote:
>
>> Hi OSC team-
>
>>
>
>> While  implementing tacker-cli commands as OSC plugins [1], We are
>
>> struck in command naming specifications.
>
>>
>
>> Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the
>
>> prefix.
>
>
>
> It's not *all* of NFV, though.
>
>
>
> This problem, by the way, is an indication that Tacker might have too 
> big a scope...and a scope that is very much tailored/purpose-built for 
> Telcos/NFV.
> But whatever, I raised this concern during the project application as 
> a member of the TC and folks ignored me, so it is what it is I guess.
>
>
>
>> We were struck in naming the below commands while aligning with the
>
>> OSC naming specs.
>
>>
>
>> For the below commands, for readability, we have added ‘-‘ within the
>
>> command names.
>
>>
>
>> Like,
>
>>
>
>>   network-service,  vnf-forwarding-graph,
>
>> service-function-chain,
>
>>
>
>> network-flow-classifier, network-forwarding-path.
>
>
>
> I think what Dean and Akihiro were suggesting is to use "vnf" as the 
> first "word" in the command list and then use space-delimited commands like 
> so:
>
>
>
> openstack vnf network service create
>
>
>
> Or just leave off the "network" above, because, well, Tacker doesn't 
> create any other type of service..., so:
>
>
>
> openstack vnf service create
>
>
>
> and then
>
>
>
> openstack vnf forwardinggraph create
>
>
>
> and
>
>
>
> openstack vnf service function chain create
>
>
>
>
>
> but then, you'll hit on the obvious overlap with networking-sfc, which 
> will bring in the obvious question of "what's the difference between 
> Tacker's SFC and networking-sfc's SFC?" which again should lead folks 
> to question the scope of Tacker in relation to other OpenStack projects...
>
>
>
> 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 Development Mailing List (not for usage questions)
Unsubscr

Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

2017-04-17 Thread Akihiro Motoki

Hi TIm,

I think no user-visible changes happen for users.
Do you have any example in your mind?

I understand horizon lacks supports of some hooks (such as adding a
menu to an existing table).
If there are missing things,

2017-04-12 2:24 GMT+09:00 Tim Bell :
> Are there any implications for the end user experience by going to different
> repos (such as requiring dedicated menu items)?
>
>
>
> Tim
>
>
>
> From: "Sridar Kandaswamy (skandasw)" 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Tuesday, 11 April 2017 at 17:01
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
>
>
> Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where
> would we like to have horizon dashboard for neutron stadium projects?
>
>
>
> Hi All:
>
>
>
> From and FWaaS perspective – we also think (a)  would be ideal.
>
>
>
> Thanks
>
>
>
> Sridar
>
>
>
> From: Kevin Benton 
> Reply-To: OpenStack List 
> Date: Monday, April 10, 2017 at 4:20 PM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where
> would we like to have horizon dashboard for neutron stadium projects?
>
>
>
> I think 'a' is probably the way to go since we can mainly rely on existing
> horizon guides for creating new dashboard repos.
>
>
>
> On Apr 10, 2017 08:11, "Akihiro Motoki"  wrote:
>
> Hi neutrinos (and horizoners),
>
> As the title says, where would we like to have horizon dashboard for
> neutron stadium projects?
> There are several projects under neutron stadium and they are trying
> to add dashboard support.
>
> I would like to raise this topic again. No dashboard support lands since
> then.
> Also Horizon team would like to move in-tree neutron stadium dashboard
> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
>
> Possible approaches
> 
>
> Several possible options in my mind:
> (a) dashboard repository per project
> (b) dashboard code in individual project
> (c) a single dashboard repository for all neutron stadium projects
>
> Which one sounds better?
>
> Pros and Cons
> 
>
> (a) dashboard repository per project
>   example, networking-sfc-dashboard repository for networking-sfc
>   Pros
>- Can use existing horizon related project convention and knowledge
>  (directory structure, testing, translation support)
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons
>- An additional repository is needed.
>
> (b) dashboard code in individual project
>   example, dashboard module for networking-sfc
>   Pros:
>- No additional repository
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons:
>- Requires extra efforts to support neutron and horizon codes in a
> single repository
>  for testing and translation supports. Each project needs to
> explore the way.
>
> (c) a single dashboard repository for all neutron stadium projects
>(something like neutron-advanced-dashboard)
>   Pros:
> - No additional repository per project
>   Each project do not need a basic setup for dashboard and
> possible makes things simple.
>   Cons:
> - Inclusion criteria depending on the neutron stadium
> inclusion/exclusion
>   (Similar discussion happens as for neutronclient OSC plugin)
>   Project before neutron stadium inclusion may need another
> implementation.
>
>
> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a
> repo).
>
> Note that as dashboard supports for feature in the main neutron repository
> are implemented in the horizon repository as we discussed several months
> ago.
> As an example, trunk support is being development in the horizon repo.
>
> Thanks,
> Akihiro
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing 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] [Tacker][OSC] Command naming specs

2017-04-17 Thread Akihiro Motoki

2017-04-15 12:44 GMT+09:00 Trinath Somanchi :
> Hi Jay-
>
> Thanks for the suggestions, we have improved this to an extent [1].
>
> For  'openstack vnf service function chain create' we agreed to go with,
> 'openstack nfv chain create' or 'openstack vnf chain create'

I agree with Jay that NFV sounds too broad.
Even though tacker's scope can cover VNF-M and NFV-O, 'nfv' still
sound too broad to me.
If a command belongs to VNF area, I would suggest to use 'vnf'.
If you have 'nfvo' related commands, you can explore an appropriate word.

VNFM and NFVO are different layers in ETSI and
for example I am not sure 'VNF' forwarding graph can be called as
'NFV' forwarding graph.

> For ' openstack vnf forwardinggraph create' , you suggestion sounds good. We
> are thinking on 'openstack vnffg create' in simple terms.

I don't think 'fg' is a common word. It is a bit long but 'forwarding
graph' is much easier to understand.
'vnffg' is difficult to understand even though I think I know NFV to
some extent.
Command line completion helps you. You should not think from the
developer perspective.

Thanks,
Akihiro

> We have come up with a rule for certain commands which conflict with other
> OpenStack projects,'nfv' is prefixed to differentiate the commands.
>
> The commands that may conflict include ``network-service``, ``classifier``,
> ``nfp``, ``chain`` and ``event``.
>
> [1]
> https://review.openstack.org/#/c/455188/14/specs/pike/python-openstackclient.rst
>
> Thanks,
>
> Trinath Somanchi.
>
>
>
> Digital Networking | NXP – Hyderabad – INDIA.
>
> Email: trinath.soman...@nxp.com
>
> Mobile: +91 9866235130 | Off: +91 4033504051
>
>
>
>
>
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Saturday, April 15, 2017 12:55 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Tacker][OSC] Command naming specs
>
>
>
> On 04/12/2017 03:08 AM, Trinath Somanchi wrote:
>
>> Hi OSC team-
>
>>
>
>> While  implementing tacker-cli commands as OSC plugins [1], We are
>
>> struck in command naming specifications.
>
>>
>
>> Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the
>
>> prefix.
>
>
>
> It's not *all* of NFV, though.
>
>
>
> This problem, by the way, is an indication that Tacker might have too big a
> scope...and a scope that is very much tailored/purpose-built for Telcos/NFV.
> But whatever, I raised this concern during the project application as a
> member of the TC and folks ignored me, so it is what it is I guess.
>
>
>
>> We were struck in naming the below commands while aligning with the
>
>> OSC naming specs.
>
>>
>
>> For the below commands, for readability, we have added ‘-‘ within the
>
>> command names.
>
>>
>
>> Like,
>
>>
>
>>   network-service,  vnf-forwarding-graph,
>
>> service-function-chain,
>
>>
>
>> network-flow-classifier, network-forwarding-path.
>
>
>
> I think what Dean and Akihiro were suggesting is to use "vnf" as the first
> "word" in the command list and then use space-delimited commands like so:
>
>
>
> openstack vnf network service create
>
>
>
> Or just leave off the "network" above, because, well, Tacker doesn't create
> any other type of service..., so:
>
>
>
> openstack vnf service create
>
>
>
> and then
>
>
>
> openstack vnf forwardinggraph create
>
>
>
> and
>
>
>
> openstack vnf service function chain create
>
>
>
>
>
> but then, you'll hit on the obvious overlap with networking-sfc, which will
> bring in the obvious question of "what's the difference between Tacker's SFC
> and networking-sfc's SFC?" which again should lead folks to question the
> scope of Tacker in relation to other OpenStack projects...
>
>
>
> 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

64 matches

Mail list logo