| opendevreview | cid proposed openstack/ironic-python-agent master: Type annotations and checking https://review.opendev.org/c/openstack/ironic-python-agent/+/958333 | 01:33 |
|---|---|---|
| opendevreview | Pierre Riteau proposed openstack/tenks master: Keep support for Python 3.9 https://review.opendev.org/c/openstack/tenks/+/958827 | 06:04 |
| opendevreview | Pierre Riteau proposed openstack/tenks master: Keep support for Python 3.9 https://review.opendev.org/c/openstack/tenks/+/958827 | 07:41 |
| opendevreview | Pierre Riteau proposed openstack/tenks master: Keep support for Python 3.9 https://review.opendev.org/c/openstack/tenks/+/958827 | 07:45 |
| abongale | good morning ironic o/ | 07:55 |
| hberaud[m] | Hey folks, following my previous patch to add hacking rules to ban eventlet in ironic (https://review.opendev.org/c/openstack/ironic/+/958738) I looked through all the ironic projects (https://governance.openstack.org... (full message at <https://matrix.org/oftc/media/v1/media/download/AQYZY1mt_dTSrGUWnAu81fi6SZQACvWZIkPmk0TduKMhF41CcRc6rxuZeMGm2-aK8oU3_RDfdynrfuLR4U8I761CeZPWfDtQAG1hdHJpeC5vcmcvRXlRQUhLaVB5SFJyWkxRc0dkdml6T1pL>) | 10:10 |
| dtantsur | Does anyone know if bifrost-integration-redfish-vmedia-uefi-centos-9 is expected to pass still? | 10:29 |
| dtantsur | We're running it on Ironic, and I think it's permafailing | 10:29 |
| dtantsur | If it's hopeless because of CS9, I'd rather replace it with a working job | 10:30 |
| dtantsur | TheJulia: https://review.opendev.org/c/openstack/ironic/+/958776 passes our CI, and passes various flavours of Metal3 CI. | 10:30 |
| dtantsur | I'm not sure why it did not occur me back then that we don't really need the local RPC... probably because I was in a terrible need of a vacation :) | 10:31 |
| priteau | dtantsur: probably some conflict between the newest requirements in master and need for py39? I guess Bifrost master could switch to c10s? | 10:49 |
| priteau | On a somewhat related note, I am looking for reviews on https://review.opendev.org/c/openstack/tenks/+/958827 | 10:49 |
| dtantsur | I remember rpittau doing something to keep bifrost working.. but I don't recall what it was | 11:03 |
| dtantsur | mm, we don't have CS10 support, I guess there have been roadblocks. Maybe because some of the OpenStack testing nodes don't support it. | 11:04 |
| dtantsur | yeah, 3.9 is gone in Ironic, so Bifrost cannot be used | 11:05 |
| priteau | CS10/RL10 support is going to be required for deploying Bifrost with Kolla | 11:06 |
| dtantsur | I imagine. Let me see what can be done.. | 11:08 |
| opendevreview | Pierre Riteau proposed openstack/bifrost master: [WIP] Test CentOS 10 support https://review.opendev.org/c/openstack/bifrost/+/958853 | 11:12 |
| priteau | I just did a find and replace on the jobs for now, to check the status | 11:13 |
| dtantsur | I'll take over rpittau's CI patch to unblock us | 11:13 |
| opendevreview | Pierre Riteau proposed openstack/bifrost master: [WIP] Test CentOS 10 support https://review.opendev.org/c/openstack/bifrost/+/958853 | 11:17 |
| opendevreview | Pierre Riteau proposed openstack/bifrost master: [WIP] Test CentOS 10 support https://review.opendev.org/c/openstack/bifrost/+/958853 | 11:18 |
| opendevreview | Dmitry Tantsur proposed openstack/bifrost master: Recover the CI https://review.opendev.org/c/openstack/bifrost/+/957847 | 11:22 |
| dtantsur | This ^^ is a bit nuclear, but nobody has time to figure out non-default Python on these versions | 11:23 |
| dtantsur | rpittau tried and got stuck in a rabbit hole | 11:23 |
| opendevreview | Pierre Riteau proposed openstack/bifrost master: [WIP] Test CentOS 10 support https://review.opendev.org/c/openstack/bifrost/+/958853 | 11:45 |
| priteau | dtantsur: I think it's fine. | 11:47 |
| opendevreview | Pierre Riteau proposed openstack/bifrost master: [WIP] Test CentOS 10 support https://review.opendev.org/c/openstack/bifrost/+/958853 | 11:48 |
| opendevreview | Dmitry Tantsur proposed openstack/bifrost master: Fix the dnsmasq.leases location on Debian systems https://review.opendev.org/c/openstack/bifrost/+/958873 | 12:33 |
| opendevreview | Pierre Riteau proposed openstack/bifrost master: [WIP] Test CentOS 10 support https://review.opendev.org/c/openstack/bifrost/+/958853 | 12:55 |
| dtantsur | Also, folks, the slurp-upgrade job is permafailing on bifrost: https://zuul.opendev.org/t/openstack/builds?job_name=bifrost-slurp-upgrade-ubuntu-jammy&project=openstack/bifrost | 13:13 |
| dtantsur | if you care about this feature, please fix it | 13:14 |
| dtantsur | Meanwhile, https://review.opendev.org/c/openstack/bifrost/+/957847 brings the bifrost voting jobs to a coherent state, I'd appreciate an urgent review | 13:15 |
| dtantsur | iurygregory, TheJulia, JayF, cardoe ^^ | 13:15 |
| dtantsur | The pxe-uefi job does not actually work as well, despite https://review.opendev.org/c/openstack/bifrost/+/958873/ | 13:18 |
| dtantsur | priteau: your cs10 patch is looking promising but it won't pass without my changes, maybe rebase? | 13:20 |
| TheJulia | Cores: we likely need to weigh some release process handling, specifically because https://review.opendev.org/c/openstack/ironic/+/958776 seeks to revert something we released in 31.0.0. | 13:23 |
| * dtantsur parse error | 13:23 | |
| dtantsur | What exactly are you suggesting? | 13:24 |
| TheJulia | I'm on the fence, FWIW, but if we can reach consensus quickly I think that is for the best | 13:24 |
| TheJulia | we released the change your seeking to revert out | 13:24 |
| dtantsur | Yep, that's unfortunate, but.. I still don't see a problem? It's not that we're removing an API? | 13:24 |
| TheJulia | True, and it was a super short term lived configuration | 13:25 |
| TheJulia | so, overall, maybe its all okay | 13:25 |
| TheJulia | as an intermediate step | 13:25 |
| TheJulia | I just want to make sure we're all on the same page | 13:25 |
| iurygregory | I think it would be ok | 13:34 |
| opendevreview | Merged openstack/ironic master: docs: trivial: clarify pull secrets for OCI image access https://review.opendev.org/c/openstack/ironic/+/958765 | 13:43 |
| priteau | dtantsur: sure I will rebase onto yours | 13:46 |
| TheJulia | JayF or cardoe, any opinion? | 13:49 |
| Sandzwerg[m] | Ohai wonderful people of ironic o/ | 13:51 |
| TheJulia | O'Hai! | 13:51 |
| cardoe | opinions on coffee? yes please. | 13:52 |
| dtantsur | ++ | 13:52 |
| TheJulia | mmmm coffeeeeeee | 13:52 |
| Sandzwerg[m] | I have a question regarding cleaning. In the config we configure a cleaning network. If a node goes through a automatic cleaning it will use that network. But if I change the status of a node so it get's through cleaning, for example "openstack baremetal node provide" on a node in manage with automated cleaning active it will create the cleaning ports in the context of the project where I execute the command instead of in the | 13:54 |
| Sandzwerg[m] | dedicated cleaning network. For a create it doesn't matter in which project I create a server/instance. The ports for the deployment will always be in the deployment network. Is this intended? Can it be changed? | 13:54 |
| * TheJulia gets more coffee before re-reading that to make sure she is reading it properly | 13:59 | |
| TheJulia | okay, so hmm | 14:01 |
| priteau | dtantsur: bifrost-integration-tinyipa-centos-10 passed :o | 14:02 |
| JayF | TheJulia: meh. I don't love that we're theoretically breaking an API, but I also don't really think anyone is going to care in any meaningful way except for theory or philosophy | 14:03 |
| TheJulia | This sounds like a bug, but it sounds like the admin context your managing nodes is not the same network, which the operator requesting a manual clean is generally expected to be | 14:03 |
| TheJulia | Sandzwerg[m]: ^^^ | 14:04 |
| TheJulia | Sandzwerg[m]: Specifically, sounds like your using the neutron or a similar network interface on the backend, not flat? | 14:04 |
| TheJulia | JayF: I can agree with that | 14:04 |
| TheJulia | your request has inbound context, which is geared for end users to trigger certian state out on the request, we likely need to detect/signal its an adminy action and explicitly ignore the embedded credentials for the action which creates the case your reporting | 14:06 |
| TheJulia | Sandzwerg[m]: can you please create a bug in launchpad? | 14:06 |
| cardoe | So we're effectively trying to say whoopsie... 31.0.0 just kidding... or if we merge that do we want to be noisy and say 31.0.0 is "yanked" (to use a pip term) and it should have never happened... there be breakage? | 14:07 |
| TheJulia | only breakage is if someone explicitly tried to use "none" as local_rpc | 14:07 |
| TheJulia | which was the first path we ended up taking to navigate eventlet removal | 14:08 |
| TheJulia | the change signals that, fwiw | 14:08 |
| TheJulia | well, the revert signals that. | 14:08 |
| cardoe | I'm just thinking if we merge it we've gotta have a clear reason why we released and why we're reverting other than its no longer relevant. Sort of like a lesson learned to avoid that mistake in the future? | 14:09 |
| TheJulia | Yeah, I know someone who was already burned by the change in some of their own development originally, maybe this will make it easier as well, btu yeah | 14:11 |
| TheJulia | There is a cost to pay with any effort and sometimes that cost is also learning we made a mistake or found a better way | 14:11 |
| dtantsur | TheJulia, cardoe, to be clear: I don't ancitipate any breakage in any case | 14:12 |
| TheJulia | for a deployed state, yeah | 14:13 |
| cardoe | okay so let's do it but have a very clear note. | 14:13 |
| TheJulia | it is sort of an edge case outside of Metal3 | 14:13 |
| dtantsur | (burned is putting it mildly btw: our port 8089 conflicts with kubernetes-nmstate) | 14:13 |
| TheJulia | DOH | 14:13 |
| TheJulia | that is super ouchy | 14:13 |
| dtantsur | yeaaaaah.. since OCP 4.20 is based on 31.0, we're moving the RPC to a different port | 14:13 |
| TheJulia | joy | 14:14 |
| TheJulia | okay | 14:14 |
| TheJulia | cardoe: did you look at the release note dtantsur put in? | 14:14 |
| * TheJulia begins wondering if this morning's IRC Channel Coffee was secretly made with decaf.... | 14:15 | |
| cardoe | yes. It's fine. It's matter of fact. | 14:15 |
| TheJulia | heh, okay | 14:15 |
| TheJulia | wait, was that about the coffee!?! I'm sooo confused now | 14:15 |
| TheJulia | (this is why Julia should not get up at 4:30 AM local) | 14:15 |
| cardoe | I haven't sipped my coffee yet. I came into my office and forgot to make a cup. ADHD powers. | 14:16 |
| dtantsur | ouch | 14:16 |
| cardoe | I don't want to be pedantic but we could be more explicit in the lesson learned. | 14:16 |
| cardoe | But as you said, it's likely not going to mess anyone up and it was in one recent release. | 14:16 |
| Sandzwerg[m] | TheJulia: yeah we use neutron. Our deployment network is in domain/project: Default/Service but there only technical users have access. But when I trigger a provide -> cleaning I do it in cloud_admin/master because there I have cloud_baremetal rights and we have port quota available. I can create a bug. What kind of information or log do you need? (We later have an issue because of this, but that is on us and our self-written | 14:16 |
| Sandzwerg[m] | neutron driver, that is unrelated to ironic) | 14:16 |
| TheJulia | cardoe: is there someone we should call to ensure coffee appears ? ;) | 14:17 |
| TheJulia | Sandzwerg[m]: cloud_baremetal, I take it, is some sort of custom role or right? | 14:17 |
| dtantsur | Well, I could say "we should not have merged any eventlet migration until we were sure it was perfect for all use cases".. but I don't know if it would be a constructive lesson | 14:17 |
| TheJulia | and perfection is also the enemy of good too.... | 14:17 |
| TheJulia | so... | 14:18 |
| TheJulia | we had to sort of find a line there someplace | 14:18 |
| Sandzwerg[m] | TheJulia: yeah that's the policy "has all ironic related rights" | 14:18 |
| TheJulia | This is why we have system scope support :) | 14:18 |
| Sandzwerg[m] | Our policy is still using the outdated format and might be a bit messed up, it's high on my to do to fix that | 14:19 |
| Sandzwerg[m] | Would that solve this here? | 14:20 |
| TheJulia | dtantsur: approved your revert with a longish note in gerrit backing up the discussion | 14:22 |
| TheJulia | Sandzwerg[m]: likely not | 14:22 |
| dtantsur | thx! | 14:22 |
| TheJulia | Sandzwerg[m]: we *might* have fixed this though, if your still defaulting to a much older policy model | 14:22 |
| TheJulia | If you want to privately message me a version, I can do the legwork to double check the logic before my next call | 14:23 |
| opendevreview | Merged openstack/ironic master: Drop wsgi script, docs around mod_wsgi https://review.opendev.org/c/openstack/ironic/+/951055 | 14:23 |
| TheJulia | FWIW, it seems super familiar | 14:23 |
| JayF | TheJulia: I suggest as soon as that lands we get a release request out and bump the major version | 14:23 |
| JayF | We also need releases of some stuff according to the mailing list | 14:24 |
| TheJulia | JayF: we already need to bump the major since we removed eventlet | 14:24 |
| dtantsur | we're like 2 weeks from the release anyway, right | 14:24 |
| dtantsur | ? | 14:24 |
| TheJulia | so, our next release will be 32.0.0 | 14:24 |
| dtantsur | a nice round number! | 14:24 |
| TheJulia | Wait until we get to 42 | 14:25 |
| TheJulia | I suggest we decide to skip semver and stay on 42 for a long time ;) | 14:25 |
| TheJulia | </joking... mostly) | 14:25 |
| Sandzwerg[m] | TheJulia: it's even opensource in all it's outdatedness :D https://github.com/sapcc/helm-charts/blob/master/openstack/ironic/templates/etc/_policy.json.tpl | 14:26 |
| * TheJulia tears up | 14:26 | |
| dtantsur | TheJulia: we could do 42.X.Y where X increases for feature releases, Y - for bug fixes :D | 14:27 |
| dtantsur | (and just assume that every X release is breaking lol) | 14:27 |
| TheJulia | dtantsur: +2 | 14:27 |
| Sandzwerg[m] | We are currently on antelope but I haven't updated the policy yet, that is mostly unchanged since puh, 8 years or so. Not sure which OpenStack that must have been. Train or even something older? | 14:27 |
| TheJulia | Sandzwerg[m]: fyi, policy has many more rules now :) https://github.com/openstack/ironic/blob/master/ironic/common/policy.py | 14:28 |
| TheJulia | Sandzwerg[m]: uhhhhhh Kilo, liberty, or maybe mitaka? | 14:30 |
| TheJulia | newton at the latest | 14:32 |
| JayF | I mainly just appreciating that we're likely going to have a 32.1.0 😂 | 14:32 |
| TheJulia | I think what your encountering may still be a bug | 14:34 |
| dtantsur | An absolutely random Friday afternoon thought: I want a tatoo with that ancient on-metal's bear playing guitar | 14:41 |
| JayF | dtantsur: I think I still have the original somewhere on a file system | 14:43 |
| JayF | dtantsur: I mailed the poster with it to rackspace though cardoe hopefully has it now | 14:43 |
| cardoe | hrm... when? | 14:44 |
| dtantsur | I guess copyright can be an issue :D (okay, my lazyness is probably a much bigger issue though) | 14:44 |
| Sandzwerg[m] | Hmm I think it might have been mitaka 😵💫 | 14:46 |
| Sandzwerg[m] | TheJulia: ok anything besides the info I mentioned here I should add to a bug report? | 14:47 |
| JayF | cardoe: I think I mailed it to James Denton? Is that the right name? | 14:47 |
| cardoe | Yep | 14:51 |
| cardoe | I'll ask him if he got it. | 14:51 |
| TheJulia | Sandzwerg[m]: nah, I think that should be good, I'm on my call now but I'll look more when I'm off the call | 14:54 |
| Sandzwerg[m] | Alright, thanks | 14:55 |
| TheJulia | Question of the day: Why does the kitten want to eat the 40G DAC cable next to my desk?!? | 15:15 |
| dtantsur | TheJulia: lack of copper in the nutrition? :D | 15:19 |
| TheJulia | I was more thinking she wants to be come hackerkittah! | 15:20 |
| dtantsur | Yep, that's a better idea :) | 15:26 |
| TheJulia | Now she is cuddled up next to the cable | 15:27 |
| dtantsur | Photos requested :) | 15:27 |
| TheJulia | She is also next to the corgi, I don't think this situation will last | 15:27 |
| opendevreview | Merged openstack/ironic master: Revert "Switch from local RPC to automated JSON RPC on localhost" https://review.opendev.org/c/openstack/ironic/+/958776 | 15:28 |
| JayF | I know the question was probably non-serious, but apparently small animals are attracted to low-level electric Fields. It's the reason why so many coax cables on poles get destroyed by squirrels. | 15:29 |
| dtantsur | TIL! | 15:32 |
| TheJulia | definitely non-serious, and definitely not powered :) | 15:36 |
| priteau | Could an Ironic core please W+1 this fix please? https://review.opendev.org/c/openstack/tenks/+/958827 | 15:42 |
| priteau | It is fixing Kayobe stable CI | 15:43 |
| priteau | Thanks TheJulia | 15:43 |
| opendevreview | Merged openstack/tenks master: Keep support for Python 3.9 https://review.opendev.org/c/openstack/tenks/+/958827 | 16:03 |
| Sandzwerg[m] | Here is the new bug. While writing it up I noticed that I missed up some details: https://bugs.launchpad.net/ironic/+bug/2121702 | 16:40 |
| TheJulia | ack, thanks | 16:42 |
| JayF | ...are we OK with tenks being stuck on an earlier version of python? | 17:04 |
| JayF | that PR looks unpleasant to have in an active openstack project, even with the caveats we were talking about yesterday :) | 17:05 |
| TheJulia | We could always kick it out of the apartment | 17:31 |
| TheJulia | if that is such a strong concern. Its a testing tool, not a end user tool. | 17:31 |
| JayF | I just feel a little like a hypocrite how much I, at a openstack-level, rail against unmaintained projects when there's one sleeping on the couch in Ironic :) | 17:35 |
| TheJulia | fair tough | 17:36 |
| TheJulia | err | 17:36 |
| TheJulia | fair enoguh | 17:36 |
| TheJulia | enough | 17:36 |
| * TheJulia can't spell | 17:36 | |
| TheJulia | I'm wondering if we should just cut a release for n-g-s at this point and wrap up the development cycle for ironic. n-g-s appears to be broken testing wise due to unhappiness with nova | 18:35 |
| TheJulia | I need to sit down and look at it next week I guess | 18:35 |
| JayF | clif: didn't you have some working devstack config locally with ngs? | 18:41 |
| JayF | clif: I wonder if you might be able to help troubleshoot networking-generic-switch CI | 18:41 |
| JayF | (he should see that on Tues) | 18:42 |
| clif | I have something that "works" for some definition of working | 18:43 |
| clif | I'm willing to try to help | 18:43 |
| clif | but I haven't done anything with it besides get it running to the point where ironic and its three tests nodes seem to come up properly | 18:44 |
| clif | I haven't gotten to the point where I need to directly mess with networking yet | 18:44 |
| clif | I also have IRC wired to ping me whenever I'm mentioned so please use judiciously ;) | 18:45 |
| JayF | Might not be a bad thing to point your brain at, given that network architeture is something you should have a chance to go deeper in | 18:47 |
| *** gmaan is now known as gmaan_afk | 19:30 | |
| cardoe | its a trap! don't do it! | 19:38 |
| cardoe | So random... we're talking about dynamic portgroups... what about dynamic volume connectors? | 19:39 |
| * JayF doesn't use any of ironic's volume magic | 19:47 | |
| cardoe | That's not water you're standing in JayF.... those are my tears. | 19:51 |
| JayF | I mean, I'm always happy to review changes made by others | 19:51 |
| JayF | but that's not on my list anywhere and I'd be unlikely to help beyond normal pushing patches around stuff | 19:51 |
| TheJulia | cardoe: I'm not opposed to such, I'm just getting worried about people failing to read between the lines or even read any of the documentation when it comes to such | 19:52 |
| cardoe | I haven't gotten any of it to work yet for my use case. | 19:52 |
| cardoe | But apparently promises were made. | 19:53 |
| TheJulia | wut?! | 19:57 |
| TheJulia | who? what? how many jelly beans? | 19:57 |
| cardoe | like twelve old licorice jellybeans from somebody's pocket... they're kinda melty with lint stuck in them | 19:58 |
| TheJulia | A reno revision that gets you | 20:00 |
| TheJulia | I need the caps to build my post-apoclyptic vault kit ;) | 20:01 |
| TheJulia | Serious question when Julia is burnt out and like.. needing comedy: Do we need a "I want ironic to support all the magical VMey features" sig? | 20:06 |
| cardoe | We can for sure. | 20:12 |
| cardoe | So the dynamic connector comment for example just stems from seeing the dynamic portgroup work and thinking about some of that. | 20:14 |
| cardoe | So today in the KVM side, there's os-brick in nova-compute | 20:14 |
| JayF | Oh, you mean you wanna adopt the out of tree libvirt management driver for Ironic? | 20:14 |
| cardoe | Well no. | 20:15 |
| cardoe | So I haven't gotten this all to work yet. | 20:15 |
| JayF | https://tinyurl.com/ironic-libvirt am I the only person who knows this exists!? | 20:15 |
| cardoe | Well so the concrete example for me is not attaching a boot volume off a NetApp. But attaching other volumes. | 20:16 |
| cardoe | So the OS is still on disk. | 20:16 |
| TheJulia | JayF: can you have an AI make a my little pony version of that, please? | 20:17 |
| JayF | cardoe: what's the value that ironic provides doing that vs post-boot automation of sorts? | 20:17 |
| JayF | ♫ We're no stranger to rainbows ♫ | 20:18 |
| cardoe | https://infohub.delltechnologies.com/sv-se/l/nvme-tcp-boot-from-san-with-dell-powerstore-storage-arrays/enable-nvme-of/ | 20:20 |
| JayF | so attaching via DRAC gives you offloading? | 20:21 |
| cardoe | Let's just assume your " key didn't work in the above statement | 20:25 |
| JayF | assume I haven't touched a unique piece of hardware personally in 5 years | 20:26 |
| JayF | which means I don't know if airquotes are needed | 20:26 |
| cardoe | So I think its evolving still is the best answer. | 20:28 |
| cardoe | But stepping back from that specific answer. | 20:28 |
| cardoe | Today the nova libvirt path uses os-brick to get the connector info. In Ironic world, that must be created first. | 20:29 |
| cardoe | With the introduction of extra metadata on ports. I could put something on those interfaces that says this is my storage path interface. | 20:31 |
| cardoe | If we're booting a systemd based Linux distro or Windows on the bare metal, we can know what the IQN or NQN is. | 20:31 |
| cardoe | For other OSes, one could fall back to the systemd method which means you'll have all the data you need in Ironic already. | 20:33 |
| JayF | ironic can't run os-brick in OS though | 20:33 |
| JayF | because it requires secrets you can't trust for a member in most use cases | 20:34 |
| cardoe | It doesn't need to is what I'm saying. | 20:34 |
| cardoe | So today nova libvirt calls out to os-brick for get_volume_connector(). And nova ironic calls out to Ironic's volume connector list for get_volume_connector(). | 20:36 |
| cardoe | So as a hack for experimentation, we've removed the call to Ironic there and instead create it from a pattern. | 20:37 |
| TheJulia | so, There is nothing saying we can't post through an update to volume connectors which could trigger an async task | 20:44 |
| TheJulia | which under the hood talks to a bmc.... | 20:44 |
| * TheJulia whistles innocently | 20:45 | |
| cardoe | yeah. there could be certain cases where it can all work. | 20:47 |
| TheJulia | so, one of the things I inherently expected was resyncing with cinder on just the base volume id | 20:48 |
| TheJulia | so entirely doing the whole dance with cinder | 20:48 |
| TheJulia | to resync target/connector data as applicable | 20:48 |
| rm_work[m] | Does ironic not actually have a native concept of Availability Zones? Is that a nova only thing? Trying to figure out how they interact, if we have racks of baremetal nodes grouped into pods and we want to have each set of racks be a different AZ | 21:11 |
| rm_work[m] | Looking at resource classes, traits, etc but failing to picture what actually ties it together, is there a doc with this somewhere | 21:11 |
| JayF | Yeah I don't have much familiarity with availability zones. I suspect you would have to use shards or conductor groups to segregate machines into separate Nova compute instances which lived in different az | 21:14 |
| JayF | As far as ironic directly, we have no first class API around availability zones | 21:14 |
| JayF | But essentially, you can map a conductor group or shard to another compute, map those Nova computes into separate availability zones just like you would map conductors into separate availability zones and I believe it should work | 21:15 |
| JayF | ***hypervisors into azs | 21:15 |
| TheJulia | Yeah, thats really the best way | 21:37 |
| TheJulia | Part of the underlying challenge is the scaling model is a bit different than other services, and often your not building a bunch of distinct bmc management networks. Besides, loosing bmc access in not ht eworst thing. | 22:05 |
| TheJulia | So an idea might be to toggle ports to FibreChannel and to use them as dedicated interfaces, i.e. not try and cross over the function to ask the OS if it wants the packet for network processing before presenting it over storage | 22:10 |
| TheJulia | Then it would *really* just be a matter of the host rescanning for a new lun just like FC | 22:11 |
| cardoe | Yeah | 22:17 |
| TheJulia | which ain't horrible... really. :\ | 22:17 |
| cardoe | And that's really how my hardware for this is setup anyway. | 22:17 |
| TheJulia | The total question is... can a machine see the card when its in that mode or what does it see it as with an OS running | 22:25 |
| TheJulia | Because then that exposes you to the inner workings under the hood | 22:25 |
| TheJulia | In theory, we could also make it easy to configure a card | 22:26 |
| TheJulia | We could also just expose it on the port and map it over | 22:26 |
| TheJulia | but we would need to disable it from being used for normal IP traffic, which is fine | 22:26 |
| *** gmaan_afk is now known as gmaan | 23:20 | |
| * TheJulia scribbles new topics into the ether pad for the PTG. | 23:21 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!