- openstack-discuss - lists.openstack.org

[all][tc][uc] Uniting the TC and the UC
by Thierry Carrez 26 Feb '20

26 Feb '20

Hi all, When our current project governance was established in 2012, we defined two separate bodies. The Technical Committee represented developers / code contributors to the open source project(s), while the User Committee represented the operators running the resulting software, as well as users of the APIs. That setup served us well in those early days. The focus on the upstream side was strongly around *development* of code, we did not have that many users, and even less users directly involved in upstream development. A separate User Committee resulted in the formation of an engaged community of users, and ensured that our community in general (and our events in particular) took the needs of operators into account. Fast-forward to 2020: the upstream focus is more on maintenance. We now have a lot of users, and thanks to the efforts of the UC they are increasingly directly involved in the open source project development, with several operators leading upstream project teams directly. There is now limited UC-specific activity, and as such it is struggling to get volunteers to step up for it: nobody nominated themselves for the last round of election. Keeping two separate bodies to represent them maintains the illusion that devs and ops are different breeds, and sometimes discourages operators from running for the TC and more directly influence the shape of the software. If anything, we need more ops representation at the TC, and seeing people like mnaser being elected at (and chairing) the TC was a great experience. I discussed the situation with the current UC members, and we decided it's time to consider having a single "community" and a single body to represent it. That body would tackle the traditional TC tasks (open source project governance and stewardship) but also the UC tasks (user survey, ambassador program...). That body would be elected by contributors, in a large sense that includes the AUC definition. I feel like that would help remove the artificial barriers discouraging users to get more directly involved with software development and maintenance. There are multiple ways to achieve that, in increasing order of complexity and bylaws changes needed: 1- No bylaws change As bylaws changes take a lot of time and energy, the simplest approach would be to merge the TC and UC without changing the bylaws at all. The single body (called TC) would incorporate the AUC criteria by adding all AUC members as extra-ATC. It would tackle all aspects of our community. To respect the letter of the bylaws, the TC would formally designate 5 of its members to be the 'UC' and those would select a 'UC chair'. But all tasks would be handled together. 2- Minimal bylaws change Same, but all mentions of the UC would be removed from the bylaws (affecting sections 4.12, 4.14, and Appendix 10). This would require a simple vote by the Board of Directors, and would avoid some confusion and having to formally designate a subset of the TC to respect the letter of the bylaws. 3- Maximal bylaws change Create a new body ("steering committee" for example) replacing the TC and the UC. This would require changing sections 4.1, 4.12, 4.13, 4.14, 4.20, 7.1.b, 7.4, 9.1, 9.2.d, and Appendixes 4 and 10. Section 4.13, 7.1 and 7.4 being heavily protected in the bylaws, they require special votes by each class of Foundation members, probably a multi-year effort. A lot of documentation would also need to be changed in case the TC is renamed. I personally don't think the benefit of the change offsets the large cost of option (3). Given the current vacancy in the UC makeup I would recommend we pursue option 1 immediately (starting at the next TC election in April), and propose minimal bylaws change to the board in parallel (option 2). Thoughts ? -- Thierry Carrez

8 16

Retiring x/devstack-plugin-bdd
by Sean McGinnis 26 Feb '20

26 Feb '20

Hello all, This is to announce that I plan on going through the process to retire the x/devstack-plugin-bdd repo. https://opendev.org/x/devstack-plugin-bdd/ This project was to allow using the Cinder block device driver in Devstack. Support for the block device driver was removed from Cinder many releases ago and there is no expectation that this devstack plugin could be used in any meaningful way. Sean

4 6

[charms] Peter Matulis -> charms-core
by James Page 26 Feb '20

26 Feb '20

Hi Team I'd like to proposed Peter Matulis for membership of the charms-core team. Although he's not be focussed on developing the codebase since he started contributing to the OpenStack Charms he's made a number of significant contributions to our documentation as well as regularly providing feedback on updates to README's and the charm deployment guide. I think he would make a valuable addition to the charms-core review team! Cheers James

5 5

[all][crazy][ideas] Call for "ideas" inside the openstack/ideas repo
by Jean-Philippe Evrard 26 Feb '20

26 Feb '20

Hello everyone, I would like to inform you that the "ideas" repos is now created, and waiting for all your fresh (or non fresh) ideas to change OpenStack! You will be able to find rendered ideas in https://governance.openstack.org/ideas/ . Currently it's lacking a little bit of content... I would love to see this changed soon, to be honest :) Here is a reminder of what the ideas repo is: - It's a place where anyone can propose an idea for changing OpenStack as a whole; - It's a git repository, which allows the versioning (and authoring) of ideas; - It's a way to refer to mailing lists, to know full context, but without having to browse through the history of the multiple mailing lists to find what you are looking for; - It's a repo where everyone can propose ideas to, and there will be no judgement on the ideas for merging them (the only thing asked is that what's written in an idea reflects what has been said on the mailing lists). Thank you for your attention! Your TC chair, Jean-Philippe Evrard (evrardjp)

2 1

[largescale-sig] Meeting summary and next actions
by Thierry Carrez 26 Feb '20

26 Feb '20

Hi everyone, The Large Scale SIG held a meeting today. You can catch up with the summary and logs of the meeting at: http://eavesdrop.openstack.org/meetings/large_scale_sig/2020/large_scale_si… amorin reported on progress documenting better configuration defaults for large scale, as can be seen on the etherpad[1]. He will set up a wiki page under our SIG page[2] to continue solidifying that content, as well as proposing a patch to Nova doc to point to that page. [1] https://etherpad.openstack.org/p/large-scale-sig-documentation [2] https://wiki.openstack.org/wiki/Large_Scale_SIG The story we collected in the scaling stories etherpad[3] proves itself very valuable. We should encourage collecting small bits of information and anecdotes of scaling up, it does not have to be as thorough of a report as the one already collected. [3] https://etherpad.openstack.org/p/scaling-stories masahito reported on progress on the oslo.metrics spec[4]. He plans to post a new patchset of that spec very soon. [4] https://review.opendev.org/#/c/704733/ In other topics, oneswig suggested that we also tackle bare metal cluster scaling. This should be considered a part of the "scaling within one cluster" goal, just for specific types of clusters. It would be great to have a session around bare metal cluster scaling at the upcoming OpenDev event[5] (under the "Large scale usage of open infrastructure" track). belmiro and masahito volunteered to be part of the programming committee for that track. the idea would be to make sure it aligns with the goals of this SIG, and that we recruit new members there. For example, we could have a specific session on scaling-stories, where people can informally talk about scaling anecdotes, and then we'd take notes and follow up with them to submit something more detailed. [5] https://www.openstack.org/events/opendev-ptg-2020/ The next meeting will happen on March 11, at 9:00 UTC on #openstack-meeting. Cheers, -- Thierry Carrez (ttx)

1 0

[tripleo] missing centos-8 rpms for kolla builds
by Wesley Hayutin 26 Feb '20

26 Feb '20

Greetings, I know the ceph repo is in progress. TripleO / RDO is not releasing opendaylight Can the RDO team comment on the rest of the missing packages here please? Thank you!! https://review.opendev.org/#/c/699414/9/kolla/image/build.py NOTE(mgoddard): Mark images with missing dependencies as unbuildable for # CentOS 8. 'centos8': { "barbican-api", # Missing uwsgi-plugin-python3 "ceph-base", # Missing Ceph repo "cinder-base", # Missing Ceph repo "collectd", # Missing collectd-ping and # collectd-sensubility packages "elasticsearch", # Missing elasticsearch repo "etcd", # Missing etcd package "fluentd", # Missing td-agent repo "glance-base", # Missing Ceph repo "gnocchi-base", # Missing Ceph repo "hacluster-base", # Missing hacluster repo "ironic-conductor", # Missing shellinabox package "kibana", # Missing elasticsearch repo "manila-share", # Missing Ceph repo "mongodb", # Missing mongodb and mongodb-server packages "monasca-grafana", # Using python2 "nova-compute", # Missing Ceph repo "nova-libvirt", # Missing Ceph repo "nova-spicehtml5proxy", # Missing spicehtml5 package "opendaylight", # Missing opendaylight repo "ovsdpdk", # Not supported on CentOS "sensu-base", # Missing sensu package "tgtd", # Not supported on CentOS 8 }, 'centos8+source': { "barbican-base", # Missing uwsgi-plugin-python3 "bifrost-base", # Bifrost does not support CentOS 8 "cyborg-agent", # opae-sdk does not support CentOS 8 "freezer-base", # Missing package trickle "masakari-monitors", # Missing hacluster repo "zun-compute", # Missing Ceph repo

9 19

OpenStack with vCenter
by Kevin Puusild 26 Feb '20

26 Feb '20

Hello I'm currently trying to setup DevStack with vCenter (Not ESXi), i found a perfect documentation for this task: https://wiki.openstack.org/wiki/NovaVMware/DeveloperGuide But the problem here is that when i start *stack.sh *with localrc file shown in documentation the installing process fails. Is this documentation out-dated? Is there some up to date documentation? -- Best Regards. Kevin Puusild

2 1

[scientific-sig] IRC Meeting today - 1100 UTC
by Stig Telfer 26 Feb '20

26 Feb '20

Hi All - We have a Scientific SIG meeting on IRC at 1100 UTC in channel #openstack-meeting. Everyone is welcome. Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_February_26th_20… <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_February_26th_20…> Today we’d like to cover SIG participation in a number of upcoming events. The best SIG events are when we get together face-to-face. Cheers, Stig

1 0

[tc] February meeting Agenda
by Jean-Philippe Evrard 26 Feb '20

26 Feb '20

Hello everyone, Our next meeting is happening next week Thursday (the 5th), and the agenda is, as usual, on the wiki! Here is a primer of the agenda for this month: Follow up on past action items Report on tc/uc merge (ttx): See http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012806… Ensuring the analysis of the survey was updated (jungleboyj) Report on telemetry after Rico's convo with the PTL (ricolin) Report on stable branch policy work: mnaser to push an update to distill what happened on the ML in terms of stable branch policy (mnaser) Report on the community goals for U and V, py2 drop (gmann) Report on release naming (mugsie) Dropping side projects - draft guidelines are available for review https://review.opendev.org/#/c/707421/ See you there! Regards, Jean-Philippe Evrard (evrardjp)

1 0

[keystone][middleware] why can not middle-ware support redis?
by guoyongxhzhf＠163.com 25 Feb '20

25 Feb '20

In my environment, there is a redis. I want the keystone client in nova to cache token and use redis as a cache server. But after reading keystone middle-ware code, now keystone middle-ware just support swift and memcached server. Can I just modify keystone middleware code to use dogpile.cache.redis directly?

2 1

[tc] Presence at OpenDev Vancouver in June
by Jean-Philippe Evrard 25 Feb '20

25 Feb '20

Hello, I am filling the survey for the room booking during the OpenDev summit in Vancouver. Do you already know if you will attend, this way we have a first guesstimate of the attendance? Can you answer it here by Thursday, please? FYI: I thought of booking for min 1.5 days, maximum time 2 days, as last time we finished the marathon in two days. For the room format, I like the roundtable (was wondering to add extra seats next to the roundtable for people joining), however it's only around 10 persons per table, which won't be enough for us all if everyone attends. Regards, JP

12 12

Re: [all][tc][uc] Uniting the TC and the UC
by Jimmy McArthur 25 Feb '20

25 Feb '20

> > Thanks a lot, ttx for starting this thread. > > option 1 looks more feasible way but few question/feedback: > - How we will execute the "designate 5 members from TC and select UC chair"? > > If by volunteer call from TC? > I think this can lead to the current situation where very few members are interested to > serve as UC. I am afraid that we will get 5 volunteers and a chair. > > If by force? > I do not think this is or should be an option :). But if then how we make sure the TC > members are ok/good to handle the UC tasks on the non-technical side for example > ambassador program. We have dedicated Foundation Staff that offer support for the Ambassador Program as well as User Survey. I don't have concerns about this falling between the cracks during the transition and it's something we can work with the new UC seats under the TC on. Cheers, Jimmy > > - Will there be any change in TC elections, votes weightage and nomination? by this change > of a new subteam under TC? > > - I think along with the merging proposal, we should distribute the current tasks handled by UC > among TC, Ops group, foundation etc. For example, the ambassador program, local user group > interaction or any other managerial tasks should be excluded from TC scope. > If we would like to merge all then I think we should rename TC to Steering Committee or > something which is option 3. > > - What about merging UC into Ops team, they are more close to users/operators and active > in terms of the meetup and providing feedback etc. > > -gmann > > >> Begin forwarded message: >> >> *From: *Thierry Carrez <thierry(a)openstack.org >> <mailto:thierry@openstack.org>> >> *Subject: **Re: [all][tc][uc] Uniting the TC and the UC* >> *Date: *February 25, 2020 at 11:36:06 AM CST >> *To: *openstack-discuss(a)lists.openstack.org >> <mailto:openstack-discuss@lists.openstack.org> >> >> Tim Bell wrote: >>> Are there some stats on the active electorate sizes ? >>> I have the impression that the voting AUCs were a smaller number of >>> people than the contributors so a single election may result in less >>> total representation compared to today’s UC & TC. >> >> I don't have the exact numbers around, but yes, there are many more >> ATCs (voters in the current TC election) than AUCs (voters in the >> current UC election). >> >> So it's a valid concern that people with more of an operator >> background would have trouble getting elected if the electorate >> contains more people with more of a developer background. >> >> But I think it's a fallacy. There is plenty of overlap. Most engaged >> operators are already ATCs, and more and more contributors have >> operational experience. Data points show that when people with more >> operational background have nominated themselves for the TC in recent >> elections, they got elected. 10 of the 13 TC seats are currently >> occupied by people with some decent amount of operational experience. >> >> So yes, we clearly need to communicate that people with >> operational/usage experience are wanted in that new body. We need to >> communicate that there is a change, and a single body will now >> steward all aspects of the open source projects and not just the >> upstream aspects. But I'm not obsessing on the fact that a single >> election would somehow suppress operator voices... >> >> The problem recently has more been to find enough people willing to >> step up and spend extra time stewarding OpenStack, than to actually >> get elected. >> >> -- >> Thierry Carrez (ttx) >> >

1 1

[openstack-ansible] ptg room
by Mohammed Naser 25 Feb '20

25 Feb '20

Hi everyone, I'd like to ask who is planning to be at the OpenDev event in Vancouver to gauge the amount if interest around having a room for OpenStack-Ansible at the PTG. Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. https://vexxhost.com

2 1

[ansible-sig][openstack-ansible][tripleo] A new meeting time and place for Openstack Ansible modules discussions
by Sagi Shnaidman 25 Feb '20

25 Feb '20

Hi, all according to our poll about meeting time[1] the winner is: Tuesday 15.00 - 16.00 UTC (3.00 PM - 4.00 PM UTC) Please be aware that we meet in different IRC channel - #openstack-ansible-sig Thanks for voting and waiting for you tomorrow in #openstack-ansible-sig at 15.00 UTC [1] https://xoyondo.com/dp/ITMGRZSvaZaONcz -- Best regards Sagi Shnaidman

1 1

[openstack-helm][Horizon] After Using a customize image of horizon container get fail.
by prashant 25 Feb '20

25 Feb '20

Hi All, We have build the horizon image via kolla and trying to deploy using openstack-helm chart. while doing it could able to pull the image but after start the container it get crashed. below logs we are getting: ------------------------------ + exec apache2 -DFOREGROUND AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.21.237.188. Set the 'ServerName' directive globally to suppress this message no listening sockets available, shutting down AH00015: Unable to open logs ----------------------------------- is any change need to be done for customize image for related to port? Thanks, Prashant

1 0

[Multi-Arch-SIG] Presence at OpenDev Vancouver in June
by Rico Lin 25 Feb '20

25 Feb '20

Hi all, As the deadline for OpenDev Vancouver team survey is near (before this weekend). We need to decide if we would like to reserve a room or not. And since I'm not that positively sure I will get the budget to travel this time. We need to make sure if anyone is going so we can have people to be the moderator. Note that I will not occupy a room if no others are able to be there. *might* going is totally fine as long as we can have people there as moderator -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[automation-sig][self-healing-sig][auto-scaling-sig] Presence at OpenDev Vancouver in June
by Rico Lin 25 Feb '20

25 Feb '20

Hi all, As the deadline for OpenDev Vancouver team survey is near (before this weekend). We need to decide if we would like to reserve a room or not. And since I'm not that positively sure I will get the budget to travel this time. We need to make sure if anyone is going so we can have people to be the moderator. Note that I will not occupy a room if no others are able to be there. *might* going is totally fine as long as we can have people there as moderator -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[heat] Presence at OpenDev Vancouver in June
by Rico Lin 25 Feb '20

25 Feb '20

Hi all, As the deadline for OpenDev Vancouver team survey is near (before this weekend). We need to decide if we would like to reserved a room or not. And since I'm not that positively sure I will get the budget to travel this time. We need to make sure if anyone is going so we can have people to be the moderator. Note that I will not occupy a room if no others are able to be there. Or at least *might* be there. -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[Watcher]We will have IRC meeting at 8:00 UTC tomorrow
by licanwei 24 Feb '20

24 Feb '20

please update the meeting agenda if you have something want to discuss. Thanks | | licanwei_cn | | 邮箱：licanwei_cn(a)163.com | 签名由网易邮箱大师定制 On 02/13/2020 17:01, licanwei wrote: Hi, next time i will send the mail one day in advance. hope to meet you next time! Thanks licanwei | | licanwei_cn | | 邮箱：licanwei_cn(a)163.com | 签名由网易邮箱大师定制 On 02/12/2020 17:58, info(a)dantalion.nl wrote: Hello Lican, Sorry but I am unable to attend at such short notice as in my timezone I won't be awake unless it is for the Watcher meeting. To be able to adjust my transit schedule I will have to know a day in advance. Hope to be there next time. Kind regards, Corne Lukken On 2/12/20 3:31 AM, licanwei wrote: > > > > > licanwei_cn > 邮箱：licanwei_cn(a)163.com > 签名由网易邮箱大师定制 > > | | > licanwei_cn > | > | > 邮箱：licanwei_cn(a)163.com > | > > 签名由网易邮箱大师定制 >

1 0

[neutron] Team meeting 25.02.2020 cancellee
by Slawek Kaplonski 24 Feb '20

24 Feb '20

Hi, I’m on PTO tomorrow and I will not be able to chair our team meeting. So lets cancel it. See You all on the meeting next week. One reminder, if You are planning to attend Vancouver PTG in June, please add Your name to the list in [1]. I need to give number of rough number of attendees by Sunday, March 2nd. Please add Your name there even if it’s not yet confirmed. [1] https://etherpad.openstack.org/p/neutron-victoria-ptg — Slawek Kaplonski Senior software engineer Red Hat

1 0

Neutron metadata service not responding due to rabbitmq dropping messages
by Grant Morley 24 Feb '20

24 Feb '20

Hi all, We have recently come across an issue where our metadata service stops responding. If you try to curl the service from within an instance you get: % curl http://169.254.169.254 <html><body><h1>504 Gateway Time-out</h1> The server didn't respond in time. </body></html> After doing some digging around on our neutron nodes I noticed we were getting loads of RabbitMQ timeout errors whilst trying to process message requests: 2020-02-24 07:28:09.747 26378 ERROR neutron.common.rpc [-] Timeout in RPC method get_ports. Waiting for 26 seconds before next attempt. If the server is not down, consider increasing the rpc_response_timeout option as Neutron server(s) may be overloaded and unable to respond quickly enough.: MessagingTimeout: Timed out waiting for a reply to message ID a14c4a1395864cd980c1ec563a5c48aa The servers are fairly busy, however we do not have a massive installation >1500 instances and roughly 850 routers. However if I restart the "neutron-metadata-agent" service and the "neutron-server" service it seems to fix the issue for a while but ultimately it comes back. I did increase the "rpc_timeout" on the netutron nodes to 120 seconds but that seems quite long to me. Likewise the RabbitMQ servers are not overly busy, we seem to get a constant stream of only 40+ messages in the queue at one time and that can spike depending on workload. Does anyone know of any tuning or tweaking we can do to the metadata service in either Neutron or Nova that might help? We are running OpenStack Queens if that helps. Many thanks, Grant

1 0

RHOSP-like installation
by Volodymyr Litovka 24 Feb '20

24 Feb '20

Dear colleagues, while having a good experience with Openstack on Ubuntu, we're facing a plenty of questions re RHOSP installation. The primary requirement for our team re RHOSP is to get a knowledge on RHOSP - how to install it and maintain. As far as I understand, RDO is the closest way to reach this target but which kind of installation it's better to use? - * plain RDO installation as described in generic Openstack guide at https://docs.openstack.org/install-guide/index.html (specifics in RHEL/CentOS sections) * or TripleO installation as described in http://tripleo.org/install/ * or, may be, it is possible to use RHOSP in kind of trial mode to get enough knowledge on this platform? Our lab consists of four servers (64G RAM, 16 cores@2GHz) which we're going to use in "ultraconverged" mode - as both controller and agent (compute/network/storage) nodes (controllers, though, can be in virsh-controlled VMs). In case of TripleO scenario, 4th server can be used for undercloud role. This installation is intended not for production use, but rather for learning purposes, so no special requirements for productivity. The only special requirement - to be functionally as much as close to canonical RHOSP platform. I will highly appreciate your suggestions on this issue. Thank you. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

2 1

[oslo] Meeting Time Poll
by Ben Nemec 24 Feb '20

24 Feb '20

Hello again, We have a few regular attendees of the Oslo meeting who have conflicts with the current meeting time. As a result, we would like to find a new time to hold the meeting. I've created a Doodle poll[0] for everyone to give their input on times. It's mostly limited to times that reasonably overlap the working day in the US and Europe since that's where most of our attendees are located (yes, I know, that's a self-fulfilling prophecy). If you attend the Oslo meeting, please fill out the poll so we can hopefully find a time that works better for everyone. Thanks! -Ben /me finally checks this one off the action items for next week :-) 0: https://doodle.com/poll/zmyhrhewtes6x9ty

1 1

[ironic][neutron][ops] Ironic multi-tenant networking with VXLAN Overlay
by Austin Cormier 24 Feb '20

24 Feb '20

We are using Openstack + Ironic to test routing software which requires the use of VLANs. Using VXLan overlays allows the VM's to have nested VLANs without issue as they are encapsulated into a VXLAN and sent across. However, we are struggling to find a path forward in extending the VXLAN overlay out to the hardware device. Unfortunately, the networking-generic-switch driver does not support VXLAN but this seems to fairly easy to extend (given the right switch). The challenge I'm facing is that with Neutron OVS + L2Pop, there seems to be no easy way to extend the L2 population to include an external device. The only path forward that I can see is to use the Linux Bridge driver + VXLAN multicast and find a switch that also supports VXLAN multicast so it can participate in the overlay dynamically. The HPE FlexFabric seems to do this from the documentation: https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c04567545 Can anyone help confirm that the switch above will work and or give alternative suggestions on approaching this problem? -Austin

1 0

[openstack-helm][stein]Cinder pods stuck in init state after deployed in k8s cluster
by Sanjay K 24 Feb '20

24 Feb '20

Hello openstack-helm team, I am trying to deploy stein cinder service in my k8s cluster using persistent volume and persistent volume claim for local storage or NFS storage. However after deploying cinder in my cluster, the cinder pods remains in Init state even though the PV and PVC are created. Please look at my below post on openstack forum and guide me how to resolve this issue. https://ask.openstack.org/en/question/126191/cinder-pods-in-init-state-when… thank you for your help and support on this. best regards, Sanjay

2 3