Earlier  
Posted Nick Remark
#openstack-nova - 2024-11-20
15:17:51 sean-k-mooney ildikov: https://docs.openstack.org/nova/latest/contributor/process.html#why-do-we-have-priorities is where we discuss priorities but we have nto enforced them for some time
15:18:21 sean-k-mooney this was the section we added most recently https://docs.openstack.org/nova/latest/contributor/process.html#what-the-review-priority-label-in-gerrit-are-use-for
15:19:03 sean-k-mooney to document how to sue review priority label but bauzas proposed a diffent way to do it via etherpads last cycle which has more or less replaced it
15:19:28 sean-k-mooney we also have old documetion of the runwasy system we used before that https://docs.openstack.org/nova/latest/contributor/process.html#runways
15:19:59 sean-k-mooney ildikov: so i can see why it might be confusitn since we still have to docs for the previous ways of working
15:20:34 sean-k-mooney ildikov: this is somthing that is continuiously evloving as we try thigns for a release or two and then try somethign new
15:21:29 sean-k-mooney so nova has a lot of docs on this topic already but most have not been updated for a few releases
15:22:21 sean-k-mooney ildikov: that partly why i tough the fedback toward nova was rather unfare in the ptg discussions
15:23:25 sean-k-mooney ildikov: it seamed to ignroe all of the existing doc we had and the efforts we had made to make it transparent
16:06:56 dansmith melwitt: okay I see, it's being echoed once because of the manage_output=$() and once for the [[ $manage_output =~ SUCCESS ]]
16:08:37 dansmith melwitt: so it might be better to do this:
16:08:49 dansmith nova_manage blah | tee /tmp/output
16:08:57 dansmith if grep SUCCESS /tmp/output;
16:09:24 dansmith so we get one copy
16:10:05 melwitt the job output is so hard to parse for me :( ok, I'll try that
16:10:06 dansmith also I just realized you're not checking the return code and just looking for the SUCCESS, but a script will be using the former, so we should probably as well yeah?
16:10:59 dansmith yeah I want the job output to be easier to read for sure and not stuffing large multi-line outputs into vars will help I think
16:12:27 melwitt yeah that would work, originally I didn't have it returning non zero for the warning case and I didn't think to change it
16:12:29 melwitt I'll do that also
18:52:22 ildikov sean-k-mooney: thank you for sharing all the links, and some details on how the documentation has been evolving
18:57:25 ildikov sean-k-mooney: I'm sorry the feedback towards the documentation felt unfair. It seems like there might be a challenge for newcomers and casual contributors to find their ways around the currently existing docs, where the disconnect might be.
18:59:13 ildikov sean-k-mooney: You mentioned that some of the docs haven't been updated in a while now. Which parts of the docs should be updated or removed, if any, to accurately reflect how the Nova team works today?
19:13:49 opendevreview melanie witt proposed openstack/nova master: nova-manage: Add flavor scanning to migrate_to_unified_limits https://review.opendev.org/c/openstack/nova/+/924110
19:23:48 melwitt sean-k-mooney: you are fast :)
19:25:47 sean-k-mooney i happend ot be doing my "finsih the day be going through my emails" routine when the notificaoin came in
19:26:22 melwitt woohoo
19:28:58 sean-k-mooney ill try and review the second patch again tomorrow
19:29:18 melwitt cool, thank you
19:30:01 sean-k-mooney i have an older veriosn checked out in one... of my devstack vms
19:30:22 sean-k-mooney i might see if i can try enabeling it and test the basics
19:30:58 melwitt the more testing the better :)
19:33:01 melwitt I realized it wouldn't be the right thing to validate resource classes (for quotas) in init_host() bc that's a nova-compute thing and the quota checking happens in nova-api and nova-conductor. so I'm looking for a similar spot I can add the validation for startup
19:39:43 melwitt oh derp, init_host() can be added for any service I see now
19:41:12 melwitt nova-api needs to be different though bc it won't go through nova.service I don't think
19:44:05 melwitt ok the wsgi app does use a nova Service but calls only Service.create()
19:45:26 sean-k-mooney it does not enven need to be init_host
19:45:46 sean-k-mooney we just need a early point to hook after the config is parsrced
19:45:56 sean-k-mooney so the post start hook woudl work too
19:47:30 sean-k-mooney actully pre_start_hook would work too
19:47:42 sean-k-mooney but ya init_host is my go too
19:50:34 sean-k-mooney melwitt: if your feellign laze it technially could go in __init__ https://github.com/openstack/nova/blob/e8a544f0e1134a4b260720cc634ad1997f936d6d/nova/manager.py#L92 but ya init_host or pre_start_hook are proably better
19:52:15 melwitt sean-k-mooney: I think the nova-api wsgi app doesn't go through init_host or pre_start_hook bc it doesn't call Service.start(). so that has to either be done differently or go into __init__ or Service.create
19:53:41 sean-k-mooney is that true... it might be i tough it was common but you might be right
19:53:57 sean-k-mooney i didnt think the manager part changed between the too
19:54:02 dansmith I'm quite sure melwitt is right here
19:54:13 dansmith there's really no service lifecycle for it under wsgi
19:54:26 sean-k-mooney sure but this is not part of the service
19:54:33 sean-k-mooney its part of the manager
19:54:33 melwitt sean-k-mooney: I was looking at this https://github.com/openstack/nova/blob/master/nova/api/openstack/wsgi_app.py#L52
19:54:50 sean-k-mooney the service calls it but init_host is a methond on the manager
19:55:07 dansmith called by the service stuff though I think
19:55:35 melwitt nova-api has no manager, no?
19:56:31 sean-k-mooney sshhh with you logic and correctness
19:56:45 sean-k-mooney your right it does not
19:56:46 melwitt 😂
19:56:56 melwitt I'm wrong most of the time, so there's that
19:57:15 sean-k-mooney that has not been my expnce but if you say so
19:57:29 melwitt heh
19:58:00 sean-k-mooney taking a step back
19:58:09 sean-k-mooney we are just talking about validating the config right
19:58:18 melwitt right
19:58:25 sean-k-mooney does oslo allow ues to register a callback for that on the config opt
19:58:39 melwitt hm, dunno but I'll look
20:01:06 melwitt not seeing something like that in https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py
20:01:32 sean-k-mooney so i know we can define our own otp types
20:01:47 sean-k-mooney and for string we have the ablity to provide enum vlaues
20:02:50 melwitt we need dynamic enum (from os-resource-classes standard classes) and a regex for CUSTOM_stuff I think
20:03:52 sean-k-mooney well i was thinking of inheriting form listOpt
20:04:03 sean-k-mooney and just adding the validation
20:04:18 sean-k-mooney basically providing a limitListOPT class
20:05:23 melwitt ah ok
20:05:47 melwitt that sounds interesting. I'll check it out
20:06:40 sean-k-mooney looking at how its implemted fro string
20:06:43 sean-k-mooney https://github.com/openstack/oslo.config/blob/68cefad313bd03522e99b3de95f1786ebea45d4b/oslo_config/types.py#L68
20:07:05 sean-k-mooney when you create and isntance of the opt you can provide choices (for a enum) or a regex
20:07:18 sean-k-mooney and then the __call__ method actully does the validation
20:07:37 melwitt that's cool
20:07:39 sean-k-mooney and raise a valueError if it invalid
20:07:47 sean-k-mooney https://github.com/openstack/oslo.config/blob/68cefad313bd03522e99b3de95f1786ebea45d4b/oslo_config/types.py#L141-L170
20:09:02 sean-k-mooney so if you inherited form List your call could call super which would provide a list and you could just loop over all the values and check if they were valid
20:09:14 sean-k-mooney if yes just return the result form the call to super else rais
20:09:37 sean-k-mooney melwitt: im not sure if that is overkill but its doable
20:10:49 sean-k-mooney and it keeps the valdiation in teh config code so thats nice cause it will work for the api the same as everything else
20:11:00 sean-k-mooney anyway o/
20:11:05 melwitt we could show off pro level oslo.config usage
20:11:39 melwitt thanks for the ideas. seeya tomorrow o/
20:56:16 frickler sean-k-mooney: sorry if I missed that in scrollback, but https://review.opendev.org/c/openstack/os-vif/+/935653 failed in gate with the error it is supposed to fix, iiuc you wanted to skip that check completely, then?
20:57:40 sean-k-mooney[m] ya i didnt get around to pushing a patch but i was going to make that test skip if the native driver was used
20:58:14 sean-k-mooney[m] i just finished dinner but i can update the patch to do that in a little bit
20:59:09 sean-k-mooney[m] we have 2 drivers ovs-vsctl and the nantive python on. its only the native one that sometimes times out
21:22:00 opendevreview sean mooney proposed openstack/os-vif master: address test stablity under load https://review.opendev.org/c/openstack/os-vif/+/935653
21:22:12 sean-k-mooney frickler: ^ updated to skip
21:22:48 sean-k-mooney the rest of the change is technially not needed but it does not hurt so i kept it
21:23:42 opendevreview Takashi Kajinami proposed openstack/os-vif master: Clean up Windows support https://review.opendev.org/c/openstack/os-vif/+/932436
21:24:37 sean-k-mooney i rebsased and reappoved ^ on top so hopefuly that will pass and we can merge both soon
21:27:15 frickler thx, will check for results tomorrow
21:44:18 opendevreview Cyril Roelandt proposed openstack/python-novaclient master: Replace glanceclient with openstacksdk https://review.opendev.org/c/openstack/python-novaclient/+/931276
21:54:18 opendevreview melanie witt proposed openstack/nova master: nova-manage: Add flavor scanning to migrate_to_unified_limits https://review.opendev.org/c/openstack/nova/+/924110
21:56:18 dansmith melwitt: why the most recent change?
21:56:23 dansmith did checking the rc not work?

Earlier   Later