Re: [openstack-dev] [keystone] rc2 updates

[Lance Bragstad]

I pushed a new revision of the initial patch [0] and the one proposed to
stable/pike [1] to fix a minor unit test failure. Prior to this patch, I
was able to recreate the issue documented in bug 1702211 [2] after about
70 - 80 consecutive runs. After applying Morgan's patch to a local
devstack install, I hit the failure on test run #213 [3]. I need to
review the fix a bit more, but it appears to mitigates some of the issue
(or at least make it happen less).


[0] https://review.openstack.org/#/c/493259/
[1] https://review.openstack.org/#/c/493260/
[2] https://bugs.launchpad.net/keystone/+bug/1702211
[3] fail tempest run --regex
tempest.api.identity.admin.v3.test_users.UsersV3TestJSON.test_password_history_not_enforced_in_admin_reset

On 08/11/2017 06:26 PM, Morgan Fainberg wrote:
> On Fri, Aug 11, 2017 at 11:10 AM, Lance Bragstad  wrote:
>> Thanks for the update.
>>
>> Outside of the docs patches, we made some good progress on a bug 1702211
>> (reported as https://bugs.launchpad.net/keystone/+bug/1703917 and
>> https://bugs.launchpad.net/keystone/+bug/1702211 but we have reason to
>> believe they are caused by the same issue).
>>
>> Morgan is currently working on a fix and we've targeted bug 1702211 to rc2.
>> I'll keep an eye out for the translations patch and make sure that lands
>> before we cut the next release candidate.
>>
>> On 08/11/2017 12:02 PM, Thierry Carrez wrote:
>>
>> Lance Bragstad wrote:
>>
>> We rolled out rc1 last night [0], but missed a couple important
>> documentation patches and release notes [1]. I'll propose rc2 as soon as
>> those merge.
>>
>> Note that we'll have to refresh the RC with translations updates closer
>> to the release anyway (start of R-1 week), so if it's just
>> doc/releasenotes updates, I'd advise you to wait a bit before cutting RC2.
>>
>> Regards,
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> Initial patch for the password created_at/expires_at change is here:
> https://review.openstack.org/493259 now waiting for review. It has
> been cherry-picked to stable/pike as well. This likely will need a
> couple more passes. Due to the complexity it only addresses the
> password created_at/expires_at columns. I will look into other cases
> of keystone storing datetime objects as a possible RC bug (in revoke
> events specifically) once I get a little time to see how this change
> works as is.
>
> --Morgan
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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

Re: [openstack-dev] [Tripleo] FFE to add Dell EMC Cinder and Manila Drivers to Triple-o

[Emilien Macchi]

On Thu, Aug 10, 2017 at 10:30 AM,   wrote:
> I would like to request a feature freeze exception to Dell EMC storage
> products support for  Triple-o. This work is done and pending verification
> Jenkins, there seems to be some gate issues that is delaying the process.
> The puppet-cinder and puppet-manila work is already merged.
>
>
>
> Pending reviews
>
>
>
> Isilon Driver
>
> https://review.openstack.org/49
>
> https://review.openstack.org/488896
>
>
>
> Unity Cinder and Manila Driver
>
> https://review.openstack.org/487599
>
> https://review.openstack.org/490581
>
> https://review.openstack.org/491078
>
>
>
> VMAX Cinder and Manila Driver
>
> https://review.openstack.org/489393
>
> https://review.openstack.org/489624
>
> https://review.openstack.org/490949
>
> https://review.openstack.org/491094
>
>
>
> VNX Driver
>
> https://review.openstack.org/490642
>
> https://review.openstack.org/491088
>

I'm usually very supportive when supporting new drivers in TripleO.
I've looked at the patches and AFIK they shouldn't break anything
critical for us.

I'll let reviewers correct me if I'm wrong but consider the FFE
granted unless we find something that we consider too late to change
at this time.

Also, I hope we can make a better job in pushing features earlier in
the cycle, but I understand everyone's busy ;-)
-- 
Emilien Macchi

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

Re: [openstack-dev] [kolla-kubernetes] Proposing Rich Wellum to core team

[Vikram Hosakote (vhosakot)]

Rich? Well, um ;)

Although I’m not a kolla-kubernetes core and my vote does not matter at all, 
I’ll still give
my +1 to Rich ☺.

Amazing work in kolla-kubernetes Rich especially your recent contribution of 
the Python
tool to automate the deployment of kolla-kubernetes.

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

Regards,
Vikram Hosakote
IRC: vhosakot

From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, August 11, 2017 at 12:01 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [kolla-kubernetes] Proposing Rich Wellum to core team

Hello,

It's my pleasure to start another core team vote. This time for our
colleague rwellum. I propose that he joins kolla-kubernetes team.

This is my +1 vote. Every kolla-kubernetes core has a vote and it can
be veto'ed.

Voting will last 2 weeks and will end at 25th of August.

Cheers,
Michal

__
OpenStack Development Mailing 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][placement] self links include /placement?

[Eric Fried]

I finally got around to fiddling with the placement API today, and
noticed something... disturbing.  To me, anyway.

When I GET a URI, such as '/resource_classes', the response includes e.g.

  {u'links': [{u'href': u'/placement/resource_classes/MEMORY_MB',
 u'rel': u'self'}],
   u'name': u'MEMORY_MB'},

If I try to GET that 'self' link, it fails (404).  I have to strip the
'/placement' prefix to make it work.

That doesn't seem right.  Can anyone comment?

(This is devstack, nova master with
https://review.openstack.org/#/c/492247/5 loaded up.)

Thanks,
efried
.

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

Re: [openstack-dev] [keystone] rc2 updates

[Morgan Fainberg]

On Fri, Aug 11, 2017 at 11:10 AM, Lance Bragstad  wrote:
> Thanks for the update.
>
> Outside of the docs patches, we made some good progress on a bug 1702211
> (reported as https://bugs.launchpad.net/keystone/+bug/1703917 and
> https://bugs.launchpad.net/keystone/+bug/1702211 but we have reason to
> believe they are caused by the same issue).
>
> Morgan is currently working on a fix and we've targeted bug 1702211 to rc2.
> I'll keep an eye out for the translations patch and make sure that lands
> before we cut the next release candidate.
>
> On 08/11/2017 12:02 PM, Thierry Carrez wrote:
>
> Lance Bragstad wrote:
>
> We rolled out rc1 last night [0], but missed a couple important
> documentation patches and release notes [1]. I'll propose rc2 as soon as
> those merge.
>
> Note that we'll have to refresh the RC with translations updates closer
> to the release anyway (start of R-1 week), so if it's just
> doc/releasenotes updates, I'd advise you to wait a bit before cutting RC2.
>
> Regards,
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Initial patch for the password created_at/expires_at change is here:
https://review.openstack.org/493259 now waiting for review. It has
been cherry-picked to stable/pike as well. This likely will need a
couple more passes. Due to the complexity it only addresses the
password created_at/expires_at columns. I will look into other cases
of keystone storing datetime objects as a possible RC bug (in revoke
events specifically) once I get a little time to see how this change
works as is.

--Morgan

__
OpenStack Development Mailing 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] [requirements][ptls] HELP! Thawing the requirements repo

[Tony Breeds]

Hi All,
The requirements repo is now branched.  If your project does NOT
have a stable/pike branch please review any bot generated changes *very*
carefully until you do have a stable/pike branch.

If you're not sure ask in #openstack-requirements for a team member to
do a quick review.

Yours Tony.


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

Re: [openstack-dev] [requirements][masakari] FFE for adding python-masakariclient in global-requirements

[Tony Breeds]

On Fri, Aug 11, 2017 at 12:23:12AM -0500, Sam P wrote:
> Hi Tony,
> 
> Correction:
> >> You can take that or:
> >> https://review.openstack.org/#/c/457491/
> > Thanks for the update and I will try to merge #/c/457491 asap.
> > Otherwise I will resolve the merge conflicts.
> I did not realize that you add [1] depends on [2]. I will wait for [2]
> to get merged.

Okay that's all done.  Please:
- Abandon: https://review.openstack.org/457491
- Merge  : https://review.openstack.org/492965

Then you're good to go :)

Yours Tony.


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

[openstack-dev] [manila] manila 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for manila for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/manila/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/manila/log/?h=stable/pike

Release notes for manila can be found at:

http://docs.openstack.org/releasenotes/manila/




__
OpenStack Development Mailing 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] Things for next week (8/14-8/18)

[Matt Riedemann]

Several cores are on vacation (myself, sdague, bauzas, stephenfin).

RC1 is cut, and we know we have some things for RC2. Those are tracked 
at the top of the etherpad here:


https://etherpad.openstack.org/p/nova-pike-release-candidate-todo

dansmith is the only person on the release team that is going to be 
around to approve stable/pike backports for RC2:


https://review.openstack.org/#/admin/groups/147,members

So all things go through Dan. You were warned.

The deadline for the final release candidate is Thursday 8/24, so we 
don't need to tag RC2 next week.


Besides tagging RC2, I'd like to do a release for stable/ocata and 
stable/newton soon (around the same time that we tag RC2).


A few of us went through open stable branch reviews today, of which 
there were many, and we should be close to flushing things out but need 
another +2 on a lot of them:


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

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

Again, that's probably going to fall largely on dansmith since several 
of the other stable cores [1] aren't around next week, unless we can 
poke lyarwood to come out of hiding.


Beyond that, I hope it's quiet. Try and break stuff and find Pike 
regressions that should go into RC2. Triage bugs daily to see if 
something gets reported. Brush your teeth. Clean your room. Etc.


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

--

Thanks,

Matt

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

[openstack-dev] [searchlight] searchlight-ui 3.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for searchlight-ui for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/searchlight-ui/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/searchlight-ui/log/?h=stable/pike

Release notes for searchlight-ui can be found at:

http://docs.openstack.org/releasenotes/searchlight-ui/

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/searchlight

and tag it *pike-rc-potential* to bring it to the searchlight-ui
release crew's attention.


__
OpenStack Development Mailing 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] [searchlight] searchlight 3.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for searchlight for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/searchlight/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/searchlight/log/?h=stable/pike

Release notes for searchlight can be found at:

http://docs.openstack.org/releasenotes/searchlight/




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

Re: [openstack-dev] [nova][docs] O search where art thou?

[Sean Dague]

On 08/11/2017 08:22 AM, Matt Riedemann wrote:
> Before the great docs migration, searching for something in the nova
> devref was restricted to the nova devref:
> 
> https://docs.openstack.org/nova/ocata/search.html?q=rbd_keywords=yes=default
> 
> 
> Now searching for something in the nova docs searches docs.o.o, ask.o.o,
> maybe other places, but it's basically so many unrelated results it's
> not usable for me:
> 
> https://docs.openstack.org/nova/latest/search.html#stq=rbd=1
> 
> Is there a way we can just get the content-specific (restricted to
> whatever is in the nova repo for docs) search results back and if people
> want more, they go to docs.o.o to search for stuff?
> 
> Because when I'm in nova docs looking for rbd stuff, I don't want to
> sift through forum questions or glance docs or cinder docs, etc.

The following change will bring back local search behavior like that -
https://review.openstack.org/#/c/493107/

It will need to be landed and release, and probably backported to
stable/pike given that all the branches have been cut.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [keystone] rc2 updates

[Lance Bragstad]

Thanks for the update.

Outside of the docs patches, we made some good progress on a bug 1702211
(reported as https://bugs.launchpad.net/keystone/+bug/1703917 and
https://bugs.launchpad.net/keystone/+bug/1702211 but we have reason to
believe they are caused by the same issue).

Morgan is currently working on a fix and we've targeted bug 1702211 to
rc2. I'll keep an eye out for the translations patch and make sure that
lands before we cut the next release candidate.

On 08/11/2017 12:02 PM, Thierry Carrez wrote:
> Lance Bragstad wrote:
>> We rolled out rc1 last night [0], but missed a couple important
>> documentation patches and release notes [1]. I'll propose rc2 as soon as
>> those merge.
> Note that we'll have to refresh the RC with translations updates closer
> to the release anyway (start of R-1 week), so if it's just
> doc/releasenotes updates, I'd advise you to wait a bit before cutting RC2.
>
> Regards,
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [refstack][interop-wg] Nomination of Megan Guiney as RefStack Core Reviewer

[Cazares, Luz]

+1. Megan will be a great addition to the core team.

Regards

From: Catherine Cuong Diep 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, August 11, 2017 at 11:37 AM
To: "openstack-dev@lists.openstack.org" , 
"interop...@lists.openstack.org" 
Subject: [openstack-dev] [refstack][interop-wg] Nomination of Megan Guiney as 
RefStack Core Reviewer


Hello everyone,

I would like to nominate Megan Guiney as a core reviewer for the RefStack 
project. Megan has been contributing new features and actively providing 
reviews and feedback over the last few months in our project. She will be a 
fantastic addition to the RefStack core review team.


Catherine Diep
__
OpenStack Development Mailing 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] [chef] Proposing Lance Albertson (Ramareth) for openstack-chef-core

[Matthew Thode]

On 17-08-08 19:24:41, Samuel Cassiba wrote:
> Ohai!
> 
> In openstack-chef-land, we generally don't use the ML very often,
> being so few; thus, when there's an occasion to send something, it
> better be worth it.
> 
> I am proposing adding Lance Albertson (otherwise known as Ramareth on
> IRC and most other places I frequent) to openstack-chef-core. In
> another life, he is the Director of the OSU Open Source Lab.
> 
> That would bring our core count up to four, but it's just a mirage.
> None of us can dedicate our full, or even quarter time to this
> project, which already requires a certain level of exposure to not
> only the nuances of Chef and Ruby, but the quirks of OpenStack and
> Python. However, we do what we can, when we can, how we can.
> 
> Any feedback is welcome. If there are no reasons otherwise, Lance will
> be added to the core group in a few days.
> 
> -- 
> Best,
> Samuel Cassiba
> 

I haven't worked with him in an openstack chef way, but I've worked with
him through the OSUOSL.  He's always been great to work with.  IIRC the
OSUOSL also uses chef to deploy openstack, so hopefully that helps with
some of the time concerns.

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [keystone] rc2 updates

[Thierry Carrez]

Lance Bragstad wrote:
> We rolled out rc1 last night [0], but missed a couple important
> documentation patches and release notes [1]. I'll propose rc2 as soon as
> those merge.

Note that we'll have to refresh the RC with translations updates closer
to the release anyway (start of R-1 week), so if it's just
doc/releasenotes updates, I'd advise you to wait a bit before cutting RC2.

Regards,

-- 
Thierry Carrez (ttx)



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

[openstack-dev] [glance] priorities for the coming week (08/11-08/17)

[Brian Rosmaita]

The first glance pike Release Candidate was released yesterday.

As discussed at yesterday's Glance meeting, we're going to definitely need
an RC-2.  Watch the etherpad for release-critical bugs/patches:
https://etherpad.openstack.org/p/glance-pike-RC-critical
More stuff will be added as the week progresses.  We want to have
everything merged so that we can release RC-2 on Wednesday 16 August.

The focus this week is on finding and fixing release-critical bugs.  Since
stable/pike has been cut, fixes will be made in master and cherry-picked
into stable/pike.  To keep the cherry-picks clean and easy, hold off on
merging any extraneous stuff into master this week.

There are two items to focus on in testing RC-1:
1  image import
2  trusts: see
https://review.openstack.org/#q,I233883dc6a37f282eb8e024c059c6a12ebb7e9f1,n,z
for what I'm talking about

Both of these are optional features, but it's important that they be
working correctly.

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

[openstack-dev] [all][I18n] Translations merge

[Ian Y. Choi]

Hello,

Translators are doing translation and translation review activities hard
especially around soft and hard StringFreeze periods, and it is also 
similar during this Pike cycle.


Looking at 
https://review.openstack.org/#/q/status:open+topic:zanata/translations,n,z

I18n team sees many projects that have not imported translations.
Please import the translations to avoid them to be reproposed every day.

Note that I18n team is preparing stable/pike translation sync jobs with 
RC1 creation of Horizon
and plugin projects, and more projects will have stable/pike translation 
sync jobs regarding stable releases.



With many thanks,

/Ian - I18n Pike cycle PTL.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-August/121038.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

[openstack-dev] [refstack][interop-wg] Nomination of Megan Guiney as RefStack Core Reviewer

[Catherine Cuong Diep]

Hello everyone,

I would like to nominate Megan Guiney as a core reviewer for the RefStack
project.  Megan has been contributing new features and  actively providing
reviews and feedback over the last few months in our project.  She will be
a fantastic addition to the RefStack core review team.


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

Re: [openstack-dev] [qa] [keystone] Random Patrole failures related to Identity v3 Extensions API

[Lance Bragstad]

Help if you actually attach the link you want to send [0].

[0] https://bugs.launchpad.net/keystone/+bug/1702211

On 08/11/2017 11:26 AM, Morgan Fainberg wrote:
> On Fri, Aug 11, 2017 at 9:25 AM, Morgan Fainberg
>  wrote:
>> On Fri, Aug 11, 2017 at 8:44 AM, Felipe Monteiro
>>  wrote:
>>> Patrole tests occasionally fail while executing tests that test the
>>> Identity v3 Extensions API [0]. Previously, this was not the case when
>>> we used Fernet tokens and used a time.sleep(1) to allow for
>>> role-switching to work correctly. However, we recently changed over to
>>> UUID tokens in the Patrole gates to avoid doing a time.sleep(1), as a
>>> time efficiency change. Ordinarily -- for well over 500 or so tests --
>>> this approach works successfully, with the exception of what appears
>>> to be *random* v3 API extension tests [1][2] (random means different
>>> tests pass or fail randomly across separate test runs).
>>>
>>> While there are a few solutions that come to mind on how to solve this
>>> Patrole-side (like re-introducing a time.sleep() for specific APIs or
>>> even avoiding role-switching altogether which is not as
>>> straightforward as it sounds), we would still not understand *why* the
>>> issue is happening in the first place. Is it a data-race condition?
>>> Something specific to the identity v3 extensions API? A potential bug
>>> or intended behavior somewhere?
>>>
>>> [0] https://developer.openstack.org/api-ref/identity/v3-ext/
>>> [1] 
>>> http://status.openstack.org/openstack-health/#/test/patrole_tempest_plugin.tests.api.identity.v3.test_ep_filter_groups_rbac.EndpointFilterGroupsV3RbacTest.test_create_endpoint_group
>>> [2] 
>>> http://logs.openstack.org/41/490641/3/gate/gate-tempest-dsvm-patrole-py35-member-ubuntu-xenial/be95da4/console.html#_2017-08-11_14_47_57_515906
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> Are your tests causing token revocations? if so, there is a case where
>> a revocation event is issued in the same second as a token (we've seen
>> similar cases even in fernet) meaning the token is invalid when it is
>> issued according to keystone. It's a long running bug.
>>
>> For the record, UUID tokens are deprecated and slated for removal in
>> the R release. I recommend reverting to using Fernet tokens sooner
>> rather than later.
>>
>> Last of all, the endpoint-filtering is generally not a great tool to
>> use. I highly recommend not using it (or encouraging the use of it),
>> it makes the catalog different depending on scope and provides zero
>> added security benefit (anyone who knows the endpoint can use it
>> anyway).
> I am spinning up a change for Pike RC (right now) to address the
> revocations occurring in the same second as the issuance of the token
> (similar to a bug with password updates, which will also be fixed).
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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

Re: [openstack-dev] [qa] [keystone] Random Patrole failures related to Identity v3 Extensions API

[Lance Bragstad]

More context on the patch Morgan is working on can be found in the bug
report [0].
[0]

On 08/11/2017 11:26 AM, Morgan Fainberg wrote:
> On Fri, Aug 11, 2017 at 9:25 AM, Morgan Fainberg
>  wrote:
>> On Fri, Aug 11, 2017 at 8:44 AM, Felipe Monteiro
>>  wrote:
>>> Patrole tests occasionally fail while executing tests that test the
>>> Identity v3 Extensions API [0]. Previously, this was not the case when
>>> we used Fernet tokens and used a time.sleep(1) to allow for
>>> role-switching to work correctly. However, we recently changed over to
>>> UUID tokens in the Patrole gates to avoid doing a time.sleep(1), as a
>>> time efficiency change. Ordinarily -- for well over 500 or so tests --
>>> this approach works successfully, with the exception of what appears
>>> to be *random* v3 API extension tests [1][2] (random means different
>>> tests pass or fail randomly across separate test runs).
>>>
>>> While there are a few solutions that come to mind on how to solve this
>>> Patrole-side (like re-introducing a time.sleep() for specific APIs or
>>> even avoiding role-switching altogether which is not as
>>> straightforward as it sounds), we would still not understand *why* the
>>> issue is happening in the first place. Is it a data-race condition?
>>> Something specific to the identity v3 extensions API? A potential bug
>>> or intended behavior somewhere?
>>>
>>> [0] https://developer.openstack.org/api-ref/identity/v3-ext/
>>> [1] 
>>> http://status.openstack.org/openstack-health/#/test/patrole_tempest_plugin.tests.api.identity.v3.test_ep_filter_groups_rbac.EndpointFilterGroupsV3RbacTest.test_create_endpoint_group
>>> [2] 
>>> http://logs.openstack.org/41/490641/3/gate/gate-tempest-dsvm-patrole-py35-member-ubuntu-xenial/be95da4/console.html#_2017-08-11_14_47_57_515906
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> Are your tests causing token revocations? if so, there is a case where
>> a revocation event is issued in the same second as a token (we've seen
>> similar cases even in fernet) meaning the token is invalid when it is
>> issued according to keystone. It's a long running bug.
>>
>> For the record, UUID tokens are deprecated and slated for removal in
>> the R release. I recommend reverting to using Fernet tokens sooner
>> rather than later.
>>
>> Last of all, the endpoint-filtering is generally not a great tool to
>> use. I highly recommend not using it (or encouraging the use of it),
>> it makes the catalog different depending on scope and provides zero
>> added security benefit (anyone who knows the endpoint can use it
>> anyway).
> I am spinning up a change for Pike RC (right now) to address the
> revocations occurring in the same second as the issuance of the token
> (similar to a bug with password updates, which will also be fixed).
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [qa] [keystone] Random Patrole failures related to Identity v3 Extensions API

[Morgan Fainberg]

On Fri, Aug 11, 2017 at 9:25 AM, Morgan Fainberg
 wrote:
> On Fri, Aug 11, 2017 at 8:44 AM, Felipe Monteiro
>  wrote:
>> Patrole tests occasionally fail while executing tests that test the
>> Identity v3 Extensions API [0]. Previously, this was not the case when
>> we used Fernet tokens and used a time.sleep(1) to allow for
>> role-switching to work correctly. However, we recently changed over to
>> UUID tokens in the Patrole gates to avoid doing a time.sleep(1), as a
>> time efficiency change. Ordinarily -- for well over 500 or so tests --
>> this approach works successfully, with the exception of what appears
>> to be *random* v3 API extension tests [1][2] (random means different
>> tests pass or fail randomly across separate test runs).
>>
>> While there are a few solutions that come to mind on how to solve this
>> Patrole-side (like re-introducing a time.sleep() for specific APIs or
>> even avoiding role-switching altogether which is not as
>> straightforward as it sounds), we would still not understand *why* the
>> issue is happening in the first place. Is it a data-race condition?
>> Something specific to the identity v3 extensions API? A potential bug
>> or intended behavior somewhere?
>>
>> [0] https://developer.openstack.org/api-ref/identity/v3-ext/
>> [1] 
>> http://status.openstack.org/openstack-health/#/test/patrole_tempest_plugin.tests.api.identity.v3.test_ep_filter_groups_rbac.EndpointFilterGroupsV3RbacTest.test_create_endpoint_group
>> [2] 
>> http://logs.openstack.org/41/490641/3/gate/gate-tempest-dsvm-patrole-py35-member-ubuntu-xenial/be95da4/console.html#_2017-08-11_14_47_57_515906
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Are your tests causing token revocations? if so, there is a case where
> a revocation event is issued in the same second as a token (we've seen
> similar cases even in fernet) meaning the token is invalid when it is
> issued according to keystone. It's a long running bug.
>
> For the record, UUID tokens are deprecated and slated for removal in
> the R release. I recommend reverting to using Fernet tokens sooner
> rather than later.
>
> Last of all, the endpoint-filtering is generally not a great tool to
> use. I highly recommend not using it (or encouraging the use of it),
> it makes the catalog different depending on scope and provides zero
> added security benefit (anyone who knows the endpoint can use it
> anyway).

I am spinning up a change for Pike RC (right now) to address the
revocations occurring in the same second as the issuance of the token
(similar to a bug with password updates, which will also be fixed).

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

Re: [openstack-dev] [qa] [keystone] Random Patrole failures related to Identity v3 Extensions API

[Morgan Fainberg]

On Fri, Aug 11, 2017 at 8:44 AM, Felipe Monteiro
 wrote:
> Patrole tests occasionally fail while executing tests that test the
> Identity v3 Extensions API [0]. Previously, this was not the case when
> we used Fernet tokens and used a time.sleep(1) to allow for
> role-switching to work correctly. However, we recently changed over to
> UUID tokens in the Patrole gates to avoid doing a time.sleep(1), as a
> time efficiency change. Ordinarily -- for well over 500 or so tests --
> this approach works successfully, with the exception of what appears
> to be *random* v3 API extension tests [1][2] (random means different
> tests pass or fail randomly across separate test runs).
>
> While there are a few solutions that come to mind on how to solve this
> Patrole-side (like re-introducing a time.sleep() for specific APIs or
> even avoiding role-switching altogether which is not as
> straightforward as it sounds), we would still not understand *why* the
> issue is happening in the first place. Is it a data-race condition?
> Something specific to the identity v3 extensions API? A potential bug
> or intended behavior somewhere?
>
> [0] https://developer.openstack.org/api-ref/identity/v3-ext/
> [1] 
> http://status.openstack.org/openstack-health/#/test/patrole_tempest_plugin.tests.api.identity.v3.test_ep_filter_groups_rbac.EndpointFilterGroupsV3RbacTest.test_create_endpoint_group
> [2] 
> http://logs.openstack.org/41/490641/3/gate/gate-tempest-dsvm-patrole-py35-member-ubuntu-xenial/be95da4/console.html#_2017-08-11_14_47_57_515906
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Are your tests causing token revocations? if so, there is a case where
a revocation event is issued in the same second as a token (we've seen
similar cases even in fernet) meaning the token is invalid when it is
issued according to keystone. It's a long running bug.

For the record, UUID tokens are deprecated and slated for removal in
the R release. I recommend reverting to using Fernet tokens sooner
rather than later.

Last of all, the endpoint-filtering is generally not a great tool to
use. I highly recommend not using it (or encouraging the use of it),
it makes the catalog different depending on scope and provides zero
added security benefit (anyone who knows the endpoint can use it
anyway).

__
OpenStack Development Mailing 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] [kolla-kubernetes] Proposing Rich Wellum to core team

[Michał Jastrzębski]

Hello,

It's my pleasure to start another core team vote. This time for our
colleague rwellum. I propose that he joins kolla-kubernetes team.

This is my +1 vote. Every kolla-kubernetes core has a vote and it can
be veto'ed.

Voting will last 2 weeks and will end at 25th of August.

Cheers,
Michal

__
OpenStack Development Mailing 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] [keystone] Random Patrole failures related to Identity v3 Extensions API

[Felipe Monteiro]

Patrole tests occasionally fail while executing tests that test the
Identity v3 Extensions API [0]. Previously, this was not the case when
we used Fernet tokens and used a time.sleep(1) to allow for
role-switching to work correctly. However, we recently changed over to
UUID tokens in the Patrole gates to avoid doing a time.sleep(1), as a
time efficiency change. Ordinarily -- for well over 500 or so tests --
this approach works successfully, with the exception of what appears
to be *random* v3 API extension tests [1][2] (random means different
tests pass or fail randomly across separate test runs).

While there are a few solutions that come to mind on how to solve this
Patrole-side (like re-introducing a time.sleep() for specific APIs or
even avoiding role-switching altogether which is not as
straightforward as it sounds), we would still not understand *why* the
issue is happening in the first place. Is it a data-race condition?
Something specific to the identity v3 extensions API? A potential bug
or intended behavior somewhere?

[0] https://developer.openstack.org/api-ref/identity/v3-ext/
[1] 
http://status.openstack.org/openstack-health/#/test/patrole_tempest_plugin.tests.api.identity.v3.test_ep_filter_groups_rbac.EndpointFilterGroupsV3RbacTest.test_create_endpoint_group
[2] 
http://logs.openstack.org/41/490641/3/gate/gate-tempest-dsvm-patrole-py35-member-ubuntu-xenial/be95da4/console.html#_2017-08-11_14_47_57_515906

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

[Chris Dent]

Placement Update 31

# What Matters Most

rc1 was just cut. There was (and still is) a lot of last minute
change going on in code related to placement, the resource tracker
and the scheduler. No one will be surprised if there are additional
issues to resolve. So at this point important things to be doing are:

* watching for new bugs tagged placement, scheduler or resource-tracker
* inspecting the logs of tempest runs (even those that have passed)
  for unexpected log messages related to managing inventory or
  allocations
* using the code, especially to do things like resize, migrate,
  evacuate, etc
* reviewing code

# What's Changed

The scheduler and the resource tracker are now doing a little dance
with allocations that's being called "doubling". When an instance
needs to be in two places at once for a while (during any kind of
migration) the allocations related to that instance need to be
doubled. Conceptually this is pretty simple but various limitations
with the way we manage data and with the way we might have both pike
and ocata compute nodes at the same time make it rather involved.

The effort and attention required to get that working has meant that
shared resource providers, though somewhat working on the placement
side, are not yet supported on the nova side.

Early in queens we should add a uuid to migrations. This will be a
first step in making the doubling actions easier to process and clean
up.

# Help Wanted

See the beginning of this message.

# Main Themes

## Custom Resource Classes for Ironic

Some last minute issues were discovered with the management of
custom resource classes and existing inventory for Ironic. A recent
change which reflects the situation is:

https://review.openstack.org/#/c/492964/4

The code to migrate flavors is still under review, mostly waiting to
see if stuff that uses it works:

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

## Traits

Work continues apace on getting filtering by traits working:

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

This has some overlap with shared provider handling (below).

Support for using traits in any practical way did not make it in Pike.

Traits on /resource_providers: https://review.openstack.org/#/c/474602/

## Shared Resource Providers

Though sharing providers didn't make their debut in Pike either, Alex
did find (and fix) some bugs, starting at:

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

## Nested Resource Providers

This will start back up after we clean off the windscreen.

## Docs

A very small number of docs patches left to do for the api-ref:

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

There are two changes which depend on that stack merging. A placement
publishing job:

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

and an addition of 'placement' to service-type-authority

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

Real live genuine placement docs will be totally awesome. Nearly
there.

# Other Code

(A lot of the stuff in this list is a loose end created in the last
two weeks of racing to rc1. Some of it is stuff that's just been
around for a while. I've tried to put more relevant stuff at the top
of the list.)

* MVP of the week gibi has created a pile of tests and experiments
  with resize-related behaviors. Current things include:
  * test server evacuation with placement
https://review.openstack.org/#/q/topic:bug/1709902
  * WIP: resize with custom resource
https://review.openstack.org/#/c/490461/
  * replace chance with filter scheduler in func tests
https://review.openstack.org/#/c/491529/
  Putting these here at the top because they exercise the new stuff
  that is in some doubt.

* A tempest test of ServerGroupAntiAffinityFilter
  https://review.openstack.org/#/c/489754/
  Some debate on this one about whether tempest is the right place.

* https://review.openstack.org/#/c/489772/
  Always include accept application/json to get json error responses

* https://review.openstack.org/#/c/427200/
  Add a status check for legacy filters in nova-status.

* https://review.openstack.org/#/c/469048/
  Provide more information about installing placement

* https://review.openstack.org/#/c/468928/
  Disambiguate resource provider conflict message

* https://review.openstack.org/#/c/485209/
  gabbi tests for shared custom resource class

* https://review.openstack.org/#/c/489633/
  Update RT aggregates less often

* https://review.openstack.org/#/c/492247/
  Use ksa adapter for placement in the new way

* https://review.openstack.org/#/c/483506/
  Call _update fewer times in the resource tracker
  I'm relatively certain we can't do this one because of the way the
  code is structured.

* https://review.openstack.org/#/c/472378/
  A proposed fix to using multiple config locations with the
  placement wsgi app. There's some active discussion on whether the
  solution in mind is the right solution, or even whether the bug is
  a bug (it is!).

* 

Re: [openstack-dev] [chef] Proposing Lance Albertson (Ramareth) for openstack-chef-core

[Samuel Cassiba]

On Tue, Aug 8, 2017 at 7:24 PM, Samuel Cassiba  wrote:
> Ohai!
>
> In openstack-chef-land, we generally don't use the ML very often,
> being so few; thus, when there's an occasion to send something, it
> better be worth it.
>
> I am proposing adding Lance Albertson (otherwise known as Ramareth on
> IRC and most other places I frequent) to openstack-chef-core. In
> another life, he is the Director of the OSU Open Source Lab.
>
> That would bring our core count up to four, but it's just a mirage.
> None of us can dedicate our full, or even quarter time to this
> project, which already requires a certain level of exposure to not
> only the nuances of Chef and Ruby, but the quirks of OpenStack and
> Python. However, we do what we can, when we can, how we can.
>
> Any feedback is welcome. If there are no reasons otherwise, Lance will
> be added to the core group in a few days.
>
> --
> Best,
> Samuel Cassiba


After discussing on IRC, we have a unanimous approval. By the power of
greyskull, it is so. Welcome!

-- 
Best,
Samuel Cassiba

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

Re: [openstack-dev] [nova][docs] O search where art thou?

[Sean Dague]

On 08/11/2017 10:49 AM, Anne Gentle wrote:
> On Fri, Aug 11, 2017 at 8:10 AM, Sean Dague  wrote:
>> On 08/11/2017 08:50 AM, Anne Gentle | Just Write Click wrote:
>>> Yeah, I need to circle back in the theme work to make sure both search 
>>> scopes are available. My prior attempt had some wonky CSS debugging and I 
>>> needed to separate patches more.
>>>
>>> I'll put up another patch to the theme today to bring in the Sphinx search 
>>> in the sidebar as it was before.
>>>
>>> I'm not sure how to solve the sort problem Sean notes, would like help 
>>> there.
>>> Hope this helps -
>>> Anne
>>
>> If we have the option to use sphinx baked in search, instead of the
>> bounce out to google swift_search that's being installed, it's all
>> solved. The sphinx search builds the search terms into a compiled
>> javascript file on build, and will only link to content in the tree.
>>
>> I think the thing to do is probably enhance openstackdocstheme to have
>> some toggle of "local_search = True" which would get rid of swift_search
>> and just use baked in local search. Then on a per site basic people
>> could turn it on / off, and openstackdocstheme could still be used for
>> sites that want global search.
> 
> The global search will always be available in the header, so my idea
> is to add the scoped-to-project's-collection search to the sidebar.
> Let me know if that works and I'll get going on it.

The sidebar would be good. I still think it's a little confusing to have
2 different search fields, but maybe if "Search" in the toolbar was
"Search all of OpenStack", and the sidebar was more clearly "Search
$project Docs", it would be more clear.

The big technical bit is actually the openstackdocstheme replaced
search.html with a form that uses swift_search. I was hacking on this
this morning and it seems that in able to get that back to something
that works with built in search is going to need to redo that page, and
also add the ability to inject script_footers (as all the javascript is
late loaded in openstackdocstheme).

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [all][barbican][freezer][horizon][karbor][keystone][mistral][nova][pack-deb][refstack][solum][storlets][swift][tacker][telemetry][watcher][zaqar] Last days for PTL candidate announ

[Anita Kuno]

On 2017-08-11 10:21 AM, Jeremy Stanley wrote:

On 2017-08-11 09:37:08 +0200 (+0200), Flavio Percoco wrote:

On 10/08/17 14:04 -0400, Anita Kuno wrote:

[...]

Also to clarify, the election officials serve the TC, not the other
way around.

I would like to clarify this sentence, though. I do not think the
election officials serve the TC, neither the TC serves the
election officials. Both bodies serve the community and the
processes defined by it.

[...]

It's more accurate to say that the election officials are *appointed
by* the TC, but I agree we're all here to serve the community. In
the particular matter of identifying leaderless teams, the election
officials are definitely acting as advisors to the TC, and I can see
how it might be taken as a bit demeaning to imply that it makes them
servants of the TC. They are charged with reporting these findings
to the TC however, so in a sense that is a form of servitude.
Basically, you're both correct depending on how you look at it. ;)

I'm not sure how the phrase "to serve" has become equated with the 
phrase "to be demeaned" but it is a leap I don't make myself.


I consider to be of service to be a privilege and an honour. I was 
honoured to serve the TC as an election official, I guess it is my 
mistake in believing that others would value the same honour.


Thanks,
Anita.


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

Re: [openstack-dev] [nova][docs] O search where art thou?

[Anne Gentle]

On Fri, Aug 11, 2017 at 9:26 AM, Doug Hellmann  wrote:
> Excerpts from Sean Dague's message of 2017-08-11 09:10:59 -0400:
>> On 08/11/2017 08:50 AM, Anne Gentle | Just Write Click wrote:
>> > Yeah, I need to circle back in the theme work to make sure both search 
>> > scopes are available. My prior attempt had some wonky CSS debugging and I 
>> > needed to separate patches more.
>> >
>> > I'll put up another patch to the theme today to bring in the Sphinx search 
>> > in the sidebar as it was before.
>> >
>> > I'm not sure how to solve the sort problem Sean notes, would like help 
>> > there.
>> > Hope this helps -
>> > Anne
>>
>> If we have the option to use sphinx baked in search, instead of the
>> bounce out to google swift_search that's being installed, it's all
>> solved. The sphinx search builds the search terms into a compiled
>> javascript file on build, and will only link to content in the tree.
>>
>> I think the thing to do is probably enhance openstackdocstheme to have
>> some toggle of "local_search = True" which would get rid of swift_search
>> and just use baked in local search. Then on a per site basic people
>> could turn it on / off, and openstackdocstheme could still be used for
>> sites that want global search.
>>
>> -Sean
>>
>
> We could also limit the global search to one of the top-level pages in
> the openstack-manuals repo and have the theme link to a search page
> there.
>

Mmm, I think it's simpler to keep the global search in the header
as-is across docs, www, ask, and so on. So, keep it in the header and
add an additional search form for within-project. Sound good?

Anne

> 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

[openstack-dev] [keystone] rc2 updates

[Lance Bragstad]

We rolled out rc1 last night [0], but missed a couple important
documentation patches and release notes [1]. I'll propose rc2 as soon as
those merge. I've also created a new official bug tag,
pike-backport-potential. Please feel free to use the tag if you're doing
bug triage and find something you think needs a fix backported to Pike.

Thanks

[0] https://review.openstack.org/#/c/492767/
[1] https://etherpad.openstack.org/p/keystone-pike-rc2-patches



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

Re: [openstack-dev] [nova][docs] O search where art thou?

[Anne Gentle]

On Fri, Aug 11, 2017 at 8:10 AM, Sean Dague  wrote:
> On 08/11/2017 08:50 AM, Anne Gentle | Just Write Click wrote:
>> Yeah, I need to circle back in the theme work to make sure both search 
>> scopes are available. My prior attempt had some wonky CSS debugging and I 
>> needed to separate patches more.
>>
>> I'll put up another patch to the theme today to bring in the Sphinx search 
>> in the sidebar as it was before.
>>
>> I'm not sure how to solve the sort problem Sean notes, would like help there.
>> Hope this helps -
>> Anne
>
> If we have the option to use sphinx baked in search, instead of the
> bounce out to google swift_search that's being installed, it's all
> solved. The sphinx search builds the search terms into a compiled
> javascript file on build, and will only link to content in the tree.
>
> I think the thing to do is probably enhance openstackdocstheme to have
> some toggle of "local_search = True" which would get rid of swift_search
> and just use baked in local search. Then on a per site basic people
> could turn it on / off, and openstackdocstheme could still be used for
> sites that want global search.

The global search will always be available in the header, so my idea
is to add the scoped-to-project's-collection search to the sidebar.
Let me know if that works and I'll get going on it.

Anne

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



-- 

Read my blog: justwrite.click
Subscribe to Docs|Code: docslikecode.com

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

Re: [openstack-dev] [nova][docs] O search where art thou?

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-08-11 09:10:59 -0400:
> On 08/11/2017 08:50 AM, Anne Gentle | Just Write Click wrote:
> > Yeah, I need to circle back in the theme work to make sure both search 
> > scopes are available. My prior attempt had some wonky CSS debugging and I 
> > needed to separate patches more.
> > 
> > I'll put up another patch to the theme today to bring in the Sphinx search 
> > in the sidebar as it was before.
> > 
> > I'm not sure how to solve the sort problem Sean notes, would like help 
> > there.
> > Hope this helps - 
> > Anne
> 
> If we have the option to use sphinx baked in search, instead of the
> bounce out to google swift_search that's being installed, it's all
> solved. The sphinx search builds the search terms into a compiled
> javascript file on build, and will only link to content in the tree.
> 
> I think the thing to do is probably enhance openstackdocstheme to have
> some toggle of "local_search = True" which would get rid of swift_search
> and just use baked in local search. Then on a per site basic people
> could turn it on / off, and openstackdocstheme could still be used for
> sites that want global search.
> 
> -Sean
> 

We could also limit the global search to one of the top-level pages in
the openstack-manuals repo and have the theme link to a search page
there.

Doug

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

Re: [openstack-dev] [all][barbican][freezer][horizon][karbor][keystone][mistral][nova][pack-deb][refstack][solum][storlets][swift][tacker][telemetry][watcher][zaqar] Last days for PTL candidate announ

[Jeremy Stanley]

On 2017-08-11 09:37:08 +0200 (+0200), Flavio Percoco wrote:
> On 10/08/17 14:04 -0400, Anita Kuno wrote:
[...]
> > Also to clarify, the election officials serve the TC, not the other
> > way around.
> 
> I would like to clarify this sentence, though. I do not think the
> election officials serve the TC, neither the TC serves the
> election officials. Both bodies serve the community and the
> processes defined by it.
[...]

It's more accurate to say that the election officials are *appointed
by* the TC, but I agree we're all here to serve the community. In
the particular matter of identifying leaderless teams, the election
officials are definitely acting as advisors to the TC, and I can see
how it might be taken as a bit demeaning to imply that it makes them
servants of the TC. They are charged with reporting these findings
to the TC however, so in a sense that is a form of servitude.
Basically, you're both correct depending on how you look at it. ;)
-- 
Jeremy Stanley


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

Re: [openstack-dev] [tc] Technical Committee Status update, August 11th

[Flavio Percoco]

On 11/08/17 12:11 +0200, Thierry Carrez wrote:

== TC member actions for the coming week(s) ==

All TC members should have a close look on Storlets team status to make
up their mind on what to do with it in Queens.

Flavio still needs to incorporate feedback in the "Drop TC meetings"
proposal and produce a new patchset, or abandon it since we pretty much
already implemented the described change.


I actually did already (probably seconds after you sent this email) :P

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

Flavio

--
@flaper87
Flavio Percoco


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

[openstack-dev] [mistral] mistral-dashboard 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for mistral-dashboard for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/mistral-dashboard/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/mistral-dashboard/log/?h=stable/pike

Release notes for mistral-dashboard can be found at:

http://docs.openstack.org/releasenotes/mistral-dashboard/




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

[openstack-dev] [mistral] mistral-extra 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for mistral-extra for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/mistral-extra/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/mistral-extra/log/?h=stable/pike

Release notes for mistral-extra can be found at:

http://docs.openstack.org/releasenotes/mistral-extra/




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

[openstack-dev] [mistral] mistral 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for mistral for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/mistral/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/mistral/log/?h=stable/pike

Release notes for mistral can be found at:

http://docs.openstack.org/releasenotes/mistral/




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

Re: [openstack-dev] [neutron][infra] Functional job failure rate at 100%

[Jakub Libosvar]

On 10/08/2017 21:16, Jeremy Stanley wrote:
> On 2017-08-10 17:13:58 + (+), Mooney, Sean K wrote:
> [...]
>> so on that it would bre quite trivial to have disk image builder
>> install The linux-image-virtual-hwe-16.04
>> linux-image-virtual-hwe-16.04-edge to pull in a 4.10 or 4.11
>> kernel respctivly if the default 4.4 is broken. We just need a new
>> dib element to install the package And modify the  nodepool config
>> to include it when it rebuildes the image every night.
>> Alternitivly You can pull a vanilla kernel form
>> http://kernel.ubuntu.com/~kernel-ppa/mainline/ Follow the process
>> documented here https://wiki.ubuntu.com/Kernel/MainlineBuilds If
>> you want to maintain testing with 4.4.x
> [...]
> 
> Sure, your definition of "quite trivial" just differs a lot from
> mine. Given that the bug in question seems to have no further impact
> to the pace of development with the discussed test temporarily
> disabled, that strikes me as a lot more maintainable in the long run
> for a problem which started getting urgent attention from the distro
> as soon as it was reported to them and will likely be resolved over
> the course of the next few days at which point we'll automatically
> update to the fixed version and you can try reenabling that test
> again.

Yeah, I totally agree with Jeremy. Ubuntu folks are very active :)
Thanks for that. My best hope is they are gonna backport the fix to
4.4.0 and tag a new kernel so we can start running the tests again.


__
OpenStack Development Mailing 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] [trove] trove-dashboard 9.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for trove-dashboard for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/trove-dashboard/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/trove-dashboard/log/?h=stable/pike

Release notes for trove-dashboard can be found at:

http://docs.openstack.org/releasenotes/trove-dashboard/




__
OpenStack Development Mailing 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] [trove] trove 8.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for trove for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/trove/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/trove/log/?h=stable/pike

Release notes for trove can be found at:

http://docs.openstack.org/releasenotes/trove/




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

Re: [openstack-dev] [nova][docs] O search where art thou?

[Sean Dague]

On 08/11/2017 08:50 AM, Anne Gentle | Just Write Click wrote:
> Yeah, I need to circle back in the theme work to make sure both search scopes 
> are available. My prior attempt had some wonky CSS debugging and I needed to 
> separate patches more.
> 
> I'll put up another patch to the theme today to bring in the Sphinx search in 
> the sidebar as it was before.
> 
> I'm not sure how to solve the sort problem Sean notes, would like help there.
> Hope this helps - 
> Anne

If we have the option to use sphinx baked in search, instead of the
bounce out to google swift_search that's being installed, it's all
solved. The sphinx search builds the search terms into a compiled
javascript file on build, and will only link to content in the tree.

I think the thing to do is probably enhance openstackdocstheme to have
some toggle of "local_search = True" which would get rid of swift_search
and just use baked in local search. Then on a per site basic people
could turn it on / off, and openstackdocstheme could still be used for
sites that want global search.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [tripleo][puppet] Hold off on approving patches until further notice

[Paul Belanger]

On Thu, Aug 10, 2017 at 10:32:25PM -0600, Alex Schultz wrote:
> On Thu, Aug 10, 2017 at 11:12 AM, Paul Belanger  wrote:
> > On Thu, Aug 10, 2017 at 07:03:32AM -0600, Alex Schultz wrote:
> >> FYI,
> >>
> >> The gates are hosed for a variety of reasons[0][1] and we can't get
> >> critical patches merged. Please hold off on rechecking or approving
> >> anything new until further notice.   We're hoping to get some of the
> >> fixes for this merged today.  I will send a note when it's OK to merge
> >> again.
> >>
> >> [0] https://bugs.launchpad.net/tripleo/+bug/1709428
> >> [1] https://bugs.launchpad.net/tripleo/+bug/1709327
> >>
> > So far, these are the 3 patches we need to land today:
> >
> >   Exclude networking-bagpipe from dlrn
> > - https://review.openstack.org/491878
> >
> >   Disable existing repositories in tripleo-ci
> > - https://review.openstack.org/492289
> >
> >   Stop trying to build networking-bagpipe with DLRN
> > - https://review.openstack.org/492339
> >
> > These 3 fixes will take care of the large amount of gate resets tripleo is
> > currently seeing. Like Alex says, please try not to approve / recheck 
> > anything
> > until we land these.
> >
> 
> Ok so we've managed to land patches to improve the reliability.
> 
> https://review.openstack.org/492339 - merged
> https://review.openstack.org/491878 - still pending but we managed to
> get the package fixed so this one is not as critical anymore
> https://review.openstack.org/491522 - merged
> https://review.openstack.org/492289 - merged
> 
> We found that the undercloud-container's job is still trying to pull
> from buildlogs.centos.org, and I've proposed a fix
> https://review.openstack.org/#/c/492786/
> 
> I've restored (and approved) previously approved patches that have a
> high/critical bug or a FFE approved blueprint associated.
> 
> It should be noted that the following patches for tripleo do not have
> a bug or bp reference so they should be updated prior to being
> re-approved:
> https://review.openstack.org/#/c/400407/
> https://review.openstack.org/#/c/489083/
> https://review.openstack.org/#/c/475457/
> 
> For tripleo patches, please refer to Emilien's email[0] about the RC
> schedule with includes these rules about what patches should be
> merged.  Please be careful on rechecks and check failures. Do not
> blindly recheck.  We have noticed some issues with citycloud nodes, so
> if you spot problems with specific clouds please let us know so we can
> track these and work with infra on it.
> 
> Thanks,
> -Alex
> 
> [0] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120806.html
> 
Thanks,

For today I'm going to keep an eye on elastic-recheck and see what is still
failing in the gate.  I agree, for the most part we seem to be looking good on
infrastructure issues but I think the container jobs are still failing too much
for my liking.

Lets see what happens today.

-PB

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

Re: [openstack-dev] [nova][docs] O search where art thou?

[Anne Gentle | Just Write Click]

Yeah, I need to circle back in the theme work to make sure both search scopes 
are available. My prior attempt had some wonky CSS debugging and I needed to 
separate patches more.

I'll put up another patch to the theme today to bring in the Sphinx search in 
the sidebar as it was before.

I'm not sure how to solve the sort problem Sean notes, would like help there.
Hope this helps - 
Anne

> On Aug 11, 2017, at 7:32 AM, Sean Dague  wrote:
> 
>> On 08/11/2017 08:22 AM, Matt Riedemann wrote:
>> Before the great docs migration, searching for something in the nova
>> devref was restricted to the nova devref:
>> 
>> https://docs.openstack.org/nova/ocata/search.html?q=rbd_keywords=yes=default
>> 
>> 
>> Now searching for something in the nova docs searches docs.o.o, ask.o.o,
>> maybe other places, but it's basically so many unrelated results it's
>> not usable for me:
>> 
>> https://docs.openstack.org/nova/latest/search.html#stq=rbd=1
>> 
>> Is there a way we can just get the content-specific (restricted to
>> whatever is in the nova repo for docs) search results back and if people
>> want more, they go to docs.o.o to search for stuff?
>> 
>> Because when I'm in nova docs looking for rbd stuff, I don't want to
>> sift through forum questions or glance docs or cinder docs, etc.
> 
> Equally problematic, in the rbd search above it returns content from all
> published branches, and seems to be coming back in reverse order. So
> mitaka content is the first link for folks for searching from latest docs.
> 
>-Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] nova 16.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for nova for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/nova/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/nova/log/?h=stable/pike

Release notes for nova can be found at:

http://docs.openstack.org/releasenotes/nova/




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

Re: [openstack-dev] [nova][docs] O search where art thou?

[Sean Dague]

On 08/11/2017 08:22 AM, Matt Riedemann wrote:
> Before the great docs migration, searching for something in the nova
> devref was restricted to the nova devref:
> 
> https://docs.openstack.org/nova/ocata/search.html?q=rbd_keywords=yes=default
> 
> 
> Now searching for something in the nova docs searches docs.o.o, ask.o.o,
> maybe other places, but it's basically so many unrelated results it's
> not usable for me:
> 
> https://docs.openstack.org/nova/latest/search.html#stq=rbd=1
> 
> Is there a way we can just get the content-specific (restricted to
> whatever is in the nova repo for docs) search results back and if people
> want more, they go to docs.o.o to search for stuff?
> 
> Because when I'm in nova docs looking for rbd stuff, I don't want to
> sift through forum questions or glance docs or cinder docs, etc.

Equally problematic, in the rbd search above it returns content from all
published branches, and seems to be coming back in reverse order. So
mitaka content is the first link for folks for searching from latest docs.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [horizon] A Monitoring panel plugin for Horizon

[Julien Danjou]

On Tue, Aug 01 2017, Gökhan IŞIK (BİLGEM BTE) wrote:

Hi,

> We are happy to share with you that we developed an AngularJS based usage
> monitoring panel for Horizon.
> The panel visualizes the collected utilization data by Ceilometer. 
>
> Source code is now available on github [1]. 
>
> The plugin consists of 3 panels; a monitoring panel for users, a project
> monitoring panel and a hypervisor monitoring panel for admins.
>
> A user can display utilization charts for the current project's instances,
> export the metrics in csv format and launch alarms using the dashboard.
> We have another service to capture these alarms and send notification e-mails
> to the cloud users which is also available on github.com/b3lab.
> An admin can display projects' utilization charts, export the metrics in csv
> format in Project Monitor panel. And the Hypervisor Monitor panel is to
> visualize SNMP based metrics collected from hypervisors.
>
> We are currently improving some features. 
>
> Some screenshots published at our website [2]. We also uploaded two videos
> showing some features of the plugin [3][4].
>
> All comments and ideas are welcome! 

Did you build all of this against the deprecated Ceilometer API rather
than Gnocchi? :(

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


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

[openstack-dev] [nova][docs] O search where art thou?

[Matt Riedemann]

Before the great docs migration, searching for something in the nova 
devref was restricted to the nova devref:


https://docs.openstack.org/nova/ocata/search.html?q=rbd_keywords=yes=default

Now searching for something in the nova docs searches docs.o.o, ask.o.o, 
maybe other places, but it's basically so many unrelated results it's 
not usable for me:


https://docs.openstack.org/nova/latest/search.html#stq=rbd=1

Is there a way we can just get the content-specific (restricted to 
whatever is in the nova repo for docs) search results back and if people 
want more, they go to docs.o.o to search for stuff?


Because when I'm in nova docs looking for rbd stuff, I don't want to 
sift through forum questions or glance docs or cinder docs, etc.


--

Thanks,

Matt

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

[openstack-dev] [freezer] freezer-web-ui 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for freezer-web-ui for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/freezer-web-ui/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/freezer-web-ui/log/?h=stable/pike

Release notes for freezer-web-ui can be found at:

http://docs.openstack.org/releasenotes/freezer-web-ui/




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

Re: [openstack-dev] [gnocchi][ceilometer] gnocchi-metricd error using redis as coordination

[Julien Danjou]

On Tue, Aug 08 2017, Yaguang Tang wrote:

Yes, this fix is included in Gnocchi 4.0.1 already.

> Thanks Along, finally I figure out that this is a bug  and fixed by this
> commit
>
> commit e749b60f49a4a3b48cc5da67a797f717dd8cd01d
> Author: Julien Danjou 
> Date:   Tue Jun 20 16:36:14 2017 +0200
>
> utils: use ASCII bytes as member id
>
> Tooz actually wants ASCII bytes and not random bytes.
>
> Fixes #130
>
> diff --git a/gnocchi/utils.py b/gnocchi/utils.py
> index f81d93e..7666711 100644
> --- a/gnocchi/utils.py
> +++ b/gnocchi/utils.py
> @@ -90,7 +90,7 @@ def _enable_coordination(coord):
>
>
>  def get_coordinator_and_start(url):
> -my_id = uuid.uuid4().bytes
> +my_id = str(uuid.uuid4()).encode()
>  coord = coordination.get_coordinator(url, my_id)
>  _enable_coordination(coord)
>  return coord, my_id
>
>
> On Mon, Aug 7, 2017 at 10:10 PM, Along Meng  wrote:
>
>> From the log info,It shows that your 'node' maybe is not the valid str.
>> You can show the node name via 'print node' and try to call 
>> str(node).encode('utf-8')
>> , identify does it can goes well.
>>
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils key =
>> str(node).encode('utf-8')
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils
>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xde in position 4:
>> ordinal not in range(128)
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils
>>
>>
>>
>> On Sat, Aug 5, 2017 at 7:16 PM, Yaguang Tang  wrote:
>>
>>> Hi gnocchi devs,
>>>
>>> I have an issue when using gnocchi 4.0, the storage backend is ceph, and
>>> tooz coordination is redis. currently  gnocchi api in apache wsgi mode,
>>> only one controller node running gnocchi-metricd & gnocchi-statsd daemon.
>>> the error log of gnocchi-metricd is as follow.
>>>
>>>
>>>
>>> 2017-08-05 18:14:18.643 1329257 INFO gnocchi.storage.common.ceph [-] Ceph
>>> storage backend use 'cradox' python library
>>> 2017-08-05 18:14:18.654 1329257 INFO gnocchi.storage.common.ceph [-] Ceph
>>> storage backend use 'cradox' python library
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils [-] Unhandled
>>> exception
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils Traceback (most
>>> recent call last):
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>>> "/usr/lib/python2.7/site-packages/cotyledon/_utils.py", line 84, in
>>> exit_on_exception
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils yield
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>>> "/usr/lib/python2.7/site-packages/cotyledon/_service.py", line 139, in
>>> _run
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils self.run()
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>>> "/usr/lib/python2.7/site-packages/gnocchi/cli.py", line 120, in run
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils
>>> self._configure()
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>>> "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 87, in
>>> wrapped_f
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils return
>>> r.call(f, *args, **kw)
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>>> "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 177, in
>>> call
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils return
>>> fut.result()
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>>> "/usr/lib/python2.7/site-packages/concurrent/futures/_base.py", line
>>> 396, in result
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils return
>>> self.__get_result()
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>>> "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 159, in
>>> call
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils result =
>>> fn(*args, **kwargs)
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>>> "/usr/lib/python2.7/site-packages/gnocchi/cli.py", line 193, in
>>> _configure
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils self.GROUP_ID,
>>> partitions=200)
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>>> "/usr/lib/python2.7/site-packages/tooz/coordination.py", line 284, in
>>> join_partitioned_group
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils return
>>> partitioner.Partitioner(self, group_id)
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>>> "/usr/lib/python2.7/site-packages/tooz/partitioner.py", line 45, in
>>> __init__
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils
>>> partitions=self.partitions)
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>>> "/usr/lib/python2.7/site-packages/tooz/hashring.py", line 47, in __init__
>>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils
>>> self.add_nodes(set(nodes))
>>> 2017-08-05 

Re: [openstack-dev] [ironic] support for various glance image reference formats - do we need them all?

[Mark Goddard]

Got it, thanks for explaining.
Mark

On 11 August 2017 at 10:46, Pavlo Shchelokovskyy <
pshchelokovs...@mirantis.com> wrote:

> Hi Mark,
>
> I do not propose to remove handling of plain http image references
> altogether, just remove the code pieces in glance service utils that
> pretend to support such refs *for glance images*.
>
> This code is never reached exactly due to plain http links being
> recognized as such from the very begining, and thus they will use a
> different 'image service' (HttpImageService) that has no notion of glance
> api, its required auth etc.
>
> Cheers,
>
> On Fri, Aug 11, 2017 at 11:59 AM, Mark Goddard  wrote:
>
>> Hi Pavlo,
>>
>> #3 is used in Bifrost, where there is no Glance service but the default
>> driver is agent_ipmitool. The images are served by the local nginx service.
>> For example, taken from one ironic node:
>>
>> 'image_source':  u'http://10.41.253.100:8080/deployment_image.qcow2'
>>
>> Mark
>>
>> On 10 August 2017 at 08:20, Pavlo Shchelokovskyy <
>> pshchelokovs...@mirantis.com> wrote:
>>
>>> HI Dmitry,
>>>
>>> On Tue, Aug 8, 2017 at 7:13 PM, Dmitry Tantsur 
>>> wrote:
>>>
 Hi!

 Thanks for raising this.

 On 08/07/2017 02:47 PM, Pavlo Shchelokovskyy wrote:

> Hi all,
>
> currently our GlanceImageService seems to support several ways of
> defining a reference to glance image:
>
> 1) simple image UUID [0]
> 2) image UUID prefixed with 'glance://' protocol [1] (well, actually
> anything starting with 'glance://' and ending with '/')
> 3) full REST path to the image (as in 
> http:///v2/images/),
> also used to extract the glance API address [2]
>
> Support for #3 must surely be removed, as we are moving to API
> endpoint discovery from keystone catalog.
> Besides I am pretty sure this code path can not actually be reached
> currently, as the 'is_glance_image' will ignore such image refs and return
> False for those [3], and 'get_image_service' would also not return the
> GlanceImageService instance for such image refs [4].
> Hence the question - if it is unusable anyway now, should we execute
> the standard deprecation process when removing support for it or just
> remove right away?
>

 If unsure, always use the standard process ;) Unless somebody is ready
 to set up DevStack, and try it out, and prove that it's completely and
 hopelessly broken.
>>>
>>>
>>> Did just that [0] - hacked up our tempest configuration so that the
>>> 'http' url for whole disk image used for *HttpLink standalone tests leads
>>> to /v2/images/ [1].
>>> As I kind of expected, both *HttpLink standalone tests failed, right on
>>> validating of the deploy interface when trying to do a HEAD on that URL
>>> instead of 'glance image show', receiving 401 [2].
>>> On a side note, it seems our logging is insufficient in this parts, as I
>>> could not find any relevant logs in ironic-conductor even at debug level,
>>> all that's there are final RPC processing error logs from api.
>>>
>>> So I am quite confident that this code paths [3] in service_utils is a
>>> dead end indeed :-/
>>>
>>> [0] https://review.openstack.org/#/c/492184/
>>> [1] http://logs.openstack.org/84/492184/1/check/gate-ironic-
>>> dsvm-standalone-ubuntu-xenial/32ea5de/logs/tempest_conf.txt.gz
>>> [2] http://logs.openstack.org/84/492184/1/check/gate-ironic-
>>> dsvm-standalone-ubuntu-xenial/32ea5de/logs/testr_results.html.gz
>>> [3] https://github.com/openstack/ironic/blob/7e6ce7e78c4378f
>>> 2f86d085df61a26507a410738/ironic/common/glance_service/servi
>>> ce_utils.py#L159-L166
>>>
>>>


> As for the #1 and #2 I do not see any big difference between those,
> and proposed deprecating and eventually removing support for #2
> ('glance://' scheme) as part of [5]. Two people in review already raised a
> concern about removing such support.
>

 To be honest, I like glance:// more, as it makes it obvious where
 the image is coming from vs http://. I don't mind removing it too
 much, but I guess supporting it is not a lot of code, right?

>>>
>>> That's not too much burden indeed, as long as we actually do only that -
>>> as I said, right now it is more like "glance:///uuid"
>>>
>>>

> Thus I'd like to ask a broader audience - do we need support for
> glance image references in 'glance://*' form? Is it actually used
> somewhere? What are the benefits of having it besides simple UUID?
>
> [0] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
> ommon/glance_service/service_utils.py#n149
> [1] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
> ommon/glance_service/service_utils.py#n155
> [2] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
> ommon/glance_service/service_utils.py#n160
> [3] 

[openstack-dev] [horizon] [i18n] Horizon RC1 tagged

[Rob Cresswell]

Hi everyone,

We've now tagged Horizon's first Release Candidate for Pike (12.0.0). Please 
test it out, and get back to us ASAP with any critical bugs. This also means 
we've now created a stable/pike branch and master is open for features again; 
however, the immediate focus for the next few weeks will be to ensure a stable 
release.

If you find any critical bugs, please tag them with 'pike-rc-potential' and 
target them to pike-rc2 on launchpad, then ping me (robcresswell), ying_zuo, 
amotoki or rdopiera on IRC so we can evaluate and address the bug if necessary. 
Bug fixes must now follow the standard stable policy, and be merged to master, 
then backported to stable/pike. They also must *not* contain any string changes 
whatsoever, as we are in Hard String Freeze, to let the translators do their 
work.

On Monday I'll remove the -2's blocking blueprint work.

Thanks for the hard work everyone,

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

[openstack-dev] [tc] Technical Committee Status update, August 11th

[Thierry Carrez]

Hi!

This is the weekly update on Technical Committee initiatives. You can
find the full list of all open topics at:

https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee


== Recently-approved changes ==

* Pike goals updates: barbican
* Removed repositories: installguide-cookiecutter
* New repositories: watcher-tempest-plugin, charm-gnocchi,
charm-interface-gnocchi, charm-interface-ceph-client

Not much TC activity again this week as everyone is focused on producing
Pike release candidates.


== Leaderless project teams ==

We have[1] two teams (3.4% of the total of teams) where nobody stepped
up to take the Project Team Lead position for the Queens cycle: Storlets
and Packaging-Deb. Following process[2], the Technical Committee will
look for and directly appoint a volunteer (or move the team off the
official OpenStack project team list if it has no further activity).

[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/120915.html
[2]
https://governance.openstack.org/tc/resolutions/20141128-elections-process-for-leaderless-programs.html

In the case of Packaging-Deb, a transition is actually under way[3] to
bring it back after Pike to Debian project infrastructure, closer to
where Debian maintainers live and usually collaborate, so it's unlikely
that the Technical Committee will appoint anyone for Queens.

[3]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/120581.html

For Storlets, the project has been a lot less active lately. I've been
reaching out to the two main recent contributors to get a more accurate
picture of their plans, so that we can take a decision there.


== Open discussions ==

Flavio just refreshed his resolution about allowing teams to host
meetings in their own IRC channels, please see it at:

https://review.openstack.org/485117

From the latest reviews, it looks like John's resolution on how
decisions should be globally inclusive could use a new patchset (or be
morphed into project-team-guide material). Please review it if you
haven't yet:

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

Trove's status:maintenance-mode addition is WIP until Queens opens,
which should happen very soon now. One question is whether Trove is now
past the low point, and setting the tag would convey the wrong message
for a recovering project. Please join the discussion if you have an opinion:

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


== Voting in progress ==

John's description of "what upstream support is" reached majority votes
a couple of days ago. It will be approved early on Tuesday unless new
objections are raised and votes are changed:

https://review.openstack.org/440601

Emmet's rewording of the leaderless project resolution seems to be
non-contentious, missing a few votes to pass:

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


== TC member actions for the coming week(s) ==

All TC members should have a close look on Storlets team status to make
up their mind on what to do with it in Queens.

Flavio still needs to incorporate feedback in the "Drop TC meetings"
proposal and produce a new patchset, or abandon it since we pretty much
already implemented the described change.


== Need for a TC meeting next Tuesday ==

It feels like things are progressing slowly, with office hours and
general #openstack-tc discussions to nudge them forward. Therefore I
don't think we need a synchronous TC meeting next week. Let me know if
you'd still like to have one and the topic you would like to see discussed.


Cheers!

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [ironic drac driver]there are some errors when I use drac driver to deploy a node

[王俊]

Hi,
 First,I use ‘node-set-target-raid-config’ to set raid 
configuration,but there is nothing in ‘target_raid_config’
 Second,I try to set node in provide,for a while, It’s failed.the error 
log is:
>
>_do_request /usr/lib/python2.7/site-packages/dracclient/wsman.py:73
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager 
>[req-4d8e6e72-6e4d-43fc-9729-ef76954a3a7d - - - - -] Failed to prepare node 
>f4decb8d-a126-4e9f-ba8f-ae29f9f89ee5 for cleaning:
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager Traceback (most 
>recent call last):
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager   File 
>"/usr/lib/python2.7/site-packages/ironic/conductor/manager.py", line 928, in 
>_do_node_clean
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager 
>prepare_result = task.driver.deploy.prepare_cleaning(task)
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager   File 
>"/usr/lib/python2.7/site-packages/ironic_lib/metrics.py", line 61, in wrapped
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager result = 
>f(*args, **kwargs)
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager   File 
>"/usr/lib/python2.7/site-packages/ironic/drivers/modules/drac/deploy.py", line 
>54, in prepare_cleaning
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager 
>manage_boot=True)
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager   File 
>"/usr/lib/python2.7/site-packages/ironic/drivers/modules/deploy_utils.py", 
>line 982, in prepare_inband_cleaning
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager 
>manager_utils.node_power_action(task, states.REBOOT)
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager   File 
>"/usr/lib/python2.7/site-packages/ironic/conductor/task_manager.py", line 146, 
>in wrapper
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager return 
>f(*args, **kwargs)
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager   File 
>"/usr/lib/python2.7/site-packages/ironic/conductor/utils.py", line 193, in 
>node_power_action
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager 
>fields.NotificationStatus.ERROR, new_state)
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager   File 
>"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in 
>__exit__
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager 
>self.force_reraise()
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager   File 
>"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
>force_reraise
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager 
>six.reraise(self.type_, self.value, self.tb)
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager   File 
>"/usr/lib/python2.7/site-packages/ironic/conductor/utils.py", line 180, in 
>node_power_action
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager 
>task.driver.power.reboot(task)
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager   File 
>"/usr/lib/python2.7/site-packages/ironic_lib/metrics.py", line 61, in wrapped
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager result = 
>f(*args, **kwargs)
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager   File 
>"/usr/lib/python2.7/site-packages/ironic/conductor/task_manager.py", line 146, 
>in wrapper
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager return 
>f(*args, **kwargs)
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager   File 
>"/usr/lib/python2.7/site-packages/ironic/drivers/modules/drac/power.py", line 
>181, in reboot
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager 
>_set_power_state(task.node, target_power_state)
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager   File 
>"/usr/lib/python2.7/site-packages/ironic/drivers/modules/drac/power.py", line 
>101, in _set_power_state
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager 
>_commit_boot_list_change(node)
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager   File 
>"/usr/lib/python2.7/site-packages/ironic/drivers/modules/drac/power.py", line 
>77, in _commit_boot_list_change
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager 
>boot_device['persistent'])
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager   File 
>"/usr/lib/python2.7/site-packages/ironic/drivers/modules/drac/management.py", 
>line 98, in set_boot_device
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager 
>current_boot_device = _get_boot_device(node, drac_boot_devices)
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager   File 
>"/usr/lib/python2.7/site-packages/ironic/drivers/modules/drac/management.py", 
>line 66, in _get_boot_device
>2017-08-11 19:55:40.771 0 ERROR ironic.conductor.manager boot_device = 
>next(key for (key, value) in _BOOT_DEVICES_MAP.items()
>2017-08-11 19:55:40.771 0 

Re: [openstack-dev] [ironic] support for various glance image reference formats - do we need them all?

[Pavlo Shchelokovskyy]

Hi Mark,

I do not propose to remove handling of plain http image references
altogether, just remove the code pieces in glance service utils that
pretend to support such refs *for glance images*.

This code is never reached exactly due to plain http links being recognized
as such from the very begining, and thus they will use a different 'image
service' (HttpImageService) that has no notion of glance api, its required
auth etc.

Cheers,

On Fri, Aug 11, 2017 at 11:59 AM, Mark Goddard  wrote:

> Hi Pavlo,
>
> #3 is used in Bifrost, where there is no Glance service but the default
> driver is agent_ipmitool. The images are served by the local nginx service.
> For example, taken from one ironic node:
>
> 'image_source':  u'http://10.41.253.100:8080/deployment_image.qcow2'
>
> Mark
>
> On 10 August 2017 at 08:20, Pavlo Shchelokovskyy <
> pshchelokovs...@mirantis.com> wrote:
>
>> HI Dmitry,
>>
>> On Tue, Aug 8, 2017 at 7:13 PM, Dmitry Tantsur 
>> wrote:
>>
>>> Hi!
>>>
>>> Thanks for raising this.
>>>
>>> On 08/07/2017 02:47 PM, Pavlo Shchelokovskyy wrote:
>>>
 Hi all,

 currently our GlanceImageService seems to support several ways of
 defining a reference to glance image:

 1) simple image UUID [0]
 2) image UUID prefixed with 'glance://' protocol [1] (well, actually
 anything starting with 'glance://' and ending with '/')
 3) full REST path to the image (as in 
 http:///v2/images/),
 also used to extract the glance API address [2]

 Support for #3 must surely be removed, as we are moving to API endpoint
 discovery from keystone catalog.
 Besides I am pretty sure this code path can not actually be reached
 currently, as the 'is_glance_image' will ignore such image refs and return
 False for those [3], and 'get_image_service' would also not return the
 GlanceImageService instance for such image refs [4].
 Hence the question - if it is unusable anyway now, should we execute
 the standard deprecation process when removing support for it or just
 remove right away?

>>>
>>> If unsure, always use the standard process ;) Unless somebody is ready
>>> to set up DevStack, and try it out, and prove that it's completely and
>>> hopelessly broken.
>>
>>
>> Did just that [0] - hacked up our tempest configuration so that the
>> 'http' url for whole disk image used for *HttpLink standalone tests leads
>> to /v2/images/ [1].
>> As I kind of expected, both *HttpLink standalone tests failed, right on
>> validating of the deploy interface when trying to do a HEAD on that URL
>> instead of 'glance image show', receiving 401 [2].
>> On a side note, it seems our logging is insufficient in this parts, as I
>> could not find any relevant logs in ironic-conductor even at debug level,
>> all that's there are final RPC processing error logs from api.
>>
>> So I am quite confident that this code paths [3] in service_utils is a
>> dead end indeed :-/
>>
>> [0] https://review.openstack.org/#/c/492184/
>> [1] http://logs.openstack.org/84/492184/1/check/gate-ironic-
>> dsvm-standalone-ubuntu-xenial/32ea5de/logs/tempest_conf.txt.gz
>> [2] http://logs.openstack.org/84/492184/1/check/gate-ironic-
>> dsvm-standalone-ubuntu-xenial/32ea5de/logs/testr_results.html.gz
>> [3] https://github.com/openstack/ironic/blob/7e6ce7e78c4378f
>> 2f86d085df61a26507a410738/ironic/common/glance_service/
>> service_utils.py#L159-L166
>>
>>
>>>
>>>
 As for the #1 and #2 I do not see any big difference between those, and
 proposed deprecating and eventually removing support for #2 ('glance://'
 scheme) as part of [5]. Two people in review already raised a concern about
 removing such support.

>>>
>>> To be honest, I like glance:// more, as it makes it obvious where
>>> the image is coming from vs http://. I don't mind removing it too much,
>>> but I guess supporting it is not a lot of code, right?
>>>
>>
>> That's not too much burden indeed, as long as we actually do only that -
>> as I said, right now it is more like "glance:///uuid"
>>
>>
>>>
 Thus I'd like to ask a broader audience - do we need support for glance
 image references in 'glance://*' form? Is it actually used somewhere?
 What are the benefits of having it besides simple UUID?

 [0] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
 ommon/glance_service/service_utils.py#n149
 [1] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
 ommon/glance_service/service_utils.py#n155
 [2] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
 ommon/glance_service/service_utils.py#n160
 [3] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
 ommon/glance_service/service_utils.py#n208
 [4] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
 ommon/image_service.py#n267
 [5] https://review.openstack.org/#/c/467728

 Cheers,

 --
 Dr. Pavlo 

[openstack-dev] [release] Release countdown for week R-2, August 11-18

[Thierry Carrez]

Welcome to our regular release countdown email!

Development Focus
-

As stable/pike branches are now (mostly) cut, focus should be on
checking current Pike release candidates for release-critical issues,
fix those in master, backport the fix to stable/pike and issue new
release candidates before the publication deadline on R-1 (August 24).

If your team attends the PTG in Denver, you should also prepare the
topics for discussion at the event.


General Information
---

Probably due to a busy gate, a number of cycle-with-milestones
deliverables are still missing their RC1 and stable/pike branch,
preventing the thawing of the requirements repository:

designate (+ designate-dashboard), freezer-web-ui, heat, manila
searchlight (+ searchlight-ui), trove (+ trove-dashboard)

In addition to that list, mistral and nova have proposed RC1 tags that
just need to be un-WIPped and processed.

Please see last week release countdown email[1] and from the
requirements team[2] for instructions, if you missed them.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/120574.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/120720.html

Note that stable/pike are under hard StringFreeze, in order to let the
I18N team do the translation work in good conditions. No change in
translatable strings is allowed at this point.


Upcoming Deadlines & Dates
--

Deadline for last release candidates / intermediary releases: August 24
Final Pike release: August 30
Queens PTG in Denver: Sept 11-15

As usual come find us on #openstack-release IRC channel if you have any
questions or concerns.

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [neutron] networking-sfc 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for networking-sfc for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-sfc/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/networking-sfc/log/?h=stable/pike

Release notes for networking-sfc can be found at:

http://docs.openstack.org/releasenotes/networking-sfc/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/networking-sfc

and tag it *pike-rc-potential* to bring it to the networking-sfc
release crew's attention.


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

[openstack-dev] [neutron] networking-midonet 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for networking-midonet for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-midonet/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:


http://git.openstack.org/cgit/openstack/networking-midonet/log/?h=stable/pike

Release notes for networking-midonet can be found at:

http://docs.openstack.org/releasenotes/networking-midonet/




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

[openstack-dev] [neutron] neutron-dynamic-routing 11.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for neutron-dynamic-routing for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-dynamic-routing/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:


http://git.openstack.org/cgit/openstack/neutron-dynamic-routing/log/?h=stable/pike

Release notes for neutron-dynamic-routing can be found at:

http://docs.openstack.org/releasenotes/neutron-dynamic-routing/




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

[openstack-dev] [neutron] networking-bagpipe 7.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for networking-bagpipe for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-bagpipe/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:


http://git.openstack.org/cgit/openstack/networking-bagpipe/log/?h=stable/pike

Release notes for networking-bagpipe can be found at:

http://docs.openstack.org/releasenotes/networking-bagpipe/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/networking-bagpipe

and tag it *pike-rc-potential* to bring it to the networking-bagpipe
release crew's attention.


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

[openstack-dev] [neutron] neutron-fwaas 11.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for neutron-fwaas for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-fwaas/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/neutron-fwaas/log/?h=stable/pike

Release notes for neutron-fwaas can be found at:

http://docs.openstack.org/releasenotes/neutron-fwaas/




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

[openstack-dev] [neutron] networking-bgpvpn 7.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for networking-bgpvpn for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-bgpvpn/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/networking-bgpvpn/log/?h=stable/pike

Release notes for networking-bgpvpn can be found at:

http://docs.openstack.org/releasenotes/networking-bgpvpn/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/bgpvpn

and tag it *pike-rc-potential* to bring it to the networking-bgpvpn
release crew's attention.


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

[openstack-dev] [neutron] neutron 11.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for neutron for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/neutron/log/?h=stable/pike

Release notes for neutron can be found at:

http://docs.openstack.org/releasenotes/neutron/




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

[openstack-dev] [neutron] networking-ovn 3.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for networking-ovn for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-ovn/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/networking-ovn/log/?h=stable/pike

Release notes for networking-ovn can be found at:

http://docs.openstack.org/releasenotes/networking-ovn/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/networking-ovn

and tag it *pike-rc-potential* to bring it to the networking-ovn
release crew's attention.


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

[openstack-dev] [neutron] networking-odl 11.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for networking-odl for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-odl/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/networking-odl/log/?h=stable/pike

Release notes for networking-odl can be found at:

http://docs.openstack.org/releasenotes/networking-odl/




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

Re: [openstack-dev] [ironic] support for various glance image reference formats - do we need them all?

[Mark Goddard]

Hi Pavlo,

#3 is used in Bifrost, where there is no Glance service but the default
driver is agent_ipmitool. The images are served by the local nginx service.
For example, taken from one ironic node:

'image_source':  u'http://10.41.253.100:8080/deployment_image.qcow2'

Mark

On 10 August 2017 at 08:20, Pavlo Shchelokovskyy <
pshchelokovs...@mirantis.com> wrote:

> HI Dmitry,
>
> On Tue, Aug 8, 2017 at 7:13 PM, Dmitry Tantsur 
> wrote:
>
>> Hi!
>>
>> Thanks for raising this.
>>
>> On 08/07/2017 02:47 PM, Pavlo Shchelokovskyy wrote:
>>
>>> Hi all,
>>>
>>> currently our GlanceImageService seems to support several ways of
>>> defining a reference to glance image:
>>>
>>> 1) simple image UUID [0]
>>> 2) image UUID prefixed with 'glance://' protocol [1] (well, actually
>>> anything starting with 'glance://' and ending with '/')
>>> 3) full REST path to the image (as in 
>>> http:///v2/images/),
>>> also used to extract the glance API address [2]
>>>
>>> Support for #3 must surely be removed, as we are moving to API endpoint
>>> discovery from keystone catalog.
>>> Besides I am pretty sure this code path can not actually be reached
>>> currently, as the 'is_glance_image' will ignore such image refs and return
>>> False for those [3], and 'get_image_service' would also not return the
>>> GlanceImageService instance for such image refs [4].
>>> Hence the question - if it is unusable anyway now, should we execute the
>>> standard deprecation process when removing support for it or just remove
>>> right away?
>>>
>>
>> If unsure, always use the standard process ;) Unless somebody is ready to
>> set up DevStack, and try it out, and prove that it's completely and
>> hopelessly broken.
>
>
> Did just that [0] - hacked up our tempest configuration so that the 'http'
> url for whole disk image used for *HttpLink standalone tests leads to
> /v2/images/ [1].
> As I kind of expected, both *HttpLink standalone tests failed, right on
> validating of the deploy interface when trying to do a HEAD on that URL
> instead of 'glance image show', receiving 401 [2].
> On a side note, it seems our logging is insufficient in this parts, as I
> could not find any relevant logs in ironic-conductor even at debug level,
> all that's there are final RPC processing error logs from api.
>
> So I am quite confident that this code paths [3] in service_utils is a
> dead end indeed :-/
>
> [0] https://review.openstack.org/#/c/492184/
> [1] http://logs.openstack.org/84/492184/1/check/gate-ironic-
> dsvm-standalone-ubuntu-xenial/32ea5de/logs/tempest_conf.txt.gz
> [2] http://logs.openstack.org/84/492184/1/check/gate-ironic-
> dsvm-standalone-ubuntu-xenial/32ea5de/logs/testr_results.html.gz
> [3] https://github.com/openstack/ironic/blob/
> 7e6ce7e78c4378f2f86d085df61a26507a410738/ironic/common/
> glance_service/service_utils.py#L159-L166
>
>
>>
>>
>>> As for the #1 and #2 I do not see any big difference between those, and
>>> proposed deprecating and eventually removing support for #2 ('glance://'
>>> scheme) as part of [5]. Two people in review already raised a concern about
>>> removing such support.
>>>
>>
>> To be honest, I like glance:// more, as it makes it obvious where
>> the image is coming from vs http://. I don't mind removing it too much,
>> but I guess supporting it is not a lot of code, right?
>>
>
> That's not too much burden indeed, as long as we actually do only that -
> as I said, right now it is more like "glance:///uuid"
>
>
>>
>>> Thus I'd like to ask a broader audience - do we need support for glance
>>> image references in 'glance://*' form? Is it actually used somewhere?
>>> What are the benefits of having it besides simple UUID?
>>>
>>> [0] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
>>> ommon/glance_service/service_utils.py#n149
>>> [1] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
>>> ommon/glance_service/service_utils.py#n155
>>> [2] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
>>> ommon/glance_service/service_utils.py#n160
>>> [3] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
>>> ommon/glance_service/service_utils.py#n208
>>> [4] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
>>> ommon/image_service.py#n267
>>> [5] https://review.openstack.org/#/c/467728
>>>
>>> Cheers,
>>>
>>> --
>>> Dr. Pavlo Shchelokovskyy
>>> Senior Software Engineer
>>> Mirantis Inc
>>> www.mirantis.com 
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 

[openstack-dev] [zaqar] zaqar 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for zaqar for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/zaqar/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/zaqar/log/?h=stable/pike

Release notes for zaqar can be found at:

http://docs.openstack.org/releasenotes/zaqar/




__
OpenStack Development Mailing 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] [octavia] octavia 1.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for octavia for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/octavia/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/octavia/log/?h=stable/pike

Release notes for octavia can be found at:

http://docs.openstack.org/releasenotes/octavia/




__
OpenStack Development Mailing 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] [octavia] neutron-lbaas-dashboard 3.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for neutron-lbaas-dashboard for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-lbaas-dashboard/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:


http://git.openstack.org/cgit/openstack/neutron-lbaas-dashboard/log/?h=stable/pike

Release notes for neutron-lbaas-dashboard can be found at:

http://docs.openstack.org/releasenotes/neutron-lbaas-dashboard/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/octavia

and tag it *pike-rc-potential* to bring it to the neutron-lbaas-dashboard
release crew's attention.


__
OpenStack Development Mailing 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] [zaqar] zaqar-ui 3.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for zaqar-ui for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/zaqar-ui/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/zaqar-ui/log/?h=stable/pike

Release notes for zaqar-ui can be found at:

http://docs.openstack.org/releasenotes/zaqar-ui/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/zaqar-ui

and tag it *pike-rc-potential* to bring it to the zaqar-ui
release crew's attention.


__
OpenStack Development Mailing 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] [octavia] neutron-lbaas 11.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for neutron-lbaas for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-lbaas/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/neutron-lbaas/log/?h=stable/pike

Release notes for neutron-lbaas can be found at:

http://docs.openstack.org/releasenotes/neutron-lbaas/




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

Re: [openstack-dev] [all][barbican][freezer][horizon][karbor][keystone][mistral][nova][pack-deb][refstack][solum][storlets][swift][tacker][telemetry][watcher][zaqar] Last days for PTL candidate announ

[Flavio Percoco]

On 10/08/17 14:04 -0400, Anita Kuno wrote:

On 2017-08-07 03:50 PM, Kendall Nelson wrote:

Hello Everyone :)

A quick reminder that we are in the last days for PTL candidate
announcements.

If you want to stand for PTL, don't delay, follow the instructions at [1]
to make sure the community knows your intentions.

Make sure your candidacy has been submitted to the openstack/election
repository and approved by election officials.

Election statistics[2]:

This means that with approximately 2.5 days left more than 27% of projects
will be deemed leaderless.  In this case the TC will be bound by [3].


I thought that the language in this sentence, that the TC is bound by
the referenced resolution was a bit of mis-stating the relationship,
but I thought I would let it pass and that things would work
themselves out. However having read the language in Emmett's post to
the TC reporting which programs don't have a self-nominated PTL, I'm
motivated to clarify.

The TC is not bound. The TC has agreed to follow a process. The
election officials are bound, in as much as they are obliged to
communicate the list of leaderless programs to the TC without delay.
The TC is enabled by the process, not bound by it.

The TC CAN appoint a leader, they are not obliged to appoint a leader.
The TC may do other things as well, it depends on the circumstances.

Also to clarify, the election officials serve the TC, not the other
way around.


I would like to clarify this sentence, though. I do not think the election
officials serve the TC, neither the TC serves the election officials. Both
bodies serve the community and the processes defined by it.

The fact the TC oversees the community does not mean the latter (or any group in
it) serves the TC. if anything, I'd prefer to think the TC serves the community
and the groups the conform it.

That said, I think we could argue for a long time on the terms and words used to
communicate the various relationships. While I believe words are extremely
important, I also believe they are a bit less important if the message goes 
through.

In this case the message is that there are cases of leaderless teams this time
around and there's a process we can, should, and will follow.

Thanks for the clarifications, Anita. Thanks for the hard work on the elections,
Kendall.
Flavio

--
@flaper87
Flavio Percoco


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

[openstack-dev] [mistral][ptl] PTL is on vacation on Aug 14-28

[Renat Akhmerov]

Hi,

I’ll be on vacation between Aug 14th and 28th.

Dougal Matthews (d0ugal in IRC) kindly agreed to replace me while I’m off. 
Please contact him, if needed.

Thanks

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

Re: [openstack-dev] [nova] Thanks gibi!

[Balazs Gibizer]

On Thu, Aug 10, 2017 at 8:43 PM, Jay Pipes  wrote:

On 08/10/2017 01:57 PM, Matt Riedemann wrote:
> Apparently we don't have community contributor awards at the PTG, 
only
> the summit, and seeing as that's several months away now, which is 
kind

> of an eternity, I wanted to take the time now to thank gibi (Balazs
> Gibizer to his parents) for all the work he's been doing in Nova.
>
> Not only does gibi lead the versioned notification transformation 
work,

> which includes running a weekly meeting (that only one other person
> shows up to) and sending a weekly status email, and does it in a
> ridiculously patient and kind way, but he's also been identifying
> several critical issues late in the release related to the 
Placement and

> claims in the scheduler work that's going on.
>
> And it's not just doing manual testing, reporting a bug and 
throwing it

> over the wall - which is a major feat in OpenStack on it's own - but
> also taking the time to write automated functional regression tests 
to

> exhibit the bugs so when we have a fix we can tell it's actually
> working, plus he's been fixing some on his own also.
>
> So with all that, I just wanted to formally and publicly say thanks 
to

> gibi for the great work he's doing which often goes overlooked when
> we're crunching toward a deadline.

Couldn't agree more. Thank you Gibi for your hard work and valuable
contributions over the last cycle and more. Your efforts have not gone
unnoticed.


Thank you guys for the nice words, the support, and the encouragement. 
I enjoy working with the community. So I'm planning to continue sending 
those bug reports in the future too.


Cheers,
gibi




All the best,
-jay

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

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



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

Re: [openstack-dev] [Openstack] 503 Errors for PUT and POST calls....

[Shyam Prasad N]

Hi Clay,

Thanks for the reply. And sorry for the late reply.
I should have added a few more details in the email.

The devices are mounted correctly and object-server is configured as
you advised. I'm not seeing these errors all the time. I was seeing it
on one of every ten to fifteen writes though. At the moment, I don't
see the errors though.
The permissions look fine to me. The swift processes are all running
with UID swiftuser, and swiftuser is the owner of the mount point and
has necessary permissions.

I'll jump into the IRC channel if I start seeing the errors again.



On Tue, Aug 8, 2017 at 9:54 PM, Clay Gerrard  wrote:
> Probably the "devices" option in the object server is misconfigured?
>
> On my lab and production servers I configure the object-server.conf with
>
> [DEFAULT]
> devices = /srv/node
>
> And then I make sure my mounted devices appear at:
>
> /srv/node/d1
> /srv/node/d2
> /srv/node/d3
>
> etc
>
> The path in the error message:
>
> /srv/xvdb1/node/xvdb1/
>
> Looks like the object-server.conf is configured with:
>
> devices = /srv/xvdb1/node
>
> And the ring has devices like "xvdb1"
>
> But as the error states: "No such file or directory at"
>
> devices + device => /srv/xvdb1/node/xvdb1/...
>
> And I trust the error that the path doesn't exist (or if it does maybe the
> swift processes don't have permissions?)
>
> Hope you can get it squared.  You might jump in IRC and join
> #openstack-swift on Freenode for some more iterative feedback (I'd recommend
> irccloud.com if you're new to IRC).
>
> GL,
>
> -Clay
>
>
> On Tue, Aug 8, 2017 at 2:54 AM, Shyam Prasad N 
> wrote:
>>
>> Hi,
>>
>> In my openstack swift cluster, I'm seeing a lot of 503 errors as a
>> result of tracebacks in swift logs with "No such file or directory"
>> exceptions...
>> # grep -Rnw txdaba05e70c6b4dfaa5884-0059895aca /var/log/swift/*
>> /var/log/swift/proxy.error:31030:Aug  7 23:31:39
>> BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c proxy-server: ERROR 500
>> Traceback (most recent call last):#012  File
>> "/usr/lib/python2.7/dist-packages/swift/obj/server.py", line 1032, in
>> __call__#012res = method(req)#012  File
>> "/usr/lib/python2.7/dist-packages/swift/common/utils.py", line 1412,
>> in _timing_stats#012resp = func(ctrl, *args, **kwargs)#012  File
>> "/usr/lib/python2.7/dist-packages/swift/obj/server.py", line 751, in
>> PUT#012writer.put(metadata)#012  File
>> "/usr/lib/python2.7/dist-packages/swift/obj/diskfile.py", line 2451,
>> in put#012super(DiskFileWriter, self)._put(metadata, True)#012
>> File "/usr/lib/python2.7/dist-packages/swift/obj/diskfile.py", line
>> 1476, in _put#012self._finalize_put, metadata, target_path,
>> cleanup)#012  File
>> "/usr/lib/python2.7/dist-packages/swift/common/utils.py", line 3342,
>> in force_run_in_thread#012return self._run_in_eventlet_tpool(func,
>> *args, **kwargs)#012  File
>> "/usr/lib/python2.7/dist-packages/swift/common/utils.py", line 3322,
>> in _run_in_eventlet_tpool#012raise result#012OSError: [Errno 2] No
>> such file or directory#012 From Object Server re:
>>
>> /v1/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1
>> 10.3.60.8:6010/xvdb1 (txn: txdaba05e70c6b4dfaa5884-0059895aca)
>> (client_ip: 10.3.60.11)
>> /var/log/swift/proxy.error:31031:Aug  7 23:31:39
>> BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c proxy-server: Object
>> PUT returning 503 for [500, 201] (txn:
>> txdaba05e70c6b4dfaa5884-0059895aca) (client_ip: 10.3.60.11)
>> /var/log/swift/proxy.error:31032:Aug  7 23:31:39
>> BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c proxy-server: STDERR:
>> 10.3.60.11 - - [08/Aug/2017 06:31:39] "PUT
>>
>> /v1/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1
>> HTTP/1.1" 503 346 1.553481 (txn: txdaba05e70c6b4dfaa5884-0059895aca)
>> /var/log/swift/proxy.log:27701:Aug  7 23:31:39
>> BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c proxy-server:
>> 10.3.60.11 10.3.60.11 08/Aug/2017/06/31/39 PUT
>>
>> /v1/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1
>> HTTP/1.0 503 - - AUTH_tke6014ecd5... 16777216 118 -
>> txdaba05e70c6b4dfaa5884-0059895aca - 1.5526 - - 1502173898.383203983
>> 1502173899.935844898 0
>> /var/log/swift/storage1.log:41634:Aug  7 23:31:39
>> BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c object-server:
>> 10.3.60.8 - - [08/Aug/2017:06:31:39 +] "PUT
>>
>> /xvdb1/118/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1"
>> 500 981 "PUT
>> http://10.3.60.8:8080/v1/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1;
>> "txdaba05e70c6b4dfaa5884-0059895aca" "proxy-server 2117" 1.0534 "-"
>> 2127 0
>> /var/log/swift/storage2.log:128852:Aug  7 23:31:39
>> BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c container-server:
>> 10.3.60.9 - - [08/Aug/2017:06:31:39 +] "PUT
>>
>> 

[openstack-dev] [dns]I want to ask questions about designate

[daixianm...@yovole.com]

Hello, I am doing the DNS research on the DNS:

My environment:

Centos7.2, Ocata version, builds according to the document of the official 
website, builds success.

The virtual machine created by default has dnsname, such as vm01.example.org, 
which can ping into it.


Ny problem is:

1. Only the domain name between the same subnet and the domain name can be ping 
into it.

2. The virtual machine has internally modified the virtual machine hostname, 
but the domain name corresponding to the vm is still old. What should I do to 
update it?

3. Create domain (example02.org) to be updated to subnet, but use the subnet to 
create virtual machine, domain suffix is still example.org, not example02.org.


I want to know the plan of designate, where can I find the doc?


Thank you!


daixianm...@yovole.com

保密：本函仅供收件人使用，如阁下并非抬头标明的收件人，请您即刻删除本函，勿以任何方式使用及传播，并请您能将此误发情形通知发件人，谢谢！
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev