[openstack-dev] [tempest] clients/manager in plugins

Hi, This is a question regarding design of clients and managers in a tempest plugin. I'm not familiar with tempest, but it seems that there are the following terms: Client: client of service or feature (part of service) ClientManager: having clients which are needed for particular

Re: [openstack-dev] [Fuel] Multiple repos UX

Hi, I agree with the idea of unification for repo configurations, but it looks like we are developing yet another standard. Do we really need a custom format? Why can not we use native format for yum.conf and apt.sources files, and native tooling (all those python bindings, cli utils and so on)

[openstack-dev] [fuel-library] making task "apache" idempotent

Hello. I am trying to pick a way of making puppet manifest fuel-library/deployment/puppet/osnailyfacter/modular/apache/apache.pp idempotent. During a normal execution flow, Fuel (fuel-astute, actually) would run "apache" task before running other tasks, which create virtual host configuration

Re: [openstack-dev] [infra][release][all] Automatic .ics generation for OpenStack's and project's deadlines

Jeremy Stanley wrote: > On 2015-12-10 18:20:44 + (+), Flavio Percoco wrote: >> Has this been attempted? Any objections? Is there something I'm not >> considering? > > I'm not aware of any work so far to that end, but have a feeling you > could reuse

Re: [openstack-dev] [all] build breaks with decorator===4.0.5

Review has merged, it's safe to recheck your reviews now. thanks, Dims On Fri, Dec 11, 2015 at 12:16 PM, Davanum Srinivas wrote: > Hi, > > Looks like a file went AWOL from pypi: > https://github.com/micheles/decorator/commits/master/ > > I am baby-sitting this requirements

Re: [openstack-dev] [Fuel] Multiple repos UX

There are common practices developed by operating system developers, and thousands of people using them every day. Redefining that experience will bring nothing more but questions and misunderstanding, because if someone has questions, instead of hundreds already written manuals a person would

[openstack-dev] [Monasca] monasca-threshold smoke is failing

Hello, Trying to install the Monasca through vagrant stuff. On the 'vagrant provision' step, getting the threshold smoke failure. Any clue what might be the cause. I am in Ubuntu 15.10: pradipm@pradipm-ThinkPad-W530:~$ uname -a Linux pradipm-ThinkPad-W530 4.2.0-19-generic #23-Ubuntu SMP Wed

Re: [openstack-dev] [Fuel] Multiple repos UX

Regarding to UI. Of course, we could provide native format to a user on UI. Although I don't think it would be much easier to edit, but it is flexible enough to define something like this: http://url trusty main http://anotherurl trusty universe multiverse restricted http://yet-another-url

[openstack-dev] [Fuel] Disable stringify_facts in 9.0

Hi folks, my sense of aesthetics was slightly disturbed when I saw that the mounts fact[1] is implemented by joining mount points using a comma. It turns out that what Alex did is completely right as Puppet up to 3.8 release has enabled stringify_facts by default. TLDR of that setting is that

Re: [openstack-dev] [python-novaclient] history of virtual-interface commands

Hi Tomi, It looks like CLI was not added from the beginning of virtual-interface history[1]. Jichenjc works on patch[2] to fix this issue. [1] - https://review.openstack.org/#/c/3368/ [2] - https://review.openstack.org/#/c/254707/ On Thu, Dec 10, 2015 at 1:26 PM, Juvonen, Tomi (Nokia -

Re: [openstack-dev] [oslo.messaging] configurable ack-then-process (at least/most once) behavior

Hello. On 02.12.2015 12:01, Bogdan Dobrelya wrote: >> Bogdan, >> >> Which service would use this flag to start with? and how would the >> code change to provide "app side is fully responsible for duplicates >> handling"? > > (fixed topic tags to match oslo.messaging) > > AFAIK, this mode is

Re: [openstack-dev] [Fuel] Multiple repos UX

Hey folks - +1 from my side on the idea of having the unified repo format. It will simplify a cross-project contribution. I think we can file a blueprint for 9.0. I have only two questions to discuss: * We need to declare format for RPM repos either. * Shouldn't we use slightly different set of

Re: [openstack-dev] [Fuel] Multiple repos UX

This thread is not about format itself, but about the approach when all repos are thought independently. I.e. no patterns like this suite, suite-updates, suite-security, no limitations for suite and suite-updates should be located on the same host. It should be flat list of independent repos.

Re: [openstack-dev] [Fuel] Multiple repos UX

> Do we really need a custom format? Why can not we use native format > for yum.conf and apt.sources files Because we don't want to parse this format each time we want to verify / handle particular component of this format. Moreover, there's no, for example, priority in Debian repo format.

Re: [openstack-dev] [Fuel] Multiple repos UX

Hello Vladimir, I definitely agree that using one uri for generating number of repos is not the best solution. According to Fuel Menu - there was the discussion in gerrit [1] about repositories format. The first version of my patch implements actually your idea about equality and independence of

[openstack-dev] [TripleO] Stable/Liberty Backports & Reviews

Hi all, So, after the painful process of getting CI working for stable/liberty, everything is now working pretty well, and I have a few small requests to hopefully help improve velocity for backports landing: 1. Please use git "cherry-pick -x" when backporting from master - this is a small

Re: [openstack-dev] [fuel-library] making task "apache" idempotent

Hi, I suppose disabling purge_configs is the only solution here. Running all the configuration in a single task does not fit well into deployment granularization philosophy. Regards, Alex On Fri, Dec 11, 2015 at 12:13 PM, Dmitry Bilunov wrote: > Hello. > > I am trying

Re: [openstack-dev] [python-glanceclient] Return request-id to caller

> -Original Message- > From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com] > Sent: 11 December 2015 09:19 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to > caller > > > > -Original

Re: [openstack-dev] [Fuel] Multiple repos UX

BTW, here you can see an example http://demo.fuel-infra.org:8000 Just go to any cluster and see Repositories section on the settings tab. Vladimir Kozhukalov On Fri, Dec 11, 2015 at 5:46 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > I'd like this module >

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

Roman, Changing arbitrary parameters supported by respective Puppet manifests for OpenStack services is implemented in this blueprint [1]. It is being landed in release 8.0. [1] https://blueprints.launchpad.net/fuel/+spec/openstack-config-change -- Best regards, Oleg Gelbukh On Thu, Dec 3,

Re: [openstack-dev] [Fuel] Multiple repos UX

Hello, Vladimir. Seems nothing is better for end-user in UI/fuel-mirror/image-bootstrap than 'You Get What You See' because system administrator should not learn new standard: http://url trusty main http://anotherurl trusty universe multiverse restricted http://yet-another-url

Re: [openstack-dev] [Fuel] Multiple repos UX

Folks, when you get consensus here, please file a bug - it's most likely fixable in 8.0. 2015-12-11 14:44 GMT+03:00 Vladimir Kozhukalov : > Regarding to UI. Of course, we could provide native format to a user on > UI. Although I don't think it would be much easier to

Re: [openstack-dev] [Fuel] Moved blueprints out of 8.0

Hi Mike, Yes, I agree that we cannot move blueprints to "Implemented" unless all dependencies are complete (incl tests and doc). Probably we can use "Beta available" for such tickets instead of "Deployment" as we can already try the functionality. All development-related child blueprints for [1]

Re: [openstack-dev] [Fuel] Disable stringify_facts in 9.0

Hi, I agree, let's do this. Regards, Alex On Fri, Dec 11, 2015 at 1:08 PM, Bartłomiej Piotrowski < bpiotrow...@mirantis.com> wrote: > Hi folks, > > my sense of aesthetics was slightly disturbed when I saw that the mounts > fact[1] is implemented by joining mount points using a comma. > > It

Re: [openstack-dev] [Fuel] Multiple repos UX

I'd like this module https://github.com/openstack/fuel-menu/blob/master/fuelmenu/modules/bootstrapimg.py to be fixed so a user can define several repos independently. This particular ML thread is not about internal repo data format, it is not about particular format that we expose to end user.

Re: [openstack-dev] [Fuel] Disable stringify_facts in 9.0

I think we should turn it on in the next release. That would be really nice to have it. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Fri, Dec 11, 2015 at 2:50 PM, Aleksandr Didenko wrote: > Hi, > > I agree, let's do this. > > Regards, > Alex > > On

[openstack-dev] [Fuel] Important: Functional tests are back. Please rebase

Fuelers, for a long time functional tests in Fuel Client were not triggered by Fuel CI because of a pesky bug [1] in our tox.ini. The fix [2] for it was landed a few minutes ago. Since we don’t have gate jobs that trigger functional tests, I gently ask you to rebase your patches for Fuel

Re: [openstack-dev] [Fuel] Moved blueprints out of 8.0

Hi Dmitry, I would like not to overcomplicate blueprints. If additional work is required there should be additional dependent blueprint. This will help us to deliver all blueprints on time while other teams are working on own blueprints (e.g. Documentation) with own release cadence. [1]

Re: [openstack-dev] [Fuel] Multiple repos UX

If there are no any objections, let's do fix fuel-menu ASAP. As Fedor said this approach was suggested first, but then it was rejected during review process. It should not be so hard to get it back. Fedor, could you please confirm that it is possible to do this before SCF? Here is the bug

Re: [openstack-dev] [Fuel] Extend FFE for "Disable queue mirroring for RPC queues in RabbitMQ"

Folks, First, let me report current feature status: we continued the work with Bogdan Dobrelya and Sergii Golovatiuk. I have incorporated their feedback into the change. Also, I have fully tested it on custom ISO and Fuel CI passes successfully. Also, I have an approval from Bogdan on the

[openstack-dev] [ironic][qa] moving to devstack/grenade plugins

Hi friends, As you may already know from my IRC/gerrit spam, I'm working hard to move Ironic to using devstack and grenade plugins, rather than being in those projects directly. I wanted to lay out some notes on that here so people know what's going on. * The patches are all in this gerrit

[openstack-dev] [Fuel] Disabling root SSH access to slave nodes.

Hello Fuelers, Due to a very large scope of the original bp/spec, it had to be split into 3 smaller ones. Currently, there is one blueprint[1] available. It covers root access to openstack nodes. It basically comes down to following: - Allow user to specify account name(s) to create and

Re: [openstack-dev] [Neutron][DVR]

Hi Armando/Carl, Yes based on Carl’s recommendation I have categorized the bugs in the Wiki below right now. If you think adding an Etherpad will be more appropriate, we can add one. https://wiki.openstack.org/wiki/Meetings/Neutron-DVR Thanks Swami From: Armando M. [mailto:arma...@gmail.com]

Re: [openstack-dev] [Congress] Mid-cycle meet-up

Folks, The meeting will be at the Cisco Campus, Building I (eye). Here it is the address: Cisco Building I (eye) 285 W. Tasman Drive San Jose California 95134 United States I will provide more details beginning of January. I am also trying to get a Monasca mid-cycle to happen the same week at

Re: [openstack-dev] [Neutron][DVR]

On 3 December 2015 at 10:46, Carl Baldwin wrote: > I was going to bring this up in the meeting this morning but IRC > troubles prevented it. > > After chatting with Armando, I'd like to suggest a few enhancements to > how we're tackling DVR during this cycle. I'm hoping that

[openstack-dev] [Fuel] Experimental Task Based Deployment Landed into Master

Fuelers I am thrilled to announce that task based deployment engine [0] has been just merged into Fuel master. We checked it against existing BVT test cases for regressions as well as against functional testing for several cases of deployment. All the OSTF and network verification tests have

Re: [openstack-dev] [tempest] clients/manager in plugins

Hi Ryota, That is the one way as you mentioned. On Fri, Dec 11, 2015 at 8:15 PM, Ryota Mibu wrote: > Hi, > > > This is a question regarding design of clients and managers in a tempest > plugin. > > > I'm not familiar with tempest, but it seems that there are the following

Re: [openstack-dev] [nova] Volume attachment APIs CRUD inconsistencies

On 12/11/2015 1:48 PM, Sam Matzek wrote: The CRUD operations for Nova volume attachments have inconsistencies between documentation and implementation. Additionally, the read/get operation is implemented twice under different URIs. What is Nova's direction for volume attachment APIs and how

Re: [openstack-dev] [Cinder] Is there anyone truly working on this issue https://bugs.launchpad.net/cinder/+bug/1520102?

Hi Thang, Vincent, I guess the root cause is that finish_volume_migration() still handles a volume as a dictionary instead of volume object and the method returns dict volume. And then, 'rpcapi.delete_volume()' in migrate_volume_completion() tries to delete dict volume but it fails due to the

Re: [openstack-dev] [nova] Volume attachment APIs CRUD inconsistencies

On Fri, Dec 11, 2015 at 7:33 PM, Matt Riedemann wrote: > > > On 12/11/2015 1:48 PM, Sam Matzek wrote: > >> The CRUD operations for Nova volume attachments have inconsistencies >> between documentation and implementation. Additionally, the read/get >> operation is

Re: [openstack-dev] [nova] Volume attachment APIs CRUD inconsistencies

On Fri, Dec 11, 2015 at 8:38 PM, Anne Gentle wrote: > > > On Fri, Dec 11, 2015 at 7:33 PM, Matt Riedemann < > mrie...@linux.vnet.ibm.com> wrote: > >> >> >> On 12/11/2015 1:48 PM, Sam Matzek wrote: >> >>> The CRUD operations for Nova volume attachments have

[openstack-dev] [oslo] stable/liberty branch needed for oslo-incubator

oslo-incubator is EOL now but it's missing a stable/liberty branch, and we need one for backporting changes that will be synced to projects in liberty. I'm not sure what commit would be used to create the stable/liberty branch though. -- Thanks, Matt Riedemann

Re: [openstack-dev] [oslo] stable/liberty branch needed for oslo-incubator

Matt, Do you have an example? This was a deliberate decision to leave it out. -- Dims On Sat, Dec 12, 2015 at 4:35 AM, Matt Riedemann wrote: > oslo-incubator is EOL now but it's missing a stable/liberty branch, and we > need one for backporting changes that will be

Re: [openstack-dev] [glance][keystone][artifacts] Service Catalog name for Glance Artifact Repository API

On 12/11/15, 3:13 PM, "Ian Cordasco" wrote: >On 12/11/15, 12:25, "Alexander Tivelkov" wrote: > >>Hi folks! >> >> >>As it was decided during the Mitaka design summit, we are separating the >>experimental Artifact Repository API from the main

Re: [openstack-dev] Fwd: [Neutron] Team meeting this Monday at 2100 UTC

On 8 December 2015 at 11:56, Doug Wiegley wrote: > I actually found this week’s meeting more useful than normal. The typical > agenda items feel rote and less useful to aligning things, sort of, > thinking out loud. > > Ok, let's keep chewing at the list. We'll send

Re: [openstack-dev] [Neutron][DVR]

On 11 December 2015 at 15:23, Vasudevan, Swaminathan (PNB Roseville) < swaminathan.vasude...@hpe.com> wrote: > Hi Armando/Carl, > > Yes based on Carl’s recommendation I have categorized the bugs in the Wiki > below right now. If you think adding an Etherpad will be more appropriate, > we can add

Re: [openstack-dev] [Fuel] Christmas Core Cleanup

Mike - I'm not a fuel-docs core, so it's up to fuel-docs-core team to remove *dead* cores. According to Stackalytics [1] Irina Povolotskaya's showing a low contribution rate. Regarding Vitaly, I don't know why Stackalytics marks him as core, since he's not a member of gerrit core group [2]. -

[openstack-dev] [all] build breaks with decorator===4.0.5

Hi, Looks like a file went AWOL from pypi: https://github.com/micheles/decorator/commits/master/ I am baby-sitting this requirements review on zuul: https://review.openstack.org/#/c/256238/ That will fix the upper-constraints.txt and will help fix the breaks. Thanks, Dims -- Davanum Srinivas

Re: [openstack-dev] [python-glanceclient] Return request-id to caller

-Original Message- From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com] Sent: 10 December 2015 12:56 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to caller -Original Message- From:

Re: [openstack-dev] [QA][Tempest] Drop javelin off tempest

Do you think that then we should mark it as 'deprecate'? so it throws a warning when called until we finally decide to drop it off in a future cycle? El 11/12/15 a las 03:52, GHANSHYAM MANN escribió: > Hi, > > Yes, That's very valid point about there might be some real users or in > future. > >

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

Hi Nikolay, Is there further information I could provide about the bug? Thanks. --Vahid __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

[openstack-dev] [Fuel] Separate master node provisioning and deployment

Dear colleagues, At the moment part of the Fuel master deployment logic is located in ISO kickstart file, which is bad. We'd better carefully split provisioning and deployment stages so as to install base operating system during provisioning stage and then everything else on the deployment stage.

[openstack-dev] [nova] Volume attachment APIs CRUD inconsistencies

The CRUD operations for Nova volume attachments have inconsistencies between documentation and implementation. Additionally, the read/get operation is implemented twice under different URIs. What is Nova's direction for volume attachment APIs and how should the following discrepancies be

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

Vahid, The bug you mentioned was fixed recently: https://review.openstack.org/#/c/255154/ Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis On Fri, Dec 11, 2015 at 10:46 PM, Vahid S Hashemian < vahidhashem...@us.ibm.com> wrote: > Hi Nikolay, > > Is there

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

Oleg, thanks. I've tried it [1], looks like it works. - GOOD. "override_resource" resource. Like "back door" into puppet modules. - BAD. It allows just apply, not track changes. Moreover works weird, if multiple changes uploaded, applying not the latest, but initial config change. - BAD. Just

Re: [openstack-dev] [infra][release][all] Automatic .ics generation for OpenStack's and project's deadlines

On Thu, Dec 10, 2015 at 06:20:44PM +, Flavio Percoco wrote: > > With the new home for the release schedule, and it being a good place > for projects to add their own deadlines as well, I believe it would be > good for people that use calendars to have these .ics being generated > and linked

[openstack-dev] OpenStack Developer Mailing List Digest December 5-11

Perma Link: http://www.openstack.org/blog/2015/12/openstack-developer-mailing-list-digest-20151205/ Success Bot Says * AJaeger: With Juno End-of-Life, Python 2.6 testing has been removed from OpenStack CI. * Tell us yours via IRC with a message “#success [insert success]”. *

Re: [openstack-dev] [glance][keystone][artifacts] Service Catalog name for Glance Artifact Repository API

On 12/11/15, 12:25, "Alexander Tivelkov" wrote: >Hi folks! > > >As it was decided during the Mitaka design summit, we are separating the >experimental Artifact Repository API from the main Glance API. This API >will have a versioning sequence independent from the main

Re: [openstack-dev] [Fuel] Separate master node provisioning and deployment

For the package-based deployment, we need to get rid of 'deployment script' whatsoever. All configuration stuff should be done in package specs, or by the user later on (maybe via some fuelmenu-like lightweight UI, or via WebUI). Thus, fuel package must install everything that is required for

Re: [openstack-dev] [telemetry][aodh][vitrage] The purpose of notification about alarm updating

sorry, my email was blocking the list for a bit so i missed this. the original reason this was implemented i believe was to track alarm state changes as an event in ceilometer events. i still see this as a valid use case but it does duplicate some of the functionality of alarm history. i

Re: [openstack-dev] neutron metadata-agent HA

> On Dec 10, 2015, at 12:56 AM, Alvise Dorigo wrote: > > So my question is: is there any progress on this topic ? is there a way > (something like a cronjob script) to make the metadata-agent redundant > without involving the clustering software Pacemaker/Corosync ?

Re: [openstack-dev] [Fuel] Feature Freeze Exceptions

Hi all, On Wed, Dec 2, 2015 at 7:47 PM, Mike Scherbakov wrote: > Hi all, > we ran a meeting and made a decision on feature freeze exceptions. Full > log is here: > https://etherpad.openstack.org/p/fuel-8.0-FF-meeting > > The following features were granted with feature

Re: [openstack-dev] [oslo.log] RFC5424-compliant dates

On Fri, Dec 11, 2015, at 10:12 AM, Chris St. Pierre wrote: > RFC5424 requires timestamps in a strict subset of RFC3339. Currently, > oslo.log has no way to provide dates in this format without specifying a > custom logging formatter, which means that oslo.log is incapable of > providing

Re: [openstack-dev] [glance][keystone][artifacts] Service Catalog name for Glance Artifact Repository API

Hi Steve, Thanks for the note on port. Any objections on glare using 9494 then? Anyone? Пт, 11 дек. 2015 г. в 21:39, McLellan, Steven : > Hi Alex, > > Searchlight uses port 9393 (it also made sense to us when we spun out of > Glance!), so we would prefer it if there's

[openstack-dev] [glance][keystone][artifacts] Service Catalog name for Glance Artifact Repository API

Hi folks! As it was decided during the Mitaka design summit, we are separating the experimental Artifact Repository API from the main Glance API. This API will have a versioning sequence independent from the main Glance API and will be run as a standalone optional service, listening on the port

Re: [openstack-dev] [glance][keystone][artifacts] Service Catalog name for Glance Artifact Repository API

Hi Alex, Searchlight uses port 9393 (it also made sense to us when we spun out of Glance!), so we would prefer it if there's another one that makes sense. Regarding the three hardest things in computer science, searchlight's already dealing with cache invalidation so I'll stay out of the

Re: [openstack-dev] [glance][keystone][artifacts] Service Catalog name for Glance Artifact Repository API

The port is an arbitray choice for developers running on standalone services over HTTP. Just don't choose something in the linux ephemeral port range :) In production, assume all services can be deployed on 443. As for service *type*, it should not include project names, code names, API versions,

Re: [openstack-dev] [Fuel] Feature Freeze Exceptions

Latest update: all implemented now. Task-based deployment was the last one, and it got merged today: http://lists.openstack.org/pipermail/openstack-dev/2015-December/082093.html . Great work everyone! On Fri, Dec 11, 2015 at 12:48 PM Sergii Golovatiuk wrote: > Hi all,

[openstack-dev] [tripleo] Pin some puppet dependencies on git clone

Hi all, Today TripleO CI jobs failed because a new commit introduced on puppetlabs-mysql[1]. Mr. Jiri Stransky solved it as a temporally fix by pinning the puppet module clone to a previous commit in the tripleo-common project[2]. source-repositories puppet element[3] allows you to pin the

[openstack-dev] Changes to Gerrit and handling double encoded slashes

Today (Dec 12) there was an update performed to gerrit web server changing how apache proxies requests to the java application. This change is in preperation for the update of gerrit planned for December 16th. We have moved from utilizing mod_rewrite to directly using mod_proxy. In performing this