December 2018 - openstack-discuss

[Searchlight] Next meeting cancelled
by Trinh Nguyen 26 Dec '18

26 Dec '18

Hi team, Next week I'm on vacation so we will have to cancel the meeting on 31st December. See you next year :) P/S: I'll be at the VietOpenInfra meetup in Ho Chi Minh city this Saturday :) -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[kolla] Today and next week meeting cancelled
by Eduardo Gonzalez 26 Dec '18

26 Dec '18

Dear Kolla Team, Because Christmas holidays many people could not attend the Kolla weekly meeting, we will cancel today (26th December) and next meeting (2nd January). We will resume the weekly meetings on 9th January. Have a nice Christmas Best regards

1 0

[dev] [horizon] No meetings until January, 9th
by Ivan Kolodyazhny 25 Dec '18

25 Dec '18

Hi all, We agreed to skip the next two meetings due to the Christmas and New Year holidays at the last meeting [1]. Enjoy the holidays! [1] http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-12-19-15.… Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

1 0

[openstack-discuss][Glance]BP to trace change to store context in request.environ[‘glance.context’]
by Leehom Li (feli5) 25 Dec '18

25 Dec '18

Hi, I encountered an error when enable audit for glance. And a bug is fired to fix the conflict in keystone middleware project. https://bugs.launchpad.net/keystonemiddleware/+bug/1809101 Brief about the bug is both keystone audit middleware and glance are using req.context. They are conflict with each other. I upload a patch to fix this issue for keystone audit middleware. But I think it would be nice to have glance consist with other OpenStack component like nova to store context in request.environ[‘glance.context’]. I checked the code of glance, use of req.context spread cross entire API level code, so I think it would be better to have a BP to trace about the change. Needs your kind advice. Best regards, Leehom Li feli5(a)cisco.com Phone: +86 512 8777 4186

2 1

[security] No meeting Dec 27th & Jan 3rd
by Gage Hugo 25 Dec '18

25 Dec '18

The Security SIG meetings for this week and next week are canceled. We will meet again on Jan 10th. Enjoy the holidays!

1 0

[vitrage] No IRC meeting tomorrow
by Ifat Afek 25 Dec '18

25 Dec '18

Hi, We will skip the IRC meeting this week. We will meet again next Wednesday, January 2nd. Thanks, Ifat

1 0

[self-healing-sig][vitrage][monasca] Vitrage and Monasca integration
by Ifat Afek 25 Dec '18

25 Dec '18

Hi, In the last self-healing SIG meeting, we discussed the integration of Monasca and Vitrage [1]. We talked about the challenge of identifying the resource in Vitrage based on Monasca metric dimensions. As we discussed [2], I wrote an initial spec for mapping the different use cases [3]. I’ll be happy to get your feedback - at this stage our main interest is to collect more use cases and concrete examples. Thanks, Ifat [1] https://review.openstack.org/#/c/622899/ [2] http://eavesdrop.openstack.org/meetings/self_healing/2018/self_healing.2018… [3] https://review.openstack.org/#/c/627180

1 0

[mistral] Let’s meet in IRC after Jan 8
by Renat Akhmerov 25 Dec '18

25 Dec '18

Hi, I guess there won’t be many working people till Jan 9 (Christmas & NY holidays) so I’m hereby calling Mistral contributors to meet after the holidays and discuss the project course and priorities for the next few months. We can do it during one of our allocated office hours slots. Will decide later when exactly. Thanks Renat Akhmerov @Nokia

1 0

[Tacker] No IRC meetings taday and next week.
by Dharmendra Kushwaha 25 Dec '18

25 Dec '18

Dear Folks, Due to the holiday season, we will not have IRC meetings today and the next week. The next meeting will be held on Jan 8th 2019. Good wishes for X-mas & new year. Enjoy holidays. Thanks & Regards Dharmendra Kushwaha

1 0

[heat] No IRC meeting until Jan. 9th
by Rico Lin 24 Dec '18

24 Dec '18

Dear all, these two weeks are Christmas and new year. We will resume our meeting on Jan. 9th, 2019 So I wish you all a merry Christmas and happy new year. -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[cyborg] No IRC meetings for until the week of Jan 7th 2019
by Li Liu 24 Dec '18

24 Dec '18

Hi Team, Due to the holiday season, we will not have irc meetings for this week and the week after. The next meeting will be held on Jan 8th 2019 Enjoy the holidays and happy new year. -- Thank you Regards Li

1 0

The design choice of keystone sso
by guoyongxhzhf＠163.com 23 Dec '18

23 Dec '18

The problem is about keystone with sso The situation: 1. the cloud based on OpenStack has use keystone to build its own user account system, and no third user account like ldap or google accounts 2. the cloud may have multi web application/entrance and have multi domain name, so we need sso So there are two choice to implement sso 1. use CAS or other open source components as sso service and use database authentication which query keystone database.(I think it's odd) 2. use cookies(including keystone token) between multi web application/entrance which is the better choice? I think if we use only users from keystone, it's not necessary to use an extra sso service.

2 1

[keystone] The design choice of keystone sso
by guoyongxhzhf＠163.com 23 Dec '18

23 Dec '18

The problem is about keystone with sso The situation: 1. the cloud based on OpenStack has use keystone to build its own user account system, and no third user account like ldap or google accounts 2. the cloud may have multi web application/entrance and have multi domain name, so we need sso So there are two choice to implement sso 1. use CAS or other open source components as sso service and use database authentication which query keystone database.(I think it's odd) 2. use cookies(including keystone token) between multi web application/entrance which is the better choice? I think if we use only users from keystone, it's not necessary to use an extra sso service.

1 0

[neutron] Subnet onboard and changing API definitions in neutron-lib
by Ryan Tidwell 23 Dec '18

23 Dec '18

All, I alluded to some concerns about the current state of subnet onboard at the end of today's neutron team meeting. I felt the mailing list was probably the best starting point for a discussion, so here it goes :) As I'm dealing with the last loose ends, I'm starting to deal with the 'subnets' extension to the subnetpool resource on the API [1]. This has me scratching my head at what the intent of this is since there isn't much history to work with. When I look at the definition of the subnet onboard extension in neutron-lib, I can see two possible "meanings" of POST/PUT here: 1. Create a subnet from this subnetpool using the default prefix length of the subnet pool. 2. Onboard the given subnet into the subnet pool. In addition to this ambiguity around the usage of the API, I also have concerns that ONBOARD_SUBNET_SPECS as currently defined makes no sense for either case. ONBOARD_SUBNET_SPECS requires that an id, network_id, and ip_version be sent on any request made. This seems unnecessary for both cases. Case 1 where we assume that we are using an alternate API to create a subnet is problematic in the following ways: - Specifying an ip_version is unnecessary because it can be inferred from the subnet pool - The definition as written doesn't seem to allow us to respond to the user with anything other than a UUID. The user then has to make a second call to actually go read the details like CIDR that are going to be useful for them going forward. - More importantly, we already have an API (and corresponding CLI) for creating subnets that works well and has much more flexibility than this provides. Why duplicate functionality here? Case 2 where we assume that we are onboarding a subnet is problematic in the following ways: - Specifying network_id and ip_version are unnecessary. These values can be read right off the subnet (which we would need to read for onboarding anyway), all that needs to be passed is the subnet UUID. - Again, we would be duplicating functionality here because we have already defined an API for onboarding a subnet in the ACTION_MAP [2] My intent is to figure out where to go from here to make this better and/or alleviate the confusion on my part so this feature can be wrapped up. Here is what I propose: Because subnet onboard is still incomplete and we are not claiming support for it yet, I am proposing we simply remove the 'subnets' extension to the subnetpools resource [3]. This simplifies the API and resolves the concerns I expressed above. It also allows us to quickly finish up subnet onboard without losing any of the desired functionality, namely the ability to move ("onboard") an existing subnet into a subnet pool (and by extension and address scope). The reason I am looking for input here is that it isn't clear to me whether the approach I'm suggesting is acceptable to the team given our policies around changing API definitions in neutron-lib. I'm not aware of a situation where we have had an unreleased feature and have discovered we don't like the API definition in neutron-lib (which has sat for quite a while unimplemented) and want to change it. I'm just not aware of any precedent for this situation, so I'm hoping the team has some thoughts on how best to move forward. For reference, the current review for subnet onboard is https://review.openstack.org/#/c/348080/. Any thoughts on this topic would be greatly appreciated by me, and hopefully this discussion can be useful to a broad audience going forward. -Ryan [1] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/defini… [2] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/defini… [3] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/defini…

4 3

Re: [infra][storyboard] Project Update/Some New Things
by Jeremy Stanley 23 Dec '18

23 Dec '18

On 2018-09-10 14:34:49 +0000 (+0000), Jeremy Stanley wrote: > On 2018-09-10 14:43:18 +0100 (+0100), Adam Coldrick wrote: [...] > > # Finding stories from a task ID > > > > It is now possible to navigate to a story given just a task ID, > > if for whatever reason that's all the information you have > > available. A link like > > > > https://storyboard.openstack.org/#!/task/12389 > > > > will work. This will redirect to the story containing the task, > > and is the first part of work to support linking directly to an > > individual task in a story. > [...] > > As an aside, I think this makes it possible now for us to start > hyperlinking Task footers in commit messages within the Gerrit > change view. I'll try and figure out what we need to adjust in our > Gerrit commentlink and its-storyboard plugin configs to make that > happen. As of Friday (2018-12-21) our Gerrit instance at https://review.openstack.org/ has started hyperlinking task footers in commit messages, leveraging the above feature (the configuration change for it merged months ago but Gerrit has been so stable lately we've not gotten around to restarting it for that to take effect until now). At this point you can omit the story footer if you have a task footer, since all the story footer has been providing is a hyperlink anyway. -- Jeremy Stanley

1 0

[TripleO] SELinux support
by Mikhail Fedosin 22 Dec '18

22 Dec '18

Hello! One of the most important tasks for this release cycle is to provide full SELinux support in the installed overcloud. Some work in this direction has already been done and in many respects, due to the recent changes, support is almost ready. However, I would like to ask a few questions about what else can be improved. In short, to provide SELinux support the main challenge for us is to ensure that docker can write to the directories protected by SELinux. To allow writing there we change the directory type to container_file_t or its alias svirt_sandbox_file_t. There are two ways to do this: 1. Explicitly - specify the type when creating a directory. # semanage fcontext -at container_file_t "/my_folder(/.*)?" # restorecon -R /my_folder # docker run -v /my_folder:/tmp/my_folder ... 2. Implicitly - use the suffix :z when mounting the partition when creating a container. # docker run -v /my_folder:/tmp/my_folder:z ... Both methods change selinux type of /my_folder to container_file_t and allow to write to the section inside the container. You can read more about this feature in the article https://www.projectatomic.io/blog/2015/06/using-volumes-with-docker-can-cau… To see how it works, I wrote a small playbook that creates two directories on the host system and modifies their selinux types in two ways: http://paste.openstack.org/show/737234/ Currently there is no consensus in TripleO which of the ways to use. For example, in many cases both methods are used, which adds unnecessary redundancy: https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… In some cases there is only :z https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… In some, only explicit setting of svirt_sandbox_file_t on the directory https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… Some services still do not have SELinux support: https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… Such inconsistency leads to hard to find bugs and makes it difficult to understand the code. An example of such a bug could be this: Here we set selinux type to svirt_sandbox_file_t for /var/log/swift https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… And rewrite it back later: https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7… For this reason, I want to come to an agreement on how we will implement SELinux support. In my understanding, the best solution would be to use the suffix :z only. Its advantage is that docker (and podman) checks the directory's selinux type before launching the container and changes it accordingly. In other words, if the type was accidentally changed during the execution of the container, then when it is restarted ":z" will return the type back. In the case of explicit type setting, we get an error. Therefore, I propose to remove the explicit setting svirt_sandbox_file_t and add the suffix ":z" where it is still missing. What do you think? Best regards, Mikhail Fedosin

2 1

[goals][upgrade-checkers] Week R-16 Update
by Matt Riedemann 21 Dec '18

21 Dec '18

By my count, 34 of 43 projects have at least the initial framework change in place (up from 28 in November). Neutron has merged the change to enable loading upgrade checks via extension point: https://review.openstack.org/#/c/615196/ The designate check has been updated (thanks Ben) and is ready for review: https://review.openstack.org/#/c/604430/ - this one is not a placeholder Otherwise I would like to highlight some initial framework changes that I think are ready to go: * magnum: https://review.openstack.org/#/c/611505/ * cloudkitty: https://review.openstack.org/#/c/613076/ * aodh: https://review.openstack.org/#/c/614401/ * barbican: https://review.openstack.org/#/c/611574/ * ceilometer: https://review.openstack.org/#/c/614400/ -- Thanks, Matt

1 0

[manila] no community meeting 27 December
by Tom Barron 21 Dec '18

21 Dec '18

As agreed at our last meeting, we will skip the regular manila community meeting on 27 December and resume our weekly cadence on 3 January 2019 at 1500 UTC on freenode #openstack-meeting-alt. All are welcome, and as usual please feel free to add to the agenda [1]. -- Tom Barron (irc: tbarron) [1] https://wiki.openstack.org/w/index.php?title=Manila/Meetings&action=edit&se…

1 0

openstack-dev] [neutron] Cancelling next Neutron drivers meeting
by Miguel Lavalle 21 Dec '18

21 Dec '18

Hi Neutrinos, Due to the Holidays season in many parts of the world, we will cancel the Neutron drivers meeting on December 28th. We will resume normally on January 4th. Best regards Miguel

1 0

[dev][keystone] Keystone Team Update - Week of 17 December 2018
by Lance Bragstad 21 Dec '18

21 Dec '18

# Keystone Team Update - Week of 17 December 2018 ## News This week was really quiet due to the holiday. Note that there won't be keystone meetings or office hours for the next two weeks since they fall on Christmas Day and New Years. If you have questions, please don't hesitate to use asynchronous communication like the mailing lists, especially since folks are likely on vacation and not lingering in IRC. ### Granular Instance Locks There is a thread about solving the problem on granular instance locks [0], which is kind of policy related. We're currently airing out all possible solutions. [0] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001223… ## Open Specs Reminder that we're about a month away from specification freeze, so specification reviews are important. I'd like to specifically call attention to the renewable app creds specification [1] since that is one the few left on our radar for this release. Stein specs: https://bit.ly/2Pi6dGj Ongoing specs: https://bit.ly/2OyDLTh [0] https://review.openstack.org/#/c/604201/ ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 4 changes this week. ## Changes that need Attention Search query: https://bit.ly/2RLApdA There are 117 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. It'll be good to start ramping up review focus since we'll start running up against deadlines shortly after the new year. Please have a look if you have time. ## Bugs This week we opened 5 new bugs and closed 1. Bugs opened (5) Bug #1808859 (keystone:High) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1808859 Bug #1809116 (keystone:Undecided) opened by Kristi Nikolla https://bugs.launchpad.net/keystone/+bug/1809116 Bug #1809237 (keystone:Undecided) opened by varocho https://bugs.launchpad.net/keystone/+bug/1809237 Bug #1808550 (keystoneauth:Undecided) opened by Ievgeniia Zadorozhna https://bugs.launchpad.net/keystoneauth/+bug/1808550 Bug #1809101 (keystonemiddleware:Undecided) opened by leehom https://bugs.launchpad.net/keystonemiddleware/+bug/1809101 Bugs closed (1) Bug #1809237 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1809237 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter Dashboard generated using gerrit-dash-creator and https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

1 0

[senlin] No meetings next two weeks
by Duc Truong 21 Dec '18

21 Dec '18

Everyone, Due to the holidays there will be no meetings on December 28th and January 3rd. We will resume the regular meetings on Friday January 11th at 530 UTC. Duc

1 0

[keystone] No meetings December 25th or January 1st
by Lance Bragstad 21 Dec '18

21 Dec '18

Hey all, We talked about this in last week's meeting, but I'm sending a reminder to the list. We won't be having a team meeting or holding office hours next week or the week after since they fall on Christmas Day and New Year's. We'll resume meetings and office hours on January 8th. Happy holidays, Lance

1 0

[openstack-dev] [neutron] Cancelling next two team meetings
by Miguel Lavalle 21 Dec '18

21 Dec '18

Hi Neutrinos, Due to the Holidays season in many parts of the world, we will cancel the weekly Neutron meeting on December 24th and January 1st. We will resume normally on January 7th Best regards Miguel

1 0

[openstack-dev] [neutron] [neutron-interconnection] neutron-interconnection core reviewers
by Miguel Lavalle 21 Dec '18

21 Dec '18

Hi Neutrinos, During the Dublin PTG we discussed and approved a neutron-interconnection proposal. Over the past few months the spec was merged ( https://specs.openstack.org/openstack/neutron-specs/specs/rocky/neutron-int…) and the corresponding repo was also approved and created: https://review.openstack.org/#/c/599428/ and https://review.openstack.org/#/c/599429/. Earlier today the core team of reviewers was created. This team includes the current Neutron core plus Thomas Morin and Yannick Thomas. So let's start pushing and reviewing code Best regards Miguel

2 1

Re: [glance][dev] Regarding "Eliminate Redundant Downloads of Uncached Images" project
by Vedartham Bharath 21 Dec '18

21 Dec '18

Hey Jim, Thank you for the reply! I was looking at this untargeted specs page for the project. http://specs.openstack.org/openstack/glance-specs/specs/untargeted/glance/d… It is stated in this page that this project is currently unassigned. I will start working on this spec. I will begin by studying Glance and start making smaller contributions to it for now. I need all the help I can get! I am very passionate about OpenStack and it's services! I will keep in touch with you and the developers through this mailing list and the IRC channel. Thank you Bharath On Fri, Dec 21, 2018, 7:20 PM Jim Rollenhagen <jim(a)jimrollenhagen.com wrote: > On Fri, Dec 21, 2018 at 2:50 AM Vedartham Bharath < > vedarthambharath(a)gmail.com> wrote: > >> Hi all, >> >> I am very interested in working on one of the untargeted approved >> specifications in Glance. It is titled "Eliminate Redundant Downloads >> of Uncached Images". >> I have noticed that it is currently unassigned. >> >> My experience with OpenStack: >> I have setup Devstack. >> I have worked extensively on Swift as part of a research project. >> I have set up Swift All in One multiple times. >> I have also set up a multi-server installation of Swift. >> I have studied the codebase of Swift and added my own features for my >> project. >> >> I don't have a lot of experience with Glance. >> I have experience with dealing with large codebases and I am willing to >> dedicate myself to study Glance and work on this project. >> I would love to know if it is up for grabs! >> > > Hi Bharath, > > The untargeted specs page for glance says "The following specs have been > reviewed and approved but have not been targeted for a release because the > proposer is no longer available to work on the implementation". I do see > the blueprint for the spec[0] is assigned, but I know Jesse no longer works > on OpenStack. I'd say go ahead and assign the blueprint to yourself and > start hacking! :) > > [0] https://blueprints.launchpad.net/glance/+spec/duplicate-downloads > > // jim >

2 1