| vanou | good morning ironic | 00:09 |
|---|---|---|
| arne_wiebalck | Good morning, Ironic! | 06:17 |
| opendevreview | Jakob Meng proposed openstack/bifrost master: [DNM] Explicitly fetch baremetal ports and use id on openstacksdk>=0.99.0 https://review.opendev.org/c/openstack/bifrost/+/859430 | 06:56 |
| opendevreview | Jakob Meng proposed openstack/bifrost master: [DNM] Explicitly fetch baremetal ports and use id on openstacksdk>=0.99.0 https://review.opendev.org/c/openstack/bifrost/+/859430 | 07:06 |
| rpittau | good morning ironic, happy Friday! o/ | 07:12 |
| opendevreview | Riccardo Pittau proposed openstack/ironic-python-agent bugfix/8.6: [DNM] TEST CI https://review.opendev.org/c/openstack/ironic-python-agent/+/859782 | 07:21 |
| opendevreview | Jakob Meng proposed openstack/bifrost master: [DNM] Explicitly fetch baremetal ports and use id on openstacksdk>=0.99.0 https://review.opendev.org/c/openstack/bifrost/+/859430 | 08:47 |
| rpittau | JayF: hi! just reading your mail on openstack-discuss, what's the reasoning behind wanting to release from bugfix branches? I don't think that's really needed since we release already from stable branches | 09:26 |
| JayF | rpittau: honestly it's as simple as: 1) we have backports there, 2) it should be just as easy to push for n+3 releases as for n | 12:16 |
| JayF | rpittau: it's possible you know something I don't, so is there a reason that's not true? | 12:17 |
| rpittau | JayF: I wonder how that would work as versions in bugfix branches are the same as the corresponding stable branches | 12:17 |
| iurygregory | morning Ironic | 12:18 |
| JayF | rpittau: I think it's just a patch release (e.g. 21.0.1) | 12:19 |
| rpittau | JayF: same as stable branches | 12:20 |
| iurygregory | tbh, I don't think we would need releases from bugfix branches | 12:22 |
| opendevreview | Jakob Meng proposed openstack/bifrost master: Use openstacksdk<0.99.0 and a-c-o<2.0.0 on bifrost-*collections-* jobs https://review.opendev.org/c/openstack/bifrost/+/859984 | 12:47 |
| opendevreview | Jakob Meng proposed openstack/bifrost master: Explicitly fetch baremetal ports and use id on openstacksdk>=0.99.0 https://review.opendev.org/c/openstack/bifrost/+/859430 | 12:50 |
| TheJulia | good morning everyone | 13:09 |
| * TheJulia suspects dtantsur is out today | 13:09 | |
| TheJulia | releases are cheap. If there is another reason or concern driving a different perspective, we should get it on the table | 13:38 |
| dtantsur | TheJulia: I started late and forgot to turn on IRC :) | 13:43 |
| dtantsur | all yours now | 13:43 |
| TheJulia | the allocations name field... varchar(255) | 13:43 |
| TheJulia | Any objection if I change this to a text field? | 13:44 |
| TheJulia | and add an index? | 13:44 |
| dtantsur | index on a text field, is it even a thing? | 13:44 |
| TheJulia | I ask because it is incompatible with mariadb w/innodb | 13:44 |
| TheJulia | yes, it is | 13:44 |
| * dtantsur is surprised | 13:44 | |
| TheJulia | we would need it for querying since text fields are stored differently | 13:45 |
| dtantsur | I have no objections, but can you elaborate on the exact issue? | 13:45 |
| dtantsur | "255 varchars exceeds the field max size of 767 bytes for varchar" WUT | 13:45 |
| TheJulia | Mariadb innodb tables have an underlying field byte limit of 767 characters, however, when you say you want varchar(255), and the system is using utf8, your really asking for 255*4 bytes | 13:46 |
| TheJulia | yup | 13:46 |
| dtantsur | fuuuuuuuuuuu | 13:46 |
| TheJulia | yeah | 13:46 |
| dtantsur | mysql is absurd | 13:46 |
| * dtantsur has always been a postgres person | 13:46 | |
| TheJulia | heh | 13:46 |
| dtantsur | should I even try contemplating where 767 is coming from? | 13:46 |
| TheJulia | 767/4 == ??? | 13:47 |
| dtantsur | or is it too dangerous for the rest of my sanity | 13:47 |
| TheJulia | :) | 13:47 |
| TheJulia | too dangerous | 13:47 |
| dtantsur | okay, I assume they really like this Boeing model | 13:47 |
| dtantsur | 767 was actually not too bad: a wide one, but not packed like 777 and on | 13:47 |
| * dtantsur is in Friday mood already | 13:47 | |
| TheJulia | heh | 13:47 |
| dtantsur | TheJulia: do we have the same problem with node names? | 13:50 |
| dtantsur | because I think I modelled the allocation name after them | 13:50 |
| TheJulia | Ode names are 63 chars | 13:51 |
| TheJulia | Node | 13:51 |
| dtantsur | oooookay | 13:52 |
| dtantsur | maybe we should shrink the allocation name | 13:52 |
| TheJulia | Can’t without nuking uniqueness and query by name | 13:53 |
| TheJulia | Indexing it should keep query performance sane if we just kick it over to text | 13:54 |
| dtantsur | because of how alter table will behave? | 13:54 |
| TheJulia | Because we break the contract for being able to use a node by name | 13:54 |
| TheJulia | And risk non unique names as a result | 13:54 |
| TheJulia | Then again, we could preflight warn… | 13:54 |
| dtantsur | yeah, I understand that it's problematic if someone has allocation names that are longer than, say, 128 chars | 13:55 |
| dtantsur | which doesn't sound super likely, so yeah, we can probably just ask people to change that pre-upgrade | 13:55 |
| TheJulia | That could work… though. Force them to reduce length before upgrading | 13:55 |
| TheJulia | We’ll need to backport the upgrade check | 13:55 |
| TheJulia | But that is easy enough | 13:55 |
| TheJulia | and once we start merging sqlalchemy2 stuff, we're moving our minimum for sqlalchemy which means we cut a whole numbered release, so including it should be fine | 13:56 |
| TheJulia | the alter for the schema, if everything is the right length, shouldn't be too horrible of a db update | 13:58 |
| * TheJulia goes and finds breakfast and then off to a doctor's appointment | 13:59 | |
| dtantsur | So, the 767 limit applies to text fields (any fields) too | 14:00 |
| dtantsur | yeah, good luck. just thinking aloud. | 14:00 |
| dtantsur | I wonder how it actually looks for a large text. will it only index the first 767 bytes? | 14:00 |
| TheJulia | text should be 64k | 14:03 |
| dtantsur | TheJulia: reading https://dev.mysql.com/doc/refman/5.6/en/column-indexes.html. with text fields we need to specify the limit | 14:03 |
| dtantsur | but we can also specify the limit for varchar? | 14:03 |
| dtantsur | maybe we can work around the problem by asking it to only index the frist 767 (or whatever) bytes? | 14:03 |
| TheJulia | ahh | 14:03 |
| TheJulia | yeah, for the index, that makes some sense | 14:03 |
| TheJulia | it can't be ensured unique then | 14:04 |
| dtantsur | same for text :( | 14:04 |
| TheJulia | yup | 14:04 |
| dtantsur | then we probably need to shrink the field | 14:04 |
| TheJulia | yeah | 14:04 |
| rpittau | bye everyone, have a great weekend! o/ | 14:04 |
| dtantsur | c u rpittau | 14:04 |
| * TheJulia notes rpittau is rightfully running away from db discussions :) | 14:04 | |
| * TheJulia seriously needs to go be on time for her appointment | 14:05 | |
| dtantsur | sorry for holding you :) | 14:05 |
| TheJulia | odds on 2 or more vaccines today?! | 14:05 |
| dtantsur | Oo | 14:05 |
| * TheJulia guesses monkeypox and covid bivalent | 14:06 | |
| ajya | mraineri: when you have a time, can you take a look at my comment here - https://review.opendev.org/c/openstack/sushy/+/856597/9#message-8fed241b28280cd93b65023f8d00383a609f94c6 Is there a generic way how to tell which property is modifiable on active resource, which on settings? cc janders | 14:07 |
| dtantsur | TheJulia: you have both of these available already? wow | 14:09 |
| * dtantsur is still unsure if he gets a covid one before x-mas holidays.. | 14:10 | |
| TheJulia | We have a monkey pox outbreak locally | 14:14 |
| dtantsur | ouch | 14:15 |
| JayF | TheJulia: rpittau: 'releases are cheap' is basically 99.99% of my reasoning for releasing bugfix branches. We've all done hard work to backport stuff there, and it's worth it even if only one or two users pulls the update | 14:28 |
| * TheJulia somehow obtained coffee hot enough to burn the sun | 14:32 | |
| JayF | TheJulia: I'd take that over this defective jelly donut | 14:33 |
| JayF | TheJulia: literally only filled in like, 1/3rd of the donut | 14:33 |
| TheJulia | Sadness :( | 14:33 |
| JayF | it's okay tbh the donuts are tasty enough w/o the filling. benefit of local places | 14:33 |
| TheJulia | That is always a benefit | 14:37 |
| dtantsur | JayF: keep in mind that bugfix releases (the last time I checked) were done manually by the release team | 14:40 |
| JayF | dtantsur: if it's not free/cheap, that's absolutely a factor I'm unaware of and will be more judicious | 14:40 |
| JayF | But like, if we're going to push bugfix releases to pypi, with some amount of patch support, we need to push patch releases there too | 14:40 |
| dtantsur | it's not a huge deal, but it does involve a living person doing `git tag/git push` | 14:41 |
| JayF | I'm sorta ok with "bugfix releases are always em-style branches" or "bugfix releases are released to pypi infrequently" but just tossing one out there and leaving it from then on seems crummy :( | 14:41 |
| JayF | but again, I don't think we have the insights to know if literally any humans at all are consuming those releases | 14:41 |
| JayF | which is unfortunate | 14:42 |
| dtantsur | I think they're em-style in my brain | 14:42 |
| dtantsur | but I'm open to changing that | 14:42 |
| dtantsur | yea... | 14:42 |
| JayF | we should document that and not ever release it if we go that route | 14:42 |
| dtantsur | we in OCP consume branches, nto releases | 14:42 |
| JayF | the in between is mainly what's uncomfy | 14:42 |
| dtantsur | I don't think we've done any bugfix branch releases in a while | 14:42 |
| dtantsur | I did a few in the very beginning, then stopped | 14:43 |
| JayF | that's exactly my motivation for doing it :D | 14:43 |
| JayF | and for stable branches too, plus it lets me know what the process is. I wouldn't hate getting on some kind of cadence for that ... tbh not neccessarily as a project, but like for me-personally pushing releases, because I'm not good at things on a "when needed" cadence vs some form of regularity | 14:43 |
| dtantsur | we already decide on a feature release cadence, we can also decide how often we do releases from all branches | 14:44 |
| TheJulia | The fact a human has to do it really means that the tooling needs to be fixed | 14:44 |
| dtantsur | (with out-of-order releases possible too, esp. for libs) | 14:44 |
| JayF | dtantsur: Can you clarify what you mean by that? | 14:45 |
| dtantsur | Fixing tooling ++, but since we're the only team doing bugfix branches.. yeah | 14:45 |
| dtantsur | JayF: we do feature releases every 2 months, right? | 14:45 |
| JayF | that is not documented in the process, even if it was practice | 14:45 |
| dtantsur | this is documented, actually | 14:45 |
| * JayF finds and re-reads the release cadence docs | 14:46 | |
| dtantsur | https://specs.openstack.org/openstack/ironic-specs/specs/approved/new-release-model.html#releasing | 14:46 |
| dtantsur | says exactly this | 14:46 |
| dtantsur | JayF: ^^ | 14:46 |
| JayF | > They are also released on a regular cadence as opposed to on-demand, namely three times a release cycle (roughly a release every 2 months). | 14:46 |
| JayF | Yep, you're 100% right | 14:46 |
| JayF | It's just awkward b/c with that kind of cadence, it's not the kind of release I'd expect to get "stable" support | 14:46 |
| JayF | but because our contributors care about them getting stable support, we do it | 14:46 |
| dtantsur | yeah, for me bugfix branches are more of an opportunity to collaborate rather than a firm support commitment | 14:47 |
| dtantsur | kinds of what em is | 14:47 |
| dtantsur | (I'm ready to change this position if we decide to as a team) | 14:47 |
| JayF | Yeah, I just hate the idea that there's a 22.0 release out there, on pypi, that if installed is missing months of fixes | 14:48 |
| JayF | s/22/21/ | 14:48 |
| dtantsur | it's not unheard of, when projects (outside of OpenStack) declare some releases as LTS/whatever, while some only receive limited support | 14:49 |
| dtantsur | I wish pypi had some metadata for that | 14:49 |
| JayF | the thing that is weird for me is that these *are effectively* LTS releases | 14:49 |
| dtantsur | wdym? | 14:49 |
| JayF | we're just ducking actually pushing the long term supported bits as patch releases | 14:49 |
| dtantsur | well... we also have 2 types of "long" :) | 14:49 |
| dtantsur | Train has been supported for how much now? I don't think any bugfix branch will survive that long. | 14:50 |
| JayF | I sure as hell hope not lol | 14:50 |
| JayF | but also like, an intermediate release getting 18-24 months of backported bugfixes is kinda awesome | 14:50 |
| JayF | we're doing lots of cool work maintaining the stable branches and mostly they are hidden under a rock | 14:51 |
| JayF | (keeping it under our red-hat? lol) | 14:51 |
| dtantsur | there is also https://specs.openstack.org/openstack/ironic-specs/specs/approved/new-release-model.html#support-phases, but I don't think we really comply with that | 14:51 |
| dtantsur | heh | 14:51 |
| JayF | dtantsur: METRICS! https://pepy.tech/project/ironic?versions=21.0.0 | 15:34 |
| JayF | I knew they had to exist somewhere if I could find out how | 15:35 |
| JayF | lol | 15:35 |
| dtantsur | Wow, interesting! | 15:35 |
| dtantsur | won't account downstream packaging and tarballs.o.o, but this is a start | 15:35 |
| JayF | I mean, when I think about a release, I primarily think about pypi | 15:36 |
| JayF | because frankly: 1) downstream packagers pull from git 2) tarballs.o.o customers would have to take explicit steps to upgrade (it's not "free") | 15:36 |
| dtantsur | #1 is not 100% correct | 15:36 |
| JayF | Interesting, does metal3 pull from pypi or something? | 15:36 |
| dtantsur | RDO master packaging pulls from git, RDO releases use tarballs.o.o | 15:36 |
| dtantsur | metal3 upstream uses RDO packages then | 15:37 |
| JayF | Interesting. I had no idea. | 15:37 |
| JayF | I've literally *never* worked anywhere that deployed ironic out of anything but git | 15:37 |
| JayF | probably just a matter of the scale of environment I've worked in | 15:37 |
| JayF | either way I think that says "nonzero numbers of people are using this" | 15:37 |
| JayF | I'm going to ask $SmartPeopleITrust if pypi has like, a noise level in the stats | 15:37 |
| dtantsur | e.g. https://github.com/rdo-packages/ironic-distgit/blob/rpm-master/openstack-ironic.spec#L16 | 15:37 |
| JayF | e.g. if ~1000/day could be just bot noise | 15:38 |
| dtantsur | a good question | 15:38 |
| JayF | Ah, the 1000/day is *all versions*, that stat doesn't change with filtering | 15:41 |
| JayF | looks like we've got hundreds/week still for bugfix/2* releases in openstack/ironic | 15:41 |
| JayF | I am going to like, aggregate this data | 15:42 |
| JayF | Plug our bugfix releases in the Zed announcement with numbers about downloads :) | 15:42 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic stable/yoga: Prevent clear_job_queue and reset_idrac failures on older iDRACs https://review.opendev.org/c/openstack/ironic/+/859915 | 16:02 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic bugfix/20.2: Prevent clear_job_queue and reset_idrac failures on older iDRACs https://review.opendev.org/c/openstack/ironic/+/859916 | 16:03 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic bugfix/20.0: Prevent clear_job_queue and reset_idrac failures on older iDRACs https://review.opendev.org/c/openstack/ironic/+/859917 | 16:03 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic bugfix/19.0: Prevent clear_job_queue and reset_idrac failures on older iDRACs https://review.opendev.org/c/openstack/ironic/+/859918 | 16:04 |
| dtantsur | janders: ^^^ for https://issues.redhat.com/browse/OCPBUGS-1740 | 16:04 |
| JayF | I'll put approvals on them, reviewed the first and it looked good, just gotta check the rest | 16:05 |
| dtantsur | thx! | 16:06 |
| JayF | (+2 not +A, wrong worD) | 16:06 |
| JayF | actually, backported by core | 16:06 |
| JayF | I'll +a the first one | 16:06 |
| JayF | dtantsur: I don't see bugfix/20.0 on our list of branches on whiteboard | 16:07 |
| JayF | dtantsur: I really, really hope that's not in use because I've not backported a single patch of the stuff I've backported there | 16:07 |
| dtantsur | possibly, I don't remember it by heart. feel free to abandon with a comment | 16:07 |
| JayF | ack okay you had me worried lol | 16:07 |
| dtantsur | 20.0 is not something we use at least | 16:08 |
| JayF | yeah, not 20.0 | 16:08 |
| JayF | I made that part of the whiteboard more useful for backporting btw | 16:08 |
| JayF | by putting the stable/ branches in there | 16:08 |
| dtantsur | ++ | 16:08 |
| JayF | so we have a reference of literally "go down this list to backport" | 16:08 |
| jm1 | dtantsur: hello :) if you have some time please review https://review.opendev.org/c/openstack/bifrost/+/859984 | 17:23 |
| dtantsur | looking | 17:24 |
| dtantsur | jm1: this lgtm, but on a related note.. I'm not sure how I feel about no longer returning NICs from node_info | 17:27 |
| dtantsur | jm1: isn't it sorta weird that we accept nics when creating a node but don't return them? | 17:27 |
| jm1 | dtantsur: you should feel good because the module only fetches what you ask for ;) | 17:27 |
| dtantsur | so, can I ask for nics? | 17:28 |
| dtantsur | (it's also a bit unfortunately that we called them "nics".. and now have port_info) | 17:29 |
| dtantsur | jm1: ^^ | 17:29 |
| jm1 | dtantsur: aoc modules are thin wrappers around openstacksdk funtionality. node calls register_machine which has a nics parameter but it does returns a Node object only. | 17:31 |
| dtantsur | sigh. we're quite inconsistent indeed. | 17:31 |
| jm1 | dtantsur: imho any "extra" functionality which does not involve calling openstacksdk functions should moved from aoc modules to openstacksdk or dropped if redundant. calling port_info is much more efficient than proactively enumerating all ports inside node module. the patch for bifrost is so straight forward, backward compatible and simple that imho its worth to do it: https://review.opendev.org/c/openstack/bifrost/+/859430/ | 17:34 |
| dtantsur | yeah, I wish Ironic could return ports as part of the node (optionally) | 17:36 |
| dtantsur | jm1: do we have any prior art? like extra_specs or flavors on servers? | 17:36 |
| jm1 | dtantsur: you mean like a flag which you could pass to a module to ask for extra info such as nics? nope | 17:37 |
| jm1 | dtantsur: at least not that i am aware of. but who knows what strange behaviour those not-yet-ported modules have ;) | 17:37 |
| dtantsur | yeah, I seem to remember some logic around it | 17:38 |
| jm1 | dtantsur: some modules had similar functionality where a module would enrich the output from the sdk. but as in this case it would happen always and it also was a *_info module, but i cannot remember which.. anyway, we dropped that part for the same reason. wont scale, user did not ask for it and if user really wanted it he would and should use the appropriate module | 17:40 |
| jm1 | dtantsur: or do you want to return nics inside Node object when register_machine is called? | 17:51 |
| dtantsur | jm1: this is probably a good idea, but the SDK's Node object doesn't account for it | 17:52 |
| jm1 | dtantsur: we have a couple of resource objects in openstacksdk which have special fields which are not always filled, only on special occasions like what you want to do with nics. one example is public_v4/public_v6/interface_ip fields in openstacksdk's Server object | 17:53 |
| jm1 | dtantsur: aoc modules will happily return whatever openstacksdk returns, so when you pass gtema's review, it will be in aoc as well ;) | 17:54 |
| dtantsur | :) | 17:54 |
| jm1 | dtantsur: but honestly i like ironic's (and thus openstacksdk's) clear distinction in Node and Port. baremetal_node's nics parameter looks like a relict from the past, much like nics parameter from server module. the latter can be really confusing because it not always does what one expects. | 17:59 |
| dtantsur | creating nics together with the node has an important role: cleaning cannot succeed without ports | 17:59 |
| jm1 | dtantsur: sure, but then why isnt it implemented in ironic itself? | 18:00 |
| dtantsur | jm1: ironic has more enrollment steps than the collection exposes | 18:01 |
| dtantsur | you see, ironic itself is not declarative | 18:01 |
| jm1 | dtantsur: "cleaning cannot succeed without ports" << implementing such a sensitive operation on clientside seems odd. if client looses connection then what? | 18:04 |
| dtantsur | jm1: what register_machine does is: 1) enroll a node, 2) enroll ports, 3) ensure the node is available for deploy | 18:05 |
| dtantsur | #3 includes cleaning. if #2 fails, it does not happen | 18:05 |
| jm1 | dtantsur: the reason i am wondering why ironic does not accept a nics/networks/whatever paramter is that Nova does exactly that: The server creation api accepts a networks parameter which will attach a server to networks and will create ports. | 18:10 |
| dtantsur | ironic's workflow is much more complex | 18:10 |
| dtantsur | the server creating IS also the server deployment | 18:10 |
| dtantsur | it's not the case for bare metal | 18:11 |
| jm1 | dtantsur: yeah i might got the wrong impression when looking at the sdk logic for register_machine | 18:17 |
| dtantsur | okay folks, time to enjoy the Friday evening | 18:24 |
| dtantsur | have a good weekend, see you on Tuesday | 18:24 |
| jm1 | dtantsur: ah damn, i just had a good idea. have a nice weekend! | 18:27 |
| dtantsur | sorry, half past eight here already :) | 18:27 |
| jm1 | dtantsur: same here ;) | 18:27 |
| dtantsur | then go open a beer, you deserved it! | 18:27 |
| * dtantsur slowly blends with the background | 18:28 | |
| jm1 | dtantsur: just wanted to write it down, we can think about it next weekend: inside register_machine you already have a list of ports, so you could simply replace the "ports" attribute of the node returned by register_machine with the real Port resource objects https://opendev.org/openstack/openstacksdk/src/commit/13117610fe7a6e39f2b01d93c3ea556aa83a5d85/openstack/cloud/_baremetal.py#L255 | 18:29 |
| jm1 | dtantsur: no need for a new "nics" field. it would simply move the functionality from the module to register_machine but without the additional api calls | 18:29 |
| jm1 | dtantsur: now have a good weekend ,) | 18:30 |
| opendevreview | Julia Kreger proposed openstack/ironic master: Add upgrade check warning for Allocation.name field https://review.opendev.org/c/openstack/ironic/+/860026 | 18:49 |
| opendevreview | Julia Kreger proposed openstack/ironic master: Change allocations name length check to an upgrade failure https://review.opendev.org/c/openstack/ironic/+/860027 | 18:49 |
| TheJulia | I'll figure out how to do the shortening of the field next week | 18:51 |
| TheJulia | Thanks Dave Neary, I'm craving pie now. | 18:51 |
| opendevreview | Merged openstack/ironic bugfix/20.2: Prevent clear_job_queue and reset_idrac failures on older iDRACs https://review.opendev.org/c/openstack/ironic/+/859916 | 18:56 |
| JayF | going to land that to yoga | 18:57 |
| JayF | So I ran the numbers via the pypi stats->bigquery interface; we have had 6196 downloads of the zed-based bugfix releases | 18:59 |
| JayF | (21.0.0 and 20.2.0) | 18:59 |
| ashinclouds[m] | Wow, not bad | 18:59 |
| JayF | I'm going to call it 6200 in my slides | 19:00 |
| JayF | if I need to, I can pip install it 4 times in a venv ;) | 19:00 |
| JayF | Do we know what releases of metal3/rdo included Ironic bugfix releases? Would be neat to call them out that way as well | 19:02 |
| TheJulia | not off the top of my head | 19:05 |
| iurygregory | afaik metal3 will push the latest rpm available | 19:05 |
| JayF | ack so not really like, a number I could point to in that slide | 19:05 |
| iurygregory | https://github.com/metal3-io/ironic-image/ | 19:05 |
| JayF | I have an "Ironic Zed - by the numbers" slide in the highlights thing | 19:06 |
| JayF | so trying to come up with interesting things to point out (the pypi numbers are going in that, to give me a chance to plug our intermeidate bugfix releases) | 19:06 |
| JayF | and I think our integration with other non-openstack projects is a cool, unique-to-ironic thing | 19:06 |
| * TheJulia cries that instacart's website seems to be unhappy | 19:12 | |
| opendevreview | Merged openstack/ironic stable/yoga: Prevent clear_job_queue and reset_idrac failures on older iDRACs https://review.opendev.org/c/openstack/ironic/+/859915 | 20:56 |
| opendevreview | Merged openstack/ironic bugfix/19.0: Prevent clear_job_queue and reset_idrac failures on older iDRACs https://review.opendev.org/c/openstack/ironic/+/859918 | 22:17 |
| JayF | dtantsur: janders: I landed those drac fixes while you all slept; hope the user is fixed and happy o/ | 22:25 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!