| cardoe | clif: So with the trait based port scheduling, wondering how the dynamic portgroup parts will work. So I'm looking at the inspection data and it'll tell me from LLDP data what the paired NICs are available. It'll also hint to me the name on the switch. I've been naming my Ironic baremetal ports with $NODE_NAME-$UEFI_NAME (I personally would have liked just $UEFI_NAME but Ironic requires the name to be unique) | 00:28 |
|---|---|---|
| cardoe | So in that case maybe it would make sense to have an enable/disable flag on the PortGroup object so that at inspection time I can create the PortGroup but have it disabled and when its disabled the current operations will treat the port singularly (like for deployment) but trait based scheduling would be able to enable the PortGroup should it be desired. | 00:30 |
| JayF | that's not really how it works for TBN? | 01:21 |
| JayF | It will create a dynamic portgroup on demand | 01:21 |
| JayF | so you would have zero starting portgroups | 01:21 |
| cardoe | Yeah I understand. I’m just theory crafting here. Obviously the other way is that I need to set some traits on the ports based on what the inspection comes up with. | 03:10 |
| cardoe | I'm saying I don't wanna do this manually and the pairing of the ports matters. So I wanna use inspection to drive it. | 03:13 |
| opendevreview | Doug Goldstein proposed openstack/ironic master: fix: local_link_connection inspection hook does not fail on missing port https://review.opendev.org/c/openstack/ironic/+/966373 | 03:17 |
| cardoe | You can see what I'm tinkering with now. | 03:18 |
| cardoe | Not saying the idea is good. | 03:18 |
| rpittau | good morning ironic! happy friday! o/ | 07:37 |
| FreemanBoss[m] | Happy Friday ironic | 07:41 |
| rpittau | please check this quick but very important change, thanks! -> https://review.opendev.org/c/openstack/bifrost/+/966283 | 13:45 |
| JayF | +2, but it's not the end of the world to slurp test there | 13:48 |
| alegacy | i've got my patches split. working on the single process support now. | 14:20 |
| alegacy | is the intent for both the conductor and networking manager to be part of the same process or is it ok for them to be in different sub processes but still started from the one process? | 14:20 |
| alegacy | I ask because launcher.launch_service(mgr) launches another sub process unless the service launcher is set with no_fork=True which is tied to: no_fork=CONF.vnc.enabled | 14:21 |
| alegacy | dtantsur: ^^ | 14:21 |
| rpittau | JayF: thanks! that's not for slurp, it's just normal upgrade | 14:22 |
| JayF | Oh I understand, I'm just trying to think of a scenario where a slurp would work but the half slurp wouldn't | 14:36 |
| opendevreview | Riccardo Pittau proposed openstack/ironic-python-agent-builder master: Use Debian Trixie for debian based IPA ramdisks https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/966253 | 14:51 |
| opendevreview | Riccardo Pittau proposed openstack/ironic-python-agent-builder master: Use Debian Trixie for debian based IPA ramdisks https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/966253 | 14:55 |
| clif | cardoe: if you categorize your ports properly you should be able to use filter expressions to assemble portgroups in the way you want | 15:13 |
| clif | if you you want filter expressions to consider additional data points we can discuss that | 15:14 |
| cardoe | Well define categorizing my ports properly... | 15:15 |
| cardoe | Cause on the VXLAN side the suggestion has been to use the category column like physical_network for fabric. | 15:15 |
| clif | :) there's a new 'category' field on both ports and portgroups that an operator can use freely | 15:15 |
| clif | so if you wanted a portgroup consisting of a particular set of ports you could label them all 'blue' and then filter portgroup assembly on 'blue' ports | 15:16 |
| cardoe | Well sounds like the inspection hooks need to be updated for this. | 15:16 |
| clif | I probably don't fully understand your use case yet, but I'm getting to the point of actually doing network operations based on how tbn is planning the network | 15:17 |
| clif | so the inspection hooks can set fields on port{group}s? | 15:17 |
| cardoe | They already do | 15:17 |
| clif | what updates would they need? | 15:18 |
| cardoe | Well today ports that can be part of the same portgroup just have some extra data stuffed into the inspection inventory. | 15:18 |
| cardoe | But it sounds like that code should set the category to something | 15:18 |
| clif | that would be easiest imo | 15:19 |
| dtantsur | alegacy: my impression was that ironic-networking as a separate process, always. This is why I requested it to be in a separate pod in Metal3, remember? | 15:19 |
| dtantsur | this is assuming that ironic-networking does not require database access (you told me it does not) | 15:19 |
| cardoe | e.g. today to use portgroups automagically the operator would do "openstack baremetal node inventory save <node-here>" parse the resultant output JSON and then run "openstack baremetal port group create blahhhhhhh" based on that JSON data. | 15:20 |
| alegacy | dtantsur: ...yes, I don't have any use cases where that would be necessary, but TheJulia and JayF both added a review comment that it should work in the singleprocess launcher if required. | 15:21 |
| dtantsur | alegacy: as the person who requested (and probably created) the singleprocess launcher, I consider this optional. | 15:22 |
| dtantsur | The idea would be to run it in a thread from inside the conductor (not from the Launcher object) | 15:23 |
| alegacy | oh | 15:23 |
| dtantsur | you can check how API and JSON RPC are run in the singleprocess mode already | 15:23 |
| dtantsur | but again, I don't think it's an MVP requirement | 15:23 |
| JayF | I don't have a crazy-strong opinion, but we don't have a singleprocess launcher anymore if we don't put -networking in it. | 15:30 |
| JayF | We have an API+Conductor combo process that may still need some side dishes | 15:30 |
| JayF | which I guess is OK, but having all the potential ironic services still able to spin up together is a nice boon | 15:30 |
| JayF | I'll point out that singleprocess mode also powers some dev workflows (e.g. `tox -e local-ironic-dev`) but I don't think that will apply strongly here | 15:31 |
| dtantsur | I don't mind eventually figuring this out, but is it really an MVP blocker? | 15:31 |
| JayF | The comment on the CR that I seconded from TheJulia read to me like an uncertainty we COULD do it in singleprocess | 15:31 |
| dtantsur | I should probably read the comment, but why not? | 15:32 |
| JayF | I don't mind doing it later; I mind (a little?) if we can't add it later | 15:32 |
| JayF | I don't wanna badly proxy someone elses' code review comment especially when it's just likely I misread it | 15:32 |
| alegacy | Doesn't sounds like there's a really hard need for it in the short term. If it's ok, I'd like to defer it. | 15:33 |
| dtantsur | Can someone point me to the patch in question? I cannot find it | 15:34 |
| alegacy | https://review.opendev.org/c/openstack/ironic/+/962493/comment/a36c24bb_fc9cce97/ | 15:35 |
| alegacy | that's the patch that I'm splitting. I've abandoned it... others are almost ready. | 15:35 |
| dtantsur | okay, I did not check the abandoned patches | 15:35 |
| dtantsur | Well, I see zero indication here that the same approach cannot be used for NetworkingRPCService that we used for everything else? I.e. start a thread from the conductor? | 15:36 |
| dtantsur | I also don't think TheJulia is claiming it's not possible, only that it's not done? | 15:36 |
| TheJulia | burried in calls, huh, what?!? | 15:37 |
| dtantsur | TheJulia: this is re ironic-networking launched as part of ironic singleprocess (which I'm saying is not a critical requirement for me atm) | 15:39 |
| JayF | As long as we know we can hook it up later, I'm okay with it | 15:41 |
| TheJulia | yeah, I mean, its a separate process or separate process launcher which can be hooked up at some point | 15:42 |
| TheJulia | sort of a chicken/egg challenge, can't do it out of the box in advance of merging the code | 15:42 |
| TheJulia | FWIW, it is also super simple if its modeled correctly, and local dev or single process should likely be second order work since someone has to sit down and make it work outside of it | 15:50 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Add standalone networking service for ironic https://review.opendev.org/c/openstack/ironic/+/966466 | 17:21 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Add networking driver framework infrastructure https://review.opendev.org/c/openstack/ironic/+/966467 | 17:21 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Implement networking service RPC API methods https://review.opendev.org/c/openstack/ironic/+/966468 | 17:21 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Add generic switch driver support https://review.opendev.org/c/openstack/ironic/+/966469 | 17:21 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Add standalone experimental network interface https://review.opendev.org/c/openstack/ironic/+/966470 | 17:21 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Add standalone networking service installation guide https://review.opendev.org/c/openstack/ironic/+/966471 | 17:21 |
| opendevreview | Allain Legacy proposed openstack/bifrost master: Add support for OVS as a virtual switch https://review.opendev.org/c/openstack/bifrost/+/962038 | 17:22 |
| opendevreview | Allain Legacy proposed openstack/bifrost master: Add support for standalone ironic networking https://review.opendev.org/c/openstack/bifrost/+/962394 | 17:22 |
| *** dking is now known as Guest30716 | 21:10 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!