May 2019 - openstack-discuss - lists.openstack.org

[Zun] openstack appcontainer run error
by Alejandro Ruiz Bermejo 03 May '19

03 May '19

I'm having troubles with the verify step of the Zun intallation at Openstack Queens on Ubuntu 18.04 LTS. I previously Posted a trouble with it and already fixed the error you guys pointed at. Now i still can't launch the app container. It freeze at container_creating task, the shows an error state root@controller /h/team# openstack appcontainer show 4a657ac5-058c-43eb-8cbf-7239ad3c4d76 +-------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Field | Value | +-------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | addresses | {} | | links | [{u'href': u' http://controller:9517/v1/containers/4a657ac5-058c-43eb-8cbf-7239ad3c4d76', u'rel': u'self'}, {u'href': u' http://controller:9517/containers/4a657ac5-058c-43eb-8cbf-7239ad3c4d76', u'rel': u'bookmark'}] | | image | cirros | | labels | {} | | disk | 0 | | security_groups | [] | | image_pull_policy | None | | user_id | a16c6ef0319b4643a4ec8e56a1d025cb | | uuid | 4a657ac5-058c-43eb-8cbf-7239ad3c4d76 | | hostname | None | | environment | {} | | memory | None | | project_id | 59065d8f970b467aa94ef7b35f1edab5 | | status | Error | | workdir | None | | auto_remove | False | | status_detail | None | | host | None | | image_driver | docker | | task_state | None | | status_reason | *Docker internal error: 500 Server Error: Internal Server Error ("failed to update store for object type *libnetwork.endpointCnt: client: endpoint http://10.8.9.54:2379 <http://10.8.9.54:2379> exceeded header timeout"). * | | name | test1 | | restart_policy | {} | | ports | [] | | command | "ping" "8.8.8.8" | | runtime | None | | cpu | None | | interactive | False | +-------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ I tried to launch another container without defining a network and without executing any command, and it also had the same error. I can launch container from the computer node cli with docker commands, the errors are when i try to launch them from the controller CLI. I run a docker run hello-world at the compute node and everything went fine Wen u runned openstack appcontainer create hello-world i had exactly the same error

2 1

[baremetal-sig] Planet for syndicating bare metal activity?
by Stig Telfer 03 May '19

03 May '19

Hi all - Good to see all the activity around bare metal this week. To keep information flowing, would it make sense to implement something like a planet feed for syndicating baremetal blog content from program members, linked to from the landing page https://www.openstack.org/bare-metal/ <https://www.openstack.org/bare-metal/> ? Cheers, Stig

1 0

[keystone][heat] security_compliance options and auto-created users
by Pavlo Shchelokovskyy 03 May '19

03 May '19

Hi all, I am currently looking at options defined in [security_compliance] section of keystone.conf [0] and trying to understand how enabling those security features may affect other services. The first thing I see is that any project that auto-creates some temporary users may be affected. Of the top of my head I can recall only Heat and Tempest doing this. For Tempest situation is easier as a) tempest can use static credentials instead of dynamic ones so it is possible to craft appropriate users beforehand and b) those users are relatively short-lived (required for limited time). In case of Heat though those users are used for deferred auth (like in autoscaling) which for long lived stacks can happen at arbitrary time in future - which is a problem. Below is breakdown of options/features possible to set and what problems that may pose for Heat and ideas on how to work those around: - disable_user_account_days_inactive - this may pose a problem for deferred auth, and it seems is not possible to override it via user "options". IMO there's a need to add a new user option to Keystone to ignore this setting for given user, and then use it in Heat to create temporary users. - lockout failure options (lockout_failure_attempts, lockout_duration) - can be overridden by user option, but Heat has to set it first. Also the question remains how realistically such problem may arise for an auto-created internal user and whether Heat should set this option at all - password expiry options (password_expires_days, unique_last_password_count, minimum_password_age) - poses a problem for deferred auth, but can be overridden by user option, so Heat should definitely set it IMO for users it creates - change_password_upon_first_use - poses problem for auto-generated users, can be overridden by a user option, but Heat must set it for its generated users - password strength enforcement (password_regex, password_regex_description) - now this is an interesting one. Currently Heat creates passwords for its temporary users with this function [1] falling back to empty password if a resource is not generating one for itself. Depending on regex_password setting in keystone, it may or may not be enough to pass the password strength check. I've looked around and (as expected) generating a random string which satisfies a pre-defined arbitrary regex is quite a non-trivial task, couple of existing Python libraries that can do this note that they support only a limited subset of full regex spec. So it seems that a most simple solution would be to add yet another user option to Keystone to ignore password strength enforcement for this given user, and amend Heat to set this option as well for internal users it creates. We in Heat may also think as to whether it would have any benefit to also set the 'lock_password' user option for the auto-created users which will prohibit such users to change their passwords via API themselves. I'd very like to hear opinion from Keystone community as most solutions I named are 'add new user option to Keystone' :-) [0] https://opendev.org/openstack/keystone/src/branch/master/keystone/conf/secu… [1] https://opendev.org/openstack/heat/src/branch/master/heat/common/password_g… Cheers, - Pavlo -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com

4 4

[sig][upgrades] job done
by James Page 03 May '19

03 May '19

Hi All After this mornings PTG session, I'm pleased to propose that we formally end the Upgrades SIG. That’s a “pleased” because we feel that our job as a SIG is done! Upgrades in OpenStack are no longer a "special interest"; they are now an integral part of the philosophy of projects within the OpenStack ecosystem and although there are probably still some rough edges, we don’t think we need a SIG to drive this area forward any longer. So thanks for all of the war stories, best practice discussion and general upgrade related conversation over the Forums, PTG’s and Summits over the last few years - it's been fun! Regards James

2 2

[nova][ptg] Summary: Stein Retrospective
by Eric Fried 02 May '19

02 May '19

Etherpad: https://etherpad.openstack.org/p/nova-ptg-train-retrospective Summary: - At least one newcomer was very happy with the welcome/support he received. Let's keep up the encouragement and make new long-term contributors - Placement extraction went pretty well. Forum session had no negative energy. (Is this because we planned really well, or because it wasn't that big a deal to begin with?) - Great work and collaboration on the bandwidth series. Framework will set us up nicely for other uses as well (e.g. cyborg). - Runways work. Let's keep using them. - Release themes: some people benefit from their existence; for others they are irrelevant but harmless. So let's keep doing them, since they benefit some. - Good coordination & communication with the TripleO team. - Long commit chains are hard. Things that have helped some people, which should be encouraged for the future: hangouts, videos, and/or emails, supplementing specs, acting as "review guidance". - The Stein release seemed a little less focused than usual. No cause or action was identified. - Pre-PTG emails around Placement were very effective for some, suggested to be used in the future for Nova, though noting the limitations and restricting to the parts of the design process not appropriate for other forums (like specs). Actions: - do themes (to be discussed Saturday 1200) - keep doing runways - (mriedem) hangout/video/review-guide-email for cross-cell resize work - Consider pre-PTG email threads for U efried .

1 0

[oslo] Proposing Hervé Beraud for Oslo Core
by Ben Nemec 02 May '19

02 May '19

Hi, Hervé has been working on Oslo for a while now and in that time has shown tremendous growth in his understanding of Oslo and OpenStack. I think he would make a good addition to the general Oslo core team. Existing Oslo team members (+Keystone, Castellan, and anyone else we co-own libraries with) please respond with +1/-1. If there are no objections I'll add him to the ACL next week and we can celebrate in person. :-) Thanks. -Ben

9 9

[openstack-dev] [neutron] Team picture
by Miguel Lavalle 02 May '19

02 May '19

Dear Neutrinos, Please remember that we will have out team picture taken at 11:50, NEXT TO THE PTG REGISTRATION DESK. Please be there on time Best regards Miguel

1 0

[requirements][qa][all] mock 3.0.0 released
by Doug Hellmann 02 May '19

02 May '19

There's a major version bump of one of our testing dependencies, so watch for new unit test job failures. Doug > Begin forwarded message: > > From: Chris Withers <chris(a)withers.org> > Subject: [TIP] mock 3.0.0 released > Date: May 2, 2019 at 2:07:34 AM MDT > To: "testing-in-python(a)lists.idyll.org" <testing-in-python(a)lists.idyll.org>, Python List <python-list(a)python.org> > > Hi All, > > I'm pleased to announce the release of mock 3.0.0: > https://pypi.org/project/mock/ > > This brings to rolling backport up to date with cpython master. > > It's been a few years since the last release, so I'd be surprised if there weren't some problems. > If you hit any issues, please pin to mock<3 and then: > > - If your issue relates to mock functionality, please report in the python tracker: https://bugs.python.org > > - If your issue is specific to the backport, please report here: https://github.com/testing-cabal/mock/issues > > If you're unsure, go for the second one and we'll figure it out. > > cheers, > > Chris > > _______________________________________________ > testing-in-python mailing list > testing-in-python(a)lists.idyll.org > http://lists.idyll.org/listinfo/testing-in-python

2 1

[stable] propose Tim Burke as stable core
by John Dickinson 02 May '19

02 May '19

Tim has been very active in proposing and maintaining patches to Swift’s stable branches. Of recent (non-automated) backports, Tim has proposed more than a third of them. --John

2 1

properly sizing openstack controlplane infrastructure
by Hartwig Hauschild 02 May '19

02 May '19

Hi everyone, A colleague and I have more or less recently been tasked with redesigning my employers openstack-infrastructure and it turned out that starting over will be easier than fixing the existing stack as we've managed to lock ourselves in a corner quite good. The requirements we've got are basically "here's 50 compute-nodes, make sure whatever you're building scales upwards from there". We have the existing pike-stack as a reference but we don't really know how the different services scale up with more compute-nodes to handle. The pike-stack has three servers as control-plane, each of them with 96G of RAM and they don't seem to have too much room left when coordinating 14 compute-nodes. We're thinking about splitting the control-nodes into infrastructure (db/rabbit/memcache) and API. What would I want to look for when sizing those control-nodes? I've not been able to find any references for this at all, just rather nebulous '8G RAM should do' which is around what our rabbit currently inhales. Also: We're currently running Neutron in OVS-DVR-VXLAN-Configuration. Does that properly scale up and above 50+ nodes or should we look into offloading the networking onto something else? I'm aware that the questions may sound a bit funny, but we have to spec out the controlplane-hardware before we can start testing and we'd prefer not to retrofit the servers because we goofed up. Thanks for your time, -- Cheers, Hardy

4 7