July 2019 - openstack-discuss - lists.openstack.org

[Airship-Seaworthy] Deployment of Airship-Seaworthy on Virtual Environment
by Anirudh Gupta 05 Aug '19

05 Aug '19

Hi Team, We want to test Production Ready Airship-Seaworthy in our virtual environment The link followed is https://airship-treasuremap.readthedocs.io/en/latest/seaworthy.html<https://ind01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fairship-t…> As per the document we need 6 DELL R720xd bare-metal servers: 3 control, and 3 compute nodes. But we need to deploy our setup on Virtual Environment. Does Airship-Seaworthy support Installation on Virtual Environment? We have 2 Rack Servers with Dual-CPU Intel® Xeon® E5 26xx with 16 cores each and 128 GB RAM. Is it possible that we can create Virtual Machines on them and set up the complete environment. In that case, what possible infrastructure do we require for setting up the complete setup. Looking forward for your response. Regards अनिरुद्ध गुप्ता (वरिष्ठ अभियंता) Hughes Systique Corporation D-23,24 Infocity II, Sector 33, Gurugram, Haryana 122001 DISCLAIMER: This electronic message and all of its contents, contains information which is privileged, confidential or otherwise protected from disclosure. The information contained in this electronic mail transmission is intended for use only by the individual or entity to which it is addressed. If you are not the intended recipient or may have received this electronic mail transmission in error, please notify the sender immediately and delete / destroy all copies of this electronic mail transmission without disclosing, copying, distributing, forwarding, printing or retaining any part of it. Hughes Systique accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus.

3 5

[manila] Enabling CephFS snapshot support by default
by Goutham Pacha Ravi 05 Aug '19

05 Aug '19

Hi Zorillas and interested parties, (Copying a couple of folks explicitly as they may not be part of openstack-discuss) Manila's CephFS driver has a configuration option "cephfs_enable_snapshots" that administrators can toggle in manila.conf to allow project users to take snapshots of their shares. [1][2] This option has defaulted to False, since the time the CephFS driver was introduced (Mitaka release of OpenStack Manila) IIUC, CephFS snapshots have been "stable" since the Mimic release of CephFS, which debuted in June 2018. [3] Since then, ceph deployers/administrators don't have to toggle anything on the backend to enable snapshots. So, can we consider changing the default value of the config opt in manila to "True" in the Train release? This will allow the driver to report the capability "snapshot_support" as enabled, and makes life easier for OpenStack deployers/administrators. I would also love to deprecate this option and remove it in a future release, since it isn't really necessary, read on: Users cannot arbitrarily take snapshots in manila, there are a couple of things that can be used to prevent them: Quotas and Share Types. Unless users create their shares using a share type that explicitly requests "snapshot_support", users can't snapshot their shares. So, we're covered by the service's API in case someone is afraid this has an impact on someone in the wild using newer versions of Manila with older versions of Ceph, where snapshots were unstable. Thoughts? [1] https://opendev.org/openstack/manila/src/commit/721bb70a81b80bf065705e8790b… [2] https://docs.openstack.org/manila/queens/admin/cephfs_driver.html#enabling-… [3] http://docs.ceph.com/docs/mimic/dev/cephfs-snapshots/

2 1

[openstack-dev][magnum] Project updates
by feilong 05 Aug '19

05 Aug '19

Hi all, Now we're very close to the milestone-2 of Train release. I'd like to take this opportunity to update the project status of Magnum. So far, we have done some great work in this cycle which make Magnum to achieve to a higher level. The first feature I'd like to highlight is the k8s version rolling upgrade. With this feature, user can upgrade their k8s version with zero downtime for their application. Another one is auto scaling, now Magnum can support k8s cluster auto scaling by leveraging the Cluster Autoscaler (there is a OpenStack Magnum driver contributed by CERN team). Besides, Magnum now can support auto repair, aka auto healing, by using a combination of Draino, Cluster Autoscaler and Node Problem Detector. Except above work we have done, there are still a lot of cool features coming: 1. The first one I'd like to mention is the boot volume support. With this feature, user can boot k8s cluster node from volume and user can even set the volume type which is super useful if the cloud provider can support high performance storage, e.g. NVME. And a new useful label named "etcd_volume_type" will be introduced by the way so that user can set the volume type for etcd volume to get a great performance for etcd cluster. 2. Private cluster. With this feature, user can set the network, subnet and floating IP when creating cluster with a public cluster template, which is very handy when user want to use public templates but still want to create the cluster in their existing network. 3. Another super fancy feature is introducing a new auto healing controller except the Draino+CA+NPD combination. Recently, we (Catalyst Cloud) contributed our Magnum auto healer[1] to Cloud-Provider-Openstack repo and we're trying to introduce it to Magnum as another auto healing controller, it would be also very useful for end user to get a zero downtime k8s cluster. As you can see, there are quite a lot of exciting features are being introduced into Magnum, however all of them are done by such a small team. What a cool team! As you know, Kubernetes is still evolving very fast, so we're very keen to get more help from the community. We're working hard to add some new core members to our existing team, but we do need more. In short, if you're interested in provisioning Kubernetes on OpenStack, please try Magnum and feel free to pop up on #openstack-containers for any question. Cheers. -- 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 ------------------------------------------------------

3 4

[release] (a bit belated) Release countdown for week R-11, July 29 - August 2
by Kendall Nelson 02 Aug '19

02 Aug '19

Hello Everyone! Development Focus ----------------- We are now past the Train-2 milestone, and entering the last development phase of the cycle. Teams should be focused on implementing planned work for the cycle. Now is a good time to review those plans and reprioritize anything if needed based on the what progress has been made and what looks realistic to complete in the next few weeks. General Information ------------------- The following cycle-with-intermediary deliverables have not done any intermediary release yet during this cycle. The cycle-with-rc release model is more suited for deliverables that plan to be released only once per cycle. As a result, we will be proposing to change the release model for the following deliverables: blazar-dashboard cloudkitty-dashboard ec2-api freezer-web-ui freezer heat-agents heat-dashboard ironic-ui karbor-dashboard karbor kuryr-kubernetes magnum-ui manila-ui masakari-dashboard monasca-agent monasca-api monasca-ceilometer monasca-events-api monasca-kibana-plugin monasca-log-api monasca-notification monasca-persister monasca-thresh monasca-transform monasca-ui murano-agent networking-baremetal networking-generic-switch networking-hyperv neutron-fwaas-dashboard neutron-vpnaas-dashboard requirements sahara-extra senlin-dashboard solum-dashboard tacker-horizon tricircle vitrage-dashboard vitrage watcher-dashboard PTLs and release liaisons for each of those deliverables can either +1 the release model change when we get them pushed, or propose an intermediary release for that deliverable. In absence of answer by the start of R-10 week we'll consider that the switch to cycle-with-rc is preferable. Upcoming Deadlines & Dates -------------------------- Non-client library freeze: September 05 (R-6 week) Client library freeze: September 12 (R-5 week) Train-3 milestone: September 12 (R-5 week) -Kendall (diablo_rojo) + the Release Management Team

6 7

[masakari] how to install masakari on centos 7
by Vu Tan 01 Aug '19

01 Aug '19

Vu Tan <vungoctan252(a)gmail.com> 10:30 AM (35 minutes ago) to openstack-discuss Sorry, I resend this email because I realized that I lacked of prefix on this email's subject Hi, I would like to use Masakari and I'm having trouble finding a step by step or other documentation to get started with. Which part should be installed on controller, which is should be on compute, and what is the prerequisite to install masakari, I have installed corosync and pacemaker on compute and controller nodes, , what else do I need to do ? step I have done so far: - installed corosync/pacemaker - install masakari on compute node on this github repo: https://github.com/openstack/masakari - add masakari in to mariadb here is my configuration file of masakari.conf, do you mind to take a look at it, if I have misconfigured anything? [DEFAULT] enabled_apis = masakari_api # Enable to specify listening IP other than default masakari_api_listen = controller # Enable to specify port other than default masakari_api_listen_port = 15868 debug = False auth_strategy=keystone [wsgi] # The paste configuration file path api_paste_config = /etc/masakari/api-paste.ini [keystone_authtoken] www_authenticate_uri = http://controller:5000 auth_url = http://controller:5000 auth_type = password project_domain_id = default user_domain_id = default project_name = service username = masakari password = P@ssword [database] connection = mysql+pymysql://masakari:P@ssword@controller/masakari

4 15

[rdo] [packstack] failing to setup Stein with Openvswitch/VXLAN networking
by Bernd Bausch 01 Aug '19

01 Aug '19

Trying to set up a Stein cloud with Packstack. I want the Openvswitch mech driver and VXLAN type driver. A few weeks ago, the following invocation was successful: |sudo packstack --debug --allinone --default-password pw \ --os-neutron-ovs-bridge-interfaces=br-ex:eth0 \ --os-neutron-ml2-tenant-network-types=vxlan \ --os-neutron-ml2-mechanism-drivers=openvswitch \ --os-neutron-ml2-type-drivers=vxlan,flat \ --os-neutron-l2-agent=openvswitch \ --provision-demo-floatrange=10.1.1.0/24\ --provision-demo-allocation-pools '["start=10.1.1.10,end=10.1.1.50"]'\ --os-heat-install=y --os-heat-cfn-install=y||| Now, it fails during network setup. My network connection to the Packstack server is severed, and it turns out that its only network interface /eth0 /has no IP address and is down. No bridge exists. In the /network.pp.finished /file, I find various /ovs-vsctl /commands including /add-br/, and a command /ifdown eth0 /which fails with exit code 1 (no error message from the /ifdown /command is logged). *Can somebody recommend the options required to successfully deploy a Stein cloud based on the Openvswitch and VXLAN drivers?* Thanks much, Bernd || ||

2 3

[dev][nova][glance][cinder] introducing 'compressed' image container_format
by Ma, Zheng 31 Jul '19

31 Jul '19

Hello Nova developers, Cinder is working on a feature that will allow it to compress volumes uploaded to Glance [0,1]. We are proposing a new container_format for Glance named 'compressed' [2]. The idea is that a consumer of a 'compressed' image would read the file to determine the kind of compression and take appropriate action (either successfully decompress to find a payload that matches the image's disk_format, or fail with 'unsupported container_format'). Our preliminary testing with a raw image with container_format == compressed, disk_format == raw is that Nova boots a VM from the image but the VM appears to be unusable. Nova seems taking it as a real RAW image as disk_format indicates. So we want to open a discussion about handling this. Thanks! [0] cinder spec patch https://review.opendev.org/#/c/652275/ [1] cinder code implementation https://review.opendev.org/#/c/668825 [2] glance spec patch https://review.opendev.org/#/c/670454/

2 1

[all] Pycharm Licences
by ʂʍɒρƞįł Ҟưȴķɒʁʉɨ 31 Jul '19

31 Jul '19

I have renewed the Pycharm licenses for community contributors until July 29, 2020. For everyone who is using it will be updated automatically. Please do not request again for renewal. Best Regards, Swapnil

2 1

[swift] Shanghai PTG attendance and etherpad
by tim＠swiftstack.com 31 Jul '19

31 Jul '19

你好! Most teams sent out emails two or three weeks ago with etherpads to start estimating headcount and coming up with discussion topics. I was a little slow, but here's Swift's: https://etherpad.openstack.org/p/swift-ptg-shanghai We're thinking of doing something a little different from our previous PTGs and hackathons and want to offer a kind of extended onboarding session. If you're new to Swift, this is a great opportunity to learn more about - how Swift works, - how to write applications against Swift, - how to deploy and operate your own Swift cluster, or - how to do upstream development for Swift. Interested? We'd love to hear from you and meet you! If there are any other aspects of Swift you'd like to learn about or dive deeper on, feel free to add them! I'll try to develop some materials based on people's level of interest so it won't all be off-the-cuff :-) Of course, there will also be more-traditional design discussions going on. (I don't think I could stop this if I tried -- it seems *any time* there are three or more Swift contributors around, there are going to be design discussions happening!) If you know you want to talk about some upcoming features or other work, please update the Development Topics at the bottom. 在上海见到您们! Tim

1 0

[openstack-ansible] office hours update
by Mohammed Naser 31 Jul '19

31 Jul '19

Hey everyone, Here is the update of what happened during the OpenStack Ansible office hours this week. We thought there was an issue with the logic that determines nova_cinder_rbd_inuse running on localhost and setting the fact only on localhost (and not the host that’s it’s running it on). So the variable ‘nova_cinder_rbd_inuse’ was always set to false on these hosts. The issue was a missing rbd configuration in nova.conf and that issue has been fixed. Thanks for tuning in and thanks for Tiffanie for taking care of the basic meeting logistics! Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 0