Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-18
17:19:08 sean-k-mooney then added the auto tratis
17:19:27 sean-k-mooney we should be able to mark them second time around
17:19:33 efried "mark" how?
17:19:49 efried You're talking about adding a metadata field to the ProviderTree object or something?
17:20:10 dansmith efried: that's what I meant, but I'll leave it to you about what approach is best for that conflict resolution
17:20:12 sean-k-mooney we woudl still get the set form teh file and then the tree we pass into upt we embed a flag in each inventory
17:20:33 efried ugh, that seems overly complicated to me.
17:20:34 sean-k-mooney efried: yes but not one that need to ever leave nova
17:20:40 efried yeah, I get that
17:20:56 efried I would just hate to explode the compute service because of a cache bug.
17:21:17 efried maybe we take advantage of the init kwarg
17:21:21 efried and only do that check the first time through.
17:21:35 efried because that's the only time we're worried about it anyway.
17:21:38 dansmith as long as we don't re-load the yaml, that would be reasonable It hink
17:21:57 sean-k-mooney well the work flwo would be. get prov_tree from placement. generate tree from file. merge them and mark any that are common as from the file then pass it to the driver upt meethod
17:21:59 efried yeah, we're definitely only loading the yaml once.
17:22:10 efried otherwise the admin can blow up the compute service with a typo.
17:22:27 sean-k-mooney we would have to load it one each agent start
17:22:33 efried yes
17:23:01 sean-k-mooney we can keep the file in memroy bettwen update_resouce calls in the RT
17:23:06 efried yes
17:23:09 efried as an attr on the rt
17:23:14 sean-k-mooney sure
17:23:23 dansmith efried: yep
17:23:45 sean-k-mooney so on the second iterate we just mark anny inventory we get from placement that is in that cached tree as form_file
17:23:48 sean-k-mooney or whatever
17:24:44 sean-k-mooney if we did not want to blow up the virt drivers
17:25:03 sean-k-mooney we could actully remove thos nodes tepmproally before we pass the tree to the driver
17:25:08 sean-k-mooney and add them back after
17:26:01 sean-k-mooney that a liitle more complext then i would like but you would hate my other idea more
17:26:30 efried anyway, we're in implementation weeds here. Do y'all want to see this flow explicitly described in the spec or can we leave it vague-ish and sort it out in code?
17:26:52 dansmith I think some of it in the spec would be good so we don't re-have this convo
17:26:58 sean-k-mooney it would be nice to see it in the spec but ill leave that up to dan.
17:27:02 efried ack
17:27:31 sean-k-mooney efried: you could also summerise it to the mailing list? and then put the high level flow in the spec
17:42:29 sean-k-mooney dansmith: efried on a different topic are ye ok with backport this to stien. the low constratit for sqlalchemy on stable/stine is above teh version wehre that was depercated
17:42:40 sean-k-mooney https://review.opendev.org/#/c/664193/2
17:42:57 efried sean-k-mooney: I'm not stable fwiw
17:43:08 sean-k-mooney its not?
17:43:29 efried I'm saying, I can't +2 a backport
17:43:37 sean-k-mooney oh
17:43:45 efried What would the motivation be for backporting that?
17:43:49 sean-k-mooney no i just wanted to know if ye are ok with me proposing ths
17:44:06 efried just to reduce log noise?
17:44:28 sean-k-mooney well we backported it down stream becasue rhel8 uses a version of sqlacamy that is new the the upper constatine on stable/stine
17:44:53 sean-k-mooney so it was causing helping to cause the subunit parser explotion
17:45:00 sean-k-mooney in our downstream functional job
17:45:21 sean-k-mooney that was not enought to fix the job donwstream but was one of the noiser things
17:45:30 efried I confirm that sqla l-c in stein is above 0.8.0, so procedurally there's no reason not to do it.
17:45:40 efried https://opendev.org/openstack/nova/src/branch/stable/stein/lower-constraints.txt#L150
17:45:49 efried so sure, if it helps ya, I don't object.
17:45:52 efried But again, I can't +2 it.
17:46:13 sean-k-mooney sure but you are ptl so its still good to check with you.
17:46:21 efried :) thank you
17:47:01 openstackgerrit sean mooney proposed openstack/nova stable/stein: Replace joinedload_all with joinedload https://review.opendev.org/671532
17:47:17 sean-k-mooney ill leave it up to the stable cores to weight in ^
17:47:25 sean-k-mooney i can always abandon it
17:48:23 openstackgerrit Jim Rollenhagen proposed openstack/nova master: ironic: take over instances from down compute services https://review.opendev.org/671534
17:48:35 sean-k-mooney currently im hoping adding --suppress-attachments to our downstream tox job will fix the sub unit issue at least for now
17:49:12 sean-k-mooney that will skip the stdout and stderror for succesfful tests which grealy reduces the test output
17:49:22 sean-k-mooney but still give you all the output if a test fails
17:49:51 sean-k-mooney btu we dont know if that will be enough so suppressing deprecation warnings also helps
18:45:26 efried dansmith: does ironic hash ring reshuffle require compute restart?
18:45:32 dansmith efried: no
18:45:45 efried I guess that still works, though, since you've already parsed the file.
18:45:47 efried thx
18:45:52 dansmith yeah
18:46:02 efried but means we can't rely on the 'startup' arg
19:00:03 efried except
19:00:41 efried if one of the new ironic nodes has inventory in a RC we've been happily adding on at the behest of the providers.yaml
19:00:47 efried then we'll blow up the compute service.
19:01:18 dansmith meaning if someone provides CUSTOM_IRONIC_GOLD in providers.yaml?
19:01:32 efried yeah
19:01:49 efried well, isn't that a trait? Not worried about traits
19:01:57 efried RC is what we blow up on
19:01:59 dansmith yeah, that's going to be a hard case to reason about I guess, because ironic is re-using customs
19:02:01 dansmith no, it's an RC
19:02:01 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Replace "integrated-gate-py3" template with new "integrated-gate-storage" https://review.opendev.org/671551
19:02:04 efried okay
19:02:05 dansmith that's the whole point
19:02:09 dansmith so what about this:
19:02:38 dansmith if we're on init=true, we set any providers inventory that isn't already in the tree, and explode otherwise
19:02:43 efried I think I can swing the "don't error if identical" thing, it's just going to be a bit tricky because I have to ignore fields (like min_unit) that weren't in the config.
19:02:50 dansmith if we're init=false, we set any inventory that isn't already in the tree, but ignore/warn otherwise
19:03:12 efried that seems safer, anyway.
19:03:25 efried could do that regardless
20:13:13 openstackgerrit Eric Fried proposed openstack/nova-specs master: Spec: Provider config YAML file https://review.opendev.org/612497
20:13:26 efried dansmith, sean-k-mooney: ^
20:27:31 efried artom: that took me a while, but reviewed (CONF.my_ip warning)
20:28:50 artom efried, aha, thanks!
20:30:56 artom I did feel a bit weird about taking out a warning, I mean, it was added for a reason, right?
20:31:50 efried artom: I linked the reason
20:31:58 efried which looks like it was a legit reason... when it was an exception.
20:32:06 artom Exactly
20:32:08 efried But as a warning, not sure if it's really worthwhile or not.
20:32:17 artom When it turned into a warning, is it really useful?
20:32:26 efried I'm not sure
20:32:34 efried it depends how the cold migration failure manifests
20:32:54 efried if it's one of those things where it's really hard to figure out why it happened, unless you have this warning, then we might want to keep it around.
20:33:27 efried then again, are you really going to notice this warning waaay back in the logs while you're investigating your cold mig failure.

Earlier   Later