Re: [openstack-dev] [rdo-list] [TripleO] What's the plan for shipping Pike TripleO containers ?
> snip > It's probably also worth asking if we want to be shipping stable > containers at all ? Who will be the users of those stable containers ? > snip My 2cts as a consumer of “just” RDO packages and working to move to containers: (We are currently running our own puppet infra and have something like a homegrown Triple0 (under-overcloud)) What I see us doing is building our own containers with Kolla putting as much of our own config in there except what needs to change at runtime. Runtime stuff are mostly passwords and things depending on the region. Some reasons for building our own containers: * we have some home grown code to put in the pipelines of various OpenStack components * makes for minimal configuration needed at deploy time if the container itself includes all settings A nice bonus I see is that we can deploy from source if ever needed with Kolla. Do note that we might not be a “standard” user in many regards as we have the skillset and time to do these things by ourselves. Cheers, Robert van Leeuwen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][osc] Openstack client, unit tests & creating default empty values
Hello,
The unit test for the network/v2/fakes.py for the port creates empty
dictionaries e.g. for allowed_address_pairs:
port_attrs = {
'admin_state_up': True,
'allowed_address_pairs': [{}],
'binding:host_id': 'binding-host-id-' + uuid.uuid4().hex,
'binding:profile': {},
In practice this value is actually “none” if someone (or nova for that matter)
creates the port without specifying anything.
This allowed for at least one bug I hit, which will traceback with 'NoneType'
object is not iterable:
https://review.openstack.org/#/c/461354/
I wonder how the unit tests should be modified to actually catch these things?
I can modify fakes.py to exclude the 'allowed_address_pairs': [{}]
However these issues might be in more places so it might require a more generic
approach.
What is the opinion on this?
Note that:
- I did not test against trunk neutron so maybe trunk behavior is different in
always returning an empty dict ?
- neutron cli used to work without this issue
Thx,
Robert van Leeuwen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
I think there are valid reasons to not use namespaces: * Fewer moving parts == less can potentialy fail * Troubleshooting is easier due to less places to look / need no familiarity with namespaces & tools * If I remember correctly setting up a namespace can get really slow when you have a lot of them on a single machine > IMHO, those shouldn’t be valid reasons anymore, since they were due iproute, > or sudo issues > that have been corrected long ago, and all distros installing neutron are > supporting netns at this Well, you exactly made my point: There is lots that can and will go wrong with more moving parts. That they are fixed at the moment does not mean that there will not be a new bug in the future… Cheers, Robert van Leeuwen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
> >> Are the setups out there *not* using the use_namespaces option? I'm > >> curious as > >> to why, and if it would be difficult to migrate such a setup to use > >> namespaces. At my previous employer we did not use namespaces. This was due to a installation a few years ago on SL6 which did not have name space support at that time. I think there are valid reasons to not use namespaces: * Fewer moving parts == less can potentialy fail * Troubleshooting is easier due to less places to look / need no familiarity with namespaces & tools * If I remember correctly setting up a namespace can get really slow when you have a lot of them on a single machine If you have a requirement for having all networks to be routable disabling namespaces does make sense. Since I’m currently in the design phase for such an install I’d surely like to know if it is going to be deprecated. Thx for letting us know about this :) Cheers, Robert van Leeuwen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
