February 2019 - openstack-discuss

Help with contributing to Storyboard for Outreachy 2019.
by Namrata Jha 28 Feb '19

28 Feb '19

I want to make contributions to the low hanging fruits in the Storyboard project, and want to make changes in the REST API documentation as is required in one of the stories, however, I have no idea how to go about it. I have even commented on the story in concern: https://storyboard.openstack.org/#!/story/298. Any help on this would be greatly appreciated. Moreover, the skills required mentioned on the Outreachy project listings page primarily includes SQL but there are no SQL related bugs to solve on the storyboard. I will contribute to improve the documentations wherever I can but how will that determine my selection as an Outreachy intern. P.S. I'm sorry @Kendall Nelson <kennelson11(a)gmail.com>, I had not intended to personally mail you this issue earlier, I replied to a previous thread and didn't realize that the mailing list wasn't included. Sorry for that. :)

2 1

[nova][keystone] project tags in context for scheduling
by Sam Morrison 27 Feb '19

27 Feb '19

Hi nova and keystone devs, We have a use case where we want to schedule a bunch of projects to specific compute nodes only. The aggregate_multitenancy_isolation isn’t viable because in some cases we will want thousands of projects to go to some hardware and it isn’t manageable/scaleable to do this in nova and aggregates. (Maybe it is and I’m being silly?) The best way I can think of doing this is to tag the keystone projects (or possibly set a custom property) and then write a custom nova scheduler filter to use the tag/property. The only issue I have is that tags/properties aren’t available to nova in it’s RequestContext. Can you think of a better way or a way that would work now? If this does in fact sound like a good way forward does authtoken middleware send this data downwards so nova could consume? If it does I assume it would be then as simple as adding these to the nova RequestContext? Thanks, Sam

3 3

[openstack-ansible] Compute nodes with mixed system releases
by Gilles Mocellin 27 Feb '19

27 Feb '19

Hello, I can ot find a real answer in the OpenStack-Ansible docs. Can I add Ubuntu 18.04 compute nodes to my actueal all Ubuntu 16.04 cluster ? Ubuntu 18.04 needs Rocky, so I will first migrate from Queens to Rocky. But then, do I need to stick to 16.04 and plan an overall upgrade after ? Of course, I understand that mixing Ubuntu release, will also mix kernel and qemu versions and can pose problems, for migrations for example.

2 2

Fw: [congress] Handling alarms that can be erroneous
by AKHIL Jain 27 Feb '19

27 Feb '19

Hi all, This discussion is about keeping, managing and executing actions based on old alarms. In Congress, when the policy is created the corresponding actions are executed based on data already existing in datasource tables and on the data that is received later in Congress datasource tables. So the alarms raised by projects like aodh, monasca are polled by congress and even the webhook notifications for alarm are received and stored in congress. In Congress, there are two scenarios of policy execution. One, execution based on data already existing before the policy is created and second, policy is created and action is executed at any time after the data is received Which can be harmful by keeping in mind that old alarms that are INVALID at present are still stored in Congress tables. So the user can trigger FALSE action based on that invalid alarm which can be very harmful to the environment. In order to tackle this, there can be multiple ways from the perspective of every OpenStack project handling alarms. One of the solutions can be: As action needs to be taken immediately after the alarm is raised, so storing only those alarms that have corresponding actions or policies(that will use the alarm) and after the policy is executed on them just discard those alarms or mark those alarm with some field like old, executed, etc. Or there are use cases that require old alarms? Also, we need to provide Operator the ability to delete the rows in congress datasource table. This will not completely help in solving this issue but still, it's better functionality to have IMO. Above solution or any discussed better solution can lead to change in mechanism i.e currently followed that involves policy execution on both new alarm and existing alarm to only new alarm. I have added the previous discussion below and discussion in Congress weekly IRC meeting can be found here http://eavesdrop.openstack.org/meetings/congressteammeeting/2019/congresste… Thanks and regards, Akhil ________________________________________ From: Eric K <ekcs.openstack(a)gmail.com> Sent: Tuesday, February 19, 2019 11:04 AM To: AKHIL Jain Subject: Re: Congress Demo and Output Thanks for the update! Yes of course if created_at field is needed by important use case then please feel free to add it! Sample policy in the commit message would be very helpful. Regarding old alarms, I need a couple clarifications: First, which categories of actions executions are we concerned about? 1. Actions executed automatically by congress policy. 2. Actions executed automatically by another service getting data from Congress. 3. Actions executed manually by operator based on data from Congress. Second, let's clarify exactly what we mean by "old". There are several categories I can think of: 1. Alarms which had been activated and then deactivated. 2. Alarms which had been activated and remains active, but it has been some time since it first became active. 3. Alarms which had been activated and triggered some action, but the alarm remains active because the action do not resolve the alarm. 4. Alarms which had been activated and triggered some action, and the action is in the process of resolving the alarm, but in the mean time the alarm remains active. (1) should generally not show up in Congress as active in push update case, but there are failure scenarios in which an update to deactivate can fail to reach Congress. (2) seems to be the thing option 1.1 would get rid of. But I am not clear what problems (2) causes. Why is a bad idea to execute actions based on an alarm that has been active for some time and remains active? An example would help me =) I can see (4) causing problems. But I'd like to work through an example to understand more concretely. In simple cases, Congress policy action execution behavior actually works well. If we have simple case like: execute[action(1)] :- alarm(1) Then action(1) is not going to be executed twice by congress because the behavior is that Congress executes only the NEWLY COMPUTED actions. If we have a more complex case like: execute[action(1)] :- alarm(1) execute[action(2)] :- alarm(1), alarm(2) If alarm (1) activates first, triggering action(1), then alarm (2) activates before alarm(1) deactivates, action(2) would be triggered because it is newly computed. Whether we WANT it executed may depend on the use case. And I'd also like to add option 1.3: Add a new table in (say monasca) called latest_alarm, which is the same as the current alarms table, except that it contains only the most recently received active alarm. That way, the policies which must avoid using older alarms can refer to the latest_alarm table. Whereas policies which would consider all currently active alarms can refer to the alarms table. Looking forward to more discussion! On 2/17/19, 10:44 PM, "AKHIL Jain" <akhil.jain(a)india.nec.com> wrote: >Hi Eric, > >There are some questions raised while working on FaultManagement usecase, >mainly below ones: >1. Keeping old alarms can be very harmful, the operator can execute >actions based on alarms that are not even existing or valid. >2. Adding a created_at field in Nova servers table can be useful. > >So for the first question, there can be multiple options: >1.1 Do not store those alarms that do not have any policy created in >Congress to execute on that alarm >1.2 Add field in alarm that can tell if the policy is executed using that >row or not. And giving the operator a command to delete them or >automatically delete them. > >For 2nd question please tell me that its good to go and I will add it. > >Regards >Akhil

2 2

[cinder] Forum and PTG Etherpads Available
by Jay Bryant 27 Feb '19

27 Feb '19

All, I just wanted to share the fact that we now have etherpads created to propose topics for the Denver Forum [1] and Denver PTG [2]. Please take a few minutes to add topics for the forum ASAP as those topics need to be proposed by 3/8. Remember that the Forum topics are supposed to be focused on things where we would like wider user/operator feedback while the PTG subjects should be more deeply technical discussion. Thanks! Jay (jungleboyj) [1] https://etherpad.openstack.org/p/cinder-denver-forum-brainstorming [2] https://etherpad.openstack.org/p/cinder-train-ptg-planning

1 0

[infra][qa] installing required projects from source in functional/devstack jobs
by Boden Russell 27 Feb '19

27 Feb '19

Question: What's the proper way to install "siblings" [1] in devstack based zuul v3 jobs for projects that also require the siblings via requirements.txt? Background: Following the zuul v3 migration guide for "sibling requirements" [1] works fine for non-devstack based jobs. However, jobs that use devstack must take other measures to install those siblings in their playbooks. Based on what I see projects like oslo.messaging doing for cross testing, they are using the PROJECTS env var to specify the siblings in their playbook (example [2]). This approach may work if those siblings are not in requirements.txt, but for projects that also require the siblings at runtime (in requirements.txt) it appears the version from the requirements.txt is used rather than the sibling's source. For example the changes in [3][4]. Thanks [1] https://docs.openstack.org/infra/manual/zuulv3.html#installation-of-sibling… [2] https://github.com/openstack/oslo.messaging/blob/master/playbooks/oslo.mess… [3] https://review.openstack.org/#/c/638099 [4] http://logs.openstack.org/99/638099/6/check/tricircle-functional/0b34687/lo…

3 5

Re: [openstack-dev] [python3] Enabling py37 unit tests
by Moises Guimaraes de Medeiros 27 Feb '19

27 Feb '19

So, at this point, is it OK to have projects running against both py35 and py37 and considering py36 covered as being included in the interval? Also about the lowest supported version, I think that is the one that should be stated in the envlist of tox.ini to fail fast during development. Em ter, 13 de nov de 2018 às 19:32, Corey Bryant <corey.bryant(a)canonical.com> escreveu: > > > On Wed, Nov 7, 2018 at 11:12 AM Clark Boylan <cboylan(a)sapwetik.org> wrote: > >> On Wed, Nov 7, 2018, at 4:47 AM, Mohammed Naser wrote: >> > On Wed, Nov 7, 2018 at 1:37 PM Doug Hellmann <doug(a)doughellmann.com> >> wrote: >> > > >> > > Corey Bryant <corey.bryant(a)canonical.com> writes: >> > > >> > > > On Wed, Oct 10, 2018 at 8:45 AM Corey Bryant < >> corey.bryant(a)canonical.com> >> > > > wrote: >> > > > >> > > > I'd like to start moving forward with enabling py37 unit tests for >> a subset >> > > > of projects. Rather than putting too much load on infra by enabling >> 3 x py3 >> > > > unit tests for every project, this would just focus on enablement >> of py37 >> > > > unit tests for a subset of projects in the Stein cycle. And just to >> be >> > > > clear, I would not be disabling any unit tests (such as py35). I'd >> just be >> > > > enabling py37 unit tests. >> > > > >> > > > As some background, this ML thread originally led to updating the >> > > > python3-first governance goal ( >> https://review.openstack.org/#/c/610708/) >> > > > but has now led back to this ML thread for a +1 rather than >> updating the >> > > > governance goal. >> > > > >> > > > I'd like to get an official +1 here on the ML from parties such as >> the TC >> > > > and infra in particular but anyone else's input would be welcomed >> too. >> > > > Obviously individual projects would have the right to reject >> proposed >> > > > changes that enable py37 unit tests. Hopefully they wouldn't, of >> course, >> > > > but they could individually vote that way. >> > > > >> > > > Thanks, >> > > > Corey >> > > >> > > This seems like a good way to start. It lets us make incremental >> > > progress while we take the time to think about the python version >> > > management question more broadly. We can come back to the other >> projects >> > > to add 3.7 jobs and remove 3.5 jobs when we have that plan worked out. >> > >> > What's the impact on the number of consumption in upstream CI node >> usage? >> > >> >> For period from 2018-10-25 15:16:32,079 to 2018-11-07 15:59:04,994, >> openstack-tox-py35 jobs in aggregate represent 0.73% of our total capacity >> usage. >> >> I don't expect py37 to significantly deviate from that. Again the major >> resource consumption is dominated by a small number of projects/repos/jobs. >> Generally testing outside of that bubble doesn't represent a significant >> resource cost. >> >> I see no problem with adding python 3.7 unit testing from an >> infrastructure perspective. >> >> Clark >> >> >> > Thanks all for the input on this. It seems like we have no objections to > moving forward so I'll plan on getting started soon. > > Thanks, > Corey > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >

6 9

[neutron] auto shedule explained?
by Fabian Zimmermann 27 Feb '19

27 Feb '19

Hi, im trying to understand the use-cases of # Allow auto scheduling networks to DHCP agent. (boolean value) network_auto_schedule = false # Allow auto scheduling of routers to L3 agent. (boolean value) router_auto_schedule = false if I read the code correctly, both options should only be used if there is (during runtime) an network without any l3 or dhcp agents, so neutron would trigger an automatic reschedule to new agents, isnt it? I disabled both options and created a new network, which automatically got l3 and dhcp agents assigned, so it seems like my assumption is correct? Thanks a lot, Fabian Zimmermann

1 0

[scientific-sig] IRC meeting 1100 UTC: Edge computing and Scientific use cases
by Stig Telfer 27 Feb '19

27 Feb '19

Hi All - We have an IRC meeting at 1100 UTC (about an hour’s time) in channel #openstack-meeting. Everyone is welcome. Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_February_27th_20… Today’s main event is that we have Ildikó Vancsa joining us to talk about edge computing use cases and find overlap with Scientific SIG use cases. Cheers, Stig

4 3

[neutron][ironic] Remove deprecated option 'external_network_bridge' from neutron config
by Slawomir Kaplonski 27 Feb '19

27 Feb '19

Hi Ironic devs, Some time ago I started removing of very old and deprecated since long time option ‚external_network_bridge’ from Neutron. Main patch for that is in [1]. All needed work to remove that is almost done. It was blocked by Tony Breeds because Ironic is still using this option. So I would like to ask You if You have any plans to remove usage of this option that we will be able to remove it completely? Thx in advance for any info about that :) [1] https://review.openstack.org/#/c/567369/ — Slawek Kaplonski Senior software engineer Red Hat

2 2