- openstack-discuss - lists.openstack.org

[keystone][nova] Availability zones and unified limits
by Lance Bragstad 21 Nov '18

21 Nov '18

Unified limits cropped up in a few discussions last week. After describing the current implementation of limits, namely the attributes that make up a limit, someone asked if availability zones were on the roadmap. Ideally, it sounded like they had multiple AZs in a single region, and they wanted to be able to limit usage within the AZ. With the current implementation, regions would be the smallest unit of a deployment they could limit (e.g., limit project Foo to only using 64 compute cores within RegionOne). Instead, the idea would be to limit the number of resources for that project on an AZ within a region. What do people think about adding availability zones to limits? Should it be an official attribute in keystone? What other services would need this outside of nova? There were a few other interesting cases that popped up, but I figured we could start here. I can start another thread if needed and we can keep this specific to discussing limits + AZs. Thoughts?

4 5

Re: [openstack-dev] [nova] Can we deprecate the server backup API please?
by Matt Riedemann 21 Nov '18

21 Nov '18

On 11/18/2018 6:51 AM, Alex Xu wrote: > Sounds make sense to me, and then we needn't fix this strange behaviour > also https://review.openstack.org/#/c/409644/ The same discussion was had in the spec for that change: https://review.openstack.org/#/c/511825/ Ultimately it amounted to a big "meh, let's just not fix the bug but also no one really cares about deprecating the API either". The only thing deprecating the API would do is signal that it probably shouldn't be used. We would still support it on older microversions. If all anyone cares about is signalling not to use the API then deprecation is probably fine, but I personally don't feel too strongly about it either way. -- Thanks, Matt __________________________________________________________________________ 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

6 5

[scientific-sig] IRC Meeting today 1100 UTC - Summit wash-up, Manila+Lustre
by Stig Telfer 21 Nov '18

21 Nov '18

Hi All - We have a Scientific SIG IRC meeting today at 1100 UTC in channel #openstack-meeting. Everyone is welcome. This week we’ve got the summit activities to digest, plus similar activities at SC. We’d also like to find out if there’s anyone using Manila to manage Lustre filesystems. Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_November_21st_20… Details on how to join our meetings are here: http://eavesdrop.openstack.org/#Scientific_Working_Group Cheers, Stig

1 0

[openstack-dev] [cyborg] [weekly-meeting]
by Li Liu 20 Nov '18

20 Nov '18

There is no weekly IRC meeting for the week of Nov 21st as most of the people are still recovering from the jetlag after the summit. I will follow up with individuals offline. -- Thank you Regards Li __________________________________________________________________________ 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

[openstack-dev] [tripleo] Feedback about our project at Summit
by Emilien Macchi 20 Nov '18

20 Nov '18

Hi folks, I wasn't at the Summit but I was interested by the feedback people gave about TripleO so I've discussed with a few people who made the trip. I would like to see what actions we can take on short and long term to address it. I collected some thoughts here: https://etherpad.openstack.org/p/BER-tripleo-feedback Which is based on https://etherpad.openstack.org/p/BER-deployment-tools-feedback initially. Feel fee to add more feedback if missing, and also comment what was written. If you're aware of some WIP that address the feedback, adjust some wording if needed or just put some links if something exists and is documented already. I believe it is critical to us to listen this feedback and include some of it into our short term roadmap, so we can reduce some frustration that we can hear sometimes. Thanks for your help, -- Emilien Macchi __________________________________________________________________________ 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

[Openstack] how to sync quota usage our of sync in Rocky release
by Manuel Sopena Ballesteros 20 Nov '18

20 Nov '18

Dear Openstack community, I often have nova complaining that I have exceeded my quota, these normally happens when I node deployment fails and the resources allocated hasn't been released. Before Rocky I used to run the command below to resync, however it looks like it has been removed from Rocky. [root@TEST-openstack-controller ~]# docker exec -it -u root nova_scheduler nova-manage project quota_usage_refresh --project abc29399b91d423088549d7446766573 --user 02132c31dafa4d1d939bd52e0420b975 usage: nova-manage [-h] [--config-dir DIR] [--config-file PATH] [--debug] [--log-config-append PATH] [--log-date-format DATE_FORMAT] [--log-dir LOG_DIR] [--log-file PATH] [--nodebug] [--nopost-mortem] [--nouse-journal] [--nouse-json] [--nouse-syslog] [--nowatch-log-file] [--post-mortem] [--syslog-log-facility SYSLOG_LOG_FACILITY] [--use-journal] [--use-json] [--use-syslog] [--version] [--watch-log-file] [--remote_debug-host REMOTE_DEBUG_HOST] [--remote_debug-port REMOTE_DEBUG_PORT] {version,bash-completion,placement,network,cell_v2,db,cell,floating,api_db} ... nova-manage: error: argument category: invalid choice: 'project' (choose from 'version', 'bash-completion', 'placement', 'network', 'cell_v2', 'db', 'cell', 'floating', 'api_db') Any idea how can I refresh the quota usage in Rocky? Thank you very much Manuel Sopena Ballesteros | Big data Engineer Garvan Institute of Medical Research The Kinghorn Cancer Centre, 370 Victoria Street, Darlinghurst, NSW 2010 T: + 61 (0)2 9355 5760 | F: +61 (0)2 9295 8507 | E: manuel.sb(a)garvan.org.au<mailto:manuel.sb@garvan.org.au> 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. _______________________________________________ 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

2 1

[openstack-dev] [nova] about filter the flavor
by Rambo 20 Nov '18

20 Nov '18

Hi,all I have an idea.Now we can't filter the special flavor according to the property.Can we achieve it?If we achieved this,we can filter the flavor according the property's key and value to filter the flavor. What do you think of the idea?Can you tell me more about this ?Thank you very much. __________________________________________________________________________ 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

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

20 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 20 Nov '18

20 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