- openstack-discuss - lists.openstack.org

[neutron] Allowing multiple segments from a routed network to the same host
by Kris G. Lindgren 21 Nov '18

21 Nov '18

Hello all, We have a use case where we need to allow multiple segments from the same routed network to a host. We have a spine-leaf L3 topology. Where the L2 domain exists only at the leaf level. In our use case we need to have multiple L2 vlans off the same switches pair mapped to all the servers on that switch. This is mainly done to split the L2 broadcast domains for that switch pair. Currently on our older clouds with non-routed networks we might have between 3 and 7 vlans each containing a /22 of ip address spacing, mapped to all the hosts on that switch. Where each of those vlans/subnets belong to the same L3 network segment, but are just used to keep the broadcast domains small on the switches. We are currently trying to implement the multi-segment to same host approach using ml2 + linuxbridge + vlan . We are running into a number of problems that we are working through, however before we go to much further I wanted to reach out and see if we are possibly just doing something wrong? Setup: 1.) Create a routed network with 2 segments, each segment is created with network_type: vlan with physical_network: fixed-net, using different vlans for the segments IE vlan 401 and vlan 402. 2.) Add one subnet per segment. 3.) Configure linuxbirdge agent - ml2.conf : [ml2] type_drivers = vlan tenant_network_types = vlan mechanism_drivers = linuxbridge extension_drivers = port_security [ml2_type_vlan] network_vlan_ranges = fixed-net:1:4095 [ml2_type_flat] flat_networks = physnet-mah [securitygroup] firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver [linux_bridge] #physical_interface_mappings = fixed-net:br0 bridge_mappings = fixed-net:br0 4.) Attempt to boot a vm Problems: 1.) The first issue that you hit will be the arbitrary more than 1 segment per host check that was added. If I remove: https://github.com/openstack/neutron/blob/master/neutron/objects/subnet.py#… The vm will boot with an ip from the first segment/subnet and everything is bound correctly. 2.) If I create a port on the second segment and boot the vm using that port. The vm will boot successfully using that port, however the HV br0.402 is not mapped into the bridge. The logs indicate that the port was bound using the first segment vlan 401. This is because https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/driver… receives 2 segments for network object, both segments are bindable to the host, so the first segment that is returned is vlan 401 segment, and neutron says its bindable and uses that. The fix that I have working here is 2 fold. First, since the port has a fixed_ip’s dict in it with a subnet_id in the port object, and the subnet contains the segment_id with which the ip of the port is supposed to be associated with. I first modify: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin… to add the segment_id into the fixed_ip dict, if the subnet_id has one: <snip> ) for ip in port['fixed_ips']: if 'subnet_id' in ip: subnet = self.get_subnet(orig_context._plugin_context, ip['subnet_id']) ip['segment_id'] = subnet['segment_id'] self._update_port_dict_binding(port, new_binding) <snip> Then, In the mech_agent I check if any of the fixed_ips has a segment_id and if it matches one of the segments on the network object, bind using that. <snip> if agent['alive']: ips = context.current['fixed_ips'] for ip in ips: if 'segment_id' in ip: for segment in context.segments_to_bind: if ip['segment_id'] == segment['id']: if self.try_to_bind_segment_for_agent(context, segment, agent): LOG.debug("Bound using segment: %s", segment) return for segment in context.segments_to_bind: <snip> This causes the correct segment_id to get sent to the agent and the agent creates br0.402 and assigns it to the bridge for the network. However, the agent assigns both br0.401 and br0.402 to the same linux bridge: -bash-4.2# brctl show <snip> brq3188bc9c-49 8000.9e8444c8e353 no br0.401 br0.402 tap1789c805-1c tap770e7357-be <snip> My guess is in order to correctly handle this neutron needs to create the brq interface based upon the segment vs's the network. I haven't yet started working on this particular issue. However, at this point I wanted to reach out to you guys to: 1.) Explain our use case. 2.) Get feedback on the path taken so far, as to be honest - while it works... its seems hacky. What we are trying to do is be able to use the vlan driver with segments and have the linuxbridge agents create the br0.<vlan_id> interfaces for us dynamically based upon the vlan id that we create the segment with. This will allow us to be able to have multiple of those segments (from the same routed network) per switch mapped into a single host. We are trying to avoid, outside of neutron, creating all the vlan interfaces/bridges, then just giving neutron the mappings in physical_interface_mappings or bridge_mappings. My understanding was that if these were normal provider networks using the vlan driver, I can have both networks map to the same interface on different vlans, by using the same physical_network name, and neutron will do the correct thing for me. 3.). Determine the correct process to follow to start working on this upstream. Does this need a spec? a RFE? Regards, Kris Lindgren

1 0

[openstack-dev] [omni] Has the Platform9's hybrid multicloud project been abandoned?
by Andrea Franceschini 21 Nov '18

21 Nov '18

Hello All, I'm trying to figure out if the project openstack/omni https://github.com/openstack/omni has been abandoned or superseded by another project, as it is no longer updated (at least not in the last year). Generally speaking, which is, if any, a project that aims at the same goal? In other words, which way should hybrid cloud be approached in Openstack? Do you have any idea/advice? Thanks a lot, Andrea __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

4 3

Re: [tc] merging this list into openstack-discuss
by Jeremy Stanley 20 Nov '18

20 Nov '18

On 2018-11-20 08:18:34 -0500 (-0500), Doug Hellmann wrote: > As discussed previously in [1] and [2], this list is being merged into > the new openstack-discuss mailing list. Messages that previously would > have gone to this list should be sent to the new list using the subject > tag "[tc]" to attract Technical Committee members' attention. > > [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.ht… > [2] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134924.ht… Per Doug's post to the (now former) openstack-tc ML, I have proceeded with its retirement. The archives will be retained indefinitely, but the list itself can no longer receive new messages. -- Jeremy Stanley

1 0

[openstack-dev] [Senlin] Does Senlin support Prometheus？
by xuchao＠chinacloud.com.cn 20 Nov '18

20 Nov '18

Hi， Senlin, Ceilometer/Aodh is currently integrated, does it support Prometheus ？ thanks __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

2 1

quick report on microstack
by Chris Morgan 20 Nov '18

20 Nov '18

Mark Shuttleworth introduced 'microstack' at the conference last week. It's a snap based openstack install suitable for getting a quick instance up for playing with. Project here : https://github.com/CanonicalLtd/microstack Its's aimed at bring-up on an actual ubuntu-installed host, however I got it running on a virtual Ubuntu VM on my Mac with a trivial change (see https://github.com/CanonicalLtd/microstack/issues/41) I found it an quick, easy, even fun way to get a test openstack instance, it installed in just a few minutes for me. It's a single command: snap install microstack --classic --edge So far I got a cirros instance to launch, but didn't yet manage to ssh into that instance, but I only had about an hour playing with it so far. Definitely a fun toy. Chris -- Chris Morgan <mihalis68(a)gmail.com>

2 1

[Openstack] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes??
by Yedhu Sastri 20 Nov '18

20 Nov '18

Hello All, I have some use-cases which I want to test in PowerPC architecture(ppc64). As I dont have any Power machines I would like to try it with ppc64 VM's. Is it possible to run these kind of VM's on my OpenStack cluster(Queens) which runs on X86_64 architecture nodes(OS RHEL 7)?? I set the image property architecture=ppc64 to the ppc64 image I uploaded to glance but no success in launching VM with those images. I am using KVM as hypervisor(qemu 2.10.0) in my compute nodes and I think it is not built to support power architecture. For testing without OpenStack I manually built qemu on a x86_64 host with ppc64 support(qemu-ppc64) and then I am able to host the ppc64 VM. But I dont know how to do this on my OpenStack cluster. Whether I need to manually build qemu on compute nodes with ppc64 support or I need to add some lines in my nova.conf to do this?? Any help to solve this issue would be much appreciated. -- Thank you for your time and have a nice day, With kind regards, Yedhu Sastri _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

4 4

[docs][i18n] Team meeting proposal
by Frank Kloeker 20 Nov '18

20 Nov '18

Hello, in the last weeks we had some informal discussions about combined team meeting for documentation and translation team. There should be overlapping topics and other project teams or operator would have the same contact persons on the same place. We also save resources on meeting chairs. Here are my proposal: 1) Meeting room #openstack-meeting 2) Switch back from (informal) Office Hour to (formal) Team Meeting. Topics for upcoming meetings will be collected on a Wiki page. If there are no topic we would skip the meeting. So often we recorded empty sessions in the past. 3) Meeting time is Thursday 07:00 UTC (odd week), 16:00 UTC (even week) 4) First part (30 min) I18n topics, second part documentation topics, meetingbot will recorded two sessions, so it's easier to read specific topics later. 5) Rotating meeting chairs between the two teams. This should renew a little bit the conversation and we are more flexible and visible on the move. kind regards Frank (PTL I18n)

5 4

[dev] [tc][all] TC office hours is started now on #openstack-tc
by Ghanshyam Mann 20 Nov '18

20 Nov '18

Hi All, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - TC

1 0

[openstack-dev] [charms] 18.11 OpenStack Charms release
by David Ames 20 Nov '18

20 Nov '18

Announcing the 18.11 release of the OpenStack Charms. The 18.11 charms have support for Nova cells v2 for deployments of Queens and later. The 18.11 release also has preview features including series upgrades and the Octavia load balancer charm. 47 bugs have been fixed and released across the OpenStack charms. For full details of the release, please refer to the release notes: https://docs.openstack.org/charm-guide/latest/1811.html Thanks go to the following contributors for this release: Alex Kavanagh Andrey Grebennikov Aymen Frikha Billy Olsen Chris MacNaughton Chris Sanders Corey Bryant David Ames Dmitrii Shcherbakov Drew Freiberger Edward Hope-Morley Felipe Reyes Frode Nordahl Fulvio Galeazzi James Page Liam Young Neiloy Mukerjee Pedro Guimarães Pete Vander Giessen Ryan Beisner Vladimir Grevtsev dongdong tao viswesuwara nathan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

1 0

[goals][tc] community-wide goals for train development cycle
by Doug Hellmann 20 Nov '18

20 Nov '18

Last week at the Forum in Berlin we met to discuss potential community-wide goals for the Train development cycle. We had a good list of proposals [1], although some of them do not meet the criteria for the goals program as currently defined [2]. We came up with a few suggestions that do fit the criteria, listed here in the order we discussed them: * Ensure that each project has contributor on-boarding documentation in a discoverable place in their documentation tree, and link to that from the contributor portal at openstack.org/community. (proposed by TheJulia) This should be relatively light-weight for teams to do, and will uncover some good opportunities for documentation reuse. * Deletion of project resources. (proposed by tobberydberg and adriant) This has been a long-standing request from operators, as discussed in forum session earlier in the week [3]. The propose next-steps are to establish a way for the existing os-purge program to accept plugins so that project teams can declare the relationships between resources that need to be deleted, to make orchestration easier. See the etherpad from the session for more details. * Finish moving legacy python-*client CLIs to python-openstackclient (proposed by mriedem on behalf of Tim Bell) This is another initiative that has been going on for a few years, and completing it would give users more clarity as well as providing a more consistent user interface. The general idea was to finish implementing all of the commands within OSC using the existing client libs, then update the SDK to support those features so we can drop the client libs from OSC as well, giving us 1 SDK and 1 CLI. That’s a multi-step process, so I think for the first phase targeting completing all of the commands within OSC using the various client libraries would be enough for 1 cycle. * Ensure all projects pass request-id when calling one another. (proposed by Pavlo Shchelokovskyy) Passing request-id allows us to chain requests together and trace them for debugging and profiling. We started this a while back and some projects are doing it but not all. * Rolling out oslo health-check middleware so each project provides that API. (proposed by mugsie) This came up at the PTG in Denver earlier this year [4]. There will be some up-front work to make the health check API able to support real backend checks for the database, message bus, etc. Then we would need to add the middleware to all services. In all of these cases, we have a bit more up-front work to do to be ready to accept the idea as a goal. There should be time during the remainder of the Stein cycle to make enough progress on that work to know if we could accept it as a goal. Our next steps are for the people proposing these goals to ensure that up-front work is done and be prepared to write up the goal document for review. If the proposes aren’t able/willing to act as goal champions, we need to identify someone else to fill that role. I propose we set a target of early March for having the formal goal proposals ready for review. That will give us time to approve them well before the next Summit/PTG, so that teams can use time during the PTG for planning their implementation. [1] https://etherpad.openstack.org/p/BER-t-series-goals [2] https://governance.openstack.org/tc/goals/index.html [3] https://etherpad.openstack.org/p/BER-deletion-of-project-resources [4] 1. https://etherpad.openstack.org/p/api-sig-stein-ptg (line 20) -- Doug

1 0