[openstack-dev] [manila] Rocky Review Focus

[Tom Barron]

It's less than a month till Milestone 3 so I've posted an etherpad 
with the new Manila driver and feature work that we've agreed to try 
to merge in Rocky:


 https://etherpad.openstack.org/p/manila-rocky-review-focus

These are making good progress but in general need more review 
attention.  Please take a look and add your name to the etherpad next 
to particular reviews so that we can all see where we need more 
reviewers.


Please don't feel like you need to be a current core reviewer or 
established in the manila community to add your name to the etherpad 
or to do reviews!


-- Tom Barron


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

Re: [openstack-dev] [Release-job-failures][release][horizon] Release of openstack/xstatic-angular-material failed

[Doug Hellmann]

Excerpts from zuul's message of 2018-06-25 12:14:34 +:
> Build failed.
> 
> - xstatic-check-version 
> http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41ac8a67d909b/release/xstatic-check-version/a501dba/
>  : FAILURE in 1m 31s
> - release-openstack-python release-openstack-python : SKIPPED
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED
> 

"git tag version (1.1.5.1) does not match package version (1.1.5.0)"

http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41ac8a67d909b/release/xstatic-check-version/a501dba/job-output.txt.gz#_2018-06-25_12_14_11_034599

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

Re: [openstack-dev] [Release-job-failures] Release of openstack/xstatic-angular-material failed

[Sean McGinnis]

This release failed due to the version set in source being different than
the tag being requested.

I've proposed https://review.openstack.org/577828 to add checks to our
validation job to catch these issues. Hopefully that will prevent this from
happening again.

For this release though, we will need a new 1.1.5.2 release requested after
the version has been updated in the repo source.

On Mon, Jun 25, 2018 at 7:14 AM,  wrote:

> Build failed.
>
> - xstatic-check-version http://logs.openstack.org/59/
> 592a9d4c90f37cd33c6f861120f41ac8a67d909b/release/xstatic-
> check-version/a501dba/ : FAILURE in 1m 31s
> - release-openstack-python release-openstack-python : SKIPPED
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED
>
> ___
> Release-job-failures mailing list
> release-job-failu...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures
>
__
OpenStack Development Mailing 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][requirements] we need to talk about eventlet

[Matthew Thode]

On 18-06-25 08:59:23, Doug Hellmann wrote:
> Excerpts from Matthew Thode's message of 2018-06-24 02:42:23 -0500:
> > The short of it is that we are currently using eventlet 0.20.0.  The bot
> > proposes 0.22.1 which fails updates, I think we need to start bugging
> > projects that fail the cross test jobs.  What do you think?
> > 
> 
> By "bugging" do you mean we should file bugs, or something else?
> 

Yes, to start, it'd look something like this.

https://bugs.launchpad.net/openstack-requirements/+bug/1749574

> Which version of eventlet is actually being used in the various
> distros?
> 

For Gentoo it's 0.20.1 right now, but that's mainly because I haven't
updated it myself (because Openstack).

-- 
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] [all][requirements] we need to talk about eventlet

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2018-06-24 02:42:23 -0500:
> The short of it is that we are currently using eventlet 0.20.0.  The bot
> proposes 0.22.1 which fails updates, I think we need to start bugging
> projects that fail the cross test jobs.  What do you think?
> 

By "bugging" do you mean we should file bugs, or something else?

Which version of eventlet is actually being used in the various
distros?

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] [Release-job-failures][release][horizon] Release of openstack/xstatic-angular-material failed

[Andreas Jaeger]

On 2018-06-25 14:57, Radomir Dopieralski wrote:
> Any idea where it took the 1.1.5.0 version from?

git grep 1.1.5 shows at least:

setup.cfg:description = Angular-Material 1.1.5 (XStatic packaging standard)
xstatic/pkg/angular_material/__init__.py:VERSION = '1.1.5'  # version of
the packaged files, please use the upstream

Not sure whether that's the right place, I suggest you build locally and
check the build tarball,

Andreas

> On Mon, Jun 25, 2018 at 2:38 PM, Doug Hellmann  > wrote:
> 
> Excerpts from zuul's message of 2018-06-25 12:14:34 +:
> > Build failed.
> >
> > - xstatic-check-version
> 
> http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41ac8a67d909b/release/xstatic-check-version/a501dba/
> 
> 
> : FAILURE in 1m 31s
> > - release-openstack-python release-openstack-python : SKIPPED
> > - announce-release announce-release : SKIPPED
> > - propose-update-constraints propose-update-constraints : SKIPPED
> >
> 
> "git tag version (1.1.5.1) does not match package version (1.1.5.0)"
> 
> 
> http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41ac8a67d909b/release/xstatic-check-version/a501dba/job-output.txt.gz#_2018-06-25_12_14_11_034599
> 
> 
> 
> __
> OpenStack Development Mailing 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
> 


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


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

Re: [openstack-dev] [Openstack-sigs] [PTG] Updates!

[Doug Hellmann]

Are we planning to have space for goal teams to answer
implementation questions?

Doug

Excerpts from Kendall Nelson's message of 2018-06-20 11:24:38 -0700:
> Hello Everyone!
> 
> Wanted to give you some updates on PTG4 planning. We have finalized the
> list of SIGs/ Groups/WGs/Teams that are attending. They are as follows:
> 
>-
> 
>Airship
>-
> 
>API SIG
>-
> 
>Barbican/Security SIG
>-
> 
>Blazar
>-
> 
>Chef OpenStack
>-
> 
>Cinder
>-
> 
>Cyborg
>-
> 
>Designate
>-
> 
>Documentation
>-
> 
>Edge Computing Group
>-
> 
>First Contact SIG
>-
> 
>Glance
>-
> 
>Heat
>-
> 
>Horizon
>-
> 
>Infrastructure
>-
> 
>Interop WG
> 
> 
>-
> 
>Ironic
>-
> 
>Kata
>-
> 
>Keystone
>-
> 
>Kolla
>-
> 
>LOCI
>-
> 
>Manila
>-
> 
>Masakari
>-
> 
>Mistral
>-
> 
>Monasca
>-
> 
>Neutron
>-
> 
>Nova
>-
> 
>Octavia
>-
> 
>OpenStack Ansible
>-
> 
>OpenStack Charms
>-
> 
>OpenStack Helm
>-
> 
>OpenStackClient
> 
> 
> 
>-
> 
>Operator Meetup
>Puppet OpenStack
>-
> 
>QA
>-
> 
>Oslo
>-
> 
>Public Cloud WG
>-
> 
>Release Management
>-
> 
>Requirements
>-
> 
>Sahara
>-
> 
>Scientific SIG
>-
> 
>Self-Healing SIG
>-
> 
>SIG- K8s
>-
> 
>StarlingX
>-
> 
>Swift
>-
> 
>TC
>-
> 
>TripleO
>-
> 
>Upgrades SIG
>-
> 
>Watcher
>-
> 
>Zuul (pending confirmation)
> 
> Thierry and I are working on placing them into a strawman schedule to
> reduce conflicts between related or overlapping groups. We should have more
> on what that will look like and a draft for you all to review in the next
> few weeks.
> 
> We also wanted to remind you all of the Travel Support Program. We are
> again doing a two phase selection. The first deadline is approaching: July
> 1st. At this point we have less than a dozen applicants so if you need it
> or even think you need it, I urge you to apply here[1].
> 
> Also! Reminder that we have a finite number of rooms in the hotel block so
> please book early to make sure you get the discounted rate before they run
> out. You can book those rooms here[2] (pardon the ugly URL).
> 
> Can't wait to see you all there!
> 
> -Kendall Nelson (diablo_rojo)
> 
> P.S. Gonna try to do a game night again since you all seemed to enjoy it so
> much last time :)
> 
> [1]
> https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018
> 
> [2]
> https://www.marriott.com/meeting-event-hotels/group-corporate-travel/groupCorp.mi?resLinkData=Project%20Teams%20Gathering%2C%20Openstack%5Edensa%60opnopna%7Copnopnb%60149.00%60USD%60false%604%609/5/18%609/18/18%608/20/18=resvlink_mobi=yes

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

Re: [openstack-dev] [Release-job-failures][release][horizon] Release of openstack/xstatic-angular-material failed

[Radomir Dopieralski]

A fix for it is in review: https://review.openstack.org/577820

On Mon, Jun 25, 2018 at 3:07 PM, Andreas Jaeger  wrote:

> On 2018-06-25 14:57, Radomir Dopieralski wrote:
> > Any idea where it took the 1.1.5.0 version from?
>
> git grep 1.1.5 shows at least:
>
> setup.cfg:description = Angular-Material 1.1.5 (XStatic packaging standard)
> xstatic/pkg/angular_material/__init__.py:VERSION = '1.1.5'  # version of
> the packaged files, please use the upstream
>
> Not sure whether that's the right place, I suggest you build locally and
> check the build tarball,
>
> Andreas
>
> > On Mon, Jun 25, 2018 at 2:38 PM, Doug Hellmann  > > wrote:
> >
> > Excerpts from zuul's message of 2018-06-25 12:14:34 +:
> > > Build failed.
> > >
> > > - xstatic-check-version
> > http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41a
> c8a67d909b/release/xstatic-check-version/a501dba/
> >  c8a67d909b/release/xstatic-check-version/a501dba/>
> > : FAILURE in 1m 31s
> > > - release-openstack-python release-openstack-python : SKIPPED
> > > - announce-release announce-release : SKIPPED
> > > - propose-update-constraints propose-update-constraints : SKIPPED
> > >
> >
> > "git tag version (1.1.5.1) does not match package version (1.1.5.0)"
> >
> > http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41a
> c8a67d909b/release/xstatic-check-version/a501dba/job-
> output.txt.gz#_2018-06-25_12_14_11_034599
> >  c8a67d909b/release/xstatic-check-version/a501dba/job-
> output.txt.gz#_2018-06-25_12_14_11_034599>
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >  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
> >
>
>
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Release-job-failures][release][horizon] Release of openstack/xstatic-angular-material failed

[Akihiro Motoki]

First of all, thanks for the release team and Radomir.

Apart from the fix, is there any good way to detect this kind of errors in
individual project reviews?
xstatic-cores have new members and all of them are not necessarily super
familiar with the xstatic process.
In addition, updates in xstatic repos do not happen often, so we
xstatic-cores (including horizon-cores)
tend to forget minor corner cases

I believe this failure is a symptom that we should add more checks in
xstatic repo gates rather than "noop" :(

Akihiro


2018年6月25日(月) 22:37 Radomir Dopieralski :

> A fix for it is in review: https://review.openstack.org/577820
>
> On Mon, Jun 25, 2018 at 3:07 PM, Andreas Jaeger  wrote:
>
>> On 2018-06-25 14:57, Radomir Dopieralski wrote:
>> > Any idea where it took the 1.1.5.0 version from?
>>
>> git grep 1.1.5 shows at least:
>>
>> setup.cfg:description = Angular-Material 1.1.5 (XStatic packaging
>> standard)
>> xstatic/pkg/angular_material/__init__.py:VERSION = '1.1.5'  # version of
>> the packaged files, please use the upstream
>>
>> Not sure whether that's the right place, I suggest you build locally and
>> check the build tarball,
>>
>> Andreas
>>
>> > On Mon, Jun 25, 2018 at 2:38 PM, Doug Hellmann > > > wrote:
>> >
>> > Excerpts from zuul's message of 2018-06-25 12:14:34 +:
>> > > Build failed.
>> > >
>> > > - xstatic-check-version
>> >
>> http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41ac8a67d909b/release/xstatic-check-version/a501dba/
>> > <
>> http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41ac8a67d909b/release/xstatic-check-version/a501dba/
>> >
>> > : FAILURE in 1m 31s
>> > > - release-openstack-python release-openstack-python : SKIPPED
>> > > - announce-release announce-release : SKIPPED
>> > > - propose-update-constraints propose-update-constraints : SKIPPED
>> > >
>> >
>> > "git tag version (1.1.5.1) does not match package version (1.1.5.0)"
>> >
>> >
>> http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41ac8a67d909b/release/xstatic-check-version/a501dba/job-output.txt.gz#_2018-06-25_12_14_11_034599
>> > <
>> http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41ac8a67d909b/release/xstatic-check-version/a501dba/job-output.txt.gz#_2018-06-25_12_14_11_034599
>> >
>> >
>> >
>>  __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > <
>> http://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
>> >
>>
>>
>> --
>>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>>HRB 21284 (AG Nürnberg)
>> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing 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] [tc] Technical Committee update for 25 June

[Doug Hellmann]

This is the weekly summary of work being done by the Technical
Committee members. The full list of active items is managed in the
wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923

== Recent Activity ==

Other approved changes:

* add champion section to goal template https://review.openstack.org/575934
* a "castellan-compatible key store" is now part of the base services
  list
  
https://governance.openstack.org/tc/reference/base-services.html#current-list-of-base-services

Office hour logs from last week:

* http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-19-09.00.html
* http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-20-01.09.html
* http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-21-15.00.html

A few folks expressed concern that using the meeting bot to record the
office hours made them more like a meeting. It would be useful to have
some feedback from the community about whether having the logs separate
is helfpul, or if linking to the timestamp in the regular channel logs
would be sufficient.


== Ongoing Discussions ==

The Adjutant team application was updated.

* https://review.openstack.org/553643

Thierry started drafting a "technical design tenets" chapter for the
project team guide as a place to explain topics like base services and
other things we expect to be common development patterns in the
community.

* https://storyboard.openstack.org/#!/story/2002611

== TC member actions/focus/discussions for the coming week(s) ==

Project team "health check" interviews continue. Our goal is to check in
with each team between now and the PTG, and record notes in the wiki.

* https://wiki.openstack.org/wiki/OpenStack_health_tracker

Remember that we agreed to send status updates on initiatives separately
to openstack-dev every two weeks. If you are working on something for
which there has not been an update in a couple of weeks, please consider
summarizing the status.

== Contacting the TC ==

The Technical Committee uses a series of weekly "office hour" time
slots for synchronous communication. We hope that by having several
such times scheduled, we will have more opportunities to engage
with members of the community from different timezones.

Office hour times in #openstack-tc:

* 09:00 UTC on Tuesdays
* 01:00 UTC on Wednesdays
* 15:00 UTC on Thursdays

If you have something you would like the TC to discuss, you can add
it to our office hour conversation starter etherpad
at:https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

Many of us also run IRC bouncers which stay in #openstack-tc most
of the time, so please do not feel that you need to wait for an
office hour time to pose a question or offer a suggestion. You can
use the string "tc-members" to alert the members to your question.

If you expect your topic to require significant discussion or to
need input from members of the community other than the TC, please
start a mailing list discussion on openstack-dev at lists.openstack.org
and use the subject tag "[tc]" to bring it to the attention of TC
members.


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

Re: [openstack-dev] [Release-job-failures][release][horizon] Release of openstack/xstatic-angular-material failed

[Radomir Dopieralski]

Any idea where it took the 1.1.5.0 version from?

On Mon, Jun 25, 2018 at 2:38 PM, Doug Hellmann 
wrote:

> Excerpts from zuul's message of 2018-06-25 12:14:34 +:
> > Build failed.
> >
> > - xstatic-check-version http://logs.openstack.org/59/
> 592a9d4c90f37cd33c6f861120f41ac8a67d909b/release/xstatic-
> check-version/a501dba/ : FAILURE in 1m 31s
> > - release-openstack-python release-openstack-python : SKIPPED
> > - announce-release announce-release : SKIPPED
> > - propose-update-constraints propose-update-constraints : SKIPPED
> >
>
> "git tag version (1.1.5.1) does not match package version (1.1.5.0)"
>
> http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41a
> c8a67d909b/release/xstatic-check-version/a501dba/job-
> output.txt.gz#_2018-06-25_12_14_11_034599
>
> __
> OpenStack Development Mailing 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] [cinder] making volume available without stopping VM

[Chris Friesen]

On 06/23/2018 08:38 AM, Volodymyr Litovka wrote:

Dear friends,

I did some tests with making volume available without stopping VM. I'm using
CEPH and these steps produce the following results:

1) openstack volume set --state available [UUID]
- nothing changed inside both VM (volume is still connected) and CEPH
2) openstack volume set --size [new size] --state in-use [UUID]
- nothing changed inside VM (volume is still connected and has an old size)
- size of CEPH volume changed to the new value
3) during these operations I was copying a lot of data from external source and
all md5 sums are the same on both VM and source
4) changes on VM happens upon any kind of power-cycle (e.g. reboot (either soft
or hard): openstack server reboot [--hard] [VM uuid] )
- note: NOT after 'reboot' from inside VM

It seems, that all these manipilations with cinder just update internal
parameters of cinder/CEPH subsystems, without immediate effect for VMs. Is it
safe to use this mechanism in this particular environent (e.g. CEPH as backend)?


There are a different set of instructions[1] which imply that the change should 
be done via the hypervisor, and that the guest will then see the changes 
immediately.


Also, If you resize the backend in a way that bypasses nova, I think it will 
result in the placement data being wrong.  (At least temporarily.)


Chris


[1] 
https://wiki.skytech.dk/index.php/Ceph_-_howto,_rbd,_lvm,_cluster#Online_resizing_of_KVM_images_.28rbd.29



__
OpenStack Development Mailing 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][requirements] we need to talk about eventlet

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2018-06-25 09:38:28 -0500:
> On 18-06-25 08:59:23, Doug Hellmann wrote:
> > Excerpts from Matthew Thode's message of 2018-06-24 02:42:23 -0500:
> > > The short of it is that we are currently using eventlet 0.20.0.  The bot
> > > proposes 0.22.1 which fails updates, I think we need to start bugging
> > > projects that fail the cross test jobs.  What do you think?
> > > 
> > 
> > By "bugging" do you mean we should file bugs, or something else?
> > 
> 
> Yes, to start, it'd look something like this.
> 
> https://bugs.launchpad.net/openstack-requirements/+bug/1749574

OK, tracking issues like that will work. You might also need a
storyboard story for projects that have already migrated.

> 
> > Which version of eventlet is actually being used in the various
> > distros?
> > 
> 
> For Gentoo it's 0.20.1 right now, but that's mainly because I haven't
> updated it myself (because Openstack).
> 

__
OpenStack Development Mailing 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-sigs] [PTG] Updates!

[Thierry Carrez]

Doug Hellmann wrote:

Are we planning to have space for goal teams to answer
implementation questions?


At previous PTGs the "goal rooms" ended up not being used (or very very 
poorly-attended), so our current plan was to not allocate specific 
space, but leverage the "Ask me anything" project help room to answer 
those questions as well. It shall be a large room, so plenty of space to 
do that... and probably nicer compared to waiting in a smaller, 
dedicated but mostly empty room.


That said, if we have people signed up to run a specific room, and 
people interested in joining that, I'm happy allocating space on Monday 
or Tuesday for that...


Otherwise there is always the option to schedule in reservable space 
using ptgbot on the fly :)


--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all][requirements] we need to talk about eventlet

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2018-06-25 10:19:50 -0500:
> On 18-06-25 10:58:26, Doug Hellmann wrote:
> > Excerpts from Matthew Thode's message of 2018-06-25 09:38:28 -0500:
> > > On 18-06-25 08:59:23, Doug Hellmann wrote:
> > > > Excerpts from Matthew Thode's message of 2018-06-24 02:42:23 -0500:
> > > > > The short of it is that we are currently using eventlet 0.20.0.  The 
> > > > > bot
> > > > > proposes 0.22.1 which fails updates, I think we need to start bugging
> > > > > projects that fail the cross test jobs.  What do you think?
> > > > > 
> > > > 
> > > > By "bugging" do you mean we should file bugs, or something else?
> > > > 
> > > 
> > > Yes, to start, it'd look something like this.
> > > 
> > > https://bugs.launchpad.net/openstack-requirements/+bug/1749574
> > 
> > OK, tracking issues like that will work. You might also need a
> > storyboard story for projects that have already migrated.
> > 
> 
> Ya, I'm not sure what to do there.  Requirements hasn't migrated because
> other projects haven't migrated (we really need to be on both systems
> unfortunately).  Is it possible to half migrate?
> 

That's a question for the SB team, although I'm not sure I see why it's
needed. If you're going to have a story and a LP bug, couldn't you just
link to one from the other to avoid having to tag the requirements repo
twice?

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][requirements] we need to talk about eventlet

[Jeremy Stanley]

On 2018-06-25 10:19:50 -0500 (-0500), Matthew Thode wrote:
> On 18-06-25 10:58:26, Doug Hellmann wrote:
> > Excerpts from Matthew Thode's message of 2018-06-25 09:38:28 -0500:
> > > On 18-06-25 08:59:23, Doug Hellmann wrote:
> > > > Excerpts from Matthew Thode's message of 2018-06-24 02:42:23 -0500:
> > > > > The short of it is that we are currently using eventlet 0.20.0.  The 
> > > > > bot
> > > > > proposes 0.22.1 which fails updates, I think we need to start bugging
> > > > > projects that fail the cross test jobs.  What do you think?
> > > > > 
> > > > 
> > > > By "bugging" do you mean we should file bugs, or something else?
> > > > 
> > > 
> > > Yes, to start, it'd look something like this.
> > > 
> > > https://bugs.launchpad.net/openstack-requirements/+bug/1749574
> > 
> > OK, tracking issues like that will work. You might also need a
> > storyboard story for projects that have already migrated.
> > 
> 
> Ya, I'm not sure what to do there.  Requirements hasn't migrated because
> other projects haven't migrated (we really need to be on both systems
> unfortunately).  Is it possible to half migrate?

The SB migration script is set up to handle incremental importing,
so this could be an option in theory. In practice, we've not really
used it to pull in updates for the same project over a span of more
than a week, though it does basically still happen for shared bugs
in LP where not all projects with bugtasks get imported in the same
timeframe.
-- 
Jeremy Stanley


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] [Openstack-sigs] [PTG] Updates!

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2018-06-25 16:01:11 +:
> On 2018-06-25 11:26:29 -0400 (-0400), Doug Hellmann wrote:
> > Excerpts from Thierry Carrez's message of 2018-06-25 17:15:44 +0200:
> > > Doug Hellmann wrote:
> > > > Are we planning to have space for goal teams to answer
> > > > implementation questions?
> > > 
> > > At previous PTGs the "goal rooms" ended up not being used (or very very 
> > > poorly-attended), so our current plan was to not allocate specific 
> > > space, but leverage the "Ask me anything" project help room to answer 
> > > those questions as well. It shall be a large room, so plenty of space to 
> > > do that... and probably nicer compared to waiting in a smaller, 
> > > dedicated but mostly empty room.
> > > 
> > > That said, if we have people signed up to run a specific room, and 
> > > people interested in joining that, I'm happy allocating space on Monday 
> > > or Tuesday for that...
> > > 
> > > Otherwise there is always the option to schedule in reservable space 
> > > using ptgbot on the fly :)
> > > 
> > 
> > OK. Given the complexity of the zuul configuration changes for the
> > python3 goal, I anticipated some questions. I will be prepared to
> > talk to people about it regardless, and maybe we won't need a
> > separate room.
> 
> I think the up side to the current plan is that there are likely to
> also be Zuulies in that same room answering Zuulish sorts of
> questions anyway, so easier to get input on goal-specific topics
> where there is such an overlap.

OK, that makes a lot of sense. I didn't see anything on the list
here that looked like an "ask me anything" room but maybe I missed
it or this list was just project teams? Either way, as long as we have
some space, it's fine.

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][requirements] we need to talk about eventlet

[Matthew Thode]

On 18-06-25 10:58:26, Doug Hellmann wrote:
> Excerpts from Matthew Thode's message of 2018-06-25 09:38:28 -0500:
> > On 18-06-25 08:59:23, Doug Hellmann wrote:
> > > Excerpts from Matthew Thode's message of 2018-06-24 02:42:23 -0500:
> > > > The short of it is that we are currently using eventlet 0.20.0.  The bot
> > > > proposes 0.22.1 which fails updates, I think we need to start bugging
> > > > projects that fail the cross test jobs.  What do you think?
> > > > 
> > > 
> > > By "bugging" do you mean we should file bugs, or something else?
> > > 
> > 
> > Yes, to start, it'd look something like this.
> > 
> > https://bugs.launchpad.net/openstack-requirements/+bug/1749574
> 
> OK, tracking issues like that will work. You might also need a
> storyboard story for projects that have already migrated.
> 

Ya, I'm not sure what to do there.  Requirements hasn't migrated because
other projects haven't migrated (we really need to be on both systems
unfortunately).  Is it possible to half migrate?

-- 
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] [Openstack-sigs] [PTG] Updates!

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2018-06-25 17:15:44 +0200:
> Doug Hellmann wrote:
> > Are we planning to have space for goal teams to answer
> > implementation questions?
> 
> At previous PTGs the "goal rooms" ended up not being used (or very very 
> poorly-attended), so our current plan was to not allocate specific 
> space, but leverage the "Ask me anything" project help room to answer 
> those questions as well. It shall be a large room, so plenty of space to 
> do that... and probably nicer compared to waiting in a smaller, 
> dedicated but mostly empty room.
> 
> That said, if we have people signed up to run a specific room, and 
> people interested in joining that, I'm happy allocating space on Monday 
> or Tuesday for that...
> 
> Otherwise there is always the option to schedule in reservable space 
> using ptgbot on the fly :)
> 

OK. Given the complexity of the zuul configuration changes for the
python3 goal, I anticipated some questions. I will be prepared to
talk to people about it regardless, and maybe we won't need a
separate room.

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-dev] [oslo][python3] testing the python3-first goal steps with oslo libraries

[Doug Hellmann]

We have already started some of the work to move Oslo to python3-first,
and I would like to work through the remaining steps as a way of testing
the goal documentation. Please take a look at the documentation [1] and
let me know if you have any concerns or questions about us doing that.

Thanks,
Doug

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

__
OpenStack Development Mailing 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] SOFT_REBOOT powers off/on the server

[Ben Nemec]

A soft reboot should allow the server to shut down gracefully.  A reset 
wouldn't do that, at least as I understand it.  A reset would be more 
appropriate for a hard reboot, although I see Dmitry had a couple of 
other concerns with implementing it as a reset on the review.


-Ben

On 06/25/2018 05:31 AM, Lenny Berkhovsky wrote:

Hi,

Is there a reason for powering off and on[1] instead of resetting server 
during SOFT_REBOOT?


I have a patchset[2] that resets the server instead of power cycling it.

[1] 
https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/ipmitool.py#L820


   elif power_state == states.SOFT_REBOOT:

     _soft_power_off(task, driver_info, timeout=timeout)

     driver_utils.ensure_next_boot_device(task, driver_info)

     _power_on(task, driver_info, timeout=timeout)

[2] https://review.openstack.org/#/c/577748/

Lenny Verkhovsky

( aka lennyb )



__
OpenStack Development Mailing 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-sigs] [PTG] Updates!

[Jeremy Stanley]

On 2018-06-25 11:26:29 -0400 (-0400), Doug Hellmann wrote:
> Excerpts from Thierry Carrez's message of 2018-06-25 17:15:44 +0200:
> > Doug Hellmann wrote:
> > > Are we planning to have space for goal teams to answer
> > > implementation questions?
> > 
> > At previous PTGs the "goal rooms" ended up not being used (or very very 
> > poorly-attended), so our current plan was to not allocate specific 
> > space, but leverage the "Ask me anything" project help room to answer 
> > those questions as well. It shall be a large room, so plenty of space to 
> > do that... and probably nicer compared to waiting in a smaller, 
> > dedicated but mostly empty room.
> > 
> > That said, if we have people signed up to run a specific room, and 
> > people interested in joining that, I'm happy allocating space on Monday 
> > or Tuesday for that...
> > 
> > Otherwise there is always the option to schedule in reservable space 
> > using ptgbot on the fly :)
> > 
> 
> OK. Given the complexity of the zuul configuration changes for the
> python3 goal, I anticipated some questions. I will be prepared to
> talk to people about it regardless, and maybe we won't need a
> separate room.

I think the up side to the current plan is that there are likely to
also be Zuulies in that same room answering Zuulish sorts of
questions anyway, so easier to get input on goal-specific topics
where there is such an overlap.
-- 
Jeremy Stanley


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

[openstack-dev] [neutron] Networking projects not setup properly for Zuul v3 and local testing

[Boden Russell]

It appears a number of networking related projects aren't setup properly
for Zuul v3 gate jobs, as well as for local testing when it comes to
pulling in dependencies from source.

Since this may not be a common concept, ask yourself: "should my
project's master branch source be running with and tested against
neutron's (or other projects) master branch source"? If the answer is
yes, this may impact you.

I started a brain-dump on etherpad [1] for this topic and best I can
tell a number of networking projects are impacted.

I would like to please ask networking related projects that are "staying
current" to have a look.

Thanks!

[1] https://etherpad.openstack.org/p/neutron-sibling-setup


__
OpenStack Development Mailing 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] Adding hostId to metadata

[Michael Still]

We only bump the version if something has changed IIRC. I think bumping
when nothing has changed would create a burden for implementers of client
software. So its not like you get a chance to sneak this in "for free".

Does this information really need to be available in the host OS? Its
trivial to look it up via our existing APIs outside the host, although
possibly less trivial if the instance has already been deleted.

Michael

On Tue, Jun 26, 2018 at 7:30 AM Mohammed Naser  wrote:

> Hi everyone:
>
> While working with the OpenStack infrastructure team, we noticed that
> we were having some intermittent issues where we wanted to identify a
> theory if all VMs with this issue were landing on the same hypervisor.
>
> However, there seems to be no way of directly accessing `hostId` from
> inside the virtual machine (such as using the metadata API).  This is
> a very useful thing to expose over the metadata API as not only would
> it help for troubleshooting these types of scenarios however it would
> also help software that can manage anti-affinity simply by checking
> the API and taking scheduling decisions.
>
> I've proposed the following patch to add this[1], however, this is
> technically an API change, and the blueprints document specifies that
> "API changes always require a design discussion."
>
> Also, I believe that we're in a state where getting a spec would
> require an exception.  However, this is a very trivial change.  Also,
> according to the notes in the metadata file, it looks like there is
> one "bump" per OpenStack release[3] which means that this change can
> just be part of that release-wide version bump of the OpenStack API.
>
> Can we include this trivial patch in the upcoming Rocky release?
>
> Thanks,
> Mohammed
>
> [1]: https://review.openstack.org/577933
> [2]: https://docs.openstack.org/nova/latest/contributor/blueprints.html
> [3]:
> http://git.openstack.org/cgit/openstack/nova/tree/nova/api/metadata/base.py#n60
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Did this email leave you hoping to cause me pain? Good news!
Sponsor me in city2surf 2018 and I promise to suffer greatly.
http://www.madebymikal.com/city2surf-2018/
__
OpenStack Development Mailing 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][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Lance Bragstad]

Keystone is hitting this, too [0]. I attempted the same solution that
Tony posted, but no luck. I've even gone so far as removing every
comment from the module to see if that helps narrow down the problem
area, but sphinx still trips. The output from the error message isn't
very descriptive either. Has anyone else had issues fixing this for
python comments, not just docstrings?

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

On 06/20/2018 11:52 PM, Takashi Yamamoto wrote:
> On Thu, Jun 21, 2018 at 12:13 PM, Tony Breeds  wrote:
>> On Wed, Jun 20, 2018 at 08:54:56PM +0900, Takashi Yamamoto wrote:
>>
>>> do you have a plan to submit these changes on gerrit?
>> I didn't but I have now:
>>
>>  * https://review.openstack.org/577028
>>  * https://review.openstack.org/577029
>>
>> Feel free to edit/test as you like.
> thank you!
>
>> Yours Tony.
>>
>> __
>> OpenStack Development Mailing 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




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

Re: [openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Tony Breeds]

On Mon, Jun 25, 2018 at 05:42:00PM -0500, Lance Bragstad wrote:
> Keystone is hitting this, too [0]. I attempted the same solution that
> Tony posted, but no luck. I've even gone so far as removing every
> comment from the module to see if that helps narrow down the problem
> area, but sphinx still trips. The output from the error message isn't
> very descriptive either. Has anyone else had issues fixing this for
> python comments, not just docstrings?
> 
> [0] https://bugs.launchpad.net/keystone/+bug/1778603

I did a little digging for the keystone problem and it's due to a
missing ':' in 
https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth1/rfc5849/request_validator.py#L819-L820

So the correct way to fix this is to correct that in oauthlib, get it
released and use that.

I hit additional problems in that enabling -W in oauthlib, to pevent
this happening in the future, lead me down a rabbit hole I don't really
have cycles to dig out of.

Here's a dump of where I got to[1].  Clearly it mixes "fixes" with
debugging but it isn't too hard to reproduce and someone that knows more
Sphinx will be able to understand the errors better than I can.


[1] http://paste.openstack.org/show/724271/

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] OpenStack Mentorship Program Relaunch

[Ell Marquez]

Hello all,

We are happy to announce the relaunch of the OpenStack Mentoring program,
and we are kicking off with some changes to the program that we hope will
better serve the community.

Previously mentoring occurred through one on one partnering of mentor and
mentee; this new program will focus on providing mentorship through
goal-focused cohorts of mentors.  This change will allow mentoring
responsibilities to be shared among each group's mentors.

The initial cohorts will be:

- Get your first patch merged

- First CFP submission / Give your first talk

- Become COA certified / study for COA

- Deploy your first Cloud

If you are interested in joining as a mentor or mentee, please sign up at :

Mentor Signup: https://openstackfoundation.formstack.com/forms/mentoring_co
horts_mentors

Mentee Signup: https://openstackfoundation.formstack.com/forms/mentoring_co
horts_mentees

freenode irc room:

#openstack-mentoring


Cheers,

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

Re: [openstack-dev] [Release-job-failures][release][horizon] Release of openstack/xstatic-angular-material failed

[Sean McGinnis]

> 
> Apart from the fix, is there any good way to detect this kind of errors in
> individual project reviews?
>

I've added xstatic version checking to our release request validation. Once
this merges, we should be able to automatically catch and error on these types
of conditions:

https://review.openstack.org/577828


__
OpenStack Development Mailing 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] Adding hostId to metadata

[Mohammed Naser]

Hi everyone:

While working with the OpenStack infrastructure team, we noticed that
we were having some intermittent issues where we wanted to identify a
theory if all VMs with this issue were landing on the same hypervisor.

However, there seems to be no way of directly accessing `hostId` from
inside the virtual machine (such as using the metadata API).  This is
a very useful thing to expose over the metadata API as not only would
it help for troubleshooting these types of scenarios however it would
also help software that can manage anti-affinity simply by checking
the API and taking scheduling decisions.

I've proposed the following patch to add this[1], however, this is
technically an API change, and the blueprints document specifies that
"API changes always require a design discussion."

Also, I believe that we're in a state where getting a spec would
require an exception.  However, this is a very trivial change.  Also,
according to the notes in the metadata file, it looks like there is
one "bump" per OpenStack release[3] which means that this change can
just be part of that release-wide version bump of the OpenStack API.

Can we include this trivial patch in the upcoming Rocky release?

Thanks,
Mohammed

[1]: https://review.openstack.org/577933
[2]: https://docs.openstack.org/nova/latest/contributor/blueprints.html
[3]: 
http://git.openstack.org/cgit/openstack/nova/tree/nova/api/metadata/base.py#n60

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

[openstack-dev] [tripleo] Referring to the --templates directory?

[Lars Kellogg-Stedman]

Is there a way to refer to the `--templates` directory when writing
service templates?  Existing service templates can use relative paths,
as in:

resources:

  ContainersCommon:
type: ./containers-common.yaml

But if I'm write a local service template (which I often do during
testing/development), I would need to use the full path to the
corresponding file:

  ContainersCommon:
type: 
/usr/share/openstack-tripleo-heat-templates/docker/services/containers-common.yaml

But that breaks if I use another template directory via the
--templates option to the `openstack overcloud deploy` command.  Is
there a way to refer to "the current templates directory"?

-- 
Lars Kellogg-Stedman  | larsks @ {irc,twitter,github}
http://blog.oddbit.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] [cinder] making volume available without stopping VM

[Sean McGinnis]

> 
> In fact, I'm ok with delayed resize (upon power-cycle), and it's not an
> issue for me that VM don't detect changes immediately. What I want to
> understand is that changes to Cinder (and, thus, underlying changes to CEPH)
> are safe for VM while it's in active state.
> 

No, this is not considered safe. You are forcing the volume state to be
availabile when it is in fact not.

Not sure if it's an option for you, but in the Pike release support was added
to be able to extend attached volumes. There are several caveats with this
feature though. I believe it only works with libvirt, and if I remember right,
only newer versions of libvirt. You need to have notifications working for Nova
to pick up that Cinder has extended the volume.

You can get some details from the cinder spec:

https://specs.openstack.org/openstack/cinder-specs/specs/pike/extend-attached-volume.html

And the corresponding Nova spec:

http://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/nova-support-attached-volume-extend.html

You may also want to read through the mailing list thread if you want to get in
to some of the nitty gritty details behind why certain design choices were
made:

http://lists.openstack.org/pipermail/openstack-dev/2017-April/115292.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] [masakari] Masakarimonitors EndpointNotFound Issue

[Braian Leiva]

Hello everyone, I've configured masakari-api (controller node01) and
masakari-processmonitor (node02, node03 compute nodes) but I have an issue
when I try to test the instance migration between nodes. The node alive
can't reach to public endpoint for instance-ha.

Jun 25 18:23:50 node02 python2: 2018-06-25 18:23:50.380 10269 INFO
masakarimonitors.hostmonitor.host_handler.handle_host [-] 'node01.xx.net'
is 'online'.
Jun 25 18:23:50 node02 python2: 2018-06-25 18:23:50.380 10269 INFO
masakarimonitors.hostmonitor.host_handler.handle_host [-] 'node03.xx.net'
is 'online'.
Jun 25 18:23:50 node02 python2: 2018-06-25 18:23:50.381 10269 INFO
masakarimonitors.ha.masakari [-] Send a notification. {'notification':
{'hostname': 'node03.xx.net', 'type': 'COMPUTE_HOST', 'payload':
{'host_status': 'NORMAL', 'event': 'STARTED', 'cluster_status': 'ONLINE'},
'generated_time': datetime.datetime(2018, 6, 25, 17, 23, 50, 381284)}}
Jun 25 18:23:50 node02 python2: 2018-06-25 18:23:50.818 10269 WARNING
masakarimonitors.ha.masakari [-] Retry sending a notification. (public
endpoint for instance-ha service not found): EndpointNotFound: public
endpoint for instance-ha service not found
Jun 25 18:23:53 node02 python2: 2018-06-25 18:23:53.826 10269 WARNING
masakarimonitors.ha.masakari [-] Retry sending a notification. (public
endpoint for instance-ha service not found): EndpointNotFound: public
endpoint for instance-ha service not found
Jun 25 18:23:56 node02 python2: 2018-06-25 18:23:56.834 10269 WARNING
masakarimonitors.ha.masakari [-] Retry sending a notification. (public
endpoint for instance-ha service not found): EndpointNotFound: public
endpoint for instance-ha service not found
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari [-] Exception caught: public endpoint for
instance-ha service not found: EndpointNotFound: public endpoint for
instance-ha service not found
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari Traceback (most recent call last):
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari   File
"/usr/lib/python2.7/site-packages/masakarimonitors/ha/masakari.py", line
68, in send_notification
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari payload=event['notification']['payload'])
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari   File
"/usr/lib/python2.7/site-packages/openstack/instance_ha/v1/_proxy.py", line
65, in create_notification
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari return
self._create(_notification.Notification, **attrs)
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari   File
"/usr/lib/python2.7/site-packages/openstack/proxy.py", line 197, in _create
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari return res.create(self)
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari   File
"/usr/lib/python2.7/site-packages/openstack/resource.py", line 729, in
create
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari json=request.body, headers=request.headers)
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari   File
"/usr/lib/python2.7/site-packages/keystoneauth1/adapter.py", line 310, in
post
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari return self.request(url, 'POST', **kwargs)
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari   File
"/usr/lib/python2.7/site-packages/openstack/_adapter.py", line 145, in
request
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari **kwargs)
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari   File
"/usr/lib/python2.7/site-packages/openstack/task_manager.py", line 138, in
submit_function
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari return self.submit_task(task)
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari   File
"/usr/lib/python2.7/site-packages/openstack/task_manager.py", line 127, in
submit_task
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari return self.run_task(task=task)
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari   File
"/usr/lib/python2.7/site-packages/openstack/task_manager.py", line 159, in
run_task
Jun 25 18:23:59 node02 python2: 2018-06-25 18:23:59.841 10269 ERROR
masakarimonitors.ha.masakari return self._run_task(task)

Re: [openstack-dev] [Openstack-sigs] [PTG] Updates!

[Kendall Nelson]

On Mon, Jun 25, 2018 at 11:00 AM Doug Hellmann 
wrote:

> Excerpts from Jeremy Stanley's message of 2018-06-25 16:01:11 +:
> > On 2018-06-25 11:26:29 -0400 (-0400), Doug Hellmann wrote:
> > > Excerpts from Thierry Carrez's message of 2018-06-25 17:15:44 +0200:
> > > > Doug Hellmann wrote:
> > > > > Are we planning to have space for goal teams to answer
> > > > > implementation questions?
> > > >
> > > > At previous PTGs the "goal rooms" ended up not being used (or very
> very
> > > > poorly-attended), so our current plan was to not allocate specific
> > > > space, but leverage the "Ask me anything" project help room to
> answer
> > > > those questions as well. It shall be a large room, so plenty of
> space to
> > > > do that... and probably nicer compared to waiting in a smaller,
> > > > dedicated but mostly empty room.
> > > >
> > > > That said, if we have people signed up to run a specific room, and
> > > > people interested in joining that, I'm happy allocating space on
> Monday
> > > > or Tuesday for that...
> > > >
> > > > Otherwise there is always the option to schedule in reservable space
> > > > using ptgbot on the fly :)
> > > >
> > >
> > > OK. Given the complexity of the zuul configuration changes for the
> > > python3 goal, I anticipated some questions. I will be prepared to
> > > talk to people about it regardless, and maybe we won't need a
> > > separate room.
> >
> > I think the up side to the current plan is that there are likely to
> > also be Zuulies in that same room answering Zuulish sorts of
> > questions anyway, so easier to get input on goal-specific topics
> > where there is such an overlap.
>
> OK, that makes a lot of sense. I didn't see anything on the list
> here that looked like an "ask me anything" room but maybe I missed
> it or this list was just project teams? Either way, as long as we have
> some space, it's fine.
>
>
Yep, this thread was to announce the teams/groups/sigs/wgs list to help
officialize who might need to attend and start booking travel.

Hopefully things will be even more clear once we have an actual strawman
schedule to send out. We will have the 'ask me anything' helproom and
reservable space as well.

-Kendall (diablo_rojo)


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

Re: [openstack-dev] [nova] Need feedback on spec for handling down cells in the API

[Matt Riedemann]

On 6/7/2018 9:02 AM, Matt Riedemann wrote:
We have a nova spec [1] which is at the point that it needs some API 
user (and operator) feedback on what nova API should be doing when 
listing servers and there are down cells (unable to reach the cell DB or 
it times out).


tl;dr: the spec proposes to return "shell" instances which have the 
server uuid and created_at fields set, and maybe some other fields we 
can set, but otherwise a bunch of fields in the server response would be 
set to UNKNOWN sentinel values. This would be unversioned, and therefore 
could wreak havoc on existing client side code that expects fields like 
'config_drive' and 'updated' to be of a certain format.


There are alternatives listed in the spec so please read this over and 
provide feedback since this is a pretty major UX change.


Oh, and no pressure, but today is the spec freeze deadline for Rocky.

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


The options laid out right now are:

1. Without a new microversion, include 'shell' servers in the response 
when listing over down cells. These would have UNKNOWN values for the 
fields in the server object. gibi and I didn't like this because 
existing client code wouldn't know how to deal with these UNKNOWN shell 
instances - and not all of the server fields are simple strings, we have 
booleans, integers, dicts and lists, so what would those values be?


2. In a new microversion, return a new top-level parameter when listing 
servers which would include minimal details about servers that are in 
down cells (minimal like just the uuid). This was an alternative gibi 
and I had discussed because we didn't like the client-side impacts w/o a 
microversion or the full 'shell' servers in option 1. From an IRC 
conversation last week with mordred [1], dansmith and mordred don't care 
for the new top-level parameter since clients would have to merge that 
in to the full list of available servers. Plus, in the future, if we 
ever have some kind of caching mechanism in the API from which we can 
pull instance information if it's in a down cell, then the new top-level 
parameter becomes kind of pointless.


3. In a new microversion, include servers from down cells in the same 
top-level servers response parameter but for those in down cells, we'll 
just include minimal information (status=UNKNOWN and the uuid). Clients 
would opt-in to the new microversion when they know how to deal with 
what an instance in UNKNOWN status means. In the future, we could use a 
caching mechanism to fill in these details for instances in down cells.


#3 is kind of a compromise on options 1 and 2, and I'm OK with it 
(barring any hairy details).


In all cases, we won't include 'shell' servers in the response if the 
user is filtering (or paging?) because we can't be honest about the 
results and just have to treat the filters as if they don't apply to the 
instances in the down cell.


If you have a server in a down cell, you can't delete it or really do 
anything with it because we literally can't pull the instance out of the 
cell database while the cell is down. You'd get a 500 or 503 in that case.


Regardless of microversion, we plan on omitting instances from down 
cells when listing which is a backportable reliability bug fix [2] so we 
don't 500 the API when listing across 70 cells and 1 is down.


[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-06-20.log.html#t2018-06-20T16:52:27

[2] https://review.openstack.org/#/c/575734/

--

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] [neutron] Bug deputy report

[Brian Haley]

Hi,

I was Neutron bug deputy last week. Below is a short summary about 
reported bugs.



Critical bugs
-
None

High bugs
-

* https://bugs.launchpad.net/neutron/+bug/1777908 -
Ensure _get_changed_synthetic_fields() return updatable fields - breaks 
consumers

  - Boden proposed reverts

* https://bugs.launchpad.net/neutron/+bug/1777922 - neutron is not 
dropping radvd privileges

  - Fix proposed, https://review.openstack.org/#/c/576923/

* https://bugs.launchpad.net/neutron/+bug/1777968 - Too many 
DBDeadlockError and IP address collision during port creating

  - Fix proposed, https://review.openstack.org/#/c/577739/

Medium bugs
---

* https://bugs.launchpad.net/neutron/+bug/1778118 - missing transaction 
in driver_controller.py for l3 flavors

  - Fix proposed, https://review.openstack.org/#/c/577246/

Wishlist bugs
-

* https://bugs.launchpad.net/neutron/+bug/146 - When use ‘neutron 
net-update’, we cannot change the 'vlan-transparent' dynamically

  - not a bug as per the API definition, asked if proposing extension
  - perhaps possible to implement in backward-compatible way

Further triage required
---

* https://bugs.launchpad.net/neutron/+bug/1777866 - QoS CLI – Warning in 
case when provided burst is lower than 80% BW

  - submitter wants CLI warning, not sure it's necessary as it is
already mentioned in the admin guide
  - possible change in OSC could address

* https://bugs.launchpad.net/neutron/+bug/1778407 - Quality of Service 
(QoS) in Neutron - Notes regarding burst (80% BW)

  - Closed as duplicate of 1777866

* https://bugs.launchpad.net/neutron/+bug/1777965 - Create port get 
quota related DBDeadLock


* https://bugs.launchpad.net/neutron/+bug/1778207 - fwaas v2 add port 
into firewall group failed

  - most likely need DVR/HA check in affected code path
  - need to ping SridarK to take a look

__
OpenStack Development Mailing 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] [magnum] New temporary meeting on Thursdays 1700UTC

[Fei Long Wang]

Hi Spyros,

Thanks for posting the discussion output. I'm not sure I can follow the
idea of simplifying CNI configuration. Though we have both calico and
flannel for k8s, but if we put both of them into single one config
script. The script could be very complex. That's why I think we should
define some naming and logging rules/policies for those scripts for long
term maintenance to make our life easier. Thoughts?


On 25/06/18 19:20, Spyros Trigazis wrote:
> Hello again,
>
> After Thursday's meeting I want to summarize what we discussed and add
> some pointers.
>
>   * Work on using the out-of-tree cloud provider and move to the new
> model of defining it
> https://storyboard.openstack.org/#!/story/1762743
> 
> https://review.openstack.org/#/c/577477/
>   * Configure kubelet and kube-proxy on master nodes
> This story of the master node label can be
> extened https://storyboard.openstack.org/#!/story/2002618
> 
> or we can add a new one
>   * Simplify CNI configuration, we have calico and flannel. Ideally we
> should a single config script for each
> one. We could move flannel to the kubernetes hosted version that
> uses kubernetes objects for storage.
> (it is the recommended way by flannel and how it is done with kubeadm)
>   * magum support in gophercloud
> https://github.com/gophercloud/gophercloud/issues/1003
>   * *needs discussion *update version of heat templates (pike or
> queens) This need its own tread
>   * Post deployment scripts for clusters, I have this since some time
> for my but doing it in
> heat is slightly (not a lot) complicated. Most magnum users favor 
> the simpler solution
> of passing a url of a manifest or script to the cluster (at least
> let's add sha512sum).
>   * Simplify addition of custom labels/parameters. To avoid patcing
> magnum, it would be
> more ops friendly to have a generic field of custom parameters
>
> Not discussed in the last meeting but we should in the next ones:
>
>   * Allow cluster scaling from different users in the same project
> https://storyboard.openstack.org/#!/story/2002648
> 
>   * Add the option to remove node from a resource group for swarm
> clusters like
> in kubernetes
> https://storyboard.openstack.org/#!/story/2002677
> 
>
> Let's follow these up in the coming meetings, Tuesday 1000UTC and
> Thursday 1700UTC.
>
> You can always consult this page [1] for future meetings.
>
> Cheers,
> Spyros
>
> [1] https://wiki.openstack.org/wiki/Meetings/Containers
>
> On Wed, 20 Jun 2018 at 18:05, Spyros Trigazis  > wrote:
>
> Hello list,
>
> We are going to have a second weekly meeting for magnum for 3 weeks
> as a test to reach out to contributors in the Americas.
>
> You can join us tomorrow (or today for some?) at 1700UTC in
> #openstack-containers .
>
> Cheers,
> Spyros
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

Re: [openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Lance Bragstad]

Thanks a bunch for digging into this, Tony. I'll follow up with the
oauthlib maintainers and see if they'd be interested in these changes
upstream. If so, I can chip away at it. For now we'll have to settle for
not treating warnings as errors to unblock our documentation gate [0].

[0] https://review.openstack.org/#/c/577974/

On 06/25/2018 07:27 PM, Tony Breeds wrote:
> On Mon, Jun 25, 2018 at 05:42:00PM -0500, Lance Bragstad wrote:
>> Keystone is hitting this, too [0]. I attempted the same solution that
>> Tony posted, but no luck. I've even gone so far as removing every
>> comment from the module to see if that helps narrow down the problem
>> area, but sphinx still trips. The output from the error message isn't
>> very descriptive either. Has anyone else had issues fixing this for
>> python comments, not just docstrings?
>>
>> [0] https://bugs.launchpad.net/keystone/+bug/1778603
> I did a little digging for the keystone problem and it's due to a
> missing ':' in 
> https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth1/rfc5849/request_validator.py#L819-L820
>
> So the correct way to fix this is to correct that in oauthlib, get it
> released and use that.
>
> I hit additional problems in that enabling -W in oauthlib, to pevent
> this happening in the future, lead me down a rabbit hole I don't really
> have cycles to dig out of.
>
> Here's a dump of where I got to[1].  Clearly it mixes "fixes" with
> debugging but it isn't too hard to reproduce and someone that knows more
> Sphinx will be able to understand the errors better than I can.
>
>
> [1] http://paste.openstack.org/show/724271/
>
> Yours Tony.
>
>
> __
> OpenStack Development Mailing 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

[openstack-dev] [ironic] SOFT_REBOOT powers off/on the server

[Lenny Berkhovsky]

Hi,
Is there a reason for powering off and on[1] instead of resetting server during 
SOFT_REBOOT?
I have a patchset[2] that resets the server instead of power cycling it.

[1] 
https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/ipmitool.py#L820
  elif power_state == states.SOFT_REBOOT:
_soft_power_off(task, driver_info, timeout=timeout)
driver_utils.ensure_next_boot_device(task, driver_info)
_power_on(task, driver_info, timeout=timeout)

[2] https://review.openstack.org/#/c/577748/

Lenny Verkhovsky
( aka lennyb )
__
OpenStack Development Mailing 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] [stable][horizon] Adding Ivan Kolodyazhny to horizon-stable-maint

[Ivan Kolodyazhny]

Thank you Tony and Team!

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Mon, Jun 25, 2018 at 3:06 AM, Tony Breeds 
wrote:

> On Mon, Jun 18, 2018 at 12:03:52PM +1000, Tony Breeds wrote:
>
> > Without strong objections I'll do that on (my) Monday 25th June.
>
> Done.
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [vitrage] Vitrage was migrated to StoryBoard

[Ifat Afek]

Hi,

During the weekend we have completed the Vitrage migration to StoryBoard.

Vitrage bugs and blueprints should be handled in StoryBoard from now on.
All Vitrage bugs have been migrated and have the same bug number as in
launchpad. Regarding the blueprints, we migrated the ones that we are
currently working on in Rocky, but not the future ones.

We created an etherpad with guidelines regarding the new process [1]. Feel
free to comment and ask if something is unclear.

Special thanks to Kendall Nelson and fungi for their help.

[1] https://etherpad.openstack.org/p/vitrage-storyboard-migration

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

Re: [openstack-dev] [cinder] making volume available without stopping VM

[Volodymyr Litovka]

Hi Jay,

We have had similar issues with extending attached volumes that are 
iSCSI based. In that case the VM has to be forced to rescan the scsi bus.


In this case I am not sure if there needs to be a change to Libvirt or 
to rbd or something else.


I would recommend reaching out to John Bernard for help.


In fact, I'm ok with delayed resize (upon power-cycle), and it's not an 
issue for me that VM don't detect changes immediately. What I want to 
understand is that changes to Cinder (and, thus, underlying changes to 
CEPH) are safe for VM while it's in active state.


Hopefully, Jon will help with this question.

Thank you!

On 6/23/18 8:41 PM, Jay Bryant wrote:



On Sat, Jun 23, 2018, 9:39 AM Volodymyr Litovka > wrote:


Dear friends,

I did some tests with making volume available without stopping VM.
I'm
using CEPH and these steps produce the following results:

1) openstack volume set --state available [UUID]
- nothing changed inside both VM (volume is still connected) and CEPH
2) openstack volume set --size [new size] --state in-use [UUID]
- nothing changed inside VM (volume is still connected and has an
old size)
- size of CEPH volume changed to the new value
3) during these operations I was copying a lot of data from external
source and all md5 sums are the same on both VM and source
4) changes on VM happens upon any kind of power-cycle (e.g. reboot
(either soft or hard): openstack server reboot [--hard] [VM uuid] )
- note: NOT after 'reboot' from inside VM

It seems, that all these manipilations with cinder just update
internal
parameters of cinder/CEPH subsystems, without immediate effect for
VMs.
Is it safe to use this mechanism in this particular environent (e.g.
CEPH as backend)?

 From practical point of view, it's useful when somebody, for
example,
update project in batch mode, and will then manually reboot every VM,
affected by the update, in appropriate time with minimized downtime
(it's just reboot, not manual stop/update/start).

Thank you.

-- 
Volodymyr Litovka

   "Vision without Execution is Hallucination." -- Thomas Edison



--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

__
OpenStack Development Mailing 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] [magnum] New temporary meeting on Thursdays 1700UTC

[Spyros Trigazis]

Hello again,

After Thursday's meeting I want to summarize what we discussed and add some
pointers.


   - Work on using the out-of-tree cloud provider and move to the new model
   of defining it
   https://storyboard.openstack.org/#!/story/1762743
   https://review.openstack.org/#/c/577477/
   - Configure kubelet and kube-proxy on master nodes
   This story of the master node label can be extened
   https://storyboard.openstack.org/#!/story/2002618
   or we can add a new one
   - Simplify CNI configuration, we have calico and flannel. Ideally we
   should a single config script for each
   one. We could move flannel to the kubernetes hosted version that uses
   kubernetes objects for storage.
   (it is the recommended way by flannel and how it is done with kubeadm)
   - magum support in gophercloud
   https://github.com/gophercloud/gophercloud/issues/1003
   - *needs discussion *update version of heat templates (pike or queens)
   This need its own tread
   - Post deployment scripts for clusters, I have this since some time for
   my but doing it in
   heat is slightly (not a lot) complicated. Most magnum users favor  the
   simpler solution
   of passing a url of a manifest or script to the cluster (at least let's
   add sha512sum).
   - Simplify addition of custom labels/parameters. To avoid patcing
   magnum, it would be
   more ops friendly to have a generic field of custom parameters

Not discussed in the last meeting but we should in the next ones:

   - Allow cluster scaling from different users in the same project
   https://storyboard.openstack.org/#!/story/2002648
   - Add the option to remove node from a resource group for swarm clusters
   like
   in kubernetes
   https://storyboard.openstack.org/#!/story/2002677

Let's follow these up in the coming meetings, Tuesday 1000UTC and Thursday
1700UTC.

You can always consult this page [1] for future meetings.

Cheers,
Spyros

[1] https://wiki.openstack.org/wiki/Meetings/Containers

On Wed, 20 Jun 2018 at 18:05, Spyros Trigazis  wrote:

> Hello list,
>
> We are going to have a second weekly meeting for magnum for 3 weeks
> as a test to reach out to contributors in the Americas.
>
> You can join us tomorrow (or today for some?) at 1700UTC in
> #openstack-containers .
>
> Cheers,
> Spyros
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev