| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-20 | |||
| 14:11:50 | sean-k-mooney | hehe well i would like to spend some time fixing some of thepci related move operations but ya | |
| 14:11:54 | gibi | and yes, technical dept removal is a good form of maintenance | |
| 14:12:14 | sean-k-mooney | ok ill update the spec to remove the trait and prefilter | |
| 14:12:24 | sean-k-mooney | and abandon the patches i submited for those | |
| 14:12:36 | gibi | sean-k-mooney: thanks | |
| 14:12:49 | sean-k-mooney | gibi: stephenfin was that the only outstanding question ye had | |
| 14:12:57 | stephenfin | yup, for me anyway | |
| 14:12:57 | sean-k-mooney | is so ill respin the spec now | |
| 14:13:07 | gibi | sean-k-mooney: nothing else from me on that sepc | |
| 14:13:08 | gibi | spec | |
| 14:13:22 | sean-k-mooney | ok thanks both of you. | |
| 14:14:17 | sean-k-mooney | gibi: your main concen with the port numa policies is the precidence right | |
| 14:14:55 | sean-k-mooney | ill poke other to review in our internal team meeting but should i add it to the adgenda for tomorrows | |
| 14:15:10 | sean-k-mooney | or maybe a ML post and ask for feedback there? | |
| 14:15:37 | gibi | sean-k-mooney: anything that puts more eyes on the spec from the perspective | |
| 14:15:55 | gibi | I think tomorrows agenda is a good idea | |
| 14:16:06 | gibi | if no objection there then I will upgrade my vote to +2 | |
| 14:16:55 | sean-k-mooney | thanks ok ill send a short mail to the list and say it to the redhat folk internally too and we can decied tomorrow | |
| 14:19:28 | nightmare_unreal | is there a reason why placement takes 1.0 api as default ? why it does not take latest like in nova | |
| 14:21:06 | sean-k-mooney | latest is a legacy thing for the nova client | |
| 14:21:59 | sean-k-mooney | latest also might not always do what you think it wont nessiarly do negociation | |
| 14:28:25 | nightmare_unreal | is there a way to specify/config that ? | |
| 14:30:22 | sean-k-mooney | so osc when you use latest just uses that latest version constnat in the nova_client lib | |
| 14:30:28 | sean-k-mooney | it does not negociatation | |
| 14:30:38 | sean-k-mooney | nova client if you dont specify a microverison negociates | |
| 14:31:00 | sean-k-mooney | if you explcitly use latest i dont no if it blindly uses it like osc or does negociation | |
| 14:31:31 | sean-k-mooney | at the api level i think its an alias for the latest microverion in nova | |
| 14:31:41 | sean-k-mooney | but that is not a stardard part of microverions | |
| 14:32:29 | sean-k-mooney | if you use latest the behavior will change between cloud or after upgrades so generally you sould not use it unless you are manually using clients to do something | |
| 14:32:43 | sean-k-mooney | e.g. if this is used in code somewhere you shoudl not use latest | |
| 14:33:02 | sean-k-mooney | you should use the minium microverion for the feature you are using | |
| 14:33:36 | sean-k-mooney | that is what nova and other service do internally when calling each other | |
| 14:36:37 | nightmare_unreal | I see | |
| 14:36:42 | nightmare_unreal | thanks for explanation | |
| 14:37:20 | sean-k-mooney | i assume you were using the openstack client when you said placment was defaulting to 1.0 | |
| 14:39:18 | sean-k-mooney | osc does not do microverion negocation to provide a stable striptable unifrom inteface. some plugins like ironic disagree with that philosocy and implemented negoication themselves but that was inteionally not done osc itself | |
| 14:40:06 | sean-k-mooney | the placment team did like the osc phioscophy so intentionlly did not implment microverion negociation in there placment plugin | |
| 14:45:47 | openstackgerrit | Lee Yarwood proposed openstack/nova-specs master: libvirt: Add support for flavor and image defined ephemeral encryption https://review.opendev.org/c/openstack/nova-specs/+/771474 | |
| 14:47:35 | gibi | hm, does somebody has an idea how can it be that a server in ERROR state does not have a fault field? http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22testtools.matchers._impl.MismatchError%3A%20'fault'%20not%20in%20%7B%5C%22 | |
| 14:49:55 | sean-k-mooney | um is it in cell0? | |
| 14:50:13 | sean-k-mooney | im not sure if the code path that lands you there would result in that but no | |
| 14:50:19 | sean-k-mooney | not of the top of my head | |
| 14:50:50 | sean-k-mooney | allthough you are looking at the unit/func tests? | |
| 14:50:55 | sean-k-mooney | so we might just not have mocked it right | |
| 14:51:43 | sean-k-mooney | in real code it maight always be set but in our unit test it might not due to incorrect mocking maybe? | |
| 14:52:01 | gibi | it is tempest | |
| 14:52:09 | sean-k-mooney | fyi ill be afk for a while but ill update the spec when i get back | |
| 14:52:16 | gibi | sean-k-mooney: ack | |
| 14:52:22 | sean-k-mooney | ah ok ya i guess using testtool makes sense there | |
| 14:53:14 | sean-k-mooney | oh needed to exted time frame so its the min bandwith tests | |
| 14:53:18 | sean-k-mooney | weird | |
| 14:53:44 | gibi | I see in the api log that fault is lazy loaded | |
| 14:53:48 | gibi | for this request | |
| 14:54:00 | gibi | so somehow the fault is missing in the db | |
| 15:12:49 | lyarwood | https://review.opendev.org/c/openstack/nova/+/754702/ - there's a first, subnode deployment failed but we still tried to run multinode tests | |
| 15:44:04 | kashyap | Unrelated ... TIL, Red Hat announced gratis RHEL (you can now run upto 16 production instances): https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-programs-easier-ways-access-rhel | |
| 15:44:35 | kashyap | lyarwood: --^ Wonder if that allows one to start testing w/ proper RHEL in the upstream CI | |
| 15:45:56 | lyarwood | kashyap: I wouldn't expect it would no | |
| 15:46:24 | lyarwood | kashyap: and in any case testing RHEL in master CI seems a little pointless if we have centOS streams | |
| 15:46:45 | kashyap | lyarwood: Ah, right; if we're testing w/ CentOS | |
| 15:46:56 | kashyap | ... Streams, it's indeed not worth it | |
| 15:47:13 | kashyap | I brought it up because some upstreams (like QEMU) will start using it now | |
| 15:48:12 | lyarwood | I'd like to introduce *some* centOS streams coverage into the Nova gate if at all possible but that's about it | |
| 15:51:43 | kashyap | lyarwood: Right; any non-trivial enterprise distro testing is upto relevant downstreams (as it's part of their value prop). | |
| 15:52:30 | kashyap | I, for one, would be happy if a Fedora job that is sustained w/o bit-rot. I don't care about CentOS or Streams, personally. | |
| 15:52:48 | lyarwood | we have that in the experimental queue | |
| 15:53:14 | lyarwood | but centOS is a supported distro unlike Fedora | |
| 15:53:27 | lyarwood | so I'd rather have it in the check and gate queues | |
| 15:54:26 | kashyap | lyarwood: Yeah; I know you did some work on that; and I use it occasionally. To which, I thank you! | |
| 15:54:43 | lyarwood | a few of us normally try to support the new fedora releases | |
| 15:54:54 | kashyap | You're saying CentOS as "supported" as in, LTS, I take it | |
| 15:55:05 | kashyap | lyarwood: Right; I did it in the past, and didn't do it after that. | |
| 15:55:19 | kashyap | I also know ianw++ does some tireless maint work | |
| 15:55:23 | sean-k-mooney | lyarwood: fedora is techniclaly not in the PTI | |
| 15:55:48 | sean-k-mooney | if your talking about devstack then its only partly supported | |
| 15:56:37 | sean-k-mooney | https://github.com/openstack/devstack/blob/master/doc/source/overview.rst#base-os | |
| 15:58:00 | kashyap | lyarwood: BTW, upstream libvirt tests CentOS7, 8, Streams, and a crap-ton of other distros: https://gitlab.com/libvirt/libvirt/-/pipelines/244260219 | |
| 15:58:41 | kashyap | It's at least good that they (including QEMU) test on RHEL; to catch regressions that can sneak in through rebases. | |
| 15:58:45 | sean-k-mooney | kashyap: by the way the previous developer licencing explcitly disallowed rhel | |
| 15:58:49 | kashyap | (And upper layers benefit from that.) | |
| 15:59:05 | lyarwood | sean-k-mooney: huh I was going on the runtimes for each release | |
| 15:59:07 | kashyap | sean-k-mooney: Yep; that's fixed now. The developer subscription is now far more useful. | |
| 15:59:37 | sean-k-mooney | lyarwood: fedora is not in the support runtime for any release | |
| 15:59:52 | sean-k-mooney | right now centos stream is not either technically | |
| 16:00:15 | sean-k-mooney | although i think that will change in the y release | |
| 16:00:27 | sean-k-mooney | i know rdo are moving to stream now | |
| 16:00:41 | sean-k-mooney | but technially that is not a supproted runtime | |
| 16:00:53 | lyarwood | yup I'd still like to move ahead with some centOS coverage of some form this cycle if possible | |
| 16:01:54 | sean-k-mooney | yes we could do that though we proably shoudl not use stream | |
| 16:02:17 | sean-k-mooney | at least until the offical runtime list is either ammened or next cycle | |
| 16:02:26 | lyarwood | yeah I'll just use whatever is in the base job from devstack/tempest (/me forgets which) | |
| 16:02:39 | sean-k-mooney | lyarwood: well both are avaiable | |
| 16:02:49 | sean-k-mooney | and i fixed the only stream issue earlier in the cycle | |
| 16:03:03 | sean-k-mooney | so we can use both if needed | |
| 16:03:15 | sean-k-mooney | its just up to use to choose the correct nodeset | |
| 16:03:41 | sean-k-mooney | kashyap: the limit on 16 instance basically means we cant use the "No-cost RHEL for small production workloads" clause | |
| 16:04:08 | kashyap | sean-k-mooney: What do you mean can't use? It is for CI/developer purposes | |
| 16:04:15 | kashyap | That's their intentional limit | |
| 16:04:30 | kashyap | sean-k-mooney: Many upstreams benefit from that | |
| 16:04:46 | kashyap | It is not supposed to solve every use case of every project. But for vast majority; this is a good move. | |