June 2019 - openstack-discuss - lists.openstack.org

Installation of Cinder in multi compute environment
by Jyoti Dahiwele 26 Jun '19

26 Jun '19

Dear Team, What is the best practise of installation of Cinder service on a controller node or separate node in multi compute openstack installation?

1 0

[tc] July meeting host
by Alexandra Settle 25 Jun '19

25 Jun '19

Hi team, The next TC meeting is set to be on the 5th of July, 2019. As I have every intention of leaving my laptop in the UK whilst I vacay on the sunny shores of US, I need a volunteer to host the meeting. I am currently going through the process of updating the meeting agenda, so minimum effort required :) just turn up, and ensure your gif game is strong, and run the commands. Any takers? I'll return for the following meeting on the 1st of August. Cheers, Alex

11 18

[scientific-sig] IRC meeting shortly: Shanghai summit CFP and planning
by Stig Telfer 25 Jun '19

25 Jun '19

Hi all - We have a Scientific SIG IRC meeting at 2100 UTC (about 20 minutes) in channel #openstack-meeting. Everyone is welcome. This week with the Shanghai summit CFP approaching we’d like to kick off the planning for Scientific SIG activities for the summit. Cheers, Stig

1 0

[heat] Resource replacement terminates at DELETE_COMPLETE
by Erik McCormick 25 Jun '19

25 Jun '19

HI everyone! I have a situation with a heat stack where it has an Octavia Load Balancer resource which it thinks it's already replaced and so will not recreate it. Resource api_lb with id 3978 already replaced by 3999; not checking check /var/lib/kolla/venv/lib/python2.7/site-packages/heat/engine/check_resource.py:310 : It goes to a DELETE_COMPLETED state and just sits there. The stack stays UPDATE_IN_PROGRESS and nothing else moves. It doesn't even time out after 4 hours. Doing a stack check puts everytinng as CHECK_COMPLETE, even the non-existent load balancers. I can mark the LB and its components unhealthy and start another update, but this just repeats the cycle. This all started with some Octavia shenanigans which ended with all the load balancers being deleted manually. I have 2 similar stacks which recreated fine, but this one went through the cycle several other times as we were trying to fix the LB problem. This is a super edge case, but hopefully someone has another idea how to get out of it. Thanks! Erik

2 1

[devel] Fast flake8 testing
by Zane Bitter 25 Jun '19

25 Jun '19

Those of you who work on a fairly large project will have noticed that running flake8 over all of it takes some time, and that this slows down development. Nova (at least) has a solution to this, in the form of a "fast8" tox environment that runs flake8 only against the files that have changed in the latest patch + the working directory. This is *much* faster, but that approach has some limitations: the script is buggy, it only tests the top-most patch, it creates a second tox environment (which is slow) that can then get out of sync with your regular pep8 environment, and of course it requires the project to add it explicitly. If you're interested in a solution with none of those limitations, here is a script that I've been using: https://gist.github.com/zaneb/7a8c752bfd97dd8972756d296fc5e41f It tests all changes on the branch, using your existing pep8 tox environment, handles deleted files and changes to non-python files correctly, and should be usable for every OpenStack project. I hope this is helpful to someone. (Note that the pep8 environment on many projects includes other test commands in addition to flake8 - such as bandit - so you should still run the pep8 tox tests once before submitting a patch.) cheers, Zane.

3 2

[magnum] nodegroups
by Bharat Kunwar 25 Jun '19

25 Jun '19

Hi Theodoros, Just replying to your message on IRC here as you appear offline. > if you don't care for what you have in the db i would do this: > - stop both api and conductor > - drop magnum db > - checkout master > - run the migrations (from master) After getting this far, I tried running `magnum-db-manage upgrade` but I hit this: sqlalchemy.exc.InternalError: (pymysql.err.InternalError) (1049, u"Unknown database 'magnum'") (Background on this error at: http://sqlalche.me/e/2j85) > - start the services I can’t start the services either but that is probably due to lack of a database… > - create a cluster > - checkout magnum_nodegroups > - stop services > - run migrations > - start the services > I know it's not great… Would you mind letting me know where I’m going wrong? Thanks Bharat

2 1

How to reduce image size?
by Manuel Sopena Ballesteros 25 Jun '19

25 Jun '19

Dear Openstack community, I would like to reduce the size of an image, I wrote this command: # openstack image set --property size=700000 centos7.6-kudu-image Unable to set 'size' to '700000'. Reason: '700000' is not of type u'null', u'integer' Failed validating u'type' in schema[u'properties'][u'size']: {u'description': u'Size of image file in bytes', u'readOnly': True, u'type': [u'null', u'integer']} On instance[u'size']: '700000' I guess the real issue is u'readOnly': True How can I reduce the image size? Thank you very much Manuel 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

[kolla][octavia][openstack-ansible][tripleo] octavia in kolla ansible
by Mark Goddard 25 Jun '19

25 Jun '19

Hi, In the recent kolla meeting [1] we discussed the usability of octavia in kolla ansible. We had feedback at the Denver summit [2] that this service is difficult to deploy and requires a number of manual steps. Certificates are one of the main headaches. It was stated that OSA [3] may have some useful code we could look into. As a starting point to improving this support, I'd like to gather information from people who are using octavia in kolla ansible, and what they have had to do to make it work. Please respond to this email. I've also tagged openstack-ansible and Tripleo - if there is any useful information those teams have to share about this topic, it is most welcome. Alternatively if your support for octavia also falls short perhaps we could collaborate on improvements. Thanks, Mark [1] http://eavesdrop.openstack.org/meetings/kolla/2019/kolla.2019-06-19-15.00.l… [2] https://etherpad.openstack.org/p/DEN-train-kolla-feedback [3] https://opendev.org/openstack/openstack-ansible-os_octavia

7 11

[ironic] To not have meetings?
by Julia Kreger 25 Jun '19

25 Jun '19

Last week the discussion came up of splitting the ironic meeting to alternate time zones as we have increasing numbers of contributors in the Asia/Pacific areas of the world[0]. With that discussion, an additional interesting question came up posing the question of shifting to the mailing list instead of our present IRC meeting[1]? It is definitely an interesting idea, one that I'm personally keen on because of time zones and daylight savings time. I think before we do this, we should collect thoughts and also try to determine how we would pull this off so we don't forget the weekly checkpoint that the meeting serves. I think we need to do something, so I guess now is a good time to provide input into what everyone thinks would be best for the project and facilitating the weekly check-in. What I think might work: By EOD UTC Monday: * Listed primary effort participants will be expected to update the whiteboard[2] weekly before EOD Monday UTC * Contributors propose patches to the whiteboard that they believe would be important for reviewers to examine this coming week. * PTL or designee sends weekly email to the mailing list to start an update thread shortly after EOD Monday UTC or early Tuesday UTC. ** Additional updates, questions, and topical discussion (new features, RFEs) would ideally be wrapped up by EOD UTC Tuesday. With that, I think we would also need to go ahead and begin having "office hours" as during the week we generally know some ironic contributors will be in IRC and able to respond to questions. I think this would initially consist of our meeting time and perhaps the other time that seems to be most friendly to the contributors int he Asia/Pacific area[3]. Thoughts/ideas/suggestions welcome! -Julia [0]: http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-iro… [1]: http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-iro… [2]: https://etherpad.openstack.org/p/IronicWhiteBoard [3]: https://doodle.com/poll/bv9a4qyqy44wiq92

6 5

[neutron] Provider/External Networking
by Jan Marquardt 25 Jun '19

25 Jun '19

Hallo, we have/are planning an Openstack cluster which is supposed to look like this: http://paste.openstack.org/show/753337/ We are currently struggling with the external/provider networks. Is there any way/best practice to terminate the provider networks directly on the network nodes and announce the prefixes through BGP to the upstream routers? Any experience report or hint would really be appreciated. Best regards Jan -- Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 E-Mail: support(a)artfiles.de | Web: http://www.artfiles.de Geschäftsführer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478

2 1