- openstack-discuss - lists.openstack.org

RE: DR options with openstack
by Burak Hoban 17 Jan '20

17 Jan '20

Hey Tony, Keep in mind that if you're looking to run OpenStack, but you're not feeling comfortable with the community support then there's always the option to go with a vendor backed version. These are usually a good option for those a little more risk adverse, or who don't have the time/or skills to maintain upstream releases - however going down that path usually means you can do less with OpenStack (depending on the vendor), but you have a large pool of resources to help troubleshoot and answer questions. We do both approaches internally for different clusters, so both approaches have their pro and cons. You touched on a few points in your original email... > If you had two OpenStack clusters, one in "site 1" and another in "site 2", then you could look at below for backup/restore of instances cross-cluster: - Freezer -> https://wiki.openstack.org/wiki/Freezer - Trillio (basically just a series of nova snapshots under the cover) -> https://www.trilio.io/ You could then over the top roll out a file level based backup tool on each instance, this would pretty much offer you replication functionality without having to do block-level tinkering. > Failover of OpenStack controller/computes If you have two sites, you can always go for 3x Controller deployment spanning cross site. Depending on latency obviously, however all you really need is a good enough link for RabbitMQ/Galera to talk reliably etc. Failing that, I'd recommend backing up your Controller with ReaR. From there you can also schedule frequent automated jobs to do a OpenStack DB backups. Recovering should be a case of ReaR restore, load latest OpenStack DB and start everything up... You'll probably want to ensure your VLANs are spanned cross-site so you can reuse same IP addresses. https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/post_de… https://superuser.openstack.org/articles/tutorial-rear-openstack-deployment/ In reality, the best solution would be to have two isolated clusters, and your workloads spanned across both sites. Obviously that isn't always possible (from personal experience), but pushing people down the Kubernetes path and then for the rest automation/backup utilities may cater for your needs. Having said that, Albert's link does look promising -> https://docs.openstack.org/cinder/pike/contributor/replication.html Date: Thu, 16 Jan 2020 19:49:08 +0000 From: Albert Braden <Albert.Braden(a)synopsys.com> To: Tony Pearce <tony.pearce(a)cinglevue.com>, "openstack-discuss(a)lists.openstack.org" <openstack-discuss(a)lists.openstack.org> Subject: RE: DR options with openstack Message-ID: <BN8PR12MB3636451FC8E2BC6A50216425D9360(a)BN8PR12MB3636.namprd12.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hi Tony, It looks like Cheesecake didn’t survive but apparently some components of it did; details in https://docs.openstack.org/cinder/pike/contributor/replication.html I’m not using Cinder now; we used it at eBay with Ceph and Netapp backends. Netapp makes it easy but is expensive; Ceph is free but you have to figure out how to make it work. You’re right about forking; we did it and then upgrading turned from an incredibly difficult ordeal to an impossible one. It’s better to stay with the “official” code so that upgrading remains an option. I’m just an operator; hopefully someone more expert will reply with more useful info. It’s true that our community lacks participation. It’s very difficult for a new operator to start using openstack and get help with the issues that they encounter. So far this mailing list has been the best resource for me. IRC and Ask Openstack are mostly unattended. I try to help out in #openstack when I can, but I don’t know a lot so I mostly end up telling people to ask on the list. On IRC sometimes I find help by asking in other openstack-* channels. Sometimes people complain that I’m asking in a developer channel, but sometimes I get help. Persistence is the key. If I keep asking long enough in enough places, eventually someone will answer. If all else fails, I open a bug. Good luck and welcome to the Openstack community! From: Tony Pearce <tony.pearce(a)cinglevue.com> Sent: Wednesday, January 15, 2020 11:37 PM To: openstack-discuss(a)lists.openstack.org Subject: DR options with openstack Hi all My questions are; 1. How are people using iSCSI Cinder storage with Openstack to-date? For example a Nimble Storage array backend. I mean to say, are people using backend integration drivers for other hardware (like netapp)? Or are they using backend iscsi for example? 2. How are people managing DR with Openstack in terms of backend storage replication to another array in another location and continuing to use Openstack? The environment which I am currently using; 1 x Nimble Storage array (iSCSI) with nimble.py Cinder driver 1 x virtualised Controller node 2 x physical compute nodes This is Openstack Pike. In addition, I have a 2nd Nimble Storage array in another location. To explain the questions I’d like to put forward my thoughts for question 2 first: For point 2 above, I have been searching for a way to utilise replicated volumes on the 2nd array from Openstack with existing instances. For example, if site 1 goes down how would I bring up openstack in the 2nd location and boot up the instances where their volumes are stored on the 2nd array. I found a proposal for something called “cheesecake” ref: https://specs.openstack.org/openstack/cinder-specs/specs/rocky/cheesecake-p…<https://urldefense.proofpoint.com/v2/url?u=https-3A__specs.openstack.org_op…> But I could not find if it had been approved or implemented. So I return to square 1. I have some thoughts about failing over the controller VM and compute node but I don’t think there’s any need to go into here because of the above blocker and for brevity anyway. The nimble.py driver which I am using came with Openstack Pike and it appears Nimble / HPE are not maintaining it any longer. I saw a commit to remove nimble.py in Openstack Train release. The driver uses the REST API to perform actions on the array. Such as creating a volume, downloading the image, mounting the volume to the instance, snapshots, clones etc. This is great for me because to date I have around 10TB of openstack storage data allocated and the Nimble array shows the amount of data being consumed is <900GB. This is due to the compression and zero-byte snapshots and clones. So coming back to question 2 – is it possible? Can you drop me some keywords that I can search for such as an Openstack component like Cheesecake? I think basically what I am looking for is a supported way of telling Openstack that the instance volumes are now located at the new / second array. This means a new cinder backend. Example, new iqn, IP address, volume serial number. I think I could probably hack the cinder db but I really want to avoid that. So failing the above, it brings me to the question 1 I asked before. How are people using Cinder volumes? May be I am going about this the wrong way and need to take a few steps backwards to go forwards? I need storage to be able to deploy instances onto. Snapshots and clones are desired. At the moment these operations take less time than the horizon dashboard takes to load because of the waiting API responses. When searching for information about the above as an end-user / consumer I get a bit concerned. Is it right that Openstack usage is dropping? There’s no web forum to post questions. The chatroom on freenode is filled with ~300 ghosts. Ask Openstack questions go without response. Earlier this week (before I found this mail list) I had to use facebook to report that the Openstack.org website had been hacked. Basically it seems that if you’re a developer that can write code then you’re in but that’s it. I have never been a coder and so I am somewhat stuck. Thanks in advance Sent from Mail<https://urldefense.proofpoint.com/v2/url?u=https-3A__go.microsoft.com_fwlin…> for Windows 10 _____________________________________________________________________ The information transmitted in this message and its attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of the sender. This message has been scanned for viruses. _____________________________________________________________________

6 6

[keystone] Keystone Team Update - Week of 13 January 2020
by Vishakha Agarwal 17 Jan '20

17 Jan '20

# Keystone Team Update - Week of 13 January 2020 ## News ### Roadmap Review The Team has decided to review the roadmap every other week so as to keep up the development momentum of the ussuri cycle [1]. [1] https://tree.taiga.io/project/keystone-ussuri-roadmap/kanban ### User Support and Bug Duty Every week the duty is being rotated between the members. The person-in-charge for bug duty for current and upcoming week can be seen on the etherpad [2] [2] https://etherpad.openstack.org/p/keystone-l1-duty ## Open Specs Ussuri specs: https://bit.ly/2XDdpkU Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 7 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 36 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ### Priority Reviews * Community Goals https://review.opendev.org/#/c/699127/ [ussuri][goal] Drop python 2.7 support and testing keystone-tempest-plugin https://review.opendev.org/#/c/699119/ [ussuri][goal] Drop python 2.7 support and testing python-keystoneclient * Special Requests https://review.opendev.org/#/c/662734/ Change the default Identity endpoint to internal https://review.opendev.org/#/c/699013/ Always have username in CADF initiator https://review.opendev.org/#/c/700826/ Fix role_assignments role.id filter https://review.opendev.org/#/c/697444/ Adding options to user cli https://review.opendev.org/#/c/702374/ Cleanup doc/requirements.txt ## Bugs This week we opened 2 new bugs and closed 4. Bugs opened (2) Bug #1859759 (keystone:Undecided): Keystone is unable to remove role-assignment for deleted LDAP users - Opened by Eigil Obrestad https://bugs.launchpad.net/keystone/+bug/1859759 Bug #1859844 (keystone:Undecided): Impossible to rename the Default domain id to the string 'default.' - Opened by Marcelo Subtil Marcal https://bugs.launchpad.net/keystone/+bug/1859844 Bugs closed (4) Bug #1833207 (keystoneauth:Undecided) https://bugs.launchpad.net/keystoneauth/+bug/1833207 Bug #1858189 (keystoneauth:Undecided) https://bugs.launchpad.net/keystoneauth/+bug/1858189 Bug #1857086 (keystone:Won't Fix) https://bugs.launchpad.net/keystone/+bug/1857086 Bug #1859844 (keystone:Invalid) https://bugs.launchpad.net/keystone/+bug/1859844 ## Milestone Outlook https://releases.openstack.org/ussuri/schedule.html Reminder for Spec freeze as it is on the week of 10 Feburary. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

[all] cirros-cloud.net is down
by Radosław Piliszek 16 Jan '20

16 Jan '20

Hi, Folks! If your CI jobs depend on downloaded cirros image, then be aware that cirros links are seemingly permanently down atm. I reported [1] due to lack of a better place (that I know of). [1] https://github.com/cirros-dev/cirros/issues/12 -yoctozepto

2 2

[tc] January meeting agenda
by Jean-Philippe Evrard 16 Jan '20

16 Jan '20

Hello everyone, Our next meeting is happening next week Thursday (the 16th), and the agenda is, as usual, on the wiki! Here is a primer of the agenda for this month: - report on large scale sig -- how does this fly and how/what are the action items. - report on the vision reflection update - report on the analysis of the survey - report on the convo for Telemetry with Catalyst -- where are we now? What are the next steps (Gnocchi fork)? - report on multi-arch SIG - report on infra liaison and static hosting -- check if there is progress - report on stable branch policy work. - report on the oslo metrics project -- has code appeared since last convo? - report on the community goals for U and V, py2 drop, and goal select process schedule. - report on release naming - report on the ideas repo See you there! Regards, Jean-Philippe Evrard (evrardjp)

1 1

[ops] live-migration progress
by Martin Gehrke 16 Jan '20

16 Jan '20

Hi, Last week at the Openstack Operators meetup in London, someone mentioned that there was an issue with the progress updates during a live migration and that by turning it off you could increase your success rate. Does anyone know more TIA Martin Gehrke DevOps Manager & OpenStack Tech Lead Two Sigma Investments, LP New York, NY

1 0

[cinder] consistency group not working
by Francois Scheurer 16 Jan '20

16 Jan '20

Dear Cinder Experts We are running the rocky release. |We can create a consistency group: openstack consistency group create --volume-type b9f67298-cf68-4cb2-bed2-c806c5f83487 fsc-consgroup Bug 1: but adding volumes is not working: openstack consistency group add volume c3f49ef0-601e-4558-a75a-9b758304ce3b b48752e3-641f-4a49-a892-6cb54ab6b74d c0022411-59a4-4c7c-9474-c7ea8ccc7691 0f4c6493-dbe2-4f75-8e37-5541a267e3f2 => Invalid volume: Volume is not local to this node. (HTTP 400) (Request-ID: req-7f67934a-5835-40ef-b25c-12591fd79f85) Bug 2: deleting consistency group is also not working (silently failing): openstack consistency group delete c3f49ef0-601e-4558-a75a-9b758304ce3b |||=> AttributeError: 'RBDDriver' object has no attribute 'delete_consistencygroup'| See details below. Using the --force option makes no difference and the consistency group is not deleted. Do you think this is a bug or a configuration issue? Thank you in advance. | Cheers Francois |Details: ==> /var/lib/docker/volumes/kolla_logs/_data/cinder/cinder-api-access.log <== 10.0.129.17 - - [27/Sep/2019:12:16:24 +0200] "POST /v3/f099965b37ac41489e9cac8c9d208711/consistencygroups/3706bbab-e2df-4507-9168-08ef811e452c/delete HTTP/1.1" 202 - 109720 "-" "python-cinderclient" ==> /var/lib/docker/volumes/kolla_logs/_data/cinder/cinder-volume.log <== 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server [req-9010336e-d569-47ad-84e2-8dd8b729939c b141574ee71f49a0b53a05ae968576c5 f099965b37ac41489e9cac8c9d208711 - default default] Exception during message handling: AttributeError: 'RBDDriver' object has no attribute 'delete_consistencygroup' 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 163, in _process_incoming 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 265, in dispatch 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 194, in _do_dispatch 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/osprofiler/profiler.py", line 159, in wrapper 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server result = f(*args, **kwargs) 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/cinder/volume/manager.py", line 3397, in delete_group 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server vol_obj.save() 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server self.force_reraise() 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server six.reraise(self.type_, self.value, self.tb) 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/cinder/volume/manager.py", line 3362, in delete_group 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server self.driver.delete_consistencygroup(context, cg, 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server AttributeError: 'RBDDriver' object has no attribute 'delete_consistencygroup' 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server| -- EveryWare AG François Scheurer Senior Systems Engineer Zurlindenstrasse 52a CH-8003 Zürich tel: +41 44 466 60 00 fax: +41 44 466 60 10 mail: francois.scheurer(a)everyware.ch web: http://www.everyware.ch

2 2

[blazar] No IRC meeting today
by Pierre Riteau 16 Jan '20

16 Jan '20

Hello, Similarly to Tuesday, I have to cancel today's Blazar IRC meeting. Sorry for the late notice. Thanks, Pierre Riteau (priteau)

1 0

[tc][all] Updates on Ussuri cycle community-wide goals
by Ghanshyam Mann 16 Jan '20

16 Jan '20

Hello Everyone, We have two goals with their champions ready for review. Please review and provide your feedback on Gerrit. 1. Add goal for project specific PTL and contributor guides - Kendall Nelson - https://review.opendev.org/#/c/691737/ 2. Propose a new goal to migrate all legacy zuul jobs - Luigi Toscano - https://review.opendev.org/#/c/691278/ We are still looking for the Champion volunteer for RBAC goal[1]. If you have any new ideas for goal, do not hesitate to add in etherpad[2] [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010291.… [2] https://etherpad.openstack.org/p/PVG-u-series-goals -gmann & diablo_rojo

1 2

Re: [magnum]: K8s cluster creation times out. OpenStack Train : [ERROR]: Unable to render networking. Network config is likely broken
by Feilong Wang 16 Jan '20

16 Jan '20

Hi Donny, Do you mean Fedore CoreOS or just CoreOS? The current CoreOS driver is not actively maintained, I would suggest migrating to Fedora CoreOS and I'm happy to help if you have any question. Thanks. On 14/01/20 9:57 AM, Donny Davis wrote: > FWIW I was only able to get the coreos image working with magnum oob.. > the rest just didn't work. > > On Mon, Jan 13, 2020 at 2:31 PM feilong <feilong(a)catalyst.net.nz > <mailto:feilong@catalyst.net.nz>> wrote: > > Hi Bhupathi, > > Firstly, I would suggest setting the use_podman=False when using > fedora atomic image. And it would be nice to set the "kube_tag", > e.g. v1.15.6 explicitly. Then please trigger a new cluster > creation. Then if you still run into error. Here is the debug steps: > > 1. ssh into the master node, check log /var/log/cloud-init-output.log > > 2. If there is no error in above log file, then run journalctl -u > heat-container-agent to check the heat-container-agent log. If > above step is correct, then you must be able to see something > useful here. > > > On 11/01/20 12:15 AM, Bhupathi, Ramakrishna wrote: >> >> Wang, >> >> Here it is . I added the labels subsequently. My nova and >> neutron are working all right as I installed various systems >> there working with no issues.. >> >> >> >> >> >> *From:*Feilong Wang [mailto:feilong@catalyst.net.nz] >> *Sent:* Thursday, January 9, 2020 6:12 PM >> *To:* openstack-discuss(a)lists.openstack.org >> <mailto:openstack-discuss@lists.openstack.org> >> *Subject:* Re: [magnum]: K8s cluster creation times out. >> OpenStack Train : [ERROR]: Unable to render networking. Network >> config is likely broken >> >> >> >> Hi Bhupathi, >> >> Could you please share your cluster template? And please make >> sure your Nova/Neutron works. >> >> >> >> On 10/01/20 2:45 AM, Bhupathi, Ramakrishna wrote: >> >> Folks, >> >> I am building a Kubernetes Cluster( Openstack Train) and >> using fedora atomic-29 image . The nodes come up fine ( I >> have a simple 1 master and 1 node) , but the cluster creation >> times out, and when I access the cloud-init logs I see this >> error . Wondering what I am missing as this used to work >> before. I wonder if this is image related . >> >> >> >> [ERROR]: Unable to render networking. Network config is >> likely broken: No available network renderers found. Searched >> through list: ['eni', 'sysconfig', 'netplan'] >> >> >> >> Essentially the stack creation fails in “kube_cluster_deploy” >> >> >> >> Can somebody help me debug this ? Any help is appreciated. >> >> >> >> --RamaK >> >> The contents of this e-mail message and >> any attachments are intended solely for the >> addressee(s) and may contain confidential >> and/or legally privileged information. If you >> are not the intended recipient of this message >> or if this message has been addressed to you >> in error, please immediately alert the sender >> by reply e-mail and then delete this message >> and any attachments. If you are not the >> intended recipient, you are notified that >> any use, dissemination, distribution, copying, >> or storage of this message or any attachment >> is strictly prohibited. >> >> -- >> Cheers & Best regards, >> Feilong Wang (王飞龙) >> Head of R&D >> Catalyst Cloud - Cloud Native New Zealand >> -------------------------------------------------------------------------- >> Tel: +64-48032246 >> Email: flwang(a)catalyst.net.nz <mailto:flwang@catalyst.net.nz> >> Level 6, Catalyst House, 150 Willis Street, Wellington >> -------------------------------------------------------------------------- >> The contents of this e-mail message and >> any attachments are intended solely for the >> addressee(s) and may contain confidential >> and/or legally privileged information. If you >> are not the intended recipient of this message >> or if this message has been addressed to you >> in error, please immediately alert the sender >> by reply e-mail and then delete this message >> and any attachments. If you are not the >> intended recipient, you are notified that >> any use, dissemination, distribution, copying, >> or storage of this message or any attachment >> is strictly prohibited. > > -- > Cheers & Best regards, > Feilong Wang (王飞龙) > ------------------------------------------------------ > Senior Cloud Software Engineer > Tel: +64-48032246 > Email: flwang(a)catalyst.net.nz <mailto:flwang@catalyst.net.nz> > Catalyst IT Limited > Level 6, Catalyst House, 150 Willis Street, Wellington > ------------------------------------------------------ > > > > -- > ~/DonnyD > C: 805 814 6800 > "No mission too difficult. No sacrifice too great. Duty First" -- Cheers & Best regards, Feilong Wang (王飞龙) Head of R&D Catalyst Cloud - Cloud Native New Zealand -------------------------------------------------------------------------- Tel: +64-48032246 Email: flwang(a)catalyst.net.nz Level 6, Catalyst House, 150 Willis Street, Wellington --------------------------------------------------------------------------

5 7

[infra] Retire x/zmq-event-publisher
by Andreas Jaeger 16 Jan '20

16 Jan '20

This repo is not used anymore, it was forked and is maintained for Jenkins now elsewhere. I'll retire the repo now with topic retire-zmq-event-publisher, Andreas -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

1 0

[tripleo] Switch to tripleo-container-manage by default (replacing Paunch)
by Emilien Macchi 15 Jan '20

15 Jan '20

Hi folks, Some work has been done to replace Paunch and use the new "podman_container" Ansible module; It's possible thanks to a role that is now documented here: https://docs.openstack.org/tripleo-ansible/latest/roles/role-tripleo-contai… While some efforts are still ongoing to replace container-puppet.py (which uses Paunch to execute a podman run); the tripleo-container-manage role has reached stability and enough maturity to be the default now. I would like to give it a try and for that I have 2 patches that would need to be landed: https://review.opendev.org/#/c/700737 https://review.opendev.org/#/c/700738 The most popular question that has been asked about $topic so far is: how can I run paunch debug to print the podman commands. Answer: https://docs.openstack.org/tripleo-ansible/latest/roles/role-tripleo-contai… Please raise any concern here and we'll address it. Hopefully we can make the default on time before U cycle ends. On a side note: I prepared all the backports to stable/train so the feature will be available in that branch as well. Thanks, -- Emilien Macchi

3 4

[deployment][kolla][tripleo][osa][docs] Intro to OpenStack
by Radosław Piliszek 15 Jan '20

15 Jan '20

Hiya, Folks! I had some thought after talking with people new to OpenStack - our deployment tools are too well-hidden in the ecosystem. People try deploying devstack for fun (and some still use packstack!) and then give up on manual installation for production due to its complexity and fear of upgrades. I also got voices that Kolla/TripleO/OSA (order random) is an "unofficial" way to deploy OpenStack and the installation guide is the only "official" one (whatever that may mean in this very context). So I decided I go the "newbie" route and inspected the website. https://www.openstack.org invites us to browse: https://www.openstack.org/software/start/ which is nice and dandy, presents options of enterprise-grade solutions etc. but fails to really mention OpenStack has deployment tools (if one does not look at the submenu bar) and instead points the "newbie" to the installation guide: https://docs.openstack.org/install-guide/overview.html which kind-of negates that OpenStack ecosystem has any ready tools of deployment by saying: "After becoming familiar with basic installation, configuration, operation, and troubleshooting of these OpenStack services, you should consider the following steps toward deployment using a production architecture: ... Implement a deployment tool such as Ansible, Chef, Puppet, or Salt to automate deployment and management of the production environment." Just some food for thought. Extra for Kolla and OSA: https://docs.openstack.org/train/deploy/ seems we no longer deploy OpenStack since Train. -yoctozepto

3 5

[nova] Removal of 'deallocate_networks_on_reschedule' virt driver API method
by Stephen Finucane 15 Jan '20

15 Jan '20

Just FYI, the 'deallocate_networks_on_reschedule' method of the nova virt driver API has been removed in [1]. It was only used for nova- network based flows and is therefore surplus to requirements. Third party drivers that implement this function can now remove it. Stephen [1] https://review.opendev.org/#/c/696516/

1 0

[scientific-sig] IRC Meeting today 1100UTC - large scale & planning for 2020
by Stig Telfer 15 Jan '20

15 Jan '20

Hi All - We have a Scientific SIG meeting today at 1100UTC (about 30 minutes time) in channel #openstack-meeting. Everyone is welcome. Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_15th_2020 <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_15th_2020> We’d like to gather some datapoints for the Large Scale SIG, and talk CFPs and conferences for 2020. Cheers, Stig

1 0

[mistral][core] Promoting Eyal Bar-Ilan to the Mistral core team
by Renat Akhmerov 15 Jan '20

15 Jan '20

Hi, I’d like to promote Eyal Bar-Ilan to the Mistral core team since he’s shown a great contribution performance in the recent months. Eyal always reacts on various CI issues timely and provides fixes very quickly. He’s also completed a number of useful functional Mistral features in Train and Ussuri. And his overall statistics for Ussuri ([1]) makes him a clear candidate for core membership. Core reviewers, please let me know if you have any objections. [1] https://www.stackalytics.com/?module=mistral-group&release=ussuri&user_id=e… Thanks Renat Akhmerov @Nokia

4 4

RE: Designate zone troubleshooting [designate]
by Albert Braden 15 Jan '20

15 Jan '20

1 0

[tripleo] rocky builds
by Wesley Hayutin 14 Jan '20

14 Jan '20

Greetings, I've confirmed that builds from the Rocky release will no longer be imported. Looking for input from the upstream folks with regards to maintaining the Rocky release for upstream. Can you please comment if you have any requirement to continue building, patching Rocky as I know there are active reviews [1]. I've added this topic to be discussed at the next meeting [2] Thank you! [1] https://review.opendev.org/#/q/status:open+tripleo+branch:stable/rocky [2] https://etherpad.openstack.org/p/tripleo-meeting-items

3 2

[cyborg] enable launchpad or storyboard for Cyborg
by Brin Zhang(张百林) 14 Jan '20

14 Jan '20

Hi Sundar and all: I think we should enable launchpad for the Cyborg project to record its reported bugs, submitted blueprints, etc., so that we can keep track of project updates and changes. Now I found there are some specifications in the cyborg-specs, and there has not been management by the Launchpad (https://launchpad.net/cyborg) or storyboard (https://storyboard.openstack.org/#!/project/openstack/cyborg) Personally recommend using Launchpad, it looks very intuitive. brinzhang

3 2

[all] DevStack jobs broken due to setuptools not available for Python 2
by Radosław Piliszek 14 Jan '20

14 Jan '20

Hi all, I noticed DevStack jobs fail all over the place [1] due to: UnsupportedPythonVersion: Package 'setuptools' requires a different Python: 2.7.17 not in '>=3.5' Bug reported in [2]. Notice USE_PYTHON3=True does not help as stack.sh is hardcoded to versionless Python. [1] https://zuul.opendev.org/t/openstack/builds?result=RETRY_LIMIT&result=FAILU… [2] https://bugs.launchpad.net/devstack/+bug/1859350 -yoctozepto

6 8

Designate zone troubleshooting
by Albert Braden 14 Jan '20

14 Jan '20

1 0

[ops] No ops meetup team meeting tomorrow (2020/1/14) on IRC
by Chris Morgan 14 Jan '20

14 Jan '20

We had a great OpenStack Ops meetup last week in London. Those involved now need to catch up on other work, so we'll resume regular meetings on Jan 21st. Our thanks to everyone who attended and/or helped make it one of the best meetups in a while. Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[blazar] No IRC meeting tomorrow
by Pierre Riteau 13 Jan '20

13 Jan '20

Hello, As announced in the last meeting, due to travel the weekly Blazar IRC meeting of January 14 is cancelled. The next meeting will be held on Jan 21. Thanks, Pierre Riteau (priteau)

1 0

Re: [magnum]: K8s cluster creation times out. OpenStack Train : [ERROR]: Unable to render networking. Network config is likely broken
by feilong 13 Jan '20

13 Jan '20

Hi Bhupathi, Firstly, I would suggest setting the use_podman=False when using fedora atomic image. And it would be nice to set the "kube_tag", e.g. v1.15.6 explicitly. Then please trigger a new cluster creation. Then if you still run into error. Here is the debug steps: 1. ssh into the master node, check log /var/log/cloud-init-output.log 2. If there is no error in above log file, then run journalctl -u heat-container-agent to check the heat-container-agent log. If above step is correct, then you must be able to see something useful here. On 11/01/20 12:15 AM, Bhupathi, Ramakrishna wrote: > > Wang, > > Here it is . I added the labels subsequently. My nova and neutron are > working all right as I installed various systems there working with no > issues.. > > > > > > *From:*Feilong Wang [mailto:feilong@catalyst.net.nz] > *Sent:* Thursday, January 9, 2020 6:12 PM > *To:* openstack-discuss(a)lists.openstack.org > *Subject:* Re: [magnum]: K8s cluster creation times out. OpenStack > Train : [ERROR]: Unable to render networking. Network config is likely > broken > > > > Hi Bhupathi, > > Could you please share your cluster template? And please make sure > your Nova/Neutron works. > > > > On 10/01/20 2:45 AM, Bhupathi, Ramakrishna wrote: > > Folks, > > I am building a Kubernetes Cluster( Openstack Train) and using > fedora atomic-29 image . The nodes come up fine ( I have a simple > 1 master and 1 node) , but the cluster creation times out, and > when I access the cloud-init logs I see this error . Wondering > what I am missing as this used to work before. I wonder if this > is image related . > > > > [ERROR]: Unable to render networking. Network config is likely > broken: No available network renderers found. Searched through > list: ['eni', 'sysconfig', 'netplan'] > > > > Essentially the stack creation fails in “kube_cluster_deploy” > > > > Can somebody help me debug this ? Any help is appreciated. > > > > --RamaK > > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. > > -- > Cheers & Best regards, > Feilong Wang (王飞龙) > Head of R&D > Catalyst Cloud - Cloud Native New Zealand > -------------------------------------------------------------------------- > Tel: +64-48032246 > Email: flwang(a)catalyst.net.nz <mailto:flwang@catalyst.net.nz> > Level 6, Catalyst House, 150 Willis Street, Wellington > -------------------------------------------------------------------------- > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. -- Cheers & Best regards, Feilong Wang (王飞龙) ------------------------------------------------------ Senior Cloud Software Engineer Tel: +64-48032246 Email: flwang(a)catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington ------------------------------------------------------

1 0

[cinder] ussuri virtual mid-cycle next week
by Brian Rosmaita 13 Jan '20

13 Jan '20

The poll results are in. There was only one time when everyone can meet (apologies to the "if need be" people, but the need be). Session One of the Cinder Ussuri virtual mid-cycle will be held: DATE: 21 JANUARY 2020 TIME: 1300-1500 UTC LOCATION: https://bluejeans.com/3228528973 The meeting will be recorded. Please add topics to the planning etherpad: https://etherpad.openstack.org/p/cinder-ussuri-mid-cycle-planning cheers, brian

1 0

[horizon][stein]issue:
by prashant 13 Jan '20

13 Jan '20

when i m deleting multiple instances into the stein, could not able to see all remaining instances until i refresh instances list again.

1 0