date:20170421

Excerpts from ChangBo Guo's message of 2017-04-21 16:04:35 +0800:
> What the related thing I can remember is we discuss oslo libraries'
> compatibility in [1], which was abandoned.
> I made stable compat ocata jobs non-voting in [2], hope can revert when
> related bug is fixed before.
> But now, If we decide remove them, we don't revert anymore.

With our constraint system and with stable branches for libraries,
do we need new releases from master to be compatible with older
services on stable branches?

Doug

> 
> [1]  https://review.openstack.org/226157
> [2]  https://review.openstack.org/#/c/448431
> 
> 2017-04-20 0:42 GMT+08:00 Doug Hellmann :
> 
> > I noticed again today that we have some test jobs running for some
> > of the Oslo libraries against old versions of services (e.g.,
> > gate-tempest-dsvm-neutron-src-oslo.log-ubuntu-xenial-newton,
> > gate-tempest-dsvm-neutron-src-oslo.log-ubuntu-xenial-ocata, and
> > gate-oslo.log-src-grenade-dsvm-ubuntu-xenial-nv).
> >
> > I don't remember what those are for, but I imagine they have to do
> > with testing compatibility. They're all non-voting, though, so maybe
> > not?
> >
> > Now that we're constraining libraries in our test systems, I wonder
> > if we still need the jobs at all?
> >
> > Doug
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 

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

Re: [openstack-dev] [oslo] Can we stop global requirements update?

Excerpts from Joshua Harlow's message of 2017-04-20 22:31:19 -0700:
> Doug Hellmann wrote:
> > Excerpts from gordon chung's message of 2017-04-20 17:12:26 +:
> >> On 20/04/17 01:32 AM, Joshua Harlow wrote:
> >>> Wasn't there also some decision made in austin (?) about how we as a
> >>> group stated something along the line of co-installability isn't as
> >>> important as it once was (and may not even be practical or what people
> >>> care about anymore anyway)?
> >
> > I don't remember that, but I may not have been in the room at the
> > time.  In the past when we've discussed that idea, we've continued
> > to maintain that co-installability is still needed for distributors
> > who have packaging constraints that require it and for use cases
> > like single-node deployments for POCs.
> 
> Ya, looking back I think it was:
> 
> https://etherpad.openstack.org/p/newton-global-requirements
> 
> I think that was robert that lead that session, but I might be incorrect 
> there.

That was me, though Robert was definitely present and vocal.

My memory of the outcome of that session was that we needed to maintain
co-installability; that we could continue to keep an eye on the
container space as an alternative; and that a new team of maintainers
would take over the requirements list (which was my secret agenda for
proposing that we stop doing it at all).

During the session in Barcelona (I previously said Austin, but
misremembered the location) we agreed that we could stop syncing,
as long as we maintained co-installability by ensuring that everyone's
requirements lists intersect with the upper-constraints.txt list. That
work has been started.

As far as I know, we have never said we could drop co-installability as
a requirement. We have wished we could, but have not said we can.

Doug

> 
> >
> >>> With kolla becoming more popular (tripleo I think is using it, and ...)
> >>> and the containers it creates making isolated per-application
> >>> environments it makes me wonder what of global-requirements is still
> >>> valid (as a concept) and what isn't.
> >
> > We still need to review dependencies for license compatibility, to
> > minimize redundancy, and to ensure that we're not adding things to
> > the list that are not being maintained upstream. Even if we stop syncing
> > versions, official projects need to be those reviews, and having the
> > global list is a way to ensure that the reviews are done.
> >
> >>> I do remember the days of free for all requirements (or requirements
> >>> sometimes just put/stashed in devstack vs elsewhere), which I don't
> >>> really want to go back to; but if we finally all agree that
> >>> co-installability isn't what people actually do and/or care about
> >>> (anymore?) then maybe we can re-think some things?
> >> agree with all of ^... but i imagine to make progress on this, we'd have
> >> to change/drop devstack usage in gate and that will take forever and a
> >> lifetime (is that a chick flick title?) given how embedded devstack is
> >> in everything. it seems like the solution starts with devstack.
> >>
> >> cheers,
> >>
> >
> > __
> > OpenStack Development Mailing 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] [requirements][all][keystone] Getting requests from keystoneauth not directly


Hey everybody!

I just put up a couple of patches here:

https://review.openstack.org/#/q/topic:ksa-requests

that remove direct depends from client libs on requests, which leave 
them to rely on keystoneauth for their requests dependency.


The reason I pushed these up is that we're seeing bug reports from users 
out there that they'll install a set of python-*clients, then try to use 
something with entrypoints and pkg_resources barfs at them.


This in turn is caused by _some_ of the clients having made releases 
with a new version exclusion placed on requests but others not having 
made that, and then the ones that haven't released with the exclusion 
yet happen to be the ones from which pip decides to install requests - 
leading to a version of requests being installed that conflicts with the 
stated version string of some of our client libs. (yay! :( )


So my general proposal is that since all of our client libs use 
keystoneauth for their REST interactions anyway (yay for real), that we 
rely on keystoneuath for installation of requests. This way if we need 
to get a fix out that involves blocking a version of requests, we simply 
need to land it in ksa and release ksa - which is also low impact 
because ksa has an extremely strict policy on changes and backwards compat.


There is a similar issue that currently exists with Babel, so I'll also 
send a few patches out. There is a MUCH LARGER overall issue at work 
here that Doug Hellmann has a proposal up for fixing in a real way. I 
don't think we should spend an excessive amount of time obsessing about 
trying to shrink transitive dependency chains like this and instead we 
should just work on Doug's thing. But requests is, well, it's kind of 
essential to all the client libs - so it seems like a fairly simple way 
to fix something that's breaking our users right now.


Monty

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

Re: [openstack-dev] [release][monasca] Release of openstack/monasca-kibana-plugin failed

Excerpts from witold.be...@est.fujitsu.com's message of 2017-04-21 09:13:03 
+:
> Hi,
> 
> I'm sorry, I missed that.
> 
> I've created the updates:
> 
> https://review.openstack.org/458773
> https://review.openstack.org/458776

Both of those look correct.

> 
> 
> Cheers
> Witek
> 
> > -Original Message-
> > From: Hochmuth, Roland M [mailto:roland.hochm...@hpe.com]
> > Sent: Freitag, 21. April 2017 06:19
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: Re: [openstack-dev] [release][monasca] Release of
> > openstack/monasca-kibana-plugin failed
> > 
> > Thanks Doug. My understanding of the issue is that we need to
> > 
> > 1. Update the version in package.json,
> > https://github.com/openstack/monasca-kibana-
> > plugin/blob/master/package.json, from "0.0.5" to "1.0.1".
> > 2. Cherry pick to Ocata.
> > 3. Then apply a new release tag for Ocata for 1.0.1 in,
> > https://review.openstack.org/#/c/433823/1/deliverables/ocata/monasca-
> > kibana-plugin.yaml.
> > 
> > Does that sound correct?
> > 
> > Regards --Roland
> > 
> > 
> > 
> > 
> > 
> > On 4/20/17, 1:41 PM, "Doug Hellmann"  wrote:
> > 
> > >Excerpts from Doug Hellmann's message of 2017-04-20 15:26:47 -0400:
> > >> The version of monasca-kibana-plugin in package.json does not match
> > >> the new tag, and that caused the publish job to fail. I'm available
> > >> to help debug or to quickly release an update after the problem is fixed.
> > >
> > >https://review.openstack.org/458629 should help us avoid this error in
> > >the future.
> > >
> > >>
> > >> Doug
> > >>
> > >> --- Begin forwarded message from jenkins ---
> > >> From: jenkins 
> > >> To: release-job-failures 
> > >> Date: Wed, 19 Apr 2017 10:01:01 +
> > >> Subject: [Release-job-failures] Release of
> > >> openstack/monasca-kibana-plugin failed
> > >>
> > >> Build failed.
> > >>
> > >> - monasca-kibana-plugin-nodejs4-npm-publish-tarball
> > >>
> > http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8
> > >> /release/monasca-kibana-plugin-nodejs4-npm-publish-tarball/4852b10/ :
> > >> SUCCESS in 4m 48s
> > >> - monasca-kibana-plugin-tarball-signing
> > >>
> > http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8
> > >> /release/monasca-kibana-plugin-tarball-signing/28e6145/ : SUCCESS in
> > >> 10s
> > >> - monasca-kibana-plugin-npm-upload
> > >>
> > http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8
> > >> /release/monasca-kibana-plugin-npm-upload/f3dd81a/ : FAILURE in 9s
> > >> - monasca-kibana-plugin-announce-release
> > >> monasca-kibana-plugin-announce-release : SKIPPED
> > >>
> > >> --- End forwarded message ---
> > >>
> > >
> > >_
> > __
> > >___ OpenStack Development Mailing List (not for usage questions)
> > >Unsubscribe:
> > >openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > __
> > 
> > OpenStack Development Mailing 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] [release][monasca] Release of openstack/monasca-kibana-plugin failed

Excerpts from Hochmuth, Roland M's message of 2017-04-21 04:18:47 +:
> Thanks Doug. My understanding of the issue is that we need to
> 
> 1. Update the version in package.json, 
> https://github.com/openstack/monasca-kibana-plugin/blob/master/package.json, 
> from "0.0.5" to "1.0.1". 
> 2. Cherry pick to Ocata.
> 3. Then apply a new release tag for Ocata for 1.0.1 in, 
> https://review.openstack.org/#/c/433823/1/deliverables/ocata/monasca-kibana-plugin.yaml.
> 
> Does that sound correct?

The release in question was tagged 1.1.0 (see
https://review.openstack.org/#/c/457605/), so you'd want to make
it 1.1.1.  That release was part of Pike, not Ocata, so the package
file only needs to be fixed on master (at least for that release,
I don't know if there were other similar issues with ocata stable
releases).

In general you don't want the version numbers from one series to be part
of the other series, so I think you'll need to accept patches on your
stable branches to set the version without those being backports. This
is a reasonable exception to our stable policy because the changes are
packaging metadata and not production code.

Doug

> 
> Regards --Roland
> 
> On 4/20/17, 1:41 PM, "Doug Hellmann"  wrote:
> 
> >Excerpts from Doug Hellmann's message of 2017-04-20 15:26:47 -0400:
> >> The version of monasca-kibana-plugin in package.json does not match the
> >> new tag, and that caused the publish job to fail. I'm available to help
> >> debug or to quickly release an update after the problem is fixed.
> >
> >https://review.openstack.org/458629 should help us avoid this error in
> >the future.
> >
> >> 
> >> Doug
> >> 
> >> --- Begin forwarded message from jenkins ---
> >> From: jenkins 
> >> To: release-job-failures 
> >> Date: Wed, 19 Apr 2017 10:01:01 +
> >> Subject: [Release-job-failures] Release of openstack/monasca-kibana-plugin 
> >> failed
> >> 
> >> Build failed.
> >> 
> >> - monasca-kibana-plugin-nodejs4-npm-publish-tarball 
> >> http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8/release/monasca-kibana-plugin-nodejs4-npm-publish-tarball/4852b10/
> >>  : SUCCESS in 4m 48s
> >> - monasca-kibana-plugin-tarball-signing 
> >> http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8/release/monasca-kibana-plugin-tarball-signing/28e6145/
> >>  : SUCCESS in 10s
> >> - monasca-kibana-plugin-npm-upload 
> >> http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8/release/monasca-kibana-plugin-npm-upload/f3dd81a/
> >>  : FAILURE in 9s
> >> - monasca-kibana-plugin-announce-release 
> >> monasca-kibana-plugin-announce-release : SKIPPED
> >> 
> >> --- End forwarded message ---
> >> 
> >
> >__
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] [ptls] Project On-Boarding Rooms

2017-04-21 Thread Rob Cresswell (rcresswe)

Hi,

Could we take Horizon off the list? That’ll free up some time for other 
projects too.

Rob

On 28 Mar 2017, at 22:59, Kendall Nelson 
> wrote:

Done! Zaqar is on the list

- Kendall

On Tue, Mar 28, 2017 at 4:17 PM Fei Long Wang 
> wrote:
Hi Kendall,

Yep， if you can help reserve a lunch slot, it would be great. Thanks.

On 28/03/17 05:36, Kendall Nelson wrote:
Hello :)

At this point we have a full list, but if you are interested in a lunch slot I 
can put Zaqar down for one of those unless some other project is willing to 
share their space/time?

Thanks for the interest!

-Kendall Nelson(diablo_rojo)

On Tue, Mar 21, 2017 at 4:50 PM Fei Long Wang 
> wrote:

As far as I know, most of Zaqar team members won't be in Boston. But I will be 
there, so pls help put Zaqar on the list if there is one available. Thanks.

On 16/03/17 07:20, Kendall Nelson wrote:
Hello All!

As you may have seen in a previous thread [1] the Forum will offer project 
on-boarding rooms! This idea is that these rooms will provide a place for new 
contributors to a given project to find out more about the project, people, and 
code base. The slots will be spread out throughout the whole Summit and will be 
90 min long.

We have a very limited slots available for interested projects so it will be a 
first come first served process. Let me know if you are interested and I will 
reserve a slot for you if there are spots left.

- Kendall Nelson (diablo_rojo)

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-March/113459.html

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

--
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

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

--
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

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

2017-04-21 Thread Jeremy Stanley

On 2017-04-21 09:00:47 + (+), witold.be...@est.fujitsu.com wrote:
> one thing which hasn't been migrated are the blueprints. We have
> noticed this after the migration. Storyboard team has said they
> had not planned on migrating blueprints because most of the
> projects use the specs server.

An option here might be to amend the migration script to also
create new stories from open blueprints and add a story tag like
"blueprint" to them. Part of the reason StoryBoard wasn't designed
with a separate blueprint feature is that its story model is
intended to be flexible enough to handle a lot of the same sorts of
use cases for which blueprints were used (since unlike LP, you can
have multiple tasks in a story for the same project without having
to predefine a separate branch or series).

But as you noted, the migration script didn't originally consider
blueprints because there was a general trend within the community to
move away from LP blueprints in favor of repos under code review
where they could curate more detailed and structured specifications
instead... so we weren't sure if anyone would still be using
blueprints at all by the time we were ready to start on the majority
migration.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [cinder] About cinder-volume HA A/A

2017-04-21 Thread Gorka Eguileor

On 21/04, Jae Sang Lee wrote:
> Hello, cinder developers.
>
> What progress about cinder-volume HA A/A? In the release notes[1],
> cinder-volume HA A/A is still progress from Newton to Ocata and there is so
> many patches and progress on the feature page[2], but it doesn't look like
> up-to-date, It's difficult to understand the current situation.
>
> Is there any developer or know people about this feature? How's it going? I
> wait this feature from long ago and I want to help in any way.
>
> Thanks.
>
> [1] https://releases.openstack.org/teams/cinder.html
>
> [2] https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1583009

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

Hi,

The HA A/A work can be thought of as having 2 different parts, one is
the core functionality in Cinder and the other is the part relative to
the drivers.

The BP for the feature has been tracking the core functionality, which
can be considered as done, now we need to start working on the
individual drivers to ensure that they support HA A/A operations.

For this we are going to write a list of tests to help vendors determine
the readiness state of their drivers and a guide explaining the
different kind of locks that are available for them to use and what
mutual exclusion cases are already covered by the cinder core
functionality.

Regards,
Gorka.

__
OpenStack Development Mailing 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] [QA][Nova] Special scenario tests

2017-04-21 Thread Ferenc Horváth


Dear OpenStackerz,

I'd like to improve the coverage of the current test suite over some 
special code parts in Nova.
My main target is to add a few scenarios [1] that would exercise the 
AggregateMultiTenancyIsolation scheduler filter.
I'm also planning on adding new test cases for other filters and for 
some libvirt related features [2] as well.


Unfortunately, [1] and [2] could not be merged into Tempest for various 
reasons, hence I started working on functional tests in Nova.
However, since functional tests cannot be used to verify that a deployed 
system behaves correctly, we still need end to end tests.
Therefore, I'm proposing a new Tempest test plug-in [3,4] that would be 
the home of currently out of tree tests.
The idea is that these tests would run separately on a weekly basis to 
not use too much resources, but the rest of the questions are still open.


Therefore, I'd appreciate any advice or review on this topic.

Thank You all in advance.

Best regards,
Ferenc Horváth

[1] https://review.openstack.org/#/c/374887/
[2] https://review.openstack.org/#/c/315786/
[3] https://review.openstack.org/#/c/448482/
[4] https://review.openstack.org/#/c/451227/

__
OpenStack Development Mailing 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] Find core developers

2017-04-21 Thread Dariusz Śmigiel

Hey TanXin,
This information can be retrieved from gerrit.
You need to be signed in, to see this tab.
Select People -> List Groups [1] and there is a search box, where you
can try to find interesting project.
When you'll go into details, you can verify, who is assigned, and what
kind of projects are included.

[1] https://review.openstack.org/#/admin/groups/

Hope it helps,
Dariusz

2017-04-21 5:56 GMT-07:00 TanXin <746534...@qq.com>:
> Hi,
>
> I have a question and need your help. I want to find the core developers for 
> each sub-project. How do I do that?
>
> Thank you!
>
>
>
> TanXin
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack



-- 
dasm, Dariusz Śmigiel

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [Cinder][Nova] Scheduling issue for the Summit

2017-04-21 Thread Sean McGinnis

On Thu, Apr 20, 2017 at 06:55:30PM -0500, Jay S Bryant wrote:
> Sean,
> 
> In the case that all the conflicts cannot be resolved I would be happy to
> cover the Onboarding session if you can keep me in the loop/take items for
> the Cinder Ephemeral session.
> 
> Let me know,
> 
> Jay
> 

Thanks Jay, that could work out well if it's too difficult to move things
around. 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

[Openstack-operators] [deployment][forum][osa][kolla][tripleo][helm] proposing a session about future of configuration management - ops + devs wanted!

2017-04-21 Thread Emilien Macchi

The session will be on Monday and we now have an etherpad:
https://etherpad.openstack.org/p/BOS-forum-future-of-configuration-management
Please start feeding with thoughts and questions!

Again, if you're interested by future of configuration management in
OpenStack, you should really join the discussion.

2.50pm - Room 102

Target: Operators, Deployment tools (TripleO, Kolla, OSA, Helm, etc).


Thanks,

On Tue, Mar 21, 2017 at 6:23 PM, Emilien Macchi  wrote:
> OpenStack developers and operators who work on deployments: we need you.
>
> http://forumtopics.openstack.org/cfp/details/15
>
> Abstract: I would like to bring Developers and Operators in a room to
> discuss about future of Configuration Management in OpenStack.
>
> Until now, we haven't done a good job in collaborating on how we make
> configuration management in a consistent way across OpenStack
> Deployment Tools.
> Some efforts started to emerge in Pike:
> https://etherpad.openstack.org/p/deployment-pike
> And some projects like TripleO started some discussion on future of
> configuration management:
> https://etherpad.openstack.org/p/tripleo-etcd-transition
>
> In this discussion, we will discuss about our common challenges and
> take some actions from there, where projects could collaborate.
>
> Desired people:
> - Folks from Deployment Tools (TripleO, Kolla, OSA, Kubernetes, etc)
> - Operators who deploy OpenStack
>
> Moderator: me + any volunteer.
>
> Any question on this proposal is very welcome by using this thread.
>
> Thanks for reading so far and I'm looking forward to making progress
> on this topic in Boston.
> --
> Emilien Macchi



-- 
Emilien Macchi

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

[openstack-dev] [deployment][forum][osa][kolla][tripleo][helm] proposing a session about future of configuration management - ops + devs wanted!

2017-04-21 Thread Emilien Macchi

The session will be on Monday and we now have an etherpad:
https://etherpad.openstack.org/p/BOS-forum-future-of-configuration-management
Please start feeding with thoughts and questions!

Again, if you're interested by future of configuration management in
OpenStack, you should really join the discussion.

2.50pm - Room 102

Target: Operators, Deployment tools (TripleO, Kolla, OSA, Helm, etc).


Thanks,

On Tue, Mar 21, 2017 at 6:23 PM, Emilien Macchi  wrote:
> OpenStack developers and operators who work on deployments: we need you.
>
> http://forumtopics.openstack.org/cfp/details/15
>
> Abstract: I would like to bring Developers and Operators in a room to
> discuss about future of Configuration Management in OpenStack.
>
> Until now, we haven't done a good job in collaborating on how we make
> configuration management in a consistent way across OpenStack
> Deployment Tools.
> Some efforts started to emerge in Pike:
> https://etherpad.openstack.org/p/deployment-pike
> And some projects like TripleO started some discussion on future of
> configuration management:
> https://etherpad.openstack.org/p/tripleo-etcd-transition
>
> In this discussion, we will discuss about our common challenges and
> take some actions from there, where projects could collaborate.
>
> Desired people:
> - Folks from Deployment Tools (TripleO, Kolla, OSA, Kubernetes, etc)
> - Operators who deploy OpenStack
>
> Moderator: me + any volunteer.
>
> Any question on this proposal is very welcome by using this thread.
>
> Thanks for reading so far and I'm looking forward to making progress
> on this topic in Boston.
> --
> Emilien Macchi



-- 
Emilien Macchi

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

[Openstack] Find core developers

2017-04-21 Thread TanXin

Hi,

I have a question and need your help. I want to find the core developers for 
each sub-project. How do I do that?

Thank you!



TanXin
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] OpenStack "R" Release Naming Preliminary Results

2017-04-21 Thread Jay Pipes


On 04/21/2017 08:11 AM, Monty Taylor wrote:

5. Rock  loses to Radium by 841–464, loses to Razorback by 660–569


Actually, Rock lost to Paper, which lost to Scissors.

-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] OpenStack "R" Release Naming Preliminary Results


Hello all!

We left the voting open for an additional week because of how long it 
took to get emails sent out and the subsequent email issues. We'll be 
looking at options for next time to make that better.


The raw results are below - however...

**PLEASE REMEMBER** that these now have to go through legal vetting. So 
it is too soon to say "All Hail OpenStack Radium" - the last several 
naming polls have produced issues with the top choice. So as exciting as 
a potentially Radioactive OpenStack release might be, we might also get 
a release that's obsessed with Interop and Consistent Logging, or one 
married to my cousin. It's _possible_ we even make it down to having a 
release that plays on the American Football Team of the University of 
Arkansas. There are so many great possibilities!


In any case, the names have been sent off to legal for vetting. As soon 
as we have a final winner, I'll let you all know.


http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_e53f789ff7acc996

Result

1. Radium  (Condorcet winner: wins contests with all other choices)
2. Rocky  loses to Radium by 807–556
3. Rex  loses to Radium by 807–532, loses to Rocky by 638–615
4. Razorback  loses to Radium by 796–516, loses to Rex by 630–626
5. Rock  loses to Radium by 841–464, loses to Razorback by 660–569
6. Root  loses to Radium by 866–442, loses to Rock by 581–527
7. Raspberry  loses to Radium by 891–381, loses to Root by 579–536
8. Ray  loses to Radium by 906–355, loses to Raspberry by 553–539
9. Rambler  loses to Radium by 916–336, loses to Ray by 542–525
10. Railspur  loses to Radium by 904–316, loses to Rambler by 507–468
11. Rampart  loses to Radium by 926–301, loses to Railspur by 475–467
12. Richmond  loses to Radium by 929–306, loses to Rampart by 506–471
13. Rockies  loses to Radium by 926–293, loses to Richmond by 475–462
14. Rosswood  loses to Radium by 938–290, loses to Rockies by 463–449
15. Rebecca  loses to Radium by 911–350, loses to Rosswood by 484–481
16. Rupert  loses to Radium by 945–283, loses to Rebecca by 514–447
17. Revelstoke  loses to Radium by 949–269, loses to Rupert by 472–425
18. Robson  loses to Radium by 977–250, loses to Revelstoke by 439–423
19. Roderick  loses to Radium by 961–243, loses to Robson by 432–409
20. Rossland  loses to Radium by 966–241, loses to Roderick by 401–394
21. Rambles  loses to Radium by 977–222, loses to Rossland by 421–381
22. Raush  loses to Radium by 986–193, loses to Rambles by 405–379
23. Renfrew  loses to Radium by 976–213, loses to Raush by 377–363

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [nova] about usage of /consoles

2017-04-21 Thread Markus Zoeller

On 21.04.2017 12:12, Chen CH Ji wrote:
> 
> Per https://bugs.launchpad.net/nova/+bug/1682303 , POST with return 200
> while GET returns [] is weird
>  what's the purpose of /consoles? looks like
> https://github.com/openstack/nova/blob/master/nova/console/rpcapi.py#L72
> will send a rpc message and which service is the reciever of this message
> and handle it? Thanks
> 
> Best Regards!
> 
> Kevin (Chen) Ji 纪 晨

Looks like this API works for the "Xen VNC proxy" service only. The
console manager triggers the console creation here:
https://github.com/openstack/nova/blob/66c661258873e2544e286099c4bc027c26c851c4/nova/console/manager.py#L79

The XVPConsoleProxy implements it here:
https://github.com/openstack/nova/blob/46b3a3ca1ac3a5ffdc7c5420263223f2d3b9a660/nova/console/xvp.py#L56-L58

Looks like that service runs with default Devstack settings as service
"nova-xvpvncproxy":
https://github.com/openstack-dev/devstack/blob/f3b2f4c85307b14f115a020f5eaf6c92026b55b4/lib/nova#L892-L892

The API microversion 2.6 introduced a consolidation of the remote consoles:
https://github.com/openstack/nova/blob/3e032fd45be28c6098235ce336e675d03ebc6619/nova/api/openstack/compute/schemas/remote_consoles.py#L101-L102

Could it be that the "GET /console" API shouldn't be available anymore
since microversion 2.6?

api-ref about the consoles:
https://developer.openstack.org/api-ref/compute/?expanded=get-vnc-console-os-getvncconsole-action-deprecated-detail,create-remote-console-detail

-- 
Regards, Markus Zoeller (markus_z)


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

Re: [Openstack] Hello

2017-04-21 Thread Jay Pipes


On 04/21/2017 07:29 AM, TanXin wrote:

I want to know if I subscribe successfully.


yes.

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [nova] placement/resource providers update 20

2017-04-21 Thread Chris Dent

20th placement and resource providers update! As usual: If I've
forgotten something, please let me know, either in a response here
or find me in IRC (as cdent).

If you're going to be in Boston there are some placement related
sessions that may be worth your while:

* Scheduler Wars: A New Hope

https://www.openstack.org/summit/boston-2017/summit-schedule/events/17501/scheduler-wars-a-new-hope

* Behind the Scenes with Placement and Resource Tracking in Nova

https://www.openstack.org/summit/boston-2017/summit-schedule/events/17511/behind-the-scenes-with-placement-and-resource-tracking-in-nova

# What Matters Most

Still some remaining issues in the claims via the scheduler spec. We
keep encountering snags here and there which need to be addressed.
See below for links and more detail.

# What's Changed

We've made progress on one issue which was stalling the claims
scheduler, only to find some more. The docs are moving along well.
Plenty of code down in "Other Code/Specs" is active and in need of
review. The placement API can now run using uwsgi and systemd in
devstack.

# 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. He has a work in progress at:

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

that seeks input and assistance.

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

Work will be required at some point on filtering resource providers
based on traits, and adding traits to resource providers from the
resource tracker.

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

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

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/

There's also a spec in progress discussing ways to filter baremetal
nodes by tenant/project:

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

## 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 as we find edge cases that impact
how we're going to handle claims. One issue is how to deal with the
concept of instance overhead and where in the system this
information should be counted. There are a variety solutions, each
on a different place on the "works well enough" to "strictly
correct" spectrum.

Thinking about claims in the scheduler 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:master+topic:bp/nested-resource-providers

## Docs

https://review.openstack.org/#/q/topic:cd/placement-api-ref

Several reviews are in progress for documenting the placement API.
This is likely going to take quite a few iterations as we work out
the patterns and tooling. But it's great to see the progress and
when looking at the draft rendered docs it makes placement feel like
a real thing™.

We need multiple reviewers on this stuff, early in the process, as
it helps to identify missteps in the phrasing and styling before we
develop bad habits.

Find me (cdent) or Andrey (avolkov) if you want to help out or have
other questions.

## Performance

We're aware that there are some redundancies in the resource tracker
that we'd like to clean up

http://lists.openstack.org/pipermail/openstack-dev/2017-January/110953.html

but it's also the case that we've

Re: [Openstack] Hello

2017-04-21 Thread Neetish Bhat

Yes Welcome Abroad TanXin

On Fri, Apr 21, 2017 at 4:59 PM, TanXin <746534...@qq.com> wrote:

> I want to know if I subscribe successfully.
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>



-- 
*Regards Neetish *
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [all][ptls][tc] help needed filling out project-navigator data

On 04/20/2017 05:03 AM, Andrey Kurilin wrote:

Hi folks!

Does it possible to store history of the project without alignment to
OpenStack releases?

Not at the moment - the view is based on OpenStack releases.

That said - it's a git repo, there's no reason we couldn't store some
additional info that the navigator doesn't (yet) need. ... Could you
describe a little more what you want to additionally store? Maybe we can
come up with something for it...

2017-04-19 17:54 GMT+03:00 Jimmy McArthur >:

Ideally, as far back as your project goes. That way we will have a
complete API history, per release, on the project navigator. This
also helps us determine the project age.

Thanks!
Jimmy

Telles Nobrega
April 19, 2017 at 9:48 AM
Hi Monty,

quick question, how far into past releases should we go?

Thanks,

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat I

tenob...@redhat.com

TRIED. TESTED. TRUSTED.

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

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

Monty Taylor
April 18, 2017 at 3:03 PM
Hey everybody!

The Foundation is rolling out a new version of the Project
Navigator. One of the things it contains is a section that shows
API versions available for each project for each release. They
asked the TC's help in providing that data, so we spun up a new
repository:

http://git.openstack.org/cgit/openstack/project-navigator-data

that the Project Navigator will consume.

We need your help!

The repo contains a file for each project for each release with
CURRENT/SUPPORTED/DEPRECATED major versions and also microversion
ranges if they exist. The data is pretty much exactly what
everyone already produces in their version discovery documents -
although it's normalized into the format described by the API-WG:

https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html#version-discovery

What would be really helpful is if someone from each project could
go make a patch to the repo adding the historical (and currently)
info for your project. We'll come up with a process for
maintaining it over time - but for now just crowdsourcing the data
seems like the best way.

The README file explains the format, and there is data from a few
of the projects for Newton.

It would be great to include an entry for every release - which
for many projects will just be the same content copied a bunch of
times back to the first release the project was part of OpenStack.

This is only needed for service projects (something that registers
in the keystone catalog) and is only needed for 'main' APIs (like,
it is not needed, for now, to put in things like Placement)

If y'all could help - it would be super great!

Thanks!
Monty

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

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

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

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

--
Best regards,
Andrey Kurilin.

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

Re: [Openstack] Hello

welcome aboard

On Fri, Apr 21, 2017 at 6:29 PM, TanXin <746534...@qq.com> wrote:

> I want to know if I subscribe successfully.
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>



-- 
Cheers,



[image: --]
Adhi Priharmanto
[image: http://]about.me/a_dhi

+62-812-82121584
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [Blazar] Meeting time slots in Boston

2017-04-21 Thread Jay Pipes


On 04/21/2017 12:41 AM, Masahito MUROI wrote:

Hi all,

Thanks for choosing time slots!  Based on the table of Doodle, I'd like
to pick following two slots for Blazar team meeting.

1. 1pm-4pm on Monday for Blazar's internal features
2. 9am-10am or 11am on Thursday for discussions with PlacementAPI team

The first meeting will focus on Blazar's internal features, roadmap and
etc.  1pm-2pm is also Lunch time. So it could start as lunch meeting.

In the second slot, we plan to discuss with PlacementAPI team. Summit
would have breakout rooms or tables as usual.  We'll gather one of these
and discuss concerns and/or usecases of collaboration with PlacementAPI.


Thanks for setting that up, Masahito! Much appreciated :)

See you in Boston!

-jay


best regards,
Masahito


On 2017/04/18 13:21, Masahito MUROI wrote:

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





__
OpenStack Development Mailing 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 "R" Release Naming Preliminary Results


Hello all!

We left the voting open for an additional week because of how long it 
took to get emails sent out and the subsequent email issues. We'll be 
looking at options for next time to make that better.


The raw results are below - however...

**PLEASE REMEMBER** that these now have to go through legal vetting. So 
it is too soon to say "All Hail OpenStack Radium" - the last several 
naming polls have produced issues with the top choice. So as exciting as 
a potentially Radioactive OpenStack release might be, we might also get 
a release that's obsessed with Interop and Consistent Logging, or one 
married to my cousin. It's _possible_ we even make it down to having a 
release that plays on the American Football Team of the University of 
Arkansas. There are so many great possibilities!


In any case, the names have been sent off to legal for vetting. As soon 
as we have a final winner, I'll let you all know.


http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_e53f789ff7acc996

Result

1. Radium  (Condorcet winner: wins contests with all other choices)
2. Rocky  loses to Radium by 807–556
3. Rex  loses to Radium by 807–532, loses to Rocky by 638–615
4. Razorback  loses to Radium by 796–516, loses to Rex by 630–626
5. Rock  loses to Radium by 841–464, loses to Razorback by 660–569
6. Root  loses to Radium by 866–442, loses to Rock by 581–527
7. Raspberry  loses to Radium by 891–381, loses to Root by 579–536
8. Ray  loses to Radium by 906–355, loses to Raspberry by 553–539
9. Rambler  loses to Radium by 916–336, loses to Ray by 542–525
10. Railspur  loses to Radium by 904–316, loses to Rambler by 507–468
11. Rampart  loses to Radium by 926–301, loses to Railspur by 475–467
12. Richmond  loses to Radium by 929–306, loses to Rampart by 506–471
13. Rockies  loses to Radium by 926–293, loses to Richmond by 475–462
14. Rosswood  loses to Radium by 938–290, loses to Rockies by 463–449
15. Rebecca  loses to Radium by 911–350, loses to Rosswood by 484–481
16. Rupert  loses to Radium by 945–283, loses to Rebecca by 514–447
17. Revelstoke  loses to Radium by 949–269, loses to Rupert by 472–425
18. Robson  loses to Radium by 977–250, loses to Revelstoke by 439–423
19. Roderick  loses to Radium by 961–243, loses to Robson by 432–409
20. Rossland  loses to Radium by 966–241, loses to Roderick by 401–394
21. Rambles  loses to Radium by 977–222, loses to Rossland by 421–381
22. Raush  loses to Radium by 986–193, loses to Rambles by 405–379
23. Renfrew  loses to Radium by 976–213, loses to Raush by 377–363

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

2017-04-21 Thread TanXin

I want to know if I subscribe successfully.

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [ironic] ipmitool

2017-04-21 Thread Vladyslav Drok

Hi Yuriy,

On Fri, Apr 21, 2017 at 12:59 PM, Yuriy Zveryanskyy <
yzveryans...@mirantis.com> wrote:

> Hi.
>
> After "ipminative" driver has been removed (I think it was right
> decision), we support IPMI in ironic only via drivers which use
> "ipmitool" utility.
> This utility is mostly good, but main problem is that running by
> ironic subprocess can be stalled on buggy/broken BMCs.
>

Here is one example of such issue -
https://bugs.launchpad.net/ironic/+bug/1683902, and a bit of comments about
the root cause in the eavesdrop

.


> This causes situations like stop executing of sync power state
> periodic task without any logging, reduce free green threads
> number in the conductor service pool etc.
> Administrators often have only one version of ipmitool in
> repository and should build new version from source for
> bug fixing.
> We can implement custom executor for ipmitool with timeout
> for process, but this adds more complexity to IPMI drivers,
> or maybe use another solution? Maybe we should have pure
> Python well tested IPMI library optimized for ironic (like sushy
> for RedFish)?
>

Or maybe work on improving pyghmi, and reintroduce the ipminative driver.


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

[openstack-dev] [nova] about usage of /consoles

2017-04-21 Thread Chen CH Ji


Per https://bugs.launchpad.net/nova/+bug/1682303 , POST with return 200
while GET returns [] is weird
 what's the purpose of /consoles? looks like
https://github.com/openstack/nova/blob/master/nova/console/rpcapi.py#L72
will send a rpc message and which service is the reciever of this message
and handle it? Thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] ipmitool

2017-04-21 Thread Yuriy Zveryanskyy

Hi.

After "ipminative" driver has been removed (I think it was right
decision), we support IPMI in ironic only via drivers which use
"ipmitool" utility.
This utility is mostly good, but main problem is that running by
ironic subprocess can be stalled on buggy/broken BMCs.
This causes situations like stop executing of sync power state
periodic task without any logging, reduce free green threads
number in the conductor service pool etc.
Administrators often have only one version of ipmitool in
repository and should build new version from source for
bug fixing.
We can implement custom executor for ipmitool with timeout
for process, but this adds more complexity to IPMI drivers,
or maybe use another solution? Maybe we should have pure
Python well tested IPMI library optimized for ironic (like sushy
for RedFish)?

Yuriy Zveryanskyy

__
OpenStack Development Mailing 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] [release][monasca] Release of openstack/monasca-kibana-plugin failed

2017-04-21 Thread witold.be...@est.fujitsu.com

Hi,

I'm sorry, I missed that.

I've created the updates:

https://review.openstack.org/458773
https://review.openstack.org/458776


Cheers
Witek




> -Original Message-
> From: Hochmuth, Roland M [mailto:roland.hochm...@hpe.com]
> Sent: Freitag, 21. April 2017 06:19
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [release][monasca] Release of
> openstack/monasca-kibana-plugin failed
> 
> Thanks Doug. My understanding of the issue is that we need to
> 
> 1. Update the version in package.json,
> https://github.com/openstack/monasca-kibana-
> plugin/blob/master/package.json, from "0.0.5" to "1.0.1".
> 2. Cherry pick to Ocata.
> 3. Then apply a new release tag for Ocata for 1.0.1 in,
> https://review.openstack.org/#/c/433823/1/deliverables/ocata/monasca-
> kibana-plugin.yaml.
> 
> Does that sound correct?
> 
> Regards --Roland
> 
> 
> 
> 
> 
> On 4/20/17, 1:41 PM, "Doug Hellmann"  wrote:
> 
> >Excerpts from Doug Hellmann's message of 2017-04-20 15:26:47 -0400:
> >> The version of monasca-kibana-plugin in package.json does not match
> >> the new tag, and that caused the publish job to fail. I'm available
> >> to help debug or to quickly release an update after the problem is fixed.
> >
> >https://review.openstack.org/458629 should help us avoid this error in
> >the future.
> >
> >>
> >> Doug
> >>
> >> --- Begin forwarded message from jenkins ---
> >> From: jenkins 
> >> To: release-job-failures 
> >> Date: Wed, 19 Apr 2017 10:01:01 +
> >> Subject: [Release-job-failures] Release of
> >> openstack/monasca-kibana-plugin failed
> >>
> >> Build failed.
> >>
> >> - monasca-kibana-plugin-nodejs4-npm-publish-tarball
> >>
> http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8
> >> /release/monasca-kibana-plugin-nodejs4-npm-publish-tarball/4852b10/ :
> >> SUCCESS in 4m 48s
> >> - monasca-kibana-plugin-tarball-signing
> >>
> http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8
> >> /release/monasca-kibana-plugin-tarball-signing/28e6145/ : SUCCESS in
> >> 10s
> >> - monasca-kibana-plugin-npm-upload
> >>
> http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8
> >> /release/monasca-kibana-plugin-npm-upload/f3dd81a/ : FAILURE in 9s
> >> - monasca-kibana-plugin-announce-release
> >> monasca-kibana-plugin-announce-release : SKIPPED
> >>
> >> --- End forwarded message ---
> >>
> >
> >_
> __
> >___ OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> >openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> 
> OpenStack Development Mailing 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] Limit Summary not update

Hi, Bartłomiej Solarz-Niesłuchowski


Thanks for suggestion, it works, does it any fixed setting in nova.conf may
be to set the automatic quota update ?

I'm still test your script in admin project, and it works, does it works to
reset other project(tenant) too ?

On Fri, Apr 21, 2017 at 3:00 PM, Bartłomiej Solarz-Niesłuchowski <
bartlomiej.solarz-niesluchow...@wit.edu.pl> wrote:

> W dniu 2017-04-21 o 09:33, Adhi Priharmanto pisze:
>
>
> Hi All,
>
> I'm in ocata release, had 2 running instance
> (openstack) server list
> +--+++--
> -++
> | ID   | Name   | Status |
> Networks  | Image Name |
> +--+++--
> -++
> | 94d63b55-1dd8-4e9e-a471-58c14defccd1 | test13 | ACTIVE |
> public119=119.x.x.x | Cirros-3-5-xen |
> | 40d68c6e-6678-4a64-9309-2302a201bc09 | test11 | ACTIVE |
> admin-int=15.15.1.13  | Cirros-3-5-xen |
> +--+++--
> -++
>
> but why when I open in the horizon at "Project / Compute / Overview" page
> it's show
>
> *"Instances Used 3 of 10" *
> and when I check from usage list it show 4 instance used ?
> (openstack) usage list
> Usage from 2017-03-24 to 2017-04-22:
> +-+-+--+---+---+
> | Project | Servers | RAM MB-Hours | CPU Hours | Disk GB-Hours |
> +-+-+--+---+---+
> | admin   |   4 | 52560.71 |102.66 |102.66 |
> +-+-+--+---+---+
>
> even I deleted all instance, the value in  "Project / Compute / Overview"
> page horizon won't be refresh/update.
>
> any suggestion for this case ?
>
> http://www.deadunicornz.org/blog/2015/02/13/openstack-
> icehouse-reset-incorrect-quota-count-for-nova
>
>
>
> --
> Bartłomiej Solarz-Niesłuchowski, Administrator WSISiZ
> e-mail: bartlomiej.solarz-niesluchow...@wit.edu.pl
> tel. 223486547, fax 223486501
> JID: sol...@jabber.wit.edu.pl
> 01-447 Warszawa, ul. Newelska 6, pokój 404, pon.-pt. 8-16
> Motto - Jak sobie pościelisz tak sie wyśpisz
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>


-- 
Cheers,



[image: --]
Adhi Priharmanto
[image: http://]about.me/a_dhi

+62-812-82121584
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [monasca][swift][storyboard] migration experience

2017-04-21 Thread witold.be...@est.fujitsu.com

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


Hi John,

one thing which hasn't been migrated are the blueprints. We have noticed this 
after the migration. Storyboard team has said they had not planned on migrating 
blueprints because most of the projects use the specs server.


Cheers
Witek
__
OpenStack Development Mailing 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] Limit Summary not update

2017-04-21 Thread Warad, Manjunath (Nokia - SG/Singapore)

hi, Warad, Manjunath

I think it's happen when failed instance build reached. Deleting failed
instance wasn't update the quota count.

On Fri, Apr 21, 2017 at 2:58 PM, Warad, Manjunath (Nokia - SG/Singapore) <
manjunath.wa...@nokia.com> wrote:

> Are all the project / tenant same in these cases?
>
>
>
> *From:* Adhi Priharmanto [mailto:adhi@gmail.com]
> *Sent:* Friday, 21 April, 2017 3:33 PM
> *To:* openstack 
> *Subject:* [Openstack] Limit Summary not update
>
>
>
>
> Hi All,
>
> I'm in ocata release, had 2 running instance
>
> (openstack) server list
> +--+++--
> -++
> | ID   | Name   | Status |
> Networks  | Image Name |
> +--+++--
> -++
> | 94d63b55-1dd8-4e9e-a471-58c14defccd1 | test13 | ACTIVE |
> public119=119.x.x.x | Cirros-3-5-xen |
> | 40d68c6e-6678-4a64-9309-2302a201bc09 | test11 | ACTIVE |
> admin-int=15.15.1.13  | Cirros-3-5-xen |
> +--+++--
> -++
>
>
>
> but why when I open in the horizon at "Project / Compute / Overview" page
> it's show *"Instances Used 3 of 10"*
>
> and when I check from usage list it show 4 instance used ?
>
> (openstack) usage list
> Usage from 2017-03-24 to 2017-04-22:
> +-+-+--+---+---+
> | Project | Servers | RAM MB-Hours | CPU Hours | Disk GB-Hours |
> +-+-+--+---+---+
> | admin   |   4 | 52560.71 |102.66 |102.66 |
> +-+-+--+---+---+
>
>
>
> even I deleted all instance, the value in  "Project / Compute / Overview"
> page horizon won't be refresh/update.
>
> any suggestion for this case ?
>
>
>
>
> --
>
> Cheers,
>
>
>
> *Error! Filename not specified.*
>
> *Adhi Priharmanto*
>
> *Error! Filename not specified.*about.me/a_dhi
>
> [image: Image removed by sender.]
>
>
>
> +62-812-82121584 <+62%20812-8212-1584>
>
>
>



-- 
Cheers,



[image: --]
Adhi Priharmanto
[image: http://]about.me/a_dhi

+62-812-82121584
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [oslo] Can we stop global requirements update?

2017-04-21 Thread ChangBo Guo

2017-04-19 23:10 GMT+08:00 Clark Boylan :

> On Wed, Apr 19, 2017, at 05:54 AM, Julien Danjou wrote:
> > Hoy,
> >
> > So Gnocchi gate is all broken (agan) because it depends on "pbr" and
> > some new release of oslo.* depends on pbr!=2.1.0.
> >
> > Neither Gnocchi nor Oslo cares about whatever bug there is in pbr 2.1.0
> > that got in banished by requirements Gods. It does not prevent it to be
> > used e.g. to install the software or get version information. But it
> > does break anything that is not in OpenStack because well, pip installs
> > the latest pbr (2.1.0) and then oslo.* is unhappy about it.
>
> It actually breaks everything, including OpenStack. Shade and others are
> affected by this as well. The specific problem here is that PBR is a
> setup_requires which means it gets installed by easy_install before
> anything else. This means that the requirements restrictions are not
> applied to it (neither are the constraints). So you get latest PBR from
> easy_install then later when something checks the requirements
> (pkg_resources console script entrypoints?) they break because latest
> PBR isn't allowed.
>
>   What we disscuss here is the way to avoid break things,  not sure  we
 add pbr into  periodic-**-with-oslo-master works in
https://review.openstack.org/458753

We need to stop pinning PBR and more generally stop pinning any
> setup_requires (there are a few more now since setuptools itself is
> starting to use that to list its deps rather than bundling them).
>
> > So I understand the culprit is probably pip installation scheme, and we
> > can blame him until we fix it. I'm also trying to push pbr 2.2.0 to
> > avoid the entire issue.
>
> Yes, a new release of PBR undoing the "pin" is the current sane step
> forward for fixing this particular issue. Monty also suggested that we
> gate global requirements changes on requiring changes not pin any
> setup_requires.
>
> > But for the future, could we stop updating the requirements in oslo libs
> > for no good reason? just because some random OpenStack project hit a bug
> > somewhere?
> >
> > For example, I've removed requirements update on tooz¹ for more than a
> > year now, which did not break *anything* in the meantime, proving that
> > this process is giving more problem than solutions. Oslo libs doing that
> > automatic update introduce more pain for all consumers than anything (at
> > least not in OpenStack).
>
> You are likely largely shielded by the constraints list here which is
> derivative of the global requirements list. Basically by using
> constraints you get distilled global requirements and even without being
> part of the requirements updates you'd be shielded from breakages when
> installed via something like devstack or other deployment method using
> constraints.
>
> > So if we care about Oslo users outside OpenStack, I beg us to stop this
> > crazyness. If we don't, we'll just spend time getting rid of Oslo over
> > the long term…
>
> I think we know from experience that just stopping (eg reverting to the
> situation we had before requirements and constraints) would lead to
> sadness. Installations would frequently be impossible due to some
> unresolvable error in dependency resolution. Do you have some
> alternative in mind? Perhaps we loosen the in project requirements and
> explicitly state that constraints are known to work due to testing and
> users should use constraints? That would give users control to manage
> their own constraints list too if they wish. Maybe we do this in
> libraries while continuing to be more specific in applications?
>
> >
> > My 2c,
> >
> > Cheers,
> >
> > ¹ Unless some API changed in a dep and we needed to raise the dep,
> > obviously.
> >
> > --
> > Julien Danjou
> > # Free Software hacker
> > # https://julien.danjou.info
>
> I don't have all the answers, but am fairly certain the situation we
> have today is better than the one from several years ago. It is just not
> perfect. I think we are better served by refining the current setup or
> replacing it with something better but not by reverting.
>
> 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
>



-- 
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] Limit Summary not update

2017-04-21 Thread Bartłomiej Solarz-Niesłuchowski


W dniu 2017-04-21 o 09:33, Adhi Priharmanto pisze:


Hi All,

I'm in ocata release, had 2 running instance
(openstack) server list
+--+++---++
| ID   | Name   | Status | 
Networks  | Image Name |

+--+++---++
| 94d63b55-1dd8-4e9e-a471-58c14defccd1 | test13 | ACTIVE | 
public119=119.x.x.x | Cirros-3-5-xen |
| 40d68c6e-6678-4a64-9309-2302a201bc09 | test11 | ACTIVE | 
admin-int=15.15.1.13  | Cirros-3-5-xen |

+--+++---++

but why when I open in the horizon at "Project / Compute / Overview" 
page it's show *"Instances Used 3 of10"


*
and when I check from usage list it show 4 instance used ?
(openstack) usage list
Usage from 2017-03-24 to 2017-04-22:
+-+-+--+---+---+
| Project | Servers | RAM MB-Hours | CPU Hours | Disk GB-Hours |
+-+-+--+---+---+
| admin   |   4 | 52560.71 |102.66 | 102.66 |
+-+-+--+---+---+

even I deleted all instance, the value in "Project / Compute / 
Overview" page horizon won't be refresh/update.


any suggestion for this case ?
http://www.deadunicornz.org/blog/2015/02/13/openstack-icehouse-reset-incorrect-quota-count-for-nova 




--
Bartłomiej Solarz-Niesłuchowski, Administrator WSISiZ
e-mail: bartlomiej.solarz-niesluchow...@wit.edu.pl
tel. 223486547, fax 223486501
JID: sol...@jabber.wit.edu.pl
01-447 Warszawa, ul. Newelska 6, pokój 404, pon.-pt. 8-16
Motto - Jak sobie pościelisz tak sie wyśpisz



smime.p7s
Description: Kryptograficzna sygnatura S/MIME
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [vitrage] about "is_admin" in ctx

2017-04-21 Thread dong.wenjuan

Hi all,

I'm a little confused about the "is_amdin" in ctx. 


From the 
hook(https://github.com/openstack/vitrage/blob/master/vitrage/api/hooks.py#L73),
 "is_admin" means admin user,.

But we define the macro as "admin project"( 
https://github.com/openstack/vitrage/blob/master/vitrage/api_handler/apis/base.py#L94
 ). 
But in my opinion,  it should be the admin role. Correct me if i'm wrong :).




BR,

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

Re: [openstack-dev] [oslo] do we still need non-voting tests for older releases?

2017-04-21 Thread ChangBo Guo

What the related thing I can remember is we discuss oslo libraries'
compatibility in [1], which was abandoned.
I made stable compat ocata jobs non-voting in [2], hope can revert when
related bug is fixed before.
But now, If we decide remove them, we don't revert anymore.

[1]  https://review.openstack.org/226157
[2]  https://review.openstack.org/#/c/448431

2017-04-20 0:42 GMT+08:00 Doug Hellmann :

> I noticed again today that we have some test jobs running for some
> of the Oslo libraries against old versions of services (e.g.,
> gate-tempest-dsvm-neutron-src-oslo.log-ubuntu-xenial-newton,
> gate-tempest-dsvm-neutron-src-oslo.log-ubuntu-xenial-ocata, and
> gate-oslo.log-src-grenade-dsvm-ubuntu-xenial-nv).
>
> I don't remember what those are for, but I imagine they have to do
> with testing compatibility. They're all non-voting, though, so maybe
> not?
>
> Now that we're constraining libraries in our test systems, I wonder
> if we still need the jobs at all?
>
> 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
>



-- 
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] Limit Summary not update

Are all the project / tenant same in these cases?

From: Adhi Priharmanto [mailto:adhi@gmail.com]
Sent: Friday, 21 April, 2017 3:33 PM
To: openstack 
Subject: [Openstack] Limit Summary not update


Hi All,
I'm in ocata release, had 2 running instance
(openstack) server list
+--+++---++
| ID   | Name   | Status | Networks 
 | Image Name |
+--+++---++
| 94d63b55-1dd8-4e9e-a471-58c14defccd1 | test13 | ACTIVE | public119=119.x.x.x 
| Cirros-3-5-xen |
| 40d68c6e-6678-4a64-9309-2302a201bc09 | test11 | ACTIVE | admin-int=15.15.1.13 
 | Cirros-3-5-xen |
+--+++---++

but why when I open in the horizon at "Project / Compute / Overview" page it's 
show "Instances Used 3 of 10"
and when I check from usage list it show 4 instance used ?
(openstack) usage list
Usage from 2017-03-24 to 2017-04-22:
+-+-+--+---+---+
| Project | Servers | RAM MB-Hours | CPU Hours | Disk GB-Hours |
+-+-+--+---+---+
| admin   |   4 | 52560.71 |102.66 |102.66 |
+-+-+--+---+---+

even I deleted all instance, the value in  "Project / Compute / Overview" page 
horizon won't be refresh/update.
any suggestion for this case ?


--
Cheers,


Error! Filename not specified.
Adhi Priharmanto
Error! Filename not specified.about.me/a_dhi






+62-812-82121584

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [cinder] About cinder-volume HA A/A

2017-04-21 Thread Jae Sang Lee

Hello, cinder developers.

What progress about cinder-volume HA A/A? In the release notes[1],
cinder-volume HA A/A is still progress from Newton to Ocata and there is so
many patches and progress on the feature page[2], but it doesn't look like
up-to-date, It's difficult to understand the current situation.

Is there any developer or know people about this feature? How's it going? I
wait this feature from long ago and I want to help in any way.

Thanks.

[1] https://releases.openstack.org/teams/cinder.html

[2] https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1583009
__
OpenStack Development Mailing 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] Limit Summary not update