February 2019 - openstack-discuss

[nova][queens] qeumu-guest-agent
by Ignazio Cassano 07 Feb '19

07 Feb '19

Hello, is it possible to force metadata for instances like the following ? hw_qemu_guest_agent='yes' os_require_quiesce='yes' I know if an instance is created from an image with the above metadata the quemu-guest-agent works, but sometimes instances can start from volumes ( for example after a cnder backup). Regards Ignazio

2 5

[TC][Searchlight] Project health evaluation
by Trinh Nguyen 07 Feb '19

07 Feb '19

Hi TC members and Searchlight team, As we discussed at the beginning of the Stein cycle, Searchlight would go through a propagation period to consider whether to let it continue to operate under the OpenStack foundation's umbrella [1]. For the last two milestones, we have achieved some results [2] [3] and designed a sustainable future for Searchlight with a vision [4]. As we're reaching the Stein-3 milestone [5] and preparing for the Denver summit. We, as a team, would like have a formal project health evaluation in several aspects such as active contributors / team, planning, bug fixes, features, etc. We would love to have some voice from the TC team and anyone from the community who follows our effort during the Stein cycle. We then would want to update the information at [6] and [7] to avoid any confusion that may stop potential contributors or users to come to Searchlight. [1] https://review.openstack.org/#/c/588644/ [2] https://www.dangtrinh.com/2018/10/searchlight-at-stein-1-weekly-report.html [3] https://www.dangtrinh.com/2019/01/searchlight-at-stein-2-r-14-r-13.html [4] https://docs.openstack.org/searchlight/latest/user/usecases.html#our-vision [5] https://releases.openstack.org/stein/schedule.html [6] https://governance.openstack.org/election/results/stein/ptl.html [7] https://wiki.openstack.org/wiki/OpenStack_health_tracker Many thanks, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

2 2

Rocky and older Ceph compatibility
by Linus Nilsson 07 Feb '19

07 Feb '19

Hi all, I'm working on upgrading our cloud, which consists of a block storage system running Ceph 11.2.1 ("Kraken") and a controlplane running OSA Newton. We want to migrate to Ceph Mimic and OSA Rocky respectively. As part of the upgrade plan we are discussing first going to Rocky while keeping the block system at the "Kraken" release. It would be helpful to know if anyone has attempted to run the Rocky Cinder/Glance drivers with Ceph Kraken or older? References or documentation is welcomed. I fail to find much information online, but perhaps I'm looking in the wrong places or I'm asking a question with an obvious answer. Thanks! Best regards, Linus UPPMAX När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/ E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/en/about-uu/data-protection-policy

3 3

[openstack-ansible][magnum]
by Alfredo De Luca 07 Feb '19

07 Feb '19

Hi all. I finally instaledl successufully openstack ansible (queens) but, after creating a cluster template I create k8s cluster, it stuck on kube_masters <https://10.1.8.113/project/stacks/stack/6221608c-e7f1-4d76-b694-cdd7ec22c38…> b7204f0c-b9d8-4ef2-8f0b-afe4c077d039 <https://10.1.8.113/project/stacks/stack/b7204f0c-b9d8-4ef2-8f0b-afe4c077d03…> OS::Heat::ResourceGroup 16 minutes Create In Progress state changedcreate in progress....and after around an hour it says...time out. k8s master seems to be up.....at least as VM. any idea? *Alfredo*

5 43

[neutron] [upgrade] No meeting on Feb. 7th
by Lujin Luo 07 Feb '19

07 Feb '19

Hi team, I will not be able to chair the meeting tomorrow. Let's skip it and resume next week! Sorry for any inconvenience caused. Best regards, Lujin

1 0

[nova[metadata] queens issues
by Ignazio Cassano 07 Feb '19

07 Feb '19

Hello All, I am facing an issue with nova metadata or probably something is missed by design. If I create an instance from an image with os_require_quiesce='yes' and hw_qemu_guest_agent='yes' and the image contain the package quemu-guest-agent, when the instance boots the service quemu.gust-agent starts fine because all needed device are created in kvm for the instance. If I destory the instance and boot another instance from the volume used by the previous instance, metadata are missed and qemu-guest agent does not start, I think this is a problem from backupping and restoring instances. Regards Ignazio

1 0

Manila Upstream Bugs
by Jason Grosso 07 Feb '19

07 Feb '19

Hello All, This is an email to the OpenStack manila upstream community but anyone can chime in would be great to get some input from other projects and how they organize their upstream defects and what tools they use... My goal here is to make the upstream manila bug process easier, cleaner, and more effective. My thoughts to accomplish this are by establishing a process that we can all agree upon. I have the following points/questions that I wanted to address to help create a more effective process: - Can we as a group go through some of the manila bugs so we can drive the visible bug count down? - How often as a group do you have bug scrubs? - Might be beneficial if we had bug scrubs every few months possibly? - It might be a good idea to go through the current upstream bugs and weed out one that can be closed or invalid. - When a new bug is logged how to we normally process this bug - How do we handle the importance? - When a manila bugs comes into launchpad I am assuming one of the people on this email will set the importance? - "Assigned" I will also assume it just picked by the person on this email list. - I am seeing some bugs "fixed committed" with no assignment. How do we know who was working on it? - What is the criteria for setting the importance. Do we have a standard understanding of what is CRITICAL or HIGH? - If there is a critical or high bug what is the response turn-around? Days or weeks? - I see some defect with HIGH that have not been assigned or looked at in a year? - I understand OpenStack has some long releases but how long do we normally keep defects around? - Do we have a way to archive bugs that are not looked at? I was told we can possibly set the status of a defect to “Invalid” or “Opinion” or “Won’t Fix” or “Expired" - Status needs to be something other than "NEW" after the first week - How can we have a defect over a year that is NEW? - Who is possible for see if there is enough information and if the bug is invalid or incomplete and if incomplete ask for relevant information. Do we randomly look at the list daily , weekly, or monthly to see if new info is needed? I started to create a google sheet [1] to see if it is easier to track some of the defect vs the manila-triage pad[2] . I have added both links here. I know a lot will not have access to this page I am working on transitioning to OpenStack ether cal. [1] https://docs.google.com/spreadsheets/d/1oaXEgo_BEkY2KleISN3M58waqw9U5W7xTR_… [2] https://etherpad.openstack.org/p/manila-bug-triage-pad *[3]* https://ethercalc.openstack.org/uc8b4567fpf4 I would also like to hear from all of you on what your issues are with the current process for upstream manila bugs using launchpad. I have not had the time to look at storyboard https://storyboard.openstack.org/ but I have heard that the OpenStack community is pushing toward using Storyboard, so I will be looking at that shortly. Any input would be greatly appreciated... Thanks All, Jason Grosso Senior Quality Engineer - Cloud Red Hat OpenStack Manila jgrosso(a)redhat.com

3 2

[ironic] cisco-ucs-managed and cisco-ucs-standalone drivers - Python3 and CI
by Julia Kreger 07 Feb '19

07 Feb '19

Greetings fellow OpenStack humans, AIs, and unknown entities! At present, ironic has two hardware types, or drivers, that are presently in the code base to support Cisco UCS hardware. These are "cisco-ucs-managed" and "cisco-ucs-standalone". At present they utilize an underlying library which is not python3 compatible and has been deprecated by the vendor. In their current state the drivers will need to be removed from ironic when python2 support is removed. While work was started[1][2] to convert these drivers, the patch author seems to have stopped working on updating these drivers. Repeated attempts to contact prior ironic contributors from Cisco and the aforementioned patch author have gone unanswered. To further complicate matters, it appears the last time Cisco CI <ml2.ci(a)cisco.com> [3] last voted was on January 30th [4] of this year and the the log server [5] appears to be unreachable. Ironic's requirement is that a vendor driver has to have third-party CI to remain in-tree. At present it appears ironic will have no choice but to deprecate the "cisco-ucs-managed" and "cisco-ucs-standalone" hardware types and remove them in the Train cycle. If nobody steps forward to maintain the drivers and CI does not return, the drivers will be marked deprecated during the Stein cycle, and ironic shall proceed to remove them during Train. Please let me know if there are any questions or concerns. Thanks, -Julia [1]: https://review.openstack.org/#/c/607732 [2]: https://review.openstack.org/#/c/598194 [3]: https://review.openstack.org/#/q/reviewedby:%22Cisco+CI+%253Cml2.ci%2540cis… [4]: https://review.openstack.org/#/c/620376/ [5]: http://3ci-logs.ciscolabs.net/76/620376/4/check/dsvm-tempest-ironic-cimc-jo…

1 0

[openstack-helm] How to specify nova override for multiple pci alias
by Gauld, James 06 Feb '19

06 Feb '19

How can I specify a helm override to configure nova PCI alias when there are multiple aliases? I haven't been able to come up with a YAML compliant specification for this. Are there other alternatives to be able to specify this as an override? I assume that a nova Chart change would be required to support this custom one-alias-entry-per-line formatting. Any insights on how to achieve this in helm are welcomed. Background: There is a limitation in the nova.conf specification of PCI alias in that it does not allow multiple PCI aliases as a list. The code says "Supports multiple aliases by repeating the option (not by specifying a list value)". Basically nova currently only supports one-alias-entry-per-line format. Ideally I would specify global pci alias in a format similar to what can be achieved with PCI passthrough_whitelist, which can takes JSON list of dictionaries. This is what I am trying to specify in nova.conf (i.e., for nova-api-osapi and nova-compute): [pci] alias = {dict 1} alias = {dict 2} . . . The following nova configuration format is desired, but not as yet supported by nova: [pci] alias = [{dict 1}, {dict 2}] The following snippet of YAML works for PCI passthrough_whitelist, where the value encoded is a JSON string: conf: nova: overrides: nova_compute: hosts: - conf: nova: pci: passthrough_whitelist: '[{"class_id": "030000", "address": "0000:00:02.0"}]' Jim Gauld

3 5

[all] Denver Open Infrastructure Summit Community Contributor Awards!
by Kendall Nelson 06 Feb '19

06 Feb '19

Hello Everyone! As we approach the Summit (still a ways away thankfully), its time to kick off the Community Contributor Award nominations[1]! For those of you that have never heard of the CCA, I'll briefly explain what they are :) We all know people in our communities that do the dirty jobs, we all know people that will bend over backwards trying to help someone new, we all know someone that is a savant in some area of the code we could never hope to understand. These people rarely get the thanks they deserve and the Community Contributor Awards are a chance to make sure they know that they are appreciated for the amazing work they do and skills they have. As always, participation is voluntary :) Nominations will close on April 14th at 7:00 UTC and recipients will be announced at the Open Infrastructure Summit in Denver[2]. Recipients will be selected by a panel of top-level OSF project representatives who wish to participate. Finally, congrats again to recipients in Berlin[3]! -Kendall Nelson (diablo_rojo) [1] https://openstackfoundation.formstack.com/forms/train_cca_nominations [2]https://www.openstack.org/summit/denver-2019/ <https://www.openstack.org/summit/berlin-2018/> [3] http://superuser.openstack.org/articles/openstack-community-contributor-awa…

1 0

[magnum][kayobe][kolla-ansible] heat-container-agent reports that `publicURL endpoint for orchestration service in null region not found` and `Source [heat] Unavailable.`
by Bharat Kunwar 06 Feb '19

06 Feb '19

I have a Magnum deployment using stable/queens which appears to be successful in every way when you look at `/var/log/cloud-init.log` and `/var/log/cloud-init-output.log`. They look something like this: http://paste.openstack.org/show/744620/ http://paste.openstack.org/show/744621/ However, `heat-container-agent` log reports this on repeat: Feb 06 17:56:38 tesom31-q7fhuprr64fp-master-0.novalocal runc[2040]: Source [heat] Unavailable. Feb 06 17:56:38 tesom31-q7fhuprr64fp-master-0.novalocal runc[2040]: /var/lib/os-collect-config/local-data not found. Skipping Feb 06 17:56:54 tesom31-q7fhuprr64fp-master-0.novalocal runc[2040]: publicURL endpoint for orchestration service in null region not found These are the parts of the heat stack that stay in CREATE_IN_PROGRESS for a long time before eventually failing: http://paste.openstack.org/show/744638/ As a result, the workers never get created. Here is what my magnum.conf looks like: http://paste.openstack.org/show/744625 <http://paste.openstack.org/show/744625>. And this is what the heat params looks like: http://paste.openstack.org/show/744639/ <http://paste.openstack.org/show/744639/> I have tried setting `send_cluster_metrics=False` and also tried adding `region_name` to [keystone*] inside `magnum.conf`. What else should I try? Best Bharat

1 0

[Cinder][driver][ScaleIO]
by Martin Chlumsky 06 Feb '19

06 Feb '19

Hello, We are using EMC ScaleIO as our backend to cinder. When we delete VMs that have attached volumes and then try deleting said volumes, the volumes will sometimes end in state error_deleting. The state is reached because for some reason the volumes are still mapped (in the ScaleIO sense of the word) to the hypervisor despite the VM being deleted. We fixed the issue by setting the following option to True in cinder.conf: # Unmap volume before deletion. (boolean value) sio_unmap_volume_before_deletion=False What is the reasoning behind this option? Why would we ever set this to False and why is it False by default? It seems you would always want to unmap the volume from the hypervisor before deleting it. Thank you, Martin

4 6

[ironic] [oslo] ironic overloading notifications for internal messaging
by Michael Still 06 Feb '19

06 Feb '19

Hi, I’ve been chasing a bug in ironic’s neutron agent for the last few days and I think its time to ask for some advice. Specifically, I was asked to debug why a set of controllers was using so much RAM, and the answer was that rabbitmq had a queue called ironic-neutron-agent-heartbeat.info with 800,000 messages enqueued. This notification queue is used by ironic’s neutron agent to calculate the hash ring. I have been able to duplicate this issue in a stock kolla-ansible install with ironic turned on but no bare metal nodes enrolled in ironic. About 0.6 messages are queued per second. I added some debugging code (hence the thread yesterday about mangling the code kolla deploys), and I can see that the messages in the queue are being read by the ironic neutron agent and acked correctly. However, they are not removed from the queue. You can see your queue size while using kolla with this command: docker exec rabbitmq rabbitmqctl list_queues messages name messages_ready consumers | sort -n | tail -1 My stock install that’s been running for about 12 hours currently has 8,244 messages in that queue. Where I’m a bit stumped is I had assumed that the messages weren’t being acked correctly, which is not the case. Is there something obvious about notification queues like them being persistent that I’ve missed in my general ignorance of the underlying implementation of notifications? Thanks, Michael

4 8

[nova] [placement] [packaging] placement extraction check in meeting
by Chris Dent 06 Feb '19

06 Feb '19

As discussed in the recent pupdate [1] there will be a meeting this Wednesday at 1700 UTC to discuss the current state of the placement extraction and get some idea on the critical items that need to be addressed to feel comfy. If you're interested in this topic, meet near that time in the #openstack-placement IRC channel and someone will produce links for a hangout, etherpad, whatever is required. Thanks. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001666.… -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

6 13

[openstack-dev] [stackalytics] Stackalytics Facelift
by Boris Renski 06 Feb '19

06 Feb '19

Folks, Happy New Year! We wanted to start the year by giving a facelift to stackalytics.com (based on stackalytics openstack project). Brief summary of updates: - We have new look and feel at stackalytics.com - We did away with DriverLog <http://stackalytics.com/report/driverlog> and Member Directory <http://stackalytics.com/report/members>, which were not very actively used or maintained. Those are still available via direct links, but not in the men on the top - BIGGEST CHANGE: You can now track some of the CNCF and Unaffiliated project commits via a separate subsection accessible at the top nav. Before this was all bunched up in Project Type -> Complimentary Happy to hear comments or feedback or answer questions. -Boris

6 10

virt-install error while trying to create a new image
by Manuel Sopena Ballesteros 06 Feb '19

06 Feb '19

Dear Openstack community, I am trying to create a new image for Ironic. I followed the documentation but got an error with virt-install. Please note: The OS has been reinstalled The host is a physical machine BIOS has virtualization enabled I changed /etc/libvirt/qemu.conf group from root to kvm following some linux forum instructions about this error but the issue persists # virt-install --virt-type kvm --name centos --ram 1024 --disk /tmp/centos.qcow2,format=qcow2 --network network=default --graphics vnc,listen=0.0.0.0 --noautoconsole --os-type=linux --os-variant=centos7.0 --location=/root/CentOS-7-x86_64-NetInstall-1810.iso Starting install... Retrieving file .treeinfo... | 0 B 00:00:00 Retrieving file content... | 0 B 00:00:00 Retrieving file vmlinuz... | 6.3 MB 00:00:00 Retrieving file initrd.img... | 50 MB 00:00:00 ERROR unsupported configuration: CPU mode 'custom' for x86_64 kvm domain on x86_64 host is not supported by hypervisor Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect qemu:///system start centos otherwise, please restart your installation. Any thoughts? Thank you very much Manuel Sopena Ballesteros | Big data Engineer Garvan Institute of Medical Research The Kinghorn Cancer Centre, 370 Victoria Street, Darlinghurst, NSW 2010 T: + 61 (0)2 9355 5760 | F: +61 (0)2 9295 8507 | E: manuel.sb(a)garvan.org.au<mailto:manuel.sb@garvan.org.au> NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

2 1

[tc][all] Project deletion community goal for Train cycle
by Adrian Turjak 06 Feb '19

06 Feb '19

Hello OpenStackers! As discussed at the Berlin Summit, one of the proposed community goals was project deletion and resource clean-up. Essentially the problem here is that for almost any company that is running OpenStack we run into the issue of how to delete a project and all the resources associated with that project. What we need is an OpenStack wide solution that every project supports which allows operators of OpenStack to delete everything related to a given project. Before we can choose this as a goal, we need to define what the actual proposed solution is, and what each service is either implementing or contributing to. I've started an Etherpad here: https://etherpad.openstack.org/p/community-goal-project-deletion Please add to it if I've missed anything about the problem description, or to flesh out the proposed solutions, but try to mostly keep any discussion here on the mailing list, so that the Etherpad can hopefully be more of a summary of where the discussions have led. This is mostly a starting point, and I expect there to be a lot of opinions and probably some push back from doing anything too big. That said, this is a major issue in OpenStack, and something we really do need because OpenStack is too big and too complicated for this not to exist in a smart cross-project manner. Let's solve this the best we can! Cheers, Adrian Turjak

7 15

[Neutron] - Bug Report for the week of Jan 29th- Feb4th.
by Swaminathan Vasudevan 06 Feb '19

06 Feb '19

Item Type: Note Date: Monday, 4 Feb 2019 Hi Neutrinos,Here is the summary of the neutron bugs that came in last week ( starting from Jan 29th - Feb 4th). https://docs.google.com/spreadsheets/d/1MwoHgK_Ve_6JGYaM8tZxWha2HDaMeAYtq4q… Thanks Swaminathan Vasudevan.

3 2

[heat]No meeting today
by Rico Lin 06 Feb '19

06 Feb '19

Hi all, since it's current Chinese New Year time for me, I will not be able to host the meeting today. Also, I believe Zane is not available for today's meeting too, so let's run our meeting next week. Here's something we need feedback on since heat-agents still broken, I still need feedback on [1] and [2]. Two features that we can use some reviews on [3], [4] and [5], so please help us if you can. [1] https://review.openstack.org/#/c/634383/ [2] https://review.openstack.org/#/c/634563/ [3] https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:… [4] https://storyboard.openstack.org/#!/story/2003579 [5] https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:… -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[neutron] OVS OpenFlow L3 DVR / dvr_bridge agent_mode
by Duarte Cardoso, Igor 05 Feb '19

05 Feb '19

Hi Neutron, I've been internally collaborating on the ``dvr_bridge`` L3 agent mode [1][2][3] work (David Shaughnessy, Xubo Zhang), which allows the L3 agent to make use of Open vSwitch / OpenFlow to implement ``distributed`` IPv4 Routers thus bypassing kernel namespaces and iptables and opening the door for higher performance by keeping packets in OVS for longer. I want to share a few questions in order to gather feedback from you. I understand parts of these questions may have been answered in the past before my involvement, but I believe it's still important to revisit and clarify them. This can impact how long it's going to take to complete the work and whether it can make it to stein-3. 1. Should OVS support also be added to the legacy router? And if so, would it make more sense to have a new variable (not ``agent_mode``) to specify what backend to use (OVS or kernel) instead of creating more combinations? 2. What is expected in terms of CI for this? Regarding testing, what should this first patch include apart from the unit tests? (since the l3_agent.ini needs to be configured differently). 3. What problems can be anticipated by having the same agent managing both kernel and OVS powered routers (depending on whether they were created as ``distributed``)? We are experimenting with different ways of decoupling RouterInfo (mainly as part of the L3 agent refactor patch) and haven't been able to find the right balance yet. On one end we have an agent that is still coupled with kernel-based RouterInfo, and on the other end we have an agent that either only accepts OVS-based RouterInfos or only kernel-based RouterInfos depending on the ``agent_mode``. We'd also appreciate reviews on the 2 patches [4][5]. The L3 refactor one should be able to pass Zuul after a recheck. [1] Spec: https://blueprints.launchpad.net/neutron/+spec/openflow-based-dvr [2] RFE: https://bugs.launchpad.net/neutron/+bug/1705536 [3] Gerrit topic: https://review.openstack.org/#/q/topic:dvr_bridge+(status:open+OR+status:me… [4] L3 agent refactor patch: https://review.openstack.org/#/c/528336/29 [5] dvr_bridge patch: https://review.openstack.org/#/c/472289/17 Thank you! Best regards, Igor D.C.

5 6

[I18n] Meeting on Demand
by Frank Kloeker 05 Feb '19

05 Feb '19

Hello Stackers, in the past we changed often the format of our team meeting to find out the right requirements and the highest comfort for all participants. We cover different time zones, tried Office Hours and joint the docs team meeting as well, so we have both meeting behind each other. At the end there are no participants and from I18n perspective also not so much topics to discuss outside the translation period. For that reason I want to change to a "Meeting on Demand" format. Feel free to add your topics on the wiki page [1] for the upcoming meeting slot (as usually Thursday [2]) or raise the topic on the mailing list with the proposal of a regular meeting. We will then arrange the next meeting. many thanks kind regards Frank [1] https://wiki.openstack.org/wiki/Meetings/I18nTeamMeeting [2] http://eavesdrop.openstack.org/#I18N_Team_Meeting

1 0

[openstack-dev] [Neutron] Propose Liu Yulong for Neutron core
by Miguel Lavalle 05 Feb '19

05 Feb '19

Hi Stackers, I want to nominate Liu Yulong (irc: liuyulong) as a member of the Neutron core team. Liu started contributing to Neutron back in Mitaka, fixing bugs in HA routers. Since then, he has specialized in L3 networking, developing a deep knowledge of DVR. More recently, he single handedly implemented QoS for floating IPs with this series of patches: https://review.openstack.org/#/q/topic:bp/floating-ip-rate-limit+(status:op…. He has also been very busy helping to improve the implementation of port forwardings and adding QoS to them. He also works for a large operator in China, which allows him to bring an important operational perspective from that part of the world to our project. The quality and number of his code reviews during the Stein cycle is on par with the leading members of the core team: https://www.stackalytics.com/?module=neutron-group. I will keep this nomination open for a week as customary. Best regards Miguel

7 7

User Committee Elections - call for candidates
by Matt Van Winkle 05 Feb '19

05 Feb '19

Hello all, It's that time again! The candidacy period for the upcoming UC election is open. Three seats are up for voting. If you are an AUC, and are interested in running for one of them, now is the time to announce it. Here are the important dates: February 04 - February 17, 05:59 UTC: Open candidacy for UC positions February 18 - February 24, 11:59 UTC: UC elections (voting) Special thanks to our election officials - Mohamed Elsakhawy and Jonathan Prolux! You can find al the info for the election here: https://governance.openstack.org/uc/reference/uc-election-feb2019.html Note: there are a couple of typos on the page that have an older date for the items above. That is being sorted in a patch today, but we wanted to go and get the notification out. The dates above and at the top of the linked page are correct. Thanks! VW -- Matt Van Winkle Senior Manager, Software Engineering | Salesforce Mobile: 210-445-4183

1 0

[publiccloud] New Contributor Joining
by Sindisiwe Chuma 05 Feb '19

05 Feb '19

Hi All, I am Sindi, a new member. I am interested in participating in the Pubic Cloud Operators Working Group. Are there current projects or initiatives running and documentation available to familiarize myself with the work done and currently being done? Could you please refer me to resources containing information. Kind Regards, Sindi +27 72 572 7757

2 1

[ops] ops meetups team meeting minutes 2019-1-29
by Chris Morgan 05 Feb '19

05 Feb '19

minutes from last week's meeting: Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:32 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:32 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… The next meeting is due in about 1h 15 minutes on #openstack-operators We are trying to finalise the evenbrite for the upcoming ops meetup in berlin March 6th,7th and we're collecting session topics here: https://etherpad.openstack.org/p/BER-ops-meetup Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0