[openstack-dev] 答复: [tripleo] Blueprints for Rocky

[dong.wenjuan]

Hi all,







I proposed a BP about the integration with Vitrage: 
https://blueprints.launchpad.net/tripleo/+spec/tripleo-vitrage-integration 


And I posted a spec patch to the gerrit:  
https://review.openstack.org/#/c/552425/


Please help to review, any comments are welcome. Thanks~






BR,


dwj















原始邮件



发件人：AlexSchultz 
收件人：OpenStack Development Mailing List (not for usage questions) 

日 期 ：2018年03月13日 22:02
主 题 ：[openstack-dev] [tripleo] Blueprints for Rocky


Hey everyone,

So we currently have 63 blueprints for currently targeted for
Rocky[0].  Please make sure that any blueprints you are interested in
delivering have an assignee set and have been approved.  I would like
to have the ones we plan on delivering for Rocky to be updated by
April 3, 2018.  Any blueprints that have not been updated will be
moved out to the next cycle after this date.

Thanks,
-Alex

[0] https://blueprints.launchpad.net/tripleo/rocky

__
OpenStack Development Mailing 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] [bifrost][helm][OSA][barbican] Switching from fedora-26 to fedora-27

[na...@vn.fujitsu.com]

Hello Paul,

I am Nam from Barbican team. I would like to notify a problem when using 
fedora-27. 

Currently, fedora-27 is using mariadb at 10.2.12. But there is a bug in this 
version and it is the main reason for failure Barbican database upgrading [1], 
the bug was fixed at 10.2.13 [2]. Would you mind updating the version of 
mariadb before removing fedora-26.

[1] https://bugs.launchpad.net/barbican/+bug/1734329 
[2] https://jira.mariadb.org/browse/MDEV-13508 

Thanks,
Nam

> -Original Message-
> From: Paul Belanger [mailto:pabelan...@redhat.com]
> Sent: Tuesday, March 13, 2018 9:54 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [bifrost][helm][OSA][barbican] Switching from
> fedora-26 to fedora-27
> 
> On Mon, Mar 05, 2018 at 06:45:13PM -0500, Paul Belanger wrote:
> > Greetings,
> >
> > A quick search of git shows your projects are using fedora-26 nodes for
> testing.
> > Please take a moment to look at gerrit[1] and help land patches.  We'd
> > like to remove fedora-26 nodes in the next week and to avoid broken
> > jobs you'll need to approve these patches.
> >
> > If you jobs are failing under fedora-27, please take the time to fix
> > any issue or update said patches to make them non-voting.
> >
> > We (openstack-infra) aim to only keep the latest fedora image online,
> > which changes aprox every 6 months.
> >
> > Thanks for your help and understanding, Paul
> >
> > [1] https://review.openstack.org/#/q/topic:fedora-27+status:open
> >
> Greetings,
> 
> This is a friendly reminder, about moving jobs to fedora-27. I'd like to 
> remove
> our fedora-26 images next week and if jobs haven't been migrated you may
> start to see NODE_FAILURE messages while running jobs.  Please take a
> moment to merge the open changes or update them to be non-voting while
> you work on fixes.
> 
> Thanks again,
> Paul
> 
> __
> 
> OpenStack Development Mailing 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] [infra][all] New Zuul Depends-On syntax

[Tristan Cacqueray]

On February 20, 2018 1:35 am, Emilien Macchi wrote:

On Mon, Feb 19, 2018 at 7:03 AM, Jeremy Stanley  wrote:
[...]


This is hopefully only a temporary measure? I think I've heard it
mentioned that planning is underway to switch that CI system to Zuul
v3 (perhaps after 3.0.0 officially releases soon).



Adding Tristan and Fabien in copy, they know better about the roadmap.
--


Hi,

We are indeed waiting for the official Zuul 3.0.0 release to ship the
next version of Software Factory and deploy it for rdoproject.org.

-Tristan


pgpxjfzJyJ7Rv.pgp
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] [masakari] Masakari Project mascot ideas

[Patil, Tushar]

Hi,


Total 4 people attended last IRC meeting and all of them have voted for 
St.Bernard Dog.


If someone has missed to vote, please vote for mascot now.


Options:

1) Asiatic black bear
2) Gekko : Geckos is able to regrow it's tail when the tail is lost.
3) St. Bernard: St. Bernard is famous as rescue dog (Masakari rescues VM 
instances)


Thank you.


Regards,

Tushar Patil




From: Bhor, Dinesh 
Sent: Wednesday, March 14, 2018 10:16:29 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [masakari] Masakari Project mascot ideas


Hi Sampath San,


There is one more option which we discussed in yesterdays masakari meeting [1]:

St. Bernard(Dog) [2].


[1] 
http://eavesdrop.openstack.org/meetings/masakari/2018/masakari.2018-03-13-04.01.log.html#l-38


[2] https://en.wikipedia.org/wiki/St._Bernard_(dog)


Thank you,

Dinesh Bhor



From: Sam P 
Sent: 13 March 2018 22:19:00
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [masakari] Masakari Project mascot ideas

Hi All,

We started this discussion on IRC meeting few weeks ago and still no 
progress..;)
(aspiers: thanks for the reminder!)

Need mascot proposals for Masakari, see FAQ [1] for more info
Current ideas: Origin of "Masakari" is related to hero from Japanese folklore 
[2].
Considering that relationship and to start the process, here are few ideas,
(1) Asiatic black bear
(2) Gekko : Geckos is able to regrow it's tail when the tail is lost.

[1] https://www.openstack.org/project-mascots/
[http://www.openstack.org/themes/openstack/images/openstack-logo-full.png]

Project Mascots - OpenStack is open source software for 
...
www.openstack.org
We are OpenStack. We’re also passionately developing more than 60 projects 
within OpenStack. To support each project’s unique identity and visually 
demonstrate ...


[2] https://en.wikipedia.org/wiki/Kintar%C5%8D

--- Regards,
Sampath


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing 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] +1 //Subject: [tricircle] Nominate change in tricircle core team

[zmj1981123]

+1  thanks for baisen work for tricircle!




 Forwarding messages 
From: "Vega Cai" 
Date: 2018-03-12 09:04:41
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [tricircle] Nominate change in tricircle core team

Hi team, I would like to nominate Baisen Song (songbaisen) for tricircle core 
reviewer. Baisen has actively joined the discussion of feature development and 
has contributed important patches since Queens, like resource deletion 
reliability and openstack-sdk new version adaption. I really think his 
experience will help us substantially improve tricircle.


BR
Zhiyuan
-- 

BR
Zhiyuan__
OpenStack Development Mailing 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 - Install gnocchi error.

[__ mango.]

After the installation (apt-get install gnocchi-api gnocchi- gnocchiclient),
When I tried to launch the gnocc-api, I got the message.
   Failed to start gnocchi-api. Service: Unit gnocchi-api. Service not found.
I checked /etc/init.d and there is no script gnocchi-api (although 
gnocchi-metricd is, and it's working properly).

Why is that? Please help me to solve it. Thank you.



-- Original --
From:  "Julien Danjou";
Date:  Tue, Mar 13, 2018 05:55 PM
To:  "__ mango."<935540...@qq.com>;
Cc:  "openstack-dev"; 
Subject:  Re: [openstack-dev] OpenStack - Install gnocchi error.



On Tue, Mar 13 2018, __ mango. wrote:

> hi,
> I refer to: 
> https://docs.openstack.org/ceilometer/pike/install/install-base-ubuntu.html 
> installation gnocchi, 
> unable to find gnocchi - API related services is this why?
> Please help answer my question, thank you!

Can you provide more details as what's your problem? thank you!

-- 
Julien Danjou
// Free Software hacker
// https://julien.danjou.info__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cyborg]Weekly Team Meeting 2018.03.14 Agenda (No Time Change For US)

[Zhipeng Huang]

Yes that would be one of the issue we need to discuss after the PoC demo :)

On Wed, Mar 14, 2018 at 10:11 AM, Nadathur, Sundar <
sundar.nadat...@intel.com> wrote:

> Hi Howard,
>
> Can we discuss the possibility of using a filter/weigher that invokes
> Cyborg API, as we discussed during the Cyborg/Nova discussion in the PTG?
>
>
>
> This is line 56 in https://etherpad.openstack.org/p/cyborg-ptg-rocky-nova-
> cyborg-interaction .
>
>
>
> Regards,
>
> Sundar
>
>
>
> *From:* Zhipeng Huang [mailto:zhipengh...@gmail.com]
> *Sent:* Monday, March 12, 2018 1:28 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Cc:* Konstantinos Samaras-Tsakiris ;
> Dutch Althoff 
> *Subject:* [openstack-dev] [cyborg]Weekly Team Meeting 2018.03.14 Agenda
> (No Time Change For US)
>
>
>
> Hi Team,
>
>
>
> We will resume the team meeting this week. The meeting starting time is
> still ET 10:00am/PT 7:00am, whereas in China it is moved one hour early to
> 10:00pm. For Europe please refer to UTC1400 as the baseline.
>
>
>
> This week we will have a special 2 hour meeting. In the first one hour we
> will have Shaohe demo the PoC Intel dev team had conducted, and in the
> second half we will confirm the task and milestones for Rocky based upon
> the PTG discussion (summary sent out last Friday).
>
>
>
> ZOOM link will be provided before the meeting :)
>
>
>
> If there are any other topics anyone would like to propose, feel free to
> reply to this email thread.
>
>
>
> --
>
> Zhipeng (Howard) Huang
>
>
>
> Standard Engineer
>
> IT Standard & Patent/IT Product Line
>
> Huawei Technologies Co,. Ltd
>
> Email: huangzhip...@huawei.com
>
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
>
>
> (Previous)
>
> Research Assistant
>
> Mobile Ad-Hoc Network Lab, Calit2
>
> University of California, Irvine
>
> Email: zhipe...@uci.edu
>
> Office: Calit2 Building Room 2402
>
>
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing 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] [cyborg]Weekly Team Meeting 2018.03.14 Agenda (No Time Change For US)

[Nadathur, Sundar]

Hi Howard,
Can we discuss the possibility of using a filter/weigher that invokes 
Cyborg API, as we discussed during the Cyborg/Nova discussion in the PTG?

This is line 56 in 
https://etherpad.openstack.org/p/cyborg-ptg-rocky-nova-cyborg-interaction .

Regards,
Sundar

From: Zhipeng Huang [mailto:zhipengh...@gmail.com]
Sent: Monday, March 12, 2018 1:28 AM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: Konstantinos Samaras-Tsakiris ; 
Dutch Althoff 
Subject: [openstack-dev] [cyborg]Weekly Team Meeting 2018.03.14 Agenda (No Time 
Change For US)

Hi Team,

We will resume the team meeting this week. The meeting starting time is still 
ET 10:00am/PT 7:00am, whereas in China it is moved one hour early to 10:00pm. 
For Europe please refer to UTC1400 as the baseline.

This week we will have a special 2 hour meeting. In the first one hour we will 
have Shaohe demo the PoC Intel dev team had conducted, and in the second half 
we will confirm the task and milestones for Rocky based upon the PTG discussion 
(summary sent out last Friday).

ZOOM link will be provided before the meeting :)

If there are any other topics anyone would like to propose, feel free to reply 
to this email thread.

--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing 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] +1：Fw: [tricircle] Nominate change in tricircle coreteam

[陈亚光]

+1


 Forwarding messages 
From: "Vega Cai" 
Date: 2018-03-12 09:04:41
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [tricircle] Nominate change in tricircle core team
Hi team, I would like to nominate Baisen Song (songbaisen) for tricircle
core reviewer. Baisen has actively joined the discussion of feature
development and has contributed important patches since Queens, like
resource deletion reliability and openstack-sdk new version adaption. I
really think his experience will help us substantially improve tricircle.

BR
Zhiyuan
-- 
BR
Zhiyuan
__
OpenStack Development Mailing 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] +1??Fw: [tricircle] Nominate change in tricircle coreteam

[???? ????]

+1



 Forwarding messages 
From: "Vega Cai" 
Date: 2018-03-12 09:04:41
To:  "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [tricircle] Nominate change in tricircle core team
Hi team, I would like to nominate Baisen Song (songbaisen) for tricircle core 
reviewer. Baisen has actively joined the discussion of feature development and 
has contributed important patches since Queens, like resource deletion 
reliability and openstack-sdk new version adaption. I really think his 
experience will help us substantially improve tricircle.

BR
Zhiyuan

-- 
BRZhiyuan


 



??|30??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] [tricircle] Nominate change in tricircle core team

[crh]

+1. It is so cool to see the new core reviewer



--



Best regards,
Ronghui Cao, Ph.D. Candidate
College of Information Science and Engineering
Hunan University, Changsha 410082, Hunan, China

At 2018-03-12 09:12:48, "joehuang"  wrote:



+1. Baisen has contributed lots of patches in Tricircle.



Best Regards
Chaoyi Huang (joehuang)
From: Vega Cai [luckyveg...@gmail.com]
Sent: 12 March 2018 9:04
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tricircle] Nominate change in tricircle core team


Hi team, I would like to nominate Baisen Song (songbaisen) for tricircle core 
reviewer. Baisen has actively joined the discussion of feature development and 
has contributed important patches since Queens, like resource deletion 
reliability and openstack-sdk new version adaption. I really think his 
experience will help us substantially improve tricircle.


BR
Zhiyuan
--

BR
Zhiyuan__
OpenStack Development Mailing 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] [masakari] Masakari Project mascot ideas

[Bhor, Dinesh]

Hi Sampath San,


There is one more option which we discussed in yesterdays masakari meeting [1]:

St. Bernard(Dog) [2].


[1] 
http://eavesdrop.openstack.org/meetings/masakari/2018/masakari.2018-03-13-04.01.log.html#l-38


[2] https://en.wikipedia.org/wiki/St._Bernard_(dog)


Thank you,

Dinesh Bhor



From: Sam P 
Sent: 13 March 2018 22:19:00
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [masakari] Masakari Project mascot ideas

Hi All,

We started this discussion on IRC meeting few weeks ago and still no 
progress..;)
​(aspiers: thanks for the reminder!)

Need mascot proposals for Masakari, see FAQ [1] for more info
Current ideas: Origin of "Masakari" is related to hero from Japanese folklore 
[2].
Considering that relationship and to start the process, here are few ideas,
(1) Asiatic black bear
(2) Gekko : Geckos is able to regrow it's tail when the tail is lost.

[1] https://www.openstack.org/project-mascots/
[2] https://en.wikipedia.org/wiki/Kintar%C5%8D

--- Regards,
Sampath


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
OpenStack Development Mailing 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] Poll: S Release Naming

[Paul Belanger]

Greetings all,

It is time again to cast your vote for the naming of the S Release. This time
is little different as we've decided to use a public polling option over per
user private URLs for voting. This means, everybody should proceed to use the
following URL to cast their vote:

  
https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_40b95cb2be3fcdf1=8cfdc1f5df5fe4d3

Because this is a public poll, results will currently be only viewable by myself
until the poll closes. Once closed, I'll post the URL making the results
viewable to everybody. This was done to avoid everybody seeing the results while
the public poll is running.

The poll will officially end on 2018-03-21 23:59:59[1], and results will be
posted shortly after.

[1] 
http://git.openstack.org/cgit/openstack/governance/tree/reference/release-naming.rst
---

According to the Release Naming Process, this poll is to determine the
community preferences for the name of the R release of OpenStack. It is
possible that the top choice is not viable for legal reasons, so the second or
later community preference could wind up being the name.

Release Name Criteria

Each release name must start with the letter of the ISO basic Latin alphabet
following the initial letter of the previous release, starting with the
initial release of "Austin". After "Z", the next name should start with
"A" again.

The name must be composed only of the 26 characters of the ISO basic Latin
alphabet. Names which can be transliterated into this character set are also
acceptable.

The name must refer to the physical or human geography of the region
encompassing the location of the OpenStack design summit for the
corresponding release. The exact boundaries of the geographic region under
consideration must be declared before the opening of nominations, as part of
the initiation of the selection process.

The name must be a single word with a maximum of 10 characters. Words that
describe the feature should not be included, so "Foo City" or "Foo Peak"
would both be eligible as "Foo".

Names which do not meet these criteria but otherwise sound really cool
should be added to a separate section of the wiki page and the TC may make
an exception for one or more of them to be considered in the Condorcet poll.
The naming official is responsible for presenting the list of exceptional
names for consideration to the TC before the poll opens.

Exact Geographic Region

The Geographic Region from where names for the S release will come is Berlin

Proposed Names

Spree (a river that flows through the Saxony, Brandenburg and Berlin states of
   Germany)

SBahn (The Berlin S-Bahn is a rapid transit system in and around Berlin)

Spandau (One of the twelve boroughs of Berlin)

Stein (Steinstraße or "Stein Street" in Berlin, can also be conveniently
   abbreviated as )

Steglitz (a locality in the South Western part of the city)

Springer (Berlin is headquarters of Axel Springer publishing house)

Staaken (a locality within the Spandau borough)

Schoenholz (A zone in the Niederschönhausen district of Berlin)

Shellhaus (A famous office building)

Suedkreuz ("southern cross" - a railway station in Tempelhof-Schöneberg)

Schiller (A park in the Mitte borough)

Saatwinkel (The name of a super tiny beach, and its surrounding neighborhood)
   (The adjective form, Saatwinkler is also a really cool bridge but
   that form is too long)

Sonne (Sonnenallee is the name of a large street in Berlin crossing the former
   wall, also translates as "sun")

Savigny (Common place in City-West)

Soorstreet (Street in Berlin restrict Charlottenburg)

Solar (Skybar in Berlin)

See (Seestraße or "See Street" in Berlin)

Thanks,
Paul

__
OpenStack Development Mailing 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] [First Contact][SIG] [PTG] Summary of Discussions

[Jay S Bryant]

Amy,

The top level page for projects is referenced under documentation from 
here:  https://docs.openstack.org/queens/projects.html


So, I think we have that one covered for people who are just looking for 
the top level documentation.


Jay


On 3/13/2018 3:02 PM, Amy Marrich wrote:
I think if we're going to have that go to the development contributors 
section (which makes sense) maybe we should also have ways of getting 
to the deployment and admin docs as well?


Amy (spotz)

On Tue, Mar 13, 2018 at 2:55 PM, Jay S Bryant > wrote:




On 3/13/2018 1:38 PM, Petr Kovar wrote:

On Thu, 8 Mar 2018 12:54:06 -0600
Jay S Bryant > wrote:

Good overview.  Thank you!

One additional goal I want to mention on the list, for
awareness, is the
fact that we would like to eventually get some consistency
to the pages
that the 'Contributor Guide' lands on for each of the
projects.  Needs
to be a page that is friendly to new contributors, makes
it easy to
learn about the project and is not overwhelming.

What exactly that looks like isn't defined yet but I have
talked to
Manila about this.  They were interested in working
together on this.
Cinder and Manila will work together to get something
consistent put
together and then we can work on spreading that to other
projects once
we have agreement from the SIG that the approach is agreeable.

This is a good cross-project goal, I think. We discussed a
similar approach
in the docs room wrt providing templates to project teams that
they can
use to design their landing pages for admin, user,
configuration docs; that
would also include the main index page for project docs.

As for the project-specific contributor guides,
https://docs.openstack.org/doc-contrib-guide/project-guides.html

specifies
that any contributor content should go to
doc/source/contributor/. This will
allow us to use templates to generate lists of links,
similarly to what
we do for other content areas.

Cheers,
pk



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

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


Petr,

Good point.  I was trying to think of how to make a better landing
page for new contributors and you may have hit on the answer. 
RIght now when you click through from  here:
https://www.openstack.org/community
 You land at the top level
Cinder documentation page which is incredibly overwhelming for a
new person: https://docs.openstack.org/cinder/latest/


If the new contributor page instead lands here:
https://docs.openstack.org/cinder/latest/contributor/index.html

It would give me a page to craft for new users looking for
information to get started.

Thoughts on this approach?

Kendall and Mike ... Does the above approach make sense?

Jay



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

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





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

[openstack-dev] [First Contact][SIG] Weekly Meeting

[Kendall Nelson]

Hello!

[1] has been merged and we have an agenda [2] so we are full steam ahead
for the upcoming meeting!

Our inaugural First Contact SIG meeting will be in #openstack-meeting at
0800 UTC Wednesday!

Hope to see you all in ~9 hours!

-Kendall (diablo_rojo)

[1]https://review.openstack.org/#/c/549849/
[2] https://wiki.openstack.org/wiki/First_Contact_SIG#Meeting_Agenda
__
OpenStack Development Mailing 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] Blueprints for Rocky

[Tony Breeds]

On Tue, Mar 13, 2018 at 07:58:48AM -0600, Alex Schultz wrote:
> Hey everyone,
> 
> So we currently have 63 blueprints for currently targeted for
> Rocky[0].  Please make sure that any blueprints you are interested in
> delivering have an assignee set and have been approved.  I would like
> to have the ones we plan on delivering for Rocky to be updated by
> April 3, 2018.  Any blueprints that have not been updated will be
> moved out to the next cycle after this date.

My BP: https://blueprints.launchpad.net/tripleo/+spec/multiarch-support
doesn't look like it needs an update but just in case I missed something
it's still very much targeted at Rocky-1, and the ball is in my court :)

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] [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions

[Amy Marrich]

Just one comment on this section before I forget again:
#IRC Channels#
We want to get rid of #openstack-101 and begin using #openstack-dev
instead. The 101 channel isn't watched closely enough anymore and it makes
more sense to move onboarding activities (like in OpenStack Upstream
Institute) to a channel where there are people that can answer questions
rather than asking those to move to a new channel. For those concerned
about noise, OUI is run the weekend before the summit when most people are
traveling to the Summit anyway.

I would recommend sending folks to #openstack vs #openstack-dev by default.

Amy (spotz)

On Mon, Mar 5, 2018 at 2:00 PM, Kendall Nelson 
wrote:

> Hello Everyone :)
>
> It was wonderful to see and talk with so many of you last week! For those
> that couldn't attend our whole day of chats or those that couldn't attend
> at all, I thought I would put forth a summary of our discussions which were
> mostly noted in the etherpad[1]
>
> #Contributor Guide#
>
> - Walkthrough: We walked through every section of what exists and came up
> with a variety of improvements on what is there. Most of these items have
> been added to our StoryBoard project[2]. This came up again Tuesday in docs
> sessions and I have added those items to StoryBoard as well.
>
> - Google Analytics: It was discussed we should do something about getting
> the contributor portal[3] to appear higher in Google searches about
> onboarding. Not sure what all this entails. NEEDS AN OWNER IF ANYONE WANTS
> TO VOLUNTEER.
>
> #Mission Statement#
>
> We updated our mission statement[4]! It now states:
>
> To provide a place for new contributors to come for information and
> advice. This group will also analyze and document successful contribution
> models while seeking out and providing information to new members of the
> community.
>
> #Weekly Meeting#
>
> We discussed beginning a weekly meeting- optimized for APAC/Europe and
> settled on 800 UTC in #openstack-meeting on Wednesdays. Proposed here[5].
> For now I added a section to our wiki for agenda organization[6]. The two
> main items we want to cover on a weekly basis are new contributor patches
> in gerrit and if anything has come up on ask.openstack.org about
> contributors so those will be standing agenda items.
>
> #Forum Session#
>
> We discussed proposing some forum sessions in order to get more
> involvement from operators. Currently, our activities focus on development
> activities and we would like to diversify. When this SIG was first proposed
> we wanted to have two chairs- one to represent developers and one to
> represent operators. We will propose a session or two when the call for
> forum proposals go out (should be today).
>
> #IRC Channels#
> We want to get rid of #openstack-101 and begin using #openstack-dev
> instead. The 101 channel isn't watched closely enough anymore and it makes
> more sense to move onboarding activities (like in OpenStack Upstream
> Institute) to a channel where there are people that can answer questions
> rather than asking those to move to a new channel. For those concerned
> about noise, OUI is run the weekend before the summit when most people are
> traveling to the Summit anyway.
>
> #Ongoing Onboarding Efforts#
>
> - GSOC: Unfortunately we didn't get accepted this year. We will try again
> next year.
>
> - Outreachy: Applications for the next round of interns are due March
> 22nd, 2018 [7]. Decisions will be made by April and then internships run
> May to August.
>
> - WoO Mentoring: The format of mentoring is changing from 1x1 to cohorts
> focused on a single goal. If you are interested in helping out, please
> contact me! I NEED HELP :)
>
> - Contributor guide: Please see the above section.
>
> - OpenStack Upstream Institute: It will be run, as usual, the weekend
> before the Summit in Vancouver. Depending on how much progress is made on
> the contributor guide, we will make use of it as opposed to slides like
> previous renditions. There have also been a number of OpenStack Days
> requesting we run it there as well. More details of those to come.
>
> #Project Liaisons#
>
> The list is filling out nicely, but we still need more coverage. If you
> know someone from a project not listed that might be willing to help,
> please reach out to them and get them added to our list [8].
>
> I thiink that is just about everything. Hopefully I at least covered
> everything important :)
>
> Thanks Everyone!
>
> - Kendall Nelson (diablo_rojo)
>
> [1] PTG Etherpad https://etherpad.openstack.org/p/FC_SIG_Rocky_PTG
> [2] StoryBoard Tracker https://storyboard.openstack.org/#!/project/913
> [3] Contributor Portal https://www.openstack.org/community/
> [4] Mission Statement Update https://review.openstack.org/#/c/548054/
> [5] Meeting Slot Proposal https://review.openstack.org/#/c/549849/
> [6] Meeting Agenda https://wiki.openstack.org/wiki/First_Contact_SIG#
> Meeting_Agenda
> [7] Outreachy 

[openstack-dev] [tripleo] The Weekly Owl - 12th Edition

[Emilien Macchi]

Note: this is the twelfth edition of a weekly update of what happens in
TripleO.
The goal is to provide a short reading (less than 5 minutes) to learn where
we are and what we're doing.
Any contributions and feedback are welcome.
Link to the previous version:
http://lists.openstack.org/pipermail/openstack-dev/2018-March/127966.html

+-+
| General announcements |
+-+

+--> We're releasing the final version of TripleO Queens this week and are
now preparing Rocky milestone 1.
+--> PTG summaries are posted on the mailing-list or via blog post, see
http://www.mariosandreou.com/tripleo/2018/03/07/openstack-rocky-ptg-dublin.html
.

+--+
| Continuous Integration |
+--+

+--> Rover is John and ruck is Matt. Please let them know any new CI issue.
+--> RDO Cloud had some downtime over the weekend but things should be
stable now.
+--> Master promotion is 8 days, Queens is 8 days, Pike is 21 days and
Ocata is 5 days.
+--> Proposal to change devmode to re-use reproduce bits (see thread).
+--> Focus is still on TripleO CI infrastructure hardening, see
https://trello.com/c/abar9eup/542-tripleo-ci-infrastructure-hardening
+--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting and
https://goo.gl/D4WuBP

+-+
| Upgrades |
+-+

+--> Very good progress on Pike to Queens upgrades workflows, patches under
review. Same for FFU
+--> Introduction of pre_upgrade_rolling_tasks interface
+--> Excellent progress on CI jobs (undercloud upgrade progress, etc).
+--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status

+---+
| Containers |
+---+

+--> Containerized undercloud is the major ongoing effort in the squad.
Focus is on making OVB working and also upgrades. Target is rocky-m1.
+--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status

+--+
| config-download |
+--+

+--> ceph-ansible support in progress
+--> starting to look at process to create a new git repo per role for
standalone ansible roles
+--> More:
https://etherpad.openstack.org/p/tripleo-config-download-squad-status

+--+
| Integration |
+--+

+--> Team is working on config-download integration for ceph and
multi-cluster support.
+--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status

+-+
| UI/CLI |
+-+

+--> Starting work on the network configuration wizard
+--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status

+---+
| Validations |
+---+

+--> No updates this week.
+--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status

+---+
| Networking |
+---+

+--> Investigations around containerizing OVS
+--> Collaboration with UI squad for network config integration
+--> lot and lot of planning for Rocky and beyond, see the etherpad for
exciting future!
+--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status

+--+
| Workflows |
+--+

+--> No updates this week.
+--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status

+---+
| Security |
+---+

+--> First meeting last week, discussions around CI, SElinux everywhere,
Security Hardening, TripleO secrets management, Public TLS by default and
more.
+--> More: https://etherpad.openstack.org/p/tripleo-security-squad

++
| Owl fact |
++

Owls can rotate their necks 270 degrees. A blood-pooling system collects
blood to power their brains and eyes when neck movement cuts off
circulation.
Source: http://www.audubon.org/news/11-fun-facts-about-owls

Stay tuned!
--
Your fellow reporter, Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Rocky PTG summary - Queens retrospective

[melanie witt]

Howdy Stackers,

I’ve created a summary etherpad [0] of the Queens retrospective session from 
the PTG and included a plain text export of it on this email.

Thank you to all who participated and please do add comments to the etherpad 
where I might have missed a perspective or interpretation in my attempt to 
summarize the session.

Best,
-melanie

[0] https://etherpad.openstack.org/p/nova-queens-retrospective-summary

*Queens Retrospective: Rocky PTG Summary

https://etherpad.openstack.org/p/nova-queens-retrospective

*Key topics

  * What went well
* Volume multiattach support is now available for libvirt+lvm and with CI 
testing
* Added Takashi Natsume to the python-novaclient core team
* osc-placement 1.0.0 is now available, so operators have a CLI to interact 
with the Placement service (with docs too)
* The run up to RC1 was much less stressful/hectic than it was in 
Ocata/Pike, we had fewer major changes leading up to the feature freeze
* We have increased the number of people committing to placement related 
code
* We had fewer approved and greater completed blueprints indicating we have 
gotten better at doing what we said we were going to do
* We have sane defaults on AArch64 architecture (like UEFI being default, 
proper 'cpu_model')
* The websocket proxy security finally landed
* Kudos to Eric Fried for his work on nested resource providers in placement
* Kudos to Chris Dent for his updates to the dev mailing list on placement
* Kudos to Matt Riedemann for serving us as PTL for the past four cycles
  * What needs to improve
* Concern around nova-core team expansion, or rather, lack of expansion and 
confusion/mystery about how to become a member of the core team
* Problems around having dev conversations and gathering outcomes of those 
conversations
* Non-priority spec/blueprint and bug fix code taking very long to merge 
and not getting visibility
* Concern that not enough people participate in providing retrospective 
comments
* Concern that we didn't actually merge things earlier in the cycle as 
decided during the Pike retrospective
* Bug triage
* Concern around time management and how to quickly get up-to-speed on what 
to review
* We have had some unexpected changes in behavior in Ocata like the 
Aggregate[Core|Ram|Disk]Filter no longer working, that caused pain for operators

*Agreements and decisions
  * Make sure that people review osc-placement changes (I've added a section 
for this to the priorities etherpad [1])
  * melwitt will rewrite the nova contributor documentation about what the core 
team looks for in potential new core team members to be clear and concise (with 
some how-to tips), and increase its visibility by making sure it's more 
directly linked from the docs home page
  * On dev conversations that happen on IRC or on hangouts, have someone from 
the conversation write up a summary of the conversation (if there was an 
outcome) and send it to the dev mailing list with appropriate tags, for example 
"[nova][placement][...]". People should feel encouraged to use the dev mailing 
list to have dev conversations and communicate outcomes. Conversations needn't 
be limited to only IRC or hangouts
  * For the most part, the priorities etherpad [1] can provide visibility for 
non-priority spec/blueprint work and trivial bug fix code (there are sections 
for both of these: "Non-priority approved blueprints" and "Trivial bug subteam")
  * melwitt to write nova contributor documentation explaining the use of the 
priorities etherpad and link
  * We need a way to quickly point contributors at the documentation ^, 
suggestions include a bot that adds a comment to a new contributor's patch that 
points them to the documentation or a NEW_CONTRIBUTOR_README.rst in the root 
directory of the nova project that points to the documentation
  * Discuss the design and implement "runways" for blueprints where we focus 
review attention on selected blueprints for a specified time-box with the goal 
being to avoid approving new non-priority work until we've merged old 
non-priority work
  * Commit to fewer blueprints and complete a higher percentage of them. This 
is about fulfilling expectations and serving contributors better as opposed to 
setting goals too high and letting people down

On the other items:
  * At first, not many people added comments to the retrospective etherpad, but 
more people added comments as we got closer to the PTG, which was good. From 
what I can tell, most of the problems we have (including lack of participation 
in the retrospective etherpad) stem from a lack of communication, visibility, 
and transparency. It is my hope that diligent use of the priorities etherpad, 
runways, clear and concise documentation, and weekly reminders/summaries of the 
priorities etherpad will result in contributors seeing progress in their work 
and becoming more engaged.
  * The concern about how we 

[openstack-dev] [manila] [ptg] queens retrospective at the rocky ptg

[Tom Barron]

At the Dublin PTG the manila team did a retrospective on the
Queens release -- raw etherpad here [1].

We summarize it here to separate it from the otherwise
forward-looking manila PTG summary (coming soon).

# Keep Doing #

- queens bug smashes, especially the Wuhan bug smash [2]
  + (mostly new) contributors from 5+ companies including
99cloud, fibrehome, chinamobile, H3c, easystack, Huawei
- bug czar role & meeting slot [3]
- trying to tag even earlier than deadlines

# Do less of / Stop Doing #

- blind rechecks
  + reviewers need to pay attention to recheck history and
push back on merges that ignore intermittent issues
  + even if the issue is unrelated to the patch we should have
an associated bug
- letting reviews languish, especially for contributors outside
US timezones
  + need more systematic approach (see suggestions below) to
review backlog

# Do More Of #

- Root cause analysis and fixing of failing tests in gate
- Groom bug lists, especially before bug smashes
- Make contributor's guide with review checklists
- Use mail-list more for asynch communication across timezones
- Help people use IRC bouncers
- Keep etherpad/dashboards for pending reviews
- Improve docs for new driver contributors

# Action Items #

- Tom will develop etherpad for priority reviews
- Ben will share past review etherpads / gerrit dashboards
(Done: see raw etherpad [3] but Tom will work to get these
unified and findable)
- Ganso will create etherpad to collaborate on reviewer/contributor
  checklists
- Tom will check how Cinder fixed log filtering problem

-- Tom Barron

[1] https://etherpad.openstack.org/p/manila-ptg-rocky-retro
[2] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Queens-Wuhan
[3] https://etherpad.openstack.org/p/manila-bug-triage-pad


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] [services][tripleo-validations] Process counts for Undercloud services

[Dan Trainor]

Hi -

tripleo-validations has a validation[0] that attempts to identify services
that have more than (in its default setting) 8 processes running when the
validation is executed.  We've seen in the past, times where too many
processes for each service may have had a significant performance impact
particularly in Undercloud systems with a less than optimal amount of
memory, but it's been a while since I've seen much discussion on this.

By default, the validation will look at the following services, and fail if
there are more than 8 processes of each running on the Undercloud:

- heat-engine
- mistral
- ironic-inspector
- ironic-conductor
- nova-api
- nova-scheduler
- nova-conductor
- nova-compute
- glance-api
- swift-proxy-server
- swift-object-server
- swift-container-server
- zaqar-server

Examples of services that this validation fails on immediately out of the
box are:

- heat-engine
- mistral
- nova-api

What I'm trying to determine right now is if that (default) maximum number
of processes (8) is still applicable, and/or reasonable.  If not, what
max_process_count value would be appropriate?

I understand that this question is highly subjective based on a number of
factors that go in to the consideration of an OpenStack environment.
However, we're looking for some baselines for these values in an effort to
make this validation more valuable.

Thanks!
-dant

---

[0]
https://github.com/openstack/tripleo-validations/blob/master/validations/undercloud-process-count.yaml
__
OpenStack Development Mailing 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] [First Contact][SIG] [PTG] Summary of Discussions

[Amy Marrich]

I think if we're going to have that go to the development contributors
section (which makes sense) maybe we should also have ways of getting to
the deployment and admin docs as well?

Amy (spotz)

On Tue, Mar 13, 2018 at 2:55 PM, Jay S Bryant  wrote:

>
>
> On 3/13/2018 1:38 PM, Petr Kovar wrote:
>
>> On Thu, 8 Mar 2018 12:54:06 -0600
>> Jay S Bryant  wrote:
>>
>> Good overview.  Thank you!
>>>
>>> One additional goal I want to mention on the list, for awareness, is the
>>> fact that we would like to eventually get some consistency to the pages
>>> that the 'Contributor Guide' lands on for each of the projects.  Needs
>>> to be a page that is friendly to new contributors, makes it easy to
>>> learn about the project and is not overwhelming.
>>>
>>> What exactly that looks like isn't defined yet but I have talked to
>>> Manila about this.  They were interested in working together on this.
>>> Cinder and Manila will work together to get something consistent put
>>> together and then we can work on spreading that to other projects once
>>> we have agreement from the SIG that the approach is agreeable.
>>>
>> This is a good cross-project goal, I think. We discussed a similar
>> approach
>> in the docs room wrt providing templates to project teams that they can
>> use to design their landing pages for admin, user, configuration docs;
>> that
>> would also include the main index page for project docs.
>>
>> As for the project-specific contributor guides,
>> https://docs.openstack.org/doc-contrib-guide/project-guides.html
>> specifies
>> that any contributor content should go to doc/source/contributor/. This
>> will
>> allow us to use templates to generate lists of links, similarly to what
>> we do for other content areas.
>>
>> Cheers,
>> pk
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> Petr,
>
> Good point.  I was trying to think of how to make a better landing page
> for new contributors and you may have hit on the answer.  RIght now when
> you click through from  here: https://www.openstack.org/community  You
> land at the top level Cinder documentation page which is incredibly
> overwhelming for a new person:  https://docs.openstack.org/cinder/latest/
>
> If the new contributor page instead lands here:
> https://docs.openstack.org/cinder/latest/contributor/index.html It would
> give me a page to craft for new users looking for information to get
> started.
>
> Thoughts on this approach?
>
> Kendall and Mike ... Does the above approach make sense?
>
> 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] [First Contact][SIG] [PTG] Summary of Discussions

[Jay S Bryant]

On 3/13/2018 1:38 PM, Petr Kovar wrote:

On Thu, 8 Mar 2018 12:54:06 -0600
Jay S Bryant  wrote:


Good overview.  Thank you!

One additional goal I want to mention on the list, for awareness, is the
fact that we would like to eventually get some consistency to the pages
that the 'Contributor Guide' lands on for each of the projects.  Needs
to be a page that is friendly to new contributors, makes it easy to
learn about the project and is not overwhelming.

What exactly that looks like isn't defined yet but I have talked to
Manila about this.  They were interested in working together on this.
Cinder and Manila will work together to get something consistent put
together and then we can work on spreading that to other projects once
we have agreement from the SIG that the approach is agreeable.

This is a good cross-project goal, I think. We discussed a similar approach
in the docs room wrt providing templates to project teams that they can
use to design their landing pages for admin, user, configuration docs; that
would also include the main index page for project docs.

As for the project-specific contributor guides,
https://docs.openstack.org/doc-contrib-guide/project-guides.html specifies
that any contributor content should go to doc/source/contributor/. This will
allow us to use templates to generate lists of links, similarly to what
we do for other content areas.

Cheers,
pk


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

Petr,

Good point.  I was trying to think of how to make a better landing page 
for new contributors and you may have hit on the answer.  RIght now when 
you click through from  here: https://www.openstack.org/community  You 
land at the top level Cinder documentation page which is incredibly 
overwhelming for a new person:  https://docs.openstack.org/cinder/latest/


If the new contributor page instead lands here: 
https://docs.openstack.org/cinder/latest/contributor/index.html It would 
give me a page to craft for new users looking for information to get 
started.


Thoughts on this approach?

Kendall and Mike ... Does the above approach make sense?

Jay


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

Re: [openstack-dev] [First Contact][SIG] [PTG] Summary of Discussions

[Petr Kovar]

On Thu, 8 Mar 2018 12:54:06 -0600
Jay S Bryant  wrote:

> Good overview.  Thank you!
> 
> One additional goal I want to mention on the list, for awareness, is the 
> fact that we would like to eventually get some consistency to the pages 
> that the 'Contributor Guide' lands on for each of the projects.  Needs 
> to be a page that is friendly to new contributors, makes it easy to 
> learn about the project and is not overwhelming.
> 
> What exactly that looks like isn't defined yet but I have talked to 
> Manila about this.  They were interested in working together on this.  
> Cinder and Manila will work together to get something consistent put 
> together and then we can work on spreading that to other projects once 
> we have agreement from the SIG that the approach is agreeable.

This is a good cross-project goal, I think. We discussed a similar approach
in the docs room wrt providing templates to project teams that they can
use to design their landing pages for admin, user, configuration docs; that
would also include the main index page for project docs.

As for the project-specific contributor guides,
https://docs.openstack.org/doc-contrib-guide/project-guides.html specifies
that any contributor content should go to doc/source/contributor/. This will
allow us to use templates to generate lists of links, similarly to what
we do for other content areas.

Cheers,
pk


__
OpenStack Development Mailing 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] [sahara][all] Sahara Rocky Virtual PTG is SCHEDULED

[Jeremy Freudberg]

Hi again all,

We will have a remote session tomorrow, March 14, beginning at 13:30
UTC. Best guess is that it will run two hours. Come and go as you need
to.

The session will be hosted by Bluejeans: https://bluejeans.com/6304900378
(Take a moment to make sure your browser and peripherals are configured nicely)

All interested parties are welcome. I reiterate that all outcomes of
the session will be logged to the dev list.

Till then,
Jeremy

__
OpenStack Development Mailing 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] [k8s] Hosting location for OpenStack Kubernetes Provider

[Chris Hoge]

At the PTG in Dublin, SIG-K8s started working towards migrating the
external Kubernetes OpenStack cloud provider[1] work to be an OpenStack
project. Coincident with that, an upstream patch[2] was proposed by 
WG-Cloud-Provider to create upstream Kubernetes repositories for the
various cloud providers.

I want to begin a conversation about where we want this provider code to
live and how we want to manage it. Three main options are to:

1) Host the provider code within the OpenStack ecosystem. The advantages
are that we can follow OpenStack community development practices, and
we have a good list of people signed up to help maintain it. We would
also have easier access to infra test resources. The downside is we pull
the code further away from the Kubernetes community, possibly making it
more difficult for end users to find and use in a way that is consistent
with other external providers.

2) Host the provider code within the Kubernetes ecosystem. The advantage
is that the code will be in a well-defined and well-known place, and
members of the Kubernetes community who want to participate will be able
to continue to use the community practices. We would still be able to
take advantage of infra resources, but it would require more setup to
trigger and report on jobs.

3) Host in OpenStack, and mirror in a Kubernetes repository. We would
need to work with the K8s team to make sure this is an acceptable option,
but would allow for a hybrid development model that could satisty the
needs of members of both communities. This would require a committment
from the K8s-SIG-OpenStack/OpenStack-SIG-K8s team to handling tickets
and pull requests that come in to the Kubernetes hosted repository.

My personal opinion is that we should take advantage of the Kubernetes
hosting, and migrate the project to one of the repositories listed in
the WG-Cloud-Provider patch. This wouldn't preclude moving it into
OpenStack infra hosting at some point in the future and possibly
adopting the hybrid approach down the line after more communication with
K8s infrastructure leaders.

There is a sense of urgency, as Dims has asked that we relieve him of
the responsibility of hosing the external provider work in his personal
GitHub repository.

Please chime in with your opinions on this here so that we can work out
an where the appropriate hosting for this project should be.

Thanks,
Chris Hoge
K8s-SIG-OpenStack/OpenStack-SIG-K8s Co-Lead

[1] https://github.com/dims/openstack-cloud-controller-manager
[2] https://github.com/kubernetes/community/pull/1862
[3] https://etherpad.openstack.org/p/sig-k8s-2018-dublin-ptg


__
OpenStack Development Mailing 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][tempest][congress] import or retain mistral tempest service client

[Eric K]

Hi Mistral folks and others,

I'm working on Congress tempest tests [1] for integration with Mistral. In
the tests, we use a Mistral service client to call Mistral APIs and
compare results against those obtained by Mistral driver for Congress.

Regarding the service client, Congress can either import directly from
Mistral tempest plugin [2] or maintain its own copy within Congress
tempest plugin. I'm not sure whether Mistral team expects the service
client to be internal use only, so I hope to hear folks' thoughts on which
approach is preferred. Thanks very much!

Eric

[1] https://review.openstack.org/#/c/538336/
[2] 
https://github.com/openstack/mistral-tempest-plugin/blob/master/mistral_tem
pest_tests/services/v2/mistral_client.py



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

Re: [openstack-dev] [kolla][vote] core nomination for caoyuan

[Swapnil Kulkarni]

On Mon, Mar 12, 2018 at 7:36 AM, Jeffrey Zhang  wrote:
> Kolla core reviewer team,
>
> It is my pleasure to nominate caoyuan for kolla core team.
>
> caoyuan's output is fantastic over the last cycle. And he is the most
> active non-core contributor on Kolla project for last 180 days[1]. He
> focuses on configuration optimize and improve the pre-checks feature.
>
> Consider this nomination a +1 vote from me.
>
> A +1 vote indicates you are in favor of caoyuan as a candidate, a -1
> is a veto. Voting is open for 7 days until Mar 12th, or a unanimous
> response is reached or a veto vote occurs.
>
> [1] http://stackalytics.com/report/contribution/kolla-group/180
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

+1

__
OpenStack Development Mailing 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] Masakari Project mascot ideas

[Sam P]

Hi All,

We started this discussion on IRC meeting few weeks ago and still no
progress..;)
​(aspiers: thanks for the reminder!)

Need mascot proposals for Masakari, see FAQ [1] for more info

Current ideas: Origin of "Masakari" is related to hero from Japanese
folklore [2].
Considering that relationship and to start the process, here are few
ideas,
(1) Asiatic black bear

(2) Gekko : Geckos is able to regrow it's tail when the tail is lost.

[1] https://www.openstack.org/project-mascots/
[2] https://en.wikipedia.org/wiki/Kintar%C5%8D

--- Regards,
Sampath
__
OpenStack Development Mailing 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][ThirdParty-CI] Nova s390x CI currently broken

[Andreas Scheuring]

Hello, the s390x CI for nova is currently broken again. The reason seems to be 
a recent change that merged in neutron. I’m looking into it...

---
Andreas Scheuring (andreas_s)



__
OpenStack Development Mailing 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][notification] Full traceback in ExceptionPayload

[Matt Riedemann]

On 3/13/2018 7:37 AM, Balázs Gibizer wrote:
I filed the bp 
https://blueprints.launchpad.net/nova/+spec/add-full-traceback-to-error-notifications


I added it to the weekly meeting agenda. I know you likely won't attend 
the meeting this week, but I can probably be your proxy on this one.


--

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] [tc] [all] TC Report 18-11

[Chris Dent]

html: https://anticdent.org/tc-report-18-11.html

Much of the activity of the TC in the past week has been devoted to
discussing and sometimes arguing about two pending resolutions:
Location of Interop Tests and Extended Maintenance (links below).
While there has been a lot of IRC chat, and back and forth on the
gerrit reviews, it has resulted in things moving forward.

Since I like to do this: a theme I would identify from this week's
discussions is continued exploration of what the TC feels it can and
should assert when making resolutions. This is especially apparent
in the discussions surrounding Interop Tests. The various options
run the gamut from describing and enforcing many details, through
providing a limited (but relatively clear) set of options, to
letting someone else decide.

I've always wanted the TC to provide enabling but not overly
limiting guidance that actively acknowledges concerns.

# Location of Interop Tests

There are three reviews related to the location of the Interop
Tests (aka Trademark Tests):

* [A detailed one, based on PTG 
discussion](https://review.openstack.org/#/c/521602/)
* [A middle of the road one, simplifying the 
first](https://review.openstack.org/#/c/550571/)
* [A (too) simple one](https://review.openstack.org/#/c/550863/)

It's looking like the middle one has the most support now, but that
is after a lot of discussion. On
[Wednesday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-07.log.html#t2018-03-07T19:07:37)
I introduced the middle of the road version to make sure the
previous discussion was represented in a relatively clear way. Then
on
[Thursday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-08.log.html#t2018-03-08T15:20:31),
a version which effectively moves responsibility to the InteropWG.

Throughout this process there have been [hidden
goals](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-08.log.html#t2018-03-08T08:41:13)
whereby this minor(?) crisis in policy is being used to attempt to
address shortcomings in the bigger picture. It's great to be working
on the bigger picture, but hidden doesn't sound like the right
approach.

# Tracking TC Goals

One of the outcomes from the PTG was an awareness that some
granular and/or middle-distance TC goals tend to get lost. The TC is
[going to try to use
StoryBoard](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-08.log.html#t2018-03-08T15:06:21)
to track these sort of things. The hope is that this will result in
more active and visible progress.

# Extended Maintenance

A proposal to [leave branches open for
patches](https://review.openstack.org/#/c/548916/) for longer has
received at least as much attention as the Interop discussions.

Some talk [starts on Thursday
afternoon](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-08.log.html#t2018-03-08T16:17:03)
and then carries on intermittently for the rest of time^w^w^w^w^wthrough
today. The review has a great deal of interaction as well.

There's general agreement on the principal ("let's not limit people
from being able to patch branches for longer") but reaching
consensus on the details has been more challenging. Different people
have different goals.

# What's a SIG for?

[Discussion](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-13.log.html#t2018-03-13T09:16:57)
about [renaming](https://review.openstack.org/#/c/551413/) the
recently [named PowerStackers
group](https://review.openstack.org/#/c/540165/) eventually
migrated into talking about what [SIGs are for or
mean](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-13.log.html#t2018-03-13T09:31:56).
There seems to be a few different interpretations, with some
overlap:

* [Upstream and downstream
  
concern](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-13.log.html#t2018-03-13T09:41:17)
  or "breadth of potential paricipants".
* [Not focused on producing
  
code](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-13.log.html#t2018-03-13T09:56:04).
* [Different people in the same
  
"room"](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-13.log.html#t2018-03-13T09:43:40).
* [In problem space rather than solution
  
space](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-13.log.html#t2018-03-13T13:34:10).

None of these are really complete. I think of SIGs as a way to break
down boundaries, provide forums for discussion and make progress
without worrying too much about bureaucracy. We probably don't need
to define them to death.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development 

Re: [openstack-dev] [bifrost][helm][OSA][barbican] Switching from fedora-26 to fedora-27

[Paul Belanger]

On Mon, Mar 05, 2018 at 06:45:13PM -0500, Paul Belanger wrote:
> Greetings,
> 
> A quick search of git shows your projects are using fedora-26 nodes for 
> testing.
> Please take a moment to look at gerrit[1] and help land patches.  We'd like to
> remove fedora-26 nodes in the next week and to avoid broken jobs you'll need 
> to
> approve these patches.
> 
> If you jobs are failing under fedora-27, please take the time to fix any issue
> or update said patches to make them non-voting.
> 
> We (openstack-infra) aim to only keep the latest fedora image online, which
> changes aprox every 6 months.
> 
> Thanks for your help and understanding,
> Paul
> 
> [1] https://review.openstack.org/#/q/topic:fedora-27+status:open
> 
Greetings,

This is a friendly reminder, about moving jobs to fedora-27. I'd like to remove
our fedora-26 images next week and if jobs haven't been migrated you may start
to see NODE_FAILURE messages while running jobs.  Please take a moment to merge
the open changes or update them to be non-voting while you work on fixes.

Thanks again,
Paul

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

Re: [openstack-dev] [oslo] Oslo PTG Summary

[Ken Giusti]

Hi Doug,

Andy updated the etherpad [0] with a new link [1].
Holler if it's still broken...


[0] https://etherpad.openstack.org/p/oslo-ptg-rocky
[1] 
https://docs.google.com/presentation/d/1PWJAGQohAvlwod4gMTp6u1jtZT1cuaE-whRmnV8uiMM/edit?usp=sharing

On Mon, Mar 12, 2018 at 11:54 AM, Doug Hellmann  wrote:
> I can’t see
>
> https://docs.google.com/presentation/d/e/2PACX-1vQpaSSm7Amk9q4sBEAUi_IpyJ4l07qd3t5T_BPZkdLWfYbtSpSmF7obSB1qRGA65wjiiq2Sb7H2ylJo/pub?start=false=false=3000=id.p
>
>
>
> On Mar 12, 2018, at 11:39 AM, Ken Giusti  wrote:
>
> Hi Josh - I'm able to view all of them, but I probably have special
> google powers ;)
>
> Which links are broken for you?
>
> thanks,
>
> On Thu, Mar 8, 2018 at 3:53 PM, Joshua Harlow  wrote:
>
>
> Can we get some of those doc links opened.
>
> 'You need permission to access this published document.' I am getting for a
> few of them :(
>
>
> Ben Nemec wrote:
>
>
> Hi,
>
> Here's my summary of the discussions we had in the Oslo room at the PTG.
> Please feel free to reply with any additions if I missed something or
> correct anything I've misrepresented.
>
> oslo.config drivers for secret management
> -
>
> The oslo.config implementation is in progress, while the Castellan
> driver still needs to be written. We want to land this early in Rocky as
> it is a significant change in architecture for oslo.config and we want
> it to be well-exercised before release.
>
> There are discussions with the TripleO team around adding support for
> this feature to its deployment tooling and there will be a functional
> test job for the Castellan driver with Custodia.
>
> There is a weekly meeting in #openstack-meeting-3 on Tuesdays at 1600
> UTC for discussion of this feature.
>
> oslo.config driver implementation: https://review.openstack.org/#/c/513844
> spec:
>
> https://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html
>
> Custodia key management support for Castellan:
> https://review.openstack.org/#/c/515190/
>
> "stable" libraries
> --
>
> Some of the Oslo libraries are in a mature state where there are very
> few, if any, meaningful changes to them. With the removal of the
> requirements sync process in Rocky, we may need to change the release
> process for these libraries. My understanding was that there were no
> immediate action items for this, but it was something we need to be
> aware of.
>
> dropping support for mox3
> -
>
> There was some concern that no one from the Oslo team is actually in a
> position to support mox3 if something were to break (such as happened in
> some libraries with Python 3.6). Since there is a community goal to
> remove mox from all OpenStack projects in Rocky this will hopefully not
> be a long-term problem, but there was some discussion that if projects
> needed to keep mox for some reason that they would be asked to provide a
> maintainer for mox3. This topic is kind of on hold pending the outcome
> of the community goal this cycle.
>
> automatic configuration migration on upgrade
> 
>
> There is a desire for oslo.config to provide a mechanism to
> automatically migrate deprecated options to their new location on
> version upgrades. This is a fairly complex topic that I can't cover
> adequately in a summary email, but there is a spec proposed at
> https://review.openstack.org/#/c/520043/ and POC changes at
> https://review.openstack.org/#/c/526314/ and
> https://review.openstack.org/#/c/526261/
>
> One outcome of the discussion was that in the initial version we would
> not try to handle complex migrations, such as the one that happened when
> we combined all of the separate rabbit connection opts into a single
> connection string. To start with we will just raise a warning to the
> user that they need to handle those manually, but a templated or
> hook-based method of automating those migrations could be added as a
> follow-up if there is sufficient demand.
>
> oslo.messaging plans
> 
>
> There was quite a bit discussed under this topic. I'm going to break it
> down into sub-topics for clarity.
>
> oslo.messaging heartbeats
> =
>
> Everyone seemed to be in favor of this feature, so we anticipate
> development moving forward in Rocky. There is an initial patch proposed
> at https://review.openstack.org/546763
>
> We felt that it should be possible to opt in and out of the feature, and
> that the configuration should be done at the application level. This
> should _not_ be an operator decision as they do not have the knowledge
> to make it sanely.
>
> There was also a desire to have a TTL for messages.
>
> bug cleanup
> ===
>
> There are quite a few launchpad bugs open against oslo.messaging that
> were reported against old, now unsupported versions. Since we have the
> 

[openstack-dev] [tripleo] Blueprints for Rocky

[Alex Schultz]

Hey everyone,

So we currently have 63 blueprints for currently targeted for
Rocky[0].  Please make sure that any blueprints you are interested in
delivering have an assignee set and have been approved.  I would like
to have the ones we plan on delivering for Rocky to be updated by
April 3, 2018.  Any blueprints that have not been updated will be
moved out to the next cycle after this date.

Thanks,
-Alex

[0] https://blueprints.launchpad.net/tripleo/rocky

__
OpenStack Development Mailing 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] [tacker][ptg] tacker vPtg will be held tomorrow

[龚永生]

https://etherpad.openstack.org/p/Tacker-PTG-Rocky



gongys
tacker
99cloud__
OpenStack Development Mailing 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] [release] Relaxed rules for cycle-trailing projects

[Thierry Carrez]

Hi!

The cycle-trailing release model is designed for OpenStack packaging /
deployment / lifecycle management tools. Since those package / help
deploy OpenStack, they are generally released after the OpenStack
coordinated release.

The rule so far was that such projects should release exactly two weeks
after the coordinated release. Feature integration and validation
testing can take a lot more (or less?) time though (depending on your
team staffing), and there is little value for our ecosystem in such a
short and determined deadline. The release team therefore agreed to
relax the rules. Such cycle-trailing deliverables can be released any
time in the 3 months following the coordinated release. It should be
plenty enough to complete the work, and if the work is not ready by
then, you should probably be focusing on supporting the upcoming release
anyway.

In addition to that, we have a rule that to be included in the upcoming
release, new deliverables need to be added before the milestone-2 of
that release cycle. The idea is to protect packaging / deployment /
lifecycle management tools teams against last-minute additions that
would jeopardize their ability to deliver proper support for the
upcoming release. That rule is very useful for the coordinated release
components, but it is useless for the packaging/deployment tools
themselves though. So we agreed to waive that rule for cycle-trailing
deliverables. Since that work happens downstream from the coordinated
release (and nobody else upstream is depending on it), it's OK for
packaging teams added after milestone-2 to publish deliverables for that
release.

The end result of these changes is that it's OK for the recently-added
OpenStack-Helm and LOCI teams to publish a release of their packaging
recipes for Queens. We encourage them to release as soon as possible,
but as long as it happens before the end of May, it would still be
accepted by the release team as their "Queens" release.

Please contact the release team (on the list or on #openstack-release)
if you have questions about this change.

-- 
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] [keystone] Keystone failing with error 104 (connection reset by peer) if using uwsgi

[Thomas Goirand]

On 03/11/2018 08:12 PM, Lance Bragstad wrote:
> Hey Thomas, 
> 
> Outside of the uwsgi config, are you following a specific guide for your
> install? I'd like to try and recreate the issue.
> 
> Do you happen to have any more logging information?
> 
> Thanks

Hi Lance,

Thanks for your proposal to try to diagnose the issue. Here's the Debian
package:

http://stretch-queens.infomaniak.ch/keystone/

(it's 13.0.0-6, but that's really a backport for Stretch...)

To use that version of Keystone, you will need this Queens repository:

deb http://stretch-queens.infomaniak.ch/debian \
stretch-queens-backports main
deb-src http://stretch-queens.infomaniak.ch/debian \
stretch-queens-backports main
deb http://stretch-queens.infomaniak.ch/debian \
stretch-queens-backports-nochange main
deb-src http://stretch-queens.infomaniak.ch/debian \
stretch-queens-backports-nochange main

(sorry for the email client that is wrapping this...)

this repository contains a full Queens backport for Stretch btw, and
also holds a version of keystone (with Apache), so make sure you're
using the correct uwsgi version from above.

Cheers,

Thomas Goirand (zigo)

__
OpenStack Development Mailing 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][notification] Full traceback in ExceptionPayload

[Balázs Gibizer]

On Fri, Mar 9, 2018 at 5:08 PM, Balázs Gibizer 
 wrote:



On Fri, Mar 9, 2018 at 3:46 PM, Matt Riedemann  
wrote:

On 3/9/2018 6:26 AM, Balázs Gibizer wrote:
The instance-action REST API has already provide the traceback to 
the user (to the admin by default) and the notifications are 
also admin only things as they are emitted to the message bus by 
default. So I assume that security is not a bigger concern for 
the notification than for the REST API. So I think the only 
issue we have to accept is that the traceback object in the 
ExceptionPayload will not be a well defined field but a simple 
string containing a serialized traceback.


If there is no objection then Kevin or I can file a specless bp to 
extend the ExceptionPayload.


I think that's probably fine. As you said, if we already provide 
tracebacks in instance action event details (and faults), then the 
serialized traceback in the error notification payload also seems 
fine, and is what the legacy notifications did so it's not like 
there wasn't precedent.


I don't think we need a blueprint for this, it's just a bug.


I thought about a bp because it was explicitly defined in the 
original spec not have traceback so for me it does not feels like a 
bug.


I filed the bp 
https://blueprints.launchpad.net/nova/+spec/add-full-traceback-to-error-notifications




Cheers,
gibi



--

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 Development Mailing 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] [publiccloud-wg] Poll new meeting time and bi-weekly meeting

[Tobias Rydberg]

Hi folks,

We have under some time had requests of changing the current time for 
our bi-weekly meetings. Not very many suggestions of new time slots have 
ended up in my inbox, so have added a few suggestions my self.


The plan is to have this set and do final voting at tomorrows meeting. 
Reply to this email if you have other suggestions and I can add those as 
well. Please mark the alternatives that works for you no later than 
tomorrow 1400UTC.


Doodle link: https://doodle.com/poll/2kv4h79xypmathac

Tomorrows meeting will be held as planned in #openstack-meeting-3 at 
1400 UTC.


Agenda can be found at: https://etherpad.openstack.org/p/publiccloud-wg

S

--
Tobias Rydberg
Senior Developer
Mobile: +46 733 312780

www.citynetwork.eu | www.citycloud.com

INNOVATION THROUGH OPEN IT INFRASTRUCTURE
ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED




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

[openstack-dev] [TripleO] ansible/config-download PTG session recap

[James Slagle]

During the PTG, TripleO held a session about moving forward with
config-download as the default deployment mechanism during Rocky.

We captured our notes in this etherpad:
https://etherpad.openstack.org/p/tripleo-ptg-config-download

There was wide agreement to continue moving forward with this
implementation. While os-collect-config and friends have served us
well for many successful releases, it seemed there was a lot of desire
to remove that polling based architecture in favor of a more pure
ansible based solution.

During the session we also talked about relying on more standalone
native ansible roles. We agreed to adopt the approach of creating a
new git repo per ansible role. While this may create more busy work
upfront, the advantages of being able to version and release each role
individually outweigh the disadvantages.

There was also some discussion about developing a script/tool to
one-time create standalone per-service ansible roles from the existing
tripleo-heat-templates service templates. Once the roles were created
they would become the source of truth moving forward for service
configuration. The service templates from tripleo-heat-templates would
then consume those roles directly. This has the advantage of removing
the inlined tasks in the templates and would give us the ability to
test the roles in a standalone fashion more easily outside of Heat. It
also aligns better with future work around k8s/apb support.

The goal is to make config-download the default by the Rocky-1
milestone (April 16 - April 20), and I feel we're still on track to do
that.

If you'd like to help with this effort we're coordinating our work
with this etherpad:
https://etherpad.openstack.org/p/tripleo-config-download-squad-status

-- 
-- James Slagle
--

__
OpenStack Development Mailing 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] Prevent ARP spoofing

[Claudiu Belu]

Hi,

Indeed ARP spoofing is prevented by default, but AFAIK, if you want it enabled 
for a port / network, you can simply disable the security groups on that 
neutron network / port.

Best regards,

Claudiu Belu


From: Татьяна Холкина [holk...@selectel.ru]
Sent: Tuesday, March 13, 2018 12:54 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] Prevent ARP spoofing

Hi,
I'm using an ocata release of OpenStack where the option prevent_arp_spoofing 
can be managed via conf. But later in pike it was removed and it was decided to 
prevent spoofing by default.
There are cases where security features should be disabled. As I can see now we 
can use a port_security option for these cases. But this option should be set 
for a particular port or network on create. The default value is set to True 
[1] and itt is impossible to change it. I'd like to suggest to get default 
value for port_security [2] from config option.
It would be nice to know your opinion.

[1] 
https://github.com/openstack/neutron-lib/blob/stable/queens/neutron_lib/api/definitions/port_security.py#L21
[2] 
https://github.com/openstack/neutron/blob/stable/queens/neutron/objects/extensions/port_security.py#L24

Best regards,
Tatiana
__
OpenStack Development Mailing 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] Prevent ARP spoofing

[Татьяна Холкина]

Hi,
I'm using an ocata release of OpenStack where the option
prevent_arp_spoofing can be managed via conf. But later in pike it was
removed and it was decided to prevent spoofing by default.
There are cases where security features should be disabled. As I can see
now we can use a port_security option for these cases. But this option
should be set for a particular port or network on create. The default value
is set to True [1] and itt is impossible to change it. I'd like to suggest
to get default value for port_security [2] from config option.
It would be nice to know your opinion.

[1]
https://github.com/openstack/neutron-lib/blob/stable/queens/neutron_lib/api/definitions/port_security.py#L21
[2]
https://github.com/openstack/neutron/blob/stable/queens/neutron/objects/extensions/port_security.py#L24

Best regards,
Tatiana
__
OpenStack Development Mailing 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 - Install gnocchi error.

[Julien Danjou]

On Tue, Mar 13 2018, __ mango. wrote:

> hi,
> I refer to: 
> https://docs.openstack.org/ceilometer/pike/install/install-base-ubuntu.html 
> installation gnocchi, 
> unable to find gnocchi - API related services is this why?
> Please help answer my question, thank you!

Can you provide more details as what's your problem? thank you!

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


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

Re: [openstack-dev] [horizon] [heat-dashboard] Horizon plugin settings for new xstatic modules

[Ivan Kolodyazhny]

Hi Kaz,

Thanks for cleaning this up. I put +1 on both of these patches

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

On Tue, Mar 13, 2018 at 4:48 AM, Kaz Shinohara  wrote:

> Hi Ivan & Horizon folks,
>
>
> Now we are submitting a couple of patches to have the new xstatic modules.
> Let me request you to have review the following patches.
> We need Horizon PTL's +1 to move these forward.
>
> project-config
> https://review.openstack.org/#/c/551978/
>
> governance
> https://review.openstack.org/#/c/551980/
>
> Thanks in advance:)
>
> Regards,
> Kaz
>
>
> 2018-03-12 20:00 GMT+09:00 Radomir Dopieralski :
> > Yes, please do that. We can then discuss in the review about technical
> > details.
> >
> > On Mon, Mar 12, 2018 at 2:54 AM, Xinni Ge 
> wrote:
> >>
> >> Hi, Akihiro
> >>
> >> Thanks for the quick reply.
> >>
> >> I agree with your opinion that BASE_XSTATIC_MODULES should not be
> >> modified.
> >> It is much better to enhance horizon plugin settings,
> >>  and I think maybe there could be one option like ADD_XSTATIC_MODULES.
> >> This option adds the plugin's xstatic files in STATICFILES_DIRS.
> >> I am considering to add a bug report to describe it at first, and give a
> >> patch later maybe.
> >> Is that ok with the Horizon team?
> >>
> >> Best Regards.
> >> Xinni
> >>
> >> On Fri, Mar 9, 2018 at 11:47 PM, Akihiro Motoki 
> wrote:
> >>>
> >>> Hi Xinni,
> >>>
> >>> 2018-03-09 12:05 GMT+09:00 Xinni Ge :
> >>> > Hello Horizon Team,
> >>> >
> >>> > I would like to hear about your opinions about how to add new xstatic
> >>> > modules to horizon settings.
> >>> >
> >>> > As for Heat-dashboard project embedded 3rd-party files issue, thanks
> >>> > for
> >>> > your advices in Dublin PTG, we are now removing them and referencing
> as
> >>> > new
> >>> > xstatic-* libs.
> >>>
> >>> Thanks for moving this forward.
> >>>
> >>> > So we installed the new xstatic files (not uploaded as openstack
> >>> > official
> >>> > repos yet) in our development environment now, but hesitate to decide
> >>> > how to
> >>> > add the new installed xstatic lib path to STATICFILES_DIRS in
> >>> > openstack_dashboard.settings so that the static files could be
> >>> > automatically
> >>> > collected by *collectstatic* process.
> >>> >
> >>> > Currently Horizon defines BASE_XSTATIC_MODULES in
> >>> > openstack_dashboard/utils/settings.py and the relevant static fils
> are
> >>> > added
> >>> > to STATICFILES_DIRS before it updates any Horizon plugin dashboard.
> >>> > We may want new plugin setting keywords ( something similar to
> >>> > ADD_JS_FILES)
> >>> > to update horizon XSTATIC_MODULES (or directly update
> >>> > STATICFILES_DIRS).
> >>>
> >>> IMHO it is better to allow horizon plugins to add xstatic modules
> >>> through horizon plugin settings. I don't think it is a good idea to
> >>> add a new entry in BASE_XSTATIC_MODULES based on horizon plugin
> >>> usages. It makes difficult to track why and where a xstatic module in
> >>> BASE_XSTATIC_MODULES is used.
> >>> Multiple horizon plugins can add a same entry, so horizon code to
> >>> handle plugin settings should merge multiple entries to a single one
> >>> hopefully.
> >>> My vote is to enhance the horizon plugin settings.
> >>>
> >>> Akihiro
> >>>
> >>> >
> >>> > Looking forward to hearing any suggestions from you guys, and
> >>> > Best Regards,
> >>> >
> >>> > Xinni Ge
> >>> >
> >>> >
> >>> > 
> __
> >>> > OpenStack Development Mailing 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
> >>
> >>
> >>
> >>
> >> --
> >> 葛馨霓 Xinni Ge
> >>
> >> 
> __
> >> OpenStack Development Mailing 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: 

Re: [openstack-dev] [Neutron] Dublin PTG Summary

[Miguel Angel Ajo Pelayo]

Very good summary, thanks for leading the PTG and neutron so well. :)


On Mon, Mar 12, 2018 at 11:25 PM fumihiko kakuma 
wrote:

> Hi Miguel,
>
> > * As part of the neutron-lib effort, we have found networking projects
> that
> > are very inactive. Examples are networking-brocade (no updates since May
> of
> > 2016) and networking-ofagent (no updates since March of 2017). Miguel
> > Lavalle will contact these projects leads to ascertain their situation.
> If
> > they are indeed inactive, we will not support them as part of neutron-lib
> > updates and will also try to remove them from code search
>
> networking-ofagent has been removed in the Newton release.
> So it will not be necessary to support it as part of neutron-lib updates.
>
> Thanks
> kakuma.
>
>
> On Mon, 12 Mar 2018 13:45:27 -0500
> Miguel Lavalle  wrote:
>
> > Hi All!
> >
> > First of all, I want to thank you the team for the productive week we had
> > in Dublin. Following below is a high level summary of the discussions we
> > had. If there is something I left out, please reply to this email thread
> to
> > add it. However, if you want to continue the discussion on any of the
> > individual points summarized below, please start a new thread, so we
> don't
> > have a lot of conversations going on attached to this update.
> >
> > You can find the etherpad we used during the PTG meetings here:
> > https://etherpad.openstack.org/p/neutron-ptg-rocky
> >
> >
> > Retrospective
> > ==
> >
> > * The team missed one community goal in the Pike cycle (
> > https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html)
> and
> > one in the Queens cycle (https://governance.openstack.
> > org/tc/goals/queens/policy-in-code.html)
> >
> >- Akihiro Motoki will work on https://governance.openstack.o
> > rg/tc/goals/queens/policy-in-code.html during Rocky
> >
> >   - We need volunteers to complete https://governance.op
> > enstack.org/tc/goals/pike/deploy-api-in-wsgi.html) and the two new goals
> > for the Rocky cycle: https://governance.openstack.o
> > rg/tc/goals/rocky/enable-mutable-configuration.html and
> > https://governance.openstack.org/tc/goals/rocky/mox_removal.html.
> Akihiro
> > Motoki will lead the effort for mox removal
> >
> >   - We decided to add a section to our weekly meeting agenda where we are
> > going to track the progress towards catching up with the community goals
> > during the Rocky cycle
> >
> > * As part of the neutron-lib effort, we have found networking projects
> that
> > are very inactive. Examples are networking-brocade (no updates since May
> of
> > 2016) and networking-ofagent (no updates since March of 2017). Miguel
> > Lavalle will contact these projects leads to ascertain their situation.
> If
> > they are indeed inactive, we will not support them as part of neutron-lib
> > updates and will also try to remove them from code search
> >
> > * We will continue our efforts to recruit new contributors and develop
> core
> > reviewers. During the conversation on this topic, Nikolai de Figueiredo
> and
> > Pawel Suder announced that they will become active in Neutron. Both of
> > them, along with Hongbin Lu, indicated that are interested in working
> > towards becoming core reviewers.
> >
> > * The team went through the blueprints in the backlog. Here is the status
> > for those blueprints that are not discussed in other sections of this
> > summary:
> >
> >- Adopt oslo.versionedobjects for database interactions. This is a
> > continuing effort. The contact is Ihar Hrachyshka  (ihrachys).
> Contributors
> > are wanted. There is a weekly meeting led by Ihar where this topic is
> > covered: http://eavesdrop.openstack.org/#Neutron_Upgrades_Meeting
> >
> >- Enable adoption of an existing subnet into a subnetpool. The final
> > patch in the series to implement this feature is:
> > https://review.openstack.org/#/c/348080. Pawel Suder will drive this
> patch
> > to completion
> >
> >- Neutron in-tree API reference (https://blueprints.launchpad.
> > net/neutron/+spec/neutron-in-tree-api-ref). There are two remaining TODOs
> > to complete this blueprint:
> https://bugs.launchpad.net/neutron/+bug/1752274
> > and https://bugs.launchpad.net/neutron/+bug/1752275. We need volunteers
> for
> > these two work items
> >
> >- Add TCP/UDP port forwarding extension to L3. The spec was merged
> > recently: https://specs.openstack.org/openstack/neutron-specs/specs/qu
> > eens/port-forwarding.html. Implementation effort is in progress:
> > https://review.openstack.org/#/c/533850/ and
> https://review.openstack.org/#
> > /c/535647/
> >
> >- Pure Python driven Linux network configuration (
> > https://bugs.launchpad.net/neutron/+bug/1492714). This effort has been
> > going on for several cycles gradually adopting pyroute2. Slawek Kaplonski
> > is continuing it with https://review.openstack.org/#/c/545355 and
> > https://review.openstack.org/#/c/548267
> >
> >
> > Port 

Re: [openstack-dev] [cinder] [manila] Performance concern on new quota system

[Gorka Eguileor]

On 09/03, Sean McGinnis wrote:
>
> > On Mar 9, 2018, at 07:37, TommyLike Hu  wrote:
> >
> > Thanks Gorka,
> > To be clear, I started this discussion not because I reject this 
> > feature, instead I like it as it's much more clean and simple, compared 
> > with performance impact it solves several other issues which we hate badly. 
> > I wrote this is to point out we may have this issue, and to see whether we 
> > could improve it before it's actually landed. Better is better:)
> >
> >
> > - Using a single query to retrieve both counts and sums instead of 2
> >  queries.
> >
> > For this advice, I think I already combined count and sum into single query.
> >

Yes, but we would be doing 2 count and sum queries, one for the volumes
and another one for the per volume types, the idea I was proposing is
doing just 1 query for both calculations, that way even if you increase
the payload of the response from the DB you are getting rid of a round
trip to the DB as well as a pass through  all the volumes for the volume
type.



> >  - DB triggers to do the actual counting.
> >
>
> Please, no DB triggers. :)
>
> > This seems a good idea, but not sure whether it could cover all of the 
> > cases we have in our quota system and whether can be easily integrated into 
> > cinder, can you share more detail on this?
> >
> > Thanks
> > TommyLike
> >
>


As a general rule I agree with Sean that it's better to not have
triggers, but I wanted to mention them as an alternative in case we
really, really, really have problems with the other alternatives.

Cheers,
Gorka.

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

[openstack-dev] OpenStack - Install gnocchi error.

[__ mango.]

hi,
I refer to: 
https://docs.openstack.org/ceilometer/pike/install/install-base-ubuntu.html 
installation gnocchi, 
unable to find gnocchi - API related services is this why?
Please help answer my question, thank you!__
OpenStack Development Mailing 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][vote] core nomination for caoyuan

[zhubingbing]

+1





在 2018-03-13 01:05:46，"Steven Dake (stdake)"  写道：


+1

 

From: Jeffrey Zhang 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Sunday, March 11, 2018 at 7:13 PM
To: OpenStack Development Mailing List 
Subject: Re: [openstack-dev] [kolla][vote] core nomination for caoyuan

 

sorry for a typo.

 

The vote is open for 7 days until Mar 19th.

 

On Mon, Mar 12, 2018 at 10:06 AM, Jeffrey Zhang  wrote:

Kolla core reviewer team,

 

It is my pleasure to nominate caoyuan for kolla core team.

 

caoyuan's output is fantastic over the last cycle. And he is the most

active non-core contributor on Kolla project for last 180 days[1]. He

focuses on configuration optimize and improve the pre-checks feature. 

 

Consider this nomination a +1 vote from me.

 

A +1 vote indicates you are in favor of caoyuan as a candidate, a -1 

is a veto. Voting is open for 7 days until Mar 12th, or a unanimous

response is reached or a veto vote occurs.

 

[1] http://stackalytics.com/report/contribution/kolla-group/180

--

Regards,

Jeffrey Zhang

Blog: http://xcodest.me





 

--

Regards,

Jeffrey Zhang

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

[openstack-dev] [QA] [PTG] QA New Office Hours and no more meetings

[Ghanshyam Mann]

Hi All,

During Dublin PTG, QA team discussed on Office hours vs meetings and to
have a consistent time for meeting or office hours [1]. Due to low
attendance in current meetings, we decided to cancel all meetings and
starting the office hours on same time every Thursday in both TZ (09:00 UTC
and 17:00 UTC).  We have tried Office hours bi-weekly in Queens cycle and
it was much productively than meetings.

Below are the changes for QA meetings and office hours:

Past:
- Thursday 08:00 UTC bi-weekly meeting on #openstack-meeting - NOW CANCELED

- Thursday 17:00 UTC bi-weekly meeting on #openstack-meeting - NOW CANCELED

Current:
- Every Thursday 09:00 UTC Office Hours on #openstack-qa
- Every Thursday 17:00 UTC Office hours on #openstack-qa

Agenda for Office hours are defined on wiki page[2] and new topic can be
added in Open Discussion section. I updated the QA meeting wiki page [2]
and irc channel info [3] to reflect the changes.

..1 https://etherpad.openstack.org/p/qa-rocky-ptg-rocky-priority
..2
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Weekly_QA_Team_meeting
..3 http://eavesdrop.openstack.org/#QA_Team_Office_hours

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