horizon: enable neutron port management
Closed, DeclinedPublic
Actions

Assigned To

Authored By

	aborrero
	Jun 17 2020, 1:07 PM

Description

Openstack/Neutron ports are generally associated with a given VM instance, therefore they are created transparently when with the common instance life-cycle.
However, for certain use cases, like creating VIP addresses for HA, manually allocating a port is something should be done by hand.

Creating a neutron port by hand can only be done using the CLI tools, but I guess horizon has some kind of panel for port management that should also allow this.

The ultimate goal is to enable for CloudVPS users the ability to create such HA configs themselves. Yes, there are quotas for ports, usually a fixed number of 500.

Details

	Subject	Repo	Branch	Lines +/-
	UNTESTED: openstack: neutron: refresh API policy to allow port management	operations/puppet	production	+6 -5

Customize query in gerrit

Related Objects

Mentioned Here: T196662: Set up LVS in beta like prod

Event Timeline

aborrero created this task.Jun 17 2020, 1:07 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 17 2020, 1:07 PM

For WMCS team discussion: is this a good idea? This would enable yet another use case for CloudVPS users. If not a good idea, we can do nothing and stay the same: the use case is only for projects under our control.

I'm pretty sure this is among the Horizon features that I marked out to avoid too many complex steps when launching VMs.

Re-enabling it should be pretty easy; I'll see if I can do a live-hack in codfw1dev to turn it on, and then we can see how complex the UI is.

@aborrero, I've enabled a few things on labtesthorizon.wikimedia.org:

The Newtworks->Network panel. This provides a 'ports' tab which seems to allow for managing ports
- It looks like anything that might involve actually creating or deleting networks or subnets is forbidden to non-admin users but we'd want to double-check that before exposing this (or remove the subnet tab entirely)

Attach/Detach interface instance actions. I'm pretty sure that these are needed to make use of the ports set above.

LMK what you think/if this supports the actions that you were hoping for.

Change 606991 had a related patch set uploaded (by Arturo Borrero Gonzalez; owner: Arturo Borrero Gonzalez):
[operations/puppet@production] UNTESTED: openstack: neutron: refresh API policy to allow port management

https://gerrit.wikimedia.org/r/606991

gerritbot added a project: Patch-For-Review.Jun 22 2020, 10:54 AM

I've been playing with this, some notes:

the form to create a port has many options we are not interested in, like selecting virtualization type, device owner, fixed IP vs subnet (we are interested in the later) , etc
if we were to enable this option, we should make sure it is properly documented, because it can be really confusing for end users if we let them guess which buttons to click and which form fields to fill in.
when I finally figured out all the correct options in the form panel, horizon failed to create the port, error:

2020-06-22 10:31:51.119694 Login successful for user "aborrero" using domain "Default", remote address 10.20.0.50.
2020-06-22 10:33:48.171474 Recoverable error: Failed to create a duplicate DefaultSecurityGroup: for attribute(s) ['PRIMARY'] with value(s) admin
2020-06-22 10:33:48.171656 Neutron server returns request_ids: ['req-eb40dc75-7a2d-484e-87b8-56d6f8720cdd']
2020-06-22 10:33:48.171677 
2020-06-22 10:35:14.851189 Recoverable error: Failed to create a duplicate DefaultSecurityGroup: for attribute(s) ['PRIMARY'] with value(s) admin
2020-06-22 10:35:14.851405 Neutron server returns request_ids: ['req-0ed44ddd-737f-4a6d-bb9a-a68abdefd9db']
2020-06-22 10:35:14.851432 
2020-06-22 10:35:15.165665 Failed to create a port for network 05a5494a-184f-4d5c-9e98-77ae61c56daa: ((rule:create_port and (rule:create_port:fixed_ips and (rule:create_port:fixed_ips:subnet_id))) and rule:create_port:port_security_enabled) is disallowed by policy
2020-06-22 10:35:15.165704 Neutron server returns request_ids: ['req-899bad20-6cce-46bd-b4bd-cc94ca0f9d80']

I guess we need a patch like https://gerrit.wikimedia.org/r/c/operations/puppet/+/606991 (untested). But changing the API policy always makes me nervous.

I'm not sure all this makes sense for a niche use case. Perhaps we can create end user docs pointing them to ask us to create the port ourselves... That doesn't scale very well, but having an elegant workflow in horizon seems to require a non-trivial amount of work.

In the 2020-06-24 we mostly agreed the CLI operations described in the docs would be enough for now.

Anyway, before closing this, I will document which parts of the UI are useless are which ones are necessary.

aborrero claimed this task.Jun 24 2020, 3:38 PM

aborrero moved this task from Needs discussion to Soon! on the cloud-services-team (Kanban) board.

• taavi subscribed.Mar 6 2021, 7:38 AM

In T255670#6253164, @aborrero wrote:

Anyway, before closing this, I will document which parts of the UI are useless are which ones are necessary.

Was this ever done? Also, could the task be renamed to reflect reality? Thanks!

For context, I'd like to take a look at T196662: Set up LVS in beta like prod some point, and since it might involve multiple Neutron ports (one for each service behind LVS), and I'd rather not bug you every time creating/deleting a service or (if I've understood correctly that each target VM behind LVS needs to have its port security rules modified) updating or changing the target servers. If there's something I can do to make this (or some other alternative) happen, please let me know.

I'm afraid I never followed up on documenting the horizon thing. And now I don't remember.

Anyway, our decision was to only support this use case for now using the CLI. We don't expect at this point to have many users of this solution, so doing by hand just one should be OK.
The raw notes from when I first tested the setup are here: https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS/Admin/Neutron_LVS

I think we can mark this task as declined, given port management wasn't enabled on horizon.

In case it wasn't clear @Majavah: you are free to tackle on T196662: Set up LVS in beta like prod when it suits you. We will be here to help with the CLI stuff on the admin side :-P follow the usual pattern: IRC ping, dedicated phab task, etc.

In T255670#6934118, @aborrero wrote:

In case it wasn't clear @Majavah: you are free to tackle on T196662: Set up LVS in beta like prod when it suits you. We will be here to help with the CLI stuff on the admin side :-P follow the usual pattern: IRC ping, dedicated phab task, etc.

Okay, thanks! Do you to know/remember if the port security rules need to be configured for each backend vm or for each LVS IP on the lvs control server only?

basically port security rules ensure only a MAC/IP address pair reach a given port (to avoid spoofing, etc). The moment you need a port to recv a different IP address then you need to update the port security.
That's the case with a VIP.

Another example of this setup is with keepalived: https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS/Admin/Keepalived

You can see the 2 openstack commands to enable the additional IP address (the VIP) in the port security for each "backend" or "real" server.

Change 606991 abandoned by Arturo Borrero Gonzalez:

[operations/puppet@production] UNTESTED: openstack: neutron: refresh API policy to allow port management

Reason:

not working on this at the moment.