- openstack-discuss - lists.openstack.org

[manila] Fw: [nova] boot from volume with root_gb=0 flavors is not allowed now
by Tom Barron 18 Feb '19

18 Feb '19

Some of the jobs in manila gate were booting service VMs with root_gb=0 and got caught by this but were fixed here [1]. That's a devstack plugin fix, so as Mohammed warns, your distribution tests downstream may require their own adjustment. [1] https://review.openstack.org/#/c/637176

1 0

[keystone][service-catalog] Region "*" for identity in service catalog
by Artem Goncharov 18 Feb '19

18 Feb '19

Hi all, In a public cloud I am using there is currently one region, but should be multiple in future. Endpoint for each service has a region set. However the only exception is identity, which has an empty region (actually "*"). If I do not specify region_name during connection (with diverse tools) everything works fine. Some "admin" operations, however, really require region to be set. But if I set in (i.e. in clouds.yaml) I can't connect to cloud, since identity in this region has no explicit endpoint (keystoneauth1 is not ok with that, gophercloud as well) I was not able to find any requirements/conventions, how such setup should be really treated. On https://wiki.openstack.org/wiki/API_Special_Interest_Group/Current_Design/S… there are service catalogs for diverse clouds, and in case where a cloud has multiple region, there are multiple entries for keystone pointing to the same endpoint. Basically each time there is region properly set. In Keystone.v2 region was mandatory, but in v3 it is not anymore ( https://docs.openstack.org/python-openstackclient/pike/cli/command-objects/…) I guess in a normal way you would not be even able to configure region "*", but it was somehow done. While there is only one region the problem is not that big, but as soon as second region is added it becomes problem. Does anyone knows if that is an "allowed" setup (but then tools should be adapted to treat it properly), or this is not an "allowed" configuration (in this case I would like to see some docs to refer properly). I would personally prefer second way of fixing catalog to avoid fixes in diverse tools, but I really need a weightful reference for that. Thanks a lot in advance, Artem

2 1

[ironic] Ironic Stein Mid-Cycle Notes
by Michael Turek 18 Feb '19

18 Feb '19

Ironic had it's virtual mid-cycle call on January 21st and 22nd. Discussions were around how far along we were with priorities this cycle, making the project more container friendly, Smart NIC support, bug triaging, and more. If you are interested in seeing more about these discussions, we suggest that you check out the etherpad where we kept notes. https://etherpad.openstack.org/p/ironic-stein-midcycle If you have anything you'd like to bring up about the notes or the mid-cycle, please reach out here or on #openstack-ironic Thanks!

1 0

Help Needed - Mirantis - All Services Down in 2 Controllers
by Raja T 18 Feb '19

18 Feb '19

Hello All, Using Mirantis - Mitaka on Ubuntu 14.04 Currently I'm facing this issue: almost all services are down on 2 controllers, and are up only in one node. Pl find below pcs status output. Any help to recover this is highly appreciated. root@node-11:/var/log# pcs status Cluster name: WARNING: corosync and pacemaker node names do not match (IPs used in setup?) Last updated: Sun Feb 17 02:12:59 2019 Last change: Sat Feb 16 08:56:52 2019 by root via crm_attribute on node-1.mydomain.com Stack: corosync Current DC: node-10.mydomain.com (version 1.1.14-70404b0) - partition with quorum 3 nodes and 46 resources configured Online: [ node-1.mydomain.com node-10.mydomain.com node-11.mydomain.com ] Full list of resources: Clone Set: clone_p_vrouter [p_vrouter] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] vip__management (ocf::fuel:ns_IPaddr2): Started node-1.mydomain.com vip__vrouter_pub (ocf::fuel:ns_IPaddr2): Started node-1.mydomain.com vip__vrouter (ocf::fuel:ns_IPaddr2): Started node-1.mydomain.com vip__public (ocf::fuel:ns_IPaddr2): Started node-1.mydomain.com Clone Set: clone_p_haproxy [p_haproxy] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Clone Set: clone_p_mysqld [p_mysqld] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Master/Slave Set: master_p_rabbitmq-server [p_rabbitmq-server] Masters: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Clone Set: clone_neutron-openvswitch-agent [neutron-openvswitch-agent] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Clone Set: clone_neutron-l3-agent [neutron-l3-agent] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Clone Set: clone_neutron-metadata-agent [neutron-metadata-agent] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Clone Set: clone_neutron-dhcp-agent [neutron-dhcp-agent] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Clone Set: clone_p_heat-engine [p_heat-engine] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] sysinfo_node-1.mydomain.com (ocf::pacemaker:SysInfo): Started node-1.mydomain.com Clone Set: clone_p_dns [p_dns] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Master/Slave Set: master_p_conntrackd [p_conntrackd] Masters: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Clone Set: clone_p_ntp [p_ntp] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Clone Set: clone_ping_vip__public [ping_vip__public] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] sysinfo_node-10.mydomain.com (ocf::pacemaker:SysInfo): Stopped sysinfo_node-11.mydomain.com (ocf::pacemaker:SysInfo): Stopped PCSD Status: node-1.mydomain.com member (172.17.6.24): Offline node-10.mydomain.com member (172.17.6.32): Offline node-11.mydomain.com member (172.17.6.33): Offline Thanks! Raja. -- :^)

2 1

Rocky undercloud/director installation getting stuck -- keepalived container issue
by Shyam Biradar 18 Feb '19

18 Feb '19

Hi, Undercloud installation getting stuck due to following issue. In short, keepalived container is not starting, hence installation going in loop. https://bugs.launchpad.net/tripleo/+bug/1816349 Any comments/ideas are welcome. Thanks & Regards, Shyam Biradar, Email: shyambiradarsggsit(a)gmail.com, Contact: +91 8600266938.

1 0

[kolla][tripleo] python3 support for RHEL based systems
by Alex Schultz 18 Feb '19

18 Feb '19

Ahoy Kolla folks, In TripleO/RDO we've been working towards getting python3 support ready when the next CentOS is released. We've been working towards getting the packaging all ready and have a basic setup working on fedora 28. We would like to get a head start in Kolla and I've proposed two possible solutions to support the python2/python3 transition in the container builds. I am looking for input from the Kolla folks on which of the two methods would be preferred so we can move forward. The first method is to handle the package names in the Dockerfiles themselves. https://review.openstack.org/#/c/632156/ (kolla python3 packages) https://review.openstack.org/#/c/624838/ (kolla WIP for fedora support (not expected to merge)) https://review.openstack.org/#/c/629679/ (tripleo specific overrides) IMHO think this method allows for a better transition between the python2 and python3 packages as it just keys off the distro_python3 setting that we added as part of https://review.openstack.org/#/c/631091/. It was mentioned that this might be more complex to follow and verbose due to the if/elses being added into the Docker files. I think the if/else complexity goes away once CentOS7 support is dropped so it's a minor transition (as I believe the target is Train for full python3 support). The second method is to add in a new configuration option that allows for package names to be overrideable/replaced. See https://review.openstack.org/#/c/636403/ (kolla package-replace option) https://review.openstack.org/#/c/636457/ (kolla python3 specifics) https://review.openstack.org/#/c/624838/ (kolla WIP for fedora support would need to be supplied to test) https://review.openstack.org/#/c/636472/ (tripleo specific overrides) IMHO I actually like the package-replace option for a few package overrides. I don't think this is a cleaner implementation for replacing all the packages because it becomes less obvious what packages would actually be used and it becomes more complex to manage. This one feels more like it's pushing the complexity to the end user and would still be problematic when CentOS8 comes out all the packages would still need to be replaced in all the Docker files (in the next cycle?). My personal preference would be to proceed with the first method and maybe merge the package-replace functionality if other would find it beneficial. I would be interested to hear if other think that the second option would be better in the long term. Thanks, -Alex

2 1

[tc][election] TC candidacy
by Thierry Carrez 18 Feb '19

18 Feb '19

Hi everyone, I've been on the OpenStack Technical Committee forever, and my original plan was to not run for re-election this cycle. Thanks to name recognition, incumbents have traditionally easily been reelected. Stepping down is the only way to make room for new leaders to emerge, a process that is necessary to keep alignment between the Technical Committee members and the active contributors that are their constituency. So, having room for new members to be elected is necessary. At the same time, there is value in historical perspective, and experienced members are useful to help newcomers into their role. We also need to be careful about the message that too many people stepping down would send. So, it's a mixed bag -- we need enough, but not too many people stepping down. Over the past cycles, we introduced about 3 new people at every election. I think renewing 3 or 4 people every 6 months in a committee of 13 members is the right balance. We already have three experienced members who announced they would not be running again this cycle, so I feel like it might not be the best moment for me to step down. With the OSF shifting from being solely about OpenStack to more generally tackling the open infrastructure space, my focus has certainly expanded lately. But I don't want to feed the trolls arguing that we are leaving OpenStack behind. I'm not done with the OpenStack TC yet, and would like to advance two more things before stepping down. OpenStack is in the middle of a transition -- from hyped project driven by startups and big service providers to a more stable project led by people running it or having a business depending on it. A lot of the systems and processes that I helped put in place to cope with explosive growth are now holding us back. We need to adapt them to a new era, and I feel like I can help bringing the original perspective of why those systems were put in place, so hopefully we do not end up throwing the baby with the bath water. I feel like there is also a lot of work to do to better present what we produce. The work on the OpenStack map and the "software" pages on the openstack.org website is far from complete. OpenStack is still much harder to navigate and understand for a newcomer than it should be. I want to continue that work for one more year. So I am announcing my candidacy for a position on the OpenStack Technical Committee in the upcoming election. Thank you for your consideration ! -- Thierry Carrez (ttx)

1 0

[tc][election] TC Candidacy
by Zane Bitter 17 Feb '19

17 Feb '19

Hello again friends, I'm running again for a second term on the Technical Committee. (For the record, I don't plan to seek a third term next year.) I've been part of the OpenStack community since 2012, and as well as a TC member I am also a core reviewer for Heat and (since very recently) Oslo. I think of the TC as effectively the 'core reviewer' team for a larger group of folks who participate in the governance of OpenStack (a group that I think we should be aiming to expand even further). I'm deeply grateful to the community for giving me the opportunity to work with what is a fantastic team of people. Here's what I've been up to in the past year on the TC: - I supported Julia's initiative to spread constructive code-review techniques by distilling some of our annual endless threads on code-review etiquette into a linkable page in the Project Teams Guide.[1] A number of people, in one case an entire team, told me that they'd tweaked their approach to code review after getting ideas from this document. (This feedback is *much* appreciated by the way, because from the TC perspective it can be very hard to tell the difference between achieving lazy consensus and shouting into the void.) - I wrote the draft of and edited contributions to what became the Vision for OpenStack Clouds,[2] contacted every affected team to explain what it meant for them individually, and presented it to the OSF Board in Berlin for their feedback as well. - I helped drive the definition of a process for determining which versions of Python3 should be tested in a release.[3] That should help us make the transitions smoothly in future, though it unfortunately started too late for Stein. - I've been actively engaged with members of the OSF Board on the topic of the process for adding new Open Infrastructure projects to the Foundation, by passing on feedback from foundation members and from the TC's own experience with evaluating project applications, and trying to publicise the board's position in the community.[4] It's hard to imagine being able to get any of those done without being a TC member. As I've written elsewhere,[5] because the TC is the only project-wide elected body, leading the community to all move in the same direction is something that cannot happen without the TC. I plan to continue trying to do that, and encouraging others to do the same. Thanks for your consideration. cheers, Zane. [1] https://docs.openstack.org/project-team-guide/review-the-openstack-way.html [2] https://governance.openstack.org/tc/reference/technical-vision.html [3] https://governance.openstack.org/tc/resolutions/20181024-python-update-proc… [4] https://www.zerobanana.com/archive/2018/06/14#osf-expansion [5] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001841.…

2 2

[tc][elections] TC candidacy
by Mohammed Naser 17 Feb '19

17 Feb '19

Hi everyone: First of all, thank you very much for giving me the opportunity to be part of the technical committee over the past term within the OpenStack project governance. I’ve also taken the vice chair role which I have had to serve for sometime during the time that our chair (Doug) was out of the office. In my candidacy email for my last term, there was a few things that I brought up which I think are still very important, as well as a few others which I think we’ve made great progress in. I’d like to start talking about those first. I still believe that it’s really important to have a contact with the users and deployers, something that we’re slowly getting better at. I have found that having some of those very large operators that sit in our technical committee meetings at the PTG super productive, because they bring an important perspective to the technical committee. As I help manage a public cloud and several private clouds all over the world, I’ve seen a lot of stories about OpenStack experiences, shortcomings and seeing how users consume OpenStack. It’s a very eye opening experience and it’s built up a strong basis to be able to formulate technical decisions and understanding the impact it has on all of our different users. I think this information is a really strong asset. I mentioned that we needed to work on improving our bridges with other communities such as Kubernetes. I’ve helped add and provide resources for OpenLab to help bring CI for the Kubernetes OpenStack cloud provider, worked on Magnum changes to help better integrate and test the project and even added resources which allowed Magnum to run full functional Kubernetes tests in it’s gate (with a work in progress of adding conformance tests). While the TC is about governance, I also think it’s important for us to get some work that gets the critical moving pieces running done. I’ve also worked with a few teams in order to help and somehow mediate a discussion to facilitate the split of the placement service and provided operator feedback, participated in the split meetings and helped to push things in the direction to make it happen. However, learning a few lessons in the way about how we might go about doing something like this in the future. I’ve also increased my engagement with our APAC community by speaking more often with them over WeChat. There is a tremendous amount of knowledge and wonderful community of people who want to participate. I’ve tried my best to also build a ‘bridge’ by sharing things that might make sense for them to see from our mailing lists (for example, the most recent one about our upcoming release name). For the upcoming term, I think that we should work on increasing our engagement with other communities. In addition, providing guidance and leadership for groups and projects that need help to merge their features, even if it involves finding the right person and asking them for a review. I’d like to personally have a more “hands-on” approach and try to work more closely with the teams, help shape and provide input into the direction of their project (while looking at the overall picture). I’d also like us to try and be more engaged with the other OSF projects such as Kata containers, StarlingX, Airship and Zuul. While the last one is our darling that was created out of our use, I think providing a bridge with the others would provide a lot of value as well. Thank you for giving me the opportunity to serve as part of your technical committee, I hope to be able to continue to help over the next term. Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

2 3

[Heat] Reg accessing variables of resource group heat api
by NANTHINI A A 17 Feb '19

17 Feb '19

Hi , We are developing heat templates for our vnf deployment .It includes multiple resources .We want to repeat the resource and hence used the api RESOURCE GROUP . Attached are the templates which we used Set1.yaml -> has the resources we want to repeat Setrepeat.yaml -> has the resource group api with count . We want to access the variables of resource in set1.yaml while repeating it with count .Eg . port name ,port fixed ip address we want to change in each set . Please let us know how we can have a variable with each repeated resource . Thanks, A.Nanthini

4 11