| opendevreview | Merged openstack/ironic master: Improve exception handling in switch driver factory https://review.opendev.org/c/openstack/ironic/+/969852 | 00:18 |
|---|---|---|
| opendevreview | Merged openstack/ironic master: Migrate database charset from UTF8MB3 to UTF8MB4 https://review.opendev.org/c/openstack/ironic/+/974430 | 00:31 |
| opendevreview | Merged openstack/sushy-tools master: Set boot to HDD after virtual media eject https://review.opendev.org/c/openstack/sushy-tools/+/975352 | 04:58 |
| cardoe | Seems reasonable JayF | 05:22 |
| cardoe | TheJulia: I read through a bunch of the patches... left some comments... running out of steam this evening | 05:23 |
| cardoe | I had spoken with clif last week? about rebasing on top of https://review.opendev.org/c/openstack/ironic/+/974524 if you folks are okay with that and he was a +1 | 05:24 |
| cardoe | Those network changes are just so dense. | 05:29 |
| opendevreview | Abhijith P C proposed openstack/ironic master: Fix grammar errors in bare metal state machine documentation https://review.opendev.org/c/openstack/ironic/+/965877 | 05:37 |
| opendevreview | Merged openstack/ironic master: fix: refactor VIF network types to be an enum and ensure all are checked https://review.opendev.org/c/openstack/ironic/+/973557 | 05:55 |
| opendevreview | Merged openstack/ironic master: Add ConfigLoader class to TBN and use it in TaskManager https://review.opendev.org/c/openstack/ironic/+/972495 | 05:55 |
| opendevreview | Jad Haj Yahya proposed openstack/ironic master: Fix Redfish boot mode handling for read-only BMCs https://review.opendev.org/c/openstack/ironic/+/975521 | 06:41 |
| opendevreview | Merged openstack/ironic master: Allow rescuing a node with vmedia interface configured https://review.opendev.org/c/openstack/ironic/+/971517 | 06:55 |
| opendevreview | Merged openstack/ironic master: Fix grammar errors in bare metal state machine documentation https://review.opendev.org/c/openstack/ironic/+/965877 | 06:55 |
| rpittau | good morning ironic! o/ | 07:56 |
| opendevreview | David Nwosu proposed openstack/ironic master: Separate enrollment documentation by content type https://review.opendev.org/c/openstack/ironic/+/975600 | 08:13 |
| opendevreview | David Nwosu proposed openstack/ironic master: Separate enrollment documentation by content type https://review.opendev.org/c/openstack/ironic/+/975600 | 08:17 |
| opendevreview | David Nwosu proposed openstack/ironic master: Separate enrollment documentation by content type https://review.opendev.org/c/openstack/ironic/+/975600 | 08:18 |
| Continuity | Morning Ironic | 10:45 |
| Continuity | Has any one had any success using DPUs alongside ironic | 10:45 |
| Continuity | We are trying to work out the best way to scale beyond plans | 10:45 |
| Continuity | *vlans | 10:47 |
| Continuity | I think being able to get ovn/ovs onto the DPU connecting it into the OVN service, then telling ironic to use the exposed dpu port. Neutron will take care of plumbing the vxlan down to the dpu | 10:49 |
| abongale | good morning ironic o/ | 10:55 |
| abongale | Folks, How do we bump up the `python-ironicclient` version?. I am asking bcz of this change https://review.opendev.org/c/openstack/python-ironicclient/+/973948 | 10:57 |
| *** debian is now known as Guest1463 | 12:21 | |
| opendevreview | Jad Haj Yahya proposed openstack/ironic master: Fix Redfish boot mode handling for read-only BMCs https://review.opendev.org/c/openstack/ironic/+/975521 | 12:34 |
| opendevreview | David Nwosu proposed openstack/ironic master: Fix firmware update error handling and test empty MessageId https://review.opendev.org/c/openstack/ironic/+/974307 | 12:47 |
| opendevreview | Iury Gregory Melo Ferreira proposed openstack/ironic master: NetworkAdapter resource ID changes unpredictably across reboots https://review.opendev.org/c/openstack/ironic/+/972421 | 13:21 |
| iurygregory | good morning ironic | 13:23 |
| rpittau | abongale: I'm not sure what you're asking for, also that patch is still under review | 13:25 |
| rpittau | ok, not for long, I've approved it :) | 13:26 |
| rpittau | abongale: ok, maybe I understand, that patch will be included in the next ironicclient release, that should happen in 2 weeks | 13:28 |
| abongale | :rpittau thank you :) | 13:28 |
| rpittau | np! | 13:28 |
| opendevreview | Merged openstack/python-ironicclient master: Fix field names for selection and json https://review.opendev.org/c/openstack/python-ironicclient/+/973948 | 13:40 |
| frickler | rpittau: abongale: fyi you could add a "Sem-Ver: feature" line in the commit message to make requesting a major version bump more explicit, see https://docs.openstack.org/pbr/latest/user/features.html#version . I'm not sure how common it is to do so these days for ironic (or openstack in general) | 13:40 |
| rpittau | frickler: thanks! I always forget about that, we don't really use it that much | 13:42 |
| abongale | frickler: thanks :) | 13:52 |
| TheJulia | good morning! | 13:58 |
| TheJulia | Continuity: so, there is like this semi-plan we have in our back pocket to maybe leverage the existing vxlan work with NGS, so if the DPUs are tied to a bgp evpn, then you just treat the config on each dpu as a switch, and in theory you get magical traffic flowing | 13:59 |
| TheJulia | Continuity: depending on vendor, its a very controlled ecosystem on each device, so just dropping upstream OVS/OVN on the devices may actually degrade performance and at least one vendor has no intention of ever putting OVN on their devices. Ultimately the OVN side code for "smartnics" does not have the same flow and logic handling as which the ovs style modeling which was originally developed. | 14:01 |
| TheJulia | cardoe: replied on the networking-baremetal patches, I think there should be some discussion regarding provider network syntax usage because that is operator focused, operators really are not creating the networks for end users requesting metal, besides OVN... blah. The trunk reconcilator patch, if you could take a quick look that would be good, there I guess I'm slightly concerned over making an implied uuid match as the | 14:04 |
| TheJulia | flow given that feels less explicit on the port looping | 14:04 |
| Continuity | So my sort of plan which we need to test is dropping nvidias ovs onto it, throwing OVN controller on there, manually hooking it up to ovn, then creating a PF representation and using that as the port in ironic | 14:05 |
| Continuity | High level and needs some obvious thought | 14:05 |
| cardoe | TheJulia: I mean the command line arguments in the documentation literally do not exist. And the statement about using them isn't valid. | 14:06 |
| TheJulia | cardoe: oh, I know, I removed them once and it re-added them | 14:06 |
| TheJulia | I just stripped them previously and didn't catch it re-adding | 14:06 |
| TheJulia | Continuity: Yeah, I don't think nvidia's OVS fork and OVN will be compatible, or will maintain compatibility given OVN is so tightly coupled the underlying OVS version. | 14:06 |
| cardoe | So --provider-network-type isn't really anything wrt to OVN | 14:07 |
| Continuity | *sad trombone* | 14:07 |
| TheJulia | cardoe: no, its not, but it does basically tell ovn to not do *anything* on lower levels which actually shoots localnet binding in the foot | 14:08 |
| cardoe | When you hit the neutron API endpoint, that field can only be provided if you're an admin. If you're not an admin, it populates the value from tenant_network_types | 14:08 |
| TheJulia | because it will get created, but won't attach | 14:08 |
| TheJulia | yup | 14:08 |
| cardoe | On openstack network create? no I don't think you're correct | 14:08 |
| cardoe | There's no knowledge of that flag being passed or not. The value is required. Neutron API just populates it into the object from tenant_network_types | 14:08 |
| TheJulia | cardoe: in general, I was doing a bunch of testing with that code early on and until I stopped creating the network as a provider network, the OVN would just ignore localnet ports | 14:09 |
| cardoe | That flag literally doesn't do anything for like 15 releases | 14:10 |
| TheJulia | Continuity: i feel like I'm always the bearer of bad news regarding dpus, granted might work, but I've heard of zero intention from nvidia to support or have OVN be a thing on the devices. That may have changed, but it feels like maybe a better path is just do BGP EVPN off of them and let NGS treat the card as a cumulus nvue device... (its just an idea, not practically tested) | 14:11 |
| TheJulia | cardoe: fun, but it did seem to have a behavioral impact in testing | 14:12 |
| cardoe | TheJulia: cause you've got a lot of networks in type_drivers and tenant_network_types | 14:12 |
| TheJulia | cardoe: I defaulted tenant_network_types to just "vxlan" | 14:13 |
| cardoe | All network objects are required to have a "provider:network-type" attribute. | 14:14 |
| cardoe | Even if they're a tenant network | 14:14 |
| TheJulia | Yes, It defaults to None if a tenant creates an overlay network | 14:14 |
| cardoe | No. It gets populated to tenant_network_types | 14:14 |
| TheJulia | uhh.... /me logs into test node | 14:15 |
| TheJulia | okay, yes, it does get set, physical_network is None because it is not mapped in advance | 14:16 |
| cardoe | Either way. Just nuke those doc comments. | 14:18 |
| cardoe | Now I believe ya on overriding physical_network stuff doing things. | 14:18 |
| cardoe | But allocate_tenant_network() just sets the network_type to the values from tenant_network_types and calls allocate_provider_network() | 14:18 |
| TheJulia | yeah, I'm good with that, what I'm trying to get across is trying to set the provider network options does indeed have a negative impact so yeah, its just the different field and claude took my broad statement as "its all ML2" | 14:22 |
| TheJulia | which is obviously wrong | 14:22 |
| Continuity | TheJulia: so we would need Nvidia to get on board the OVN train. I know k8s OVN is supported by nvidia, so maybe we can leverage that | 14:31 |
| TheJulia | They have thus far seemed disinterested when approached... but customers are who is listened to by most hardware companies so.. maybe. | 14:33 |
| Continuity | We might have some sway... | 14:35 |
| Continuity | Maybe | 14:35 |
| Continuity | Time for some size nines | 14:35 |
| TheJulia | cardoe: anyway, https://review.opendev.org/c/openstack/networking-baremetal/+/974619/8/networking_baremetal/agent/l2vni_trunk_manager.py line 915 is what I really wanted to talk to you about earlier | 15:43 |
| cardoe | Yeah it was just an idea. I didn't know if its possible for us to do that. | 16:06 |
| TheJulia | okay, pondering now that I've also re-read it | 16:06 |
| TheJulia | The more I think about it, the more I'm not digging that query model at all | 16:10 |
| * TheJulia challenges claude to make it more efficient | 16:10 | |
| opendevreview | Dmitry Tantsur proposed openstack/ironic master: Allow aborting deployments in "wait call-back" state https://review.opendev.org/c/openstack/ironic/+/973279 | 16:17 |
| dtantsur | rpittau: updated ^^ thx | 16:17 |
| JayF | dtantsur: quick question re: that change if you're still around: are we going to leave the node in a fail state or do the usual, configurable stuff after a failure (e.g. power_off_after_deploy_failure and others) | 16:52 |
| JayF | dtantsur: It's not like an actionable comment because I think either way is sane, but it just made me think | 16:52 |
| TheJulia | cardoe: the path seems to be a cache to save us from additional lookups but to only allow linkage data to be valid for so long. | 16:54 |
| TheJulia | $0.01, configurable is best. I'm hearing some GPU cards actually degrade if the power is left off because they were basically all designed to be "on around the clock no matter what", which has also had me wondering if we need an option to leave nodes "on" when not in use..... | 16:55 |
| JayF | obeying the existing configs is a good idea, I just suspect some oper is gonna do an abort as a troubleshooting step | 17:01 |
| JayF | and be salty when it cleans lol | 17:01 |
| TheJulia | oh, likely as well | 17:04 |
| JayF | https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/975579 CI is badly broken here? looks like we have a requirement that got removed from g-r? | 17:04 |
| opendevreview | Merged openstack/ironic master: Revert "ci: stabilize ironic-standalone-redfish" https://review.opendev.org/c/openstack/ironic/+/956515 | 17:10 |
| opendevreview | Merged openstack/ironic master: Parse and validate [console] port_range at config loading layer https://review.opendev.org/c/openstack/ironic/+/971716 | 17:10 |
| TheJulia | - to _ translation maybe, but requriements has a dash and an underscore as well | 17:23 |
| opendevreview | Julia Kreger proposed openstack/networking-baremetal master: l2vni baremetal mech driver https://review.opendev.org/c/openstack/networking-baremetal/+/973889 | 17:54 |
| opendevreview | Julia Kreger proposed openstack/networking-baremetal master: Trunk port reconciliation for L2VNI attachments https://review.opendev.org/c/openstack/networking-baremetal/+/974619 | 17:54 |
| TheJulia | cardoe: ^^ | 17:54 |
| * cardoe narrows his eyes. | 17:54 | |
| TheJulia | rutro | 17:59 |
| opendevreview | Julia Kreger proposed openstack/networking-baremetal master: Add a reconciler to fix bug 1995078 https://review.opendev.org/c/openstack/networking-baremetal/+/975333 | 17:59 |
| * TheJulia slides coffee forward as a peace offering | 17:59 | |
| JayF | https://review.opendev.org/c/openstack/ironic/+/974519/6 this has 2x+2 from me, cid right now -- would appreciate a non-GR review but I will land it today/tomorrow even without one barring a comment here | 18:16 |
| opendevreview | Julia Kreger proposed openstack/networking-generic-switch master: l2vni plug case with Cisco NXOS https://review.opendev.org/c/openstack/networking-generic-switch/+/968377 | 18:17 |
| opendevreview | Julia Kreger proposed openstack/networking-generic-switch master: vxlan: Arista EOS and vendor neutral SONiC https://review.opendev.org/c/openstack/networking-generic-switch/+/972763 | 18:17 |
| opendevreview | Julia Kreger proposed openstack/networking-generic-switch master: vxlan: OVS testing patch for 'vxlan' binding model https://review.opendev.org/c/openstack/networking-generic-switch/+/972765 | 18:17 |
| opendevreview | Julia Kreger proposed openstack/networking-generic-switch master: vxlan: Add Junos, Cumulus NVUE, and denote Dell OS10 as unsupported https://review.opendev.org/c/openstack/networking-generic-switch/+/972764 | 18:17 |
| opendevreview | Julia Kreger proposed openstack/networking-generic-switch master: vxlan: OVS testing patch for 'vxlan' binding model https://review.opendev.org/c/openstack/networking-generic-switch/+/972765 | 18:17 |
| opendevreview | Clif Houck proposed openstack/ironic master: Add default trait behavior to _vif_attach_tbn https://review.opendev.org/c/openstack/ironic/+/974960 | 18:30 |
| opendevreview | Clif Houck proposed openstack/ironic master: Filter out already attached portlikes in plan_vif_attach https://review.opendev.org/c/openstack/ironic/+/974521 | 18:30 |
| opendevreview | Clif Houck proposed openstack/ironic master: WIP: Update TBN simulator for vif_attach planning https://review.opendev.org/c/openstack/ironic/+/973691 | 18:30 |
| opendevreview | Clif Houck proposed openstack/ironic master: Add docstrings to Trait Based Networking https://review.opendev.org/c/openstack/ironic/+/975685 | 18:30 |
| opendevreview | Clif Houck proposed openstack/ironic master: WIP: Documentation for Trait Based Networking https://review.opendev.org/c/openstack/ironic/+/975686 | 18:30 |
| opendevreview | Merged openstack/ironic master: Integrate TBN with vif_attach https://review.opendev.org/c/openstack/ironic/+/973690 | 19:31 |
| alegacy | jayf: wrt to your comments in https://review.opendev.org/c/openstack/ironic/+/966471... the examples were setup to use json-rpc and http_basic because it was my understanding that in a 'standalone' configuration where this would be used there would be no Keystone or RabbitMQ. The examples can be changed of course, but seemed best to keep them simple. | 19:44 |
| JayF | I think that is a view of a single specific use case; I have use cases for this code which would include things like keystone and rabbit even if not Neutron. Either way, what's most important to me is that we are clear about what is and isn't possible; and right now that doc implies (through omission) that it may not work well in smaller openstack w/Ironic but not Nova/Neutron. | 20:12 |
| alegacy | k, I can add a couple of small sections to cover the transport options, and auth strategies. | 20:13 |
| alegacy | if that's included do you also want the examples changed? | 20:13 |
| JayF | Whatever makes sense to you :) as long as we understand what the goal is | 20:16 |
| JayF | note that comment came with a +2 :) this is suggested improvements not blocking feedback | 20:16 |
| alegacy | k, i'll respin since I have to respin the patch under it anyway. | 20:20 |
| opendevreview | Julia Kreger proposed openstack/networking-baremetal master: l2vni baremetal mech driver https://review.opendev.org/c/openstack/networking-baremetal/+/973889 | 21:08 |
| JayF | https://blogs.oracle.com/mysql/no-more-hidden-changes-how-mysql-9-6-transforms-foreign-key-management is worth paying attention to | 21:43 |
| JayF | I think it should overall be a win for openstack use cases; but we may wanna just have some awareness of it in case we get weird perf bugs | 21:43 |
| cardoe | JayF: you seem to have powers on https://review.opendev.org/c/x/proliantutils/+/974571 what can I do to land that series of changes? | 23:36 |
| JayF | I don't have power | 23:38 |
| JayF | and if I did, I wouldn't use them | 23:38 |
| JayF | it's not an openstack deliverable and I don't do free work for HPE | 23:38 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!