[openstack-dev] [grenade][osc][rocky]openstack client Rocky does not work with python-cinderclient Rocky

[Ghanshyam Mann]

Hi All,

While doing the grenade setting to test the Rocky upgrade testing [1], i found 
osc Rocky version (3.15 or 3.16) does not work with python-cinderclient Rocky 
version (>=4.0.0) [2].

Failure are due to source_replica arg has been removed from python-cinderclient 
which went in Rocky release and osc fix of that went in after Rocky. 

Openstackclient Rocky version - 3.16.0
cinderclient Rocky version - 4.0.1

These 2 version does not work because cinderclient >=4.0.0 has removed the 
source_replica arg which is being taken care in openstackclient > 3.16 [2] so 
openastackclient rocky version (3.15 or 3.16 does not work with cinderclient 
rocky version)

We should backport the openstackclient fix [3] to Rocky and then release the 
osc version for Rocky. I have proposed the backport [4]. 

[1] https://review.openstack.org/#/c/591594
[2] 
http://logs.openstack.org/94/591594/2/check/neutron-grenade/b281347/logs/grenade.sh.txt.gz#_2018-09-03_01_29_36_289
 
[3] https://review.openstack.org/#/c/587005/
[4] https://review.openstack.org/#/c/599291/

-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

Re: [openstack-dev] [nova-lxd]Feature support matrix of nova-lxd

[Rikimaru Honjo]

Hi James,

Thank you for agreeing.
I begin to write the document.

Best regards,

On 2018/08/31 20:03, James Page wrote:

Hi Rikimaru

On Fri, 31 Aug 2018 at 11:28 Rikimaru Honjo 
wrote:


Hello,

I'm planning to write a feature support matrix[1] of nova-lxd and
add it to nova-lxd repository.
A similar document exists as todo.txt[2], but this is old.

Can I write it?



Yes please!



If someone is writing the same document now, I'll stop writing.



They are not - please go ahead - this would be a valuable contribution for
users evaluating this driver.

Regards

Jjames



__
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



--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
★部署名が変わりました。

NTTテクノクロス株式会社
IoTイノベーション事業部 第二ビジネスユニット（IV2BU）
本上力丸
TEL.  :045-212-7539
E-mail:honjo.rikim...@po.ntt-tx.co.jp
〒220-0012
  横浜市西区みなとみらい4丁目4番5号
  横浜アイマークプレイス 13階



__
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] [grenade][osc][rocky]openstack client Rocky does not work with python-cinderclient Rocky

[Ghanshyam Mann]

  On Mon, 03 Sep 2018 15:27:10 +0900 Ghanshyam Mann 
 wrote  
 > Hi All,
 > 
 > While doing the grenade setting to test the Rocky upgrade testing [1], i 
 > found osc Rocky version (3.15 or 3.16) does not work with 
 > python-cinderclient Rocky version (>=4.0.0) [2].
 > 
 > Failure are due to source_replica arg has been removed from 
 > python-cinderclient which went in Rocky release and osc fix of that went in 
 > after Rocky. 
 > 
 > Openstackclient Rocky version - 3.16.0
 > cinderclient Rocky version - 4.0.1
 > 
 > These 2 version does not work because cinderclient >=4.0.0 has removed the 
 > source_replica arg which is being taken care in openstackclient > 3.16 [2] 
 > so openastackclient rocky version (3.15 or 3.16 does not work with 
 > cinderclient rocky version)
 > 
 > We should backport the openstackclient fix [3] to Rocky and then release the 
 > osc version for Rocky. I have proposed the backport [4]. 
 > 
 > [1] https://review.openstack.org/#/c/591594
 > [2] 
 > http://logs.openstack.org/94/591594/2/check/neutron-grenade/b281347/logs/grenade.sh.txt.gz#_2018-09-03_01_29_36_289
 >  
 > [3] https://review.openstack.org/#/c/587005/
 > [4] https://review.openstack.org/#/c/599291/
 > 

This should be detected in osc Rocky patches but seems like 
osc-functional-devstack job does not run for stable/rocky zuul.yaml or tox.ini 
only changes [1]. I am not sure why osc-functional-devstack job did not run for 
below patches. I did not find irrelevant-files regex which exclude those file. 
We can see stable/queens run the functional job for similar changes [2].  Is 
something wrong in job selection on zuul side ?

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

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

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



__
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] fluentd logging status

[Juan Badia Payno]

On Fri, Aug 31, 2018 at 3:08 PM, Juan Antonio Osorio Robles <
jaosor...@redhat.com> wrote:

> Logging is a topic that I think should get more love on the TripleO side.
>
> On 08/24/2018 12:17 PM, Juan Badia Payno wrote:
>
> Recently, I did a little test regarding fluentd logging on the gates
> master[1], queens[2], pike [3]. I don't like the status of it, I'm still
> working on them, but basically there are quite a lot of misconfigured logs
> and some services that they are not configured at all.
>
> I think we need to put some effort on the logging. The purpose of this
> email is to point out that we need to do a little effort on the task.
>
> First of all, I think we need to enable fluentd on all the scenarios, as
> it is on the tests [1][2][3] commented on the beginning of the email. Once
> everything is ok and some automatic test regarding logging is done they can
> be disabled.
>
> Wes, do you have an opinion about this? I think it would be a good idea to
> avoid these types of regressions.
>
>
> I'd love not to create a new bug for every misconfigured/unconfigured
> service, but if requested to grab more attention on it, I will open it.
>
> One bug to fix all this is fine, but we do need a public place to track
> all the work that needs to be done. Lets reference that place on the bug.
> Could be Trello or an etherpad, or whatever you want, it's up to you.
>
I'm creating the google spreadsheet [4] to track the status of the fluentd
logging from pike to master.

>
> The plan I have in mind is something like:
>  * Make an initial picture of what the fluentd/log status is (from pike
> upwards).
>  * Fix all misconfigured services. (designate,...)
>  * Add the non-configured services. (manila,...)
>  * Add an automated check to find a possible unconfigured/misconfigured
> problem.
>
> Any comments, doubts or questions are welcome
>
> Cheers,
> Juan
>
> [1] https://review.openstack.org/594836
> [2] https://review.openstack.org/594838
> [3] https://review.openstack.org/594840
>
> [4]
https://docs.google.com/spreadsheets/d/1Keh_hBYGb92rXV3VN44oPR6eGnX9LnTpcadWfMO8dZs/edit?usp=sharing


>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>
>


-- 

Juan Badia Payno

Software Engineer

Red Hat EMEA ENG Openstack Infrastructure
__
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-ansible] Stepping down from OpenStack-Ansible core

[Hugh Saunders]

Thanks for all your hard work on OSA Andy :)

On Thu, 30 Aug 2018 at 18:41 Andy McCrae  wrote:

> Now that Rocky is all but ready it seems like a good time! Since changing
> roles I've not been able to keep up enough focus on reviews and other
> obligations - so I think it's time to step aside as a core reviewer.
>
> I want to say thanks to everybody in the community, I'm really proud to
> see the work we've done and how the OSA team has grown. I've learned a
> tonne from all of you - it's definitely been a great experience.
>
> Thanks,
> Andy
> __
> 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] [neutron] Bug deputy report week August 27 - September 2

[Hirofumi Ichihara]

Hi,

I was the bug deputy for the week of August 27 - September 2.

There is no Ctirical bug.

High:
https://bugs.launchpad.net/neutron/+bug/1789878
https://bugs.launchpad.net/neutron/+bug/1789846
https://bugs.launchpad.net/neutron/+bug/1789579
https://bugs.launchpad.net/neutron/+bug/1789434
https://bugs.launchpad.net/neutron/+bug/1789403

Medium:
https://bugs.launchpad.net/neutron/+bug/1790143
https://bugs.launchpad.net/neutron/+bug/1789499

New:
https://bugs.launchpad.net/neutron/+bug/1790084 This is needed to triage
by l3-dvr-backlog lieutenants.
https://bugs.launchpad.net/neutron/+bug/1790038 This is needed to triage
by l3-dvr-backlog lieutenants.
https://bugs.launchpad.net/neutron/+bug/1789334 This is needed to triage by
troubleshooting lieutenants or Osprofier forks.

Incomplete:
https://bugs.launchpad.net/neutron/+bug/1790023
https://bugs.launchpad.net/neutron/+bug/1789870
https://bugs.launchpad.net/neutron/+bug/1789844

Wishlist:
https://bugs.launchpad.net/neutron/+bug/1789378

RFE:
https://bugs.launchpad.net/neutron/+bug/1789592
https://bugs.launchpad.net/neutron/+bug/1789391

Thanks,
Hirofumi
__
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] Nominating Chris Dent for placement-core

[Stephen Finucane]

On Fri, 2018-08-31 at 10:45 -0500, Eric Fried wrote:
> The openstack/placement project [1] and its core team [2] have been
> established in gerrit.
> 
> I hereby nominate Chris Dent for membership in the placement-core team.
> He has been instrumental in the design, implementation, and stewardship
> of the placement API since its inception and has shown clear and
> consistent leadership.
> 
> As we are effectively bootstrapping placement-core at this time, it
> would seem appropriate to consider +1/-1 responses from heavy placement
> contributors as well as existing cores (currently nova-core).
> 
> [1] https://review.openstack.org/#/admin/projects/openstack/placement
> [2] https://review.openstack.org/#/admin/groups/1936,members

+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] [glance][ptl] Canceled: Glance meeting Thu 6th and 13th of Sept

[Erno Kuvaja]

Hi all,

PTG is approaching fast and I'm pretty much offline this week for
holidays so will cancel the two next meetings.

We will get together over Wed to Fri in the PTG and have next Glance
weekly meeting the week after.

Safe travels everyone and I'm looking forward to see as many of ye as
possible in Denver.

Erno -jokke- Kuvaja

__
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] [charms] Deployment guide stable/rocky cut

[Alex Kavanagh]

Hi Ed

Yes, it's in hand.  I've got a review up:
https://review.openstack.org/#/c/598138/ but I also need to create some
stable branches, etc.  May take a few more days.

Thanks
Alex.

On Fri, Aug 31, 2018 at 12:48 PM, Edward Hope-Morley 
wrote:

> Hi Frode, I think it would be a good idea to add a link to the charm
> deployment guide at the following page:
>
> https://docs.openstack.org/rocky/deploy/
>
> - Ed
>
> On 17/08/18 08:47, Frode Nordahl wrote:
>
> Hello OpenStack charmers,
>
> I am writing to inform you that  a `stable/rocky` branch has been cut for
> the `openstack/charm-deployment-guide` repository.
>
> Should there be any further updates to the guide before the release the
> changes will need to be landed in `master` and then back-ported to
> `stable/rocky`.
>
> --
> Frode Nordahl
> Software Engineer
> Canonical Ltd.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>
>


-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
__
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] [networking-odl][networking-bgpvpn][ceilometer] all requirement updates are currently blocked

[Thomas Morin]

Hi Mathew,

Matthew Thode, 2018-08-31 19:52:
> The requirements project has a co-installability test for the various
> projects, networking-odl being included.
> 
> Because of the way the dependancy on ceilometer is done it is
> blocking all reviews and updates to the requirements project.

(also blocking reviews for networking-bgpvpn)

> 
http://logs.openstack.org/96/594496/2/check/requirements-integration/8378cd8/job-output.txt.gz#_2018-08-31_22_54_49_357505
> 
> If networking-odl is not meant to be used as a library I'd recommend
> it's removal from networking-bgpvpn (it's test-requirements.txt
> file).

Historically, the driver allowing the use of networking-bgpvpn with the
ODL SDN controller was in the networking-bgpvpn project ; this is why
we have this dependency (the driver using some ODL utility code found
in the networking-odl project).

We can work at removing this historical driver from networking-bgpvpn.
Since a v2 driver (hosted in networking-odl) has been existing for a
long time, we possibly can do that without waiting. Just need to think
about the best way to do it.

ODL team, what do you think ?

In the meantime, to unbreak the CI for networking-bgpvpn, I'm pushing
[1], which puts an upper bound (< 13) on the dependency on networking-
odl to avoid drawing version 13 of networking-odl which introduces the
requirement on ceilometer.

-Thomas

[1] https://review.openstack.org/#/c/599310/2/test-requirements.txt


> Once that is done networking-odl can be removed from global-
> requirements
> and we won't be blocked anymore.
> 
> As a side note, fungi noticed that when you branched you are still
> installing ceilometer from master.  Also, the ceilometer team
> doesnt wish it to be used as a library either (like networking-odl
> doesn't wish to be used as a library).
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] Nominating Chris Dent for placement-core

[Balázs Gibizer]

On Fri, Aug 31, 2018 at 5:45 PM, Eric Fried  wrote:

The openstack/placement project [1] and its core team [2] have been
established in gerrit.

I hereby nominate Chris Dent for membership in the placement-core 
team.
He has been instrumental in the design, implementation, and 
stewardship

of the placement API since its inception and has shown clear and
consistent leadership.

As we are effectively bootstrapping placement-core at this time, it
would seem appropriate to consider +1/-1 responses from heavy 
placement

contributors as well as existing cores (currently nova-core).

[1] https://review.openstack.org/#/admin/projects/openstack/placement
[2] https://review.openstack.org/#/admin/groups/1936,members


+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 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] Call for OpenStack Outreachy internship project proposals and funding

[Mahati C]

Hello everyone!

An update on the Outreachy program, including a request for volunteer
mentors and funding.

Outreachy  helps people from
underrepresented groups get involved in free and open source software by
matching interns with established mentors in the upstream community.
OpenStack is a participating organization in the Outreachy Dec 2018 to Mar
2019 internships. If you're interested to be a mentor, please publish your
project ideas on this page
https://www.outreachy.org/communities/cfp/openstack/submit-project/. Here
is a link that helps you get acquainted with mentorship process:
https://wiki.openstack.org/wiki/Outreachy/Mentors.

We have funding for two interns so far. We are looking for additional
sponsors to help support OpenStack applicants. The sponsorship cost is
6,500 USD per intern, which is used to provide them a stipend for the
three-month program. You can learn more about sponsorship here:
https://www.outreachy.org/sponsor/ . Outreachy has been one of the most
important and effective diversity efforts we’ve invested in. We have had
many interns turn into long term OpenStack contributors. Please help spread
the word.

If you are interested in becoming a mentor or sponsoring an intern, please
contact me (mahati.chamarthy AT intel.com) or Sameul ( samueldmq AT
gmail.com ). Thank you!

Best,
Mahati
__
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] Nominating Chris Dent for placement-core

[Kenichi Omichi]

+1

2018年8月31日(金) 8:45 Eric Fried :

> The openstack/placement project [1] and its core team [2] have been
> established in gerrit.
>
> I hereby nominate Chris Dent for membership in the placement-core team.
> He has been instrumental in the design, implementation, and stewardship
> of the placement API since its inception and has shown clear and
> consistent leadership.
>
> As we are effectively bootstrapping placement-core at this time, it
> would seem appropriate to consider +1/-1 responses from heavy placement
> contributors as well as existing cores (currently nova-core).
>
> [1] https://review.openstack.org/#/admin/projects/openstack/placement
> [2] https://review.openstack.org/#/admin/groups/1936,members
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
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] Bug deputy report week August 27 - September 2

[Gary Kotton]

Thanks for the update. I have taken the baton from the 2nd. Thankfully last few 
days have been quite.
A luta continua

From: Hirofumi Ichihara 
Reply-To: OpenStack List 
Date: Monday, September 3, 2018 at 11:54 AM
To: OpenStack List 
Subject: [openstack-dev] [neutron] Bug deputy report week August 27 - September 
2

Hi,

I was the bug deputy for the week of August 27 - September 2.

There is no Ctirical bug.

High:
https://bugs.launchpad.net/neutron/+bug/1789878
https://bugs.launchpad.net/neutron/+bug/1789846
https://bugs.launchpad.net/neutron/+bug/1789579
https://bugs.launchpad.net/neutron/+bug/1789434
https://bugs.launchpad.net/neutron/+bug/1789403

Medium:
https://bugs.launchpad.net/neutron/+bug/1790143
https://bugs.launchpad.net/neutron/+bug/1789499

New:
https://bugs.launchpad.net/neutron/+bug/1790084
 This is needed to triage by l3-dvr-backlog lieutenants.
https://bugs.launchpad.net/neutron/+bug/1790038
 This is needed to triage by l3-dvr-backlog lieutenants.
https://bugs.launchpad.net/neutron/+bug/1789334
 This is needed to triage by troubleshooting lieutenants or Osprofier forks.

Incomplete:
https://bugs.launchpad.net/neutron/+bug/1790023
https://bugs.launchpad.net/neutron/+bug/1789870

Re: [openstack-dev] [api] Open API 3.0 for OpenStack API

[Gilles Dubreuil]

On 30/08/18 13:56, Edison Xiang wrote:

Hi Ed Leafe,

Thanks your reply.
Open API defines a standard interface description for REST APIs.
Open API 3.0 can make a description(schema) for current OpenStack REST 
API.

It will not change current OpenStack API.
I am not a GraphQL expert. I look up something about GraphQL.
In my understanding, GraphQL will get current OpenAPI together and 
provide another APIs based on Relay,


Not sure what you mean here, could you please develop?


and Open API is used to describe REST APIs and GraphQL is used to 
describe Relay APIs.


There is no such thing as "Relay APIs".
GraphQL povides a de-facto API Schema and Relay provides extensions on 
top to facilitate re-fetching, paging and more.
GraphQL and OpenAPI have a different feature scope and both have pros 
and cons.
GraphQL is delivering API without using REST verbs as all requests are 
undone using POST and its data.
Beyond that what would be great (and it will ultimately come) is to have 
both of them working together.


The idea of the GraphQL Proof of Concept is see what it can bring and at 
what cost such as effort and trade-offs.
And to compare this against the effort to adapt OpenStack APIs to use 
Open API.


BTW what's the status of Open API 3.0 in regards of Microversion?

Regards,
Gilles



Best Regards,
Edison Xiang

On Wed, Aug 29, 2018 at 9:33 PM Ed Leafe > wrote:


On Aug 29, 2018, at 1:36 AM, Edison Xiang mailto:xiang.edi...@gmail.com>> wrote:
>
> As we know, Open API 3.0 was released on July, 2017, it is about
one year ago.
> Open API 3.0 support some new features like anyof, oneof and
allof than Open API 2.0(Swagger 2.0).
> Now OpenStack projects do not support Open API.
> Also I found some old emails in the Mail List about supporting
Open API 2.0 in OpenStack.

There is currently an effort by some developers to investigate the
possibility of using GraphQL with OpenStack APIs. What would Open
API 3.0 provide that GraphQL would not? I’m asking because I don’t
know enough about Open API to compare them.


-- Ed Leafe






__
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


--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
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] [placement] extraction (technical) update

[Chris Dent]

There's been some progress on the technical side of extracting
placement to it own repo. The summary is:

* https://git.openstack.org/cgit/openstack/placement exists
* https://review.openstack.org/#/c/599416/ is at the top of a
  series of patches. That patch is passing and voting on unit and
  functional for py 2.7 and 3.5 and is passing pep8.

More below, in the steps.

On Tue, 28 Aug 2018, Chris Dent wrote:

On Mon, 27 Aug 2018, melanie witt wrote:
1. We copy the placement code into the openstack/placement repo and have it 
passing all of its own unit and functional tests.


To break that down to more detail, how does this look?
(note the ALL CAPS where more than acknowledgement is requested)

1.1 Run the git filter-branch on a copy of nova
   1.1.1 Add missing files to the file list:
 1.1.1.1 .gitignore
 1.1.1.2 # ANYTHING ELSE?
1.2 Push -f that thing, acknowledge to be broken, to a seed repo on github
   (ed's repo should be fine)
1.3 Do the repo creation bits described in
   https://docs.openstack.org/infra/manual/creators.html
   to seed openstack/placement
   1.3.1 set zuul jobs. Either to noop-jobs, or non voting basic
   func and unit # INPUT DESIRED HERE
1.4 Once the repo exists with some content, incrementally bring it to
   working
   1.4.1 Update tox.ini to be placement oriented
   1.4.2 Update setup.cfg to be placement oriented
   1.4.3 Correct .stesr.conf
   1.4.4 Move base of placement to "right" place
   1.4.5 Move unit and functionals to right place
   1.4.6 Do automated path fixings
   1.4.7 Set up translation domain and i18n.py corectly
   1.4.8 Trim placement/conf to just the conf settings required
 (api, base, database, keystone, paths, placement)
   1.4.9 Remove database files that are not relevant (the db api is
 not used by placement)
   1.4.10 Fix the Database Fixture to be just one database
   1.4.11 Disable migrations that can't work (because of
  dependencies on nova code, 014 and 030 are examples)
  # INPUT DESIRED HERE AND ON SCHEMA MIGRATIONS IN GENERAL


030 is okay as long as nothing goes wrong. If something does it
raises exceptions which would currently fail as the exceptions are
not there. See below for more about exceptions.


   1.4.12 Incrementally get tests working
   1.4.13 Fix pep8
1.5 Make zuul pep, unit and functional voting


This is where we are now at https://review.openstack.org/#/c/599416/


1.6 Create tools for db table sync/create


It made some TODOs about this in setup.cfg, also nothing that in
additional to a placement-manage we'll want a placement-status.


1.7 Concurrently go to step 2, where the harder magic happens.
1.8 Find and remove dead code (there will be some).


Some dead code has been removed, but there will definitely be plenty
more to find.


1.9 Tune up and confirm docs
1.10 Grep for remaining "nova" (as string and spirit) and fix



Item 1.4.12 may deserve some discussion. When I've done this the
several times before, the strategy I've used is to be test driven:
run either functional or unit tests, find and fix one of the errors
revealed, commit, move on.


In the patch set that ends with the review linked above, this is
pretty much what I did. Switching between a tox run of the full
suite and using testtools.run to run an individual test file.

2. We have a stack of changes to zuul jobs that show nova working but 
deploying placement in devstack from the new repo instead of nova's repo. 
This includes the grenade job, ensuring that upgrade works.


Do people have the time or info needed to break this step down into
multiple steps like the '1' section above. Things I can think of:

* devstack patch to deploy placement from the new repo
  * and use placement.conf
* stripping of placement out of nova, a bit like
  https://review.openstack.org/#/c/596291/ , unless we leave that
  enitrely to step 4
* grenade tweaks (?)
* more

3. When those pass, we merge them, effectively orphaning nova's copy of 
placement. Switch those jobs to voting.


4. Finally, we delete the orphaned code from nova (without needing to make 
any changes to non-placement-only test code -- code is truly orphaned).


Some questions I have:

* Presumably we can trim the placement DB migrations to just stuff
  that is relevant to placement and renumber accordingly?

* Could we also make it so we only run the migrations if we are not
  in a fresh install? In a fresh install we ought to be able to skip
  the migrations entirely and create the tables by reflection with
  the class models [1].

* I had another but I forgot.

[1] I did something similar to placedock for when starting from
scratch:
https://github.com/cdent/placedock/blob/b5ca753a0d97e0d9a324e196349e3a19eb62668b/sync.py#L68-L73


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

Re: [openstack-dev] [networking-odl][networking-bgpvpn][ceilometer] all requirement updates are currently blocked

[Thomas Morin]

Thomas Morin, 2018-09-03 13:31:
> Matthew Thode, 2018-08-31 19:52:
> > 
> > If networking-odl is not meant to be used as a library I'd
> > recommend
> > it's removal from networking-bgpvpn (it's test-requirements.txt
> > file).
> 
> We can work at removing this historical driver from networking-
> bgpvpn. Since a v2 driver (hosted in networking-odl) has been
> existing for a long time, we possibly can do that without waiting.
> Just need to think about the best way to do it.

Realizing that we've had a warning announcing deprecation and
future removal for the last release [1], I've pushed [2] to remove the
ODL driver from master without waiting.

Please comment there as needed.

-Thomas

[1] 
https://github.com/openstack/networking-bgpvpn/commit/ffee38097709dd4091fb8709a70cf6c361ed60ee#diff-88cc53515016b9f865a830b216c8e564
[2] https://review.openstack.org/599422


> > Once that is done networking-odl can be removed from global-
> > requirements
> > and we won't be blocked anymore.
> > 
> > As a side note, fungi noticed that when you branched you are still
> > installing ceilometer from master.  Also, the ceilometer team
> > doesnt wish it to be used as a library either (like networking-odl
> > doesn't wish to be used as a library).
> > 
> > ___
> > __
> > _
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bs
> > cribe
> > 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:unsubs
> cribe
> 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] [chef] fog-openstack 0.2.0 breakage

[Samuel Cassiba]

On Fri, Aug 31, 2018 at 8:59 AM, Samuel Cassiba  wrote:
> Ohai!
>
> fog-openstack 0.2.0 was recently released, which had less than optimal
> effects on Chef OpenStack due to the client cookbook's lack of version
> pinning on the gem.
>

Currently, the client cookbook is pinned to <0.2.0 going back to
Ocata. Supermarket is updated as well.

Due to the fallout generated, 0.2.x will be allowed where ChefDK
introduces it, but 0.2.1 should be usable if you want to give it a go.

Best,
scas

__
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] Future plans

[Martin Magr]

Gretings,

  since I did not find any blueprint regarding proper usage of
tripleo-ansible, I would like to ask how exactly we plan to use
tripleo-ansible project, what should be the proper structure of
roles/playbooks, etc. Given the discussion in [1] it is the best place for
backup and restore playbooks and I'd like to start preparing patches for
B Currently the development being done in [2], but I hope that is only
temporary location.

Thanks in advance for answers,
Martin

[1] https://review.openstack.org/#/c/582453/
[2] https://github.com/centos-opstools/os-backup-ansible

-- 
Martin Mágr
Senior Software Engineer
Red Hat Czech
__
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