| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-18 | |||
| 17:16:17 | efried | yeah, or that, that could work. | |
| 17:16:25 | efried | um | |
| 17:16:28 | dansmith | just "isn't already defined or is exactly the same" | |
| 17:16:42 | efried | except "identical" needs to be forgiving of defaults | |
| 17:16:54 | efried | because my providers.yaml is allowed to give only "total" and let the other fields default. | |
| 17:17:04 | dansmith | it's already limited to CUSTOM_ so there wouldn't be any of those right? | |
| 17:17:08 | sean-k-mooney | is identical would require the virt driver to have the infor from the yaml to compare agaisnt | |
| 17:17:19 | cdent | good luck, gotta make dinner | |
| 17:17:19 | efried | default inventory values, like min_unit etc. | |
| 17:17:21 | dansmith | efried: oh I see, | |
| 17:17:23 | efried | o/ cdent | |
| 17:17:29 | sean-k-mooney | unless the virt driver kept a list of the invetores it managed and only looked at those | |
| 17:17:30 | dansmith | well, I'm sure you can work that out | |
| 17:17:35 | sean-k-mooney | cdent: o/ | |
| 17:17:40 | efried | sean-k-mooney: the virt driver does that | |
| 17:17:51 | dansmith | sean-k-mooney: I think what you mean is just mark in the provider tree where each thing came from | |
| 17:17:54 | sean-k-mooney | right so if it igores inventories not in that list | |
| 17:17:56 | dansmith | so we can check the origin | |
| 17:18:05 | efried | except "only looked at those" is what I'm saying *doesn't* work. | |
| 17:18:29 | sean-k-mooney | ya but we dont have an owner on the inventory to do that currently | |
| 17:18:32 | sean-k-mooney | or ever | |
| 17:18:33 | efried | because we're enforcing that providers.yaml is not allowed to muck with resources upt controls. | |
| 17:18:41 | sean-k-mooney | so we would have to determin that in the RT | |
| 17:18:51 | efried | yes | |
| 17:18:57 | sean-k-mooney | whci we could do if we updated form teh provder.yaml first | |
| 17:19:01 | sean-k-mooney | then called the virt dirver | |
| 17:19:07 | efried | not the second time around. | |
| 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 | |