| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-18 | |||
| 17:08:47 | efried | So then this suggests a flow like: | |
| 17:08:48 | efried | 4) update_from_provider_tree (flush to placement) (as today) | |
| 17:08:48 | efried | 3) merge in providers.yaml stuff. (I think a second level of validation happens here, and fails the compute service if something is wrong -- that should only be possible the first time through, so we're not worried about the service dying after having been running for a while) | |
| 17:10:37 | efried | I'm not sure how to detect a conflict between a custom RC from upt and one from providers.yaml. | |
| 17:11:04 | sean-k-mooney | the validation of 3 might be as simple as make sure the intersection between the inventoires form each part of the merger is 0 | |
| 17:11:19 | efried | yeah, that's what I'm noodling | |
| 17:11:27 | sean-k-mooney | e.g. an invenotry is not defiend both the provider and virt driver trees | |
| 17:11:35 | efried | that puts a bit of extra onus on upt to make sure it doesn't "ignore resource classes it doesn't know about" | |
| 17:12:05 | efried | cause today we're careful to tell upt it must "ignore child providers it doesn't know about" | |
| 17:12:09 | sean-k-mooney | ya that is related to the general problem of shareign RP between service. | |
| 17:12:13 | efried | but I think that doesn't conflict. | |
| 17:12:15 | sean-k-mooney | which for now we have punted | |
| 17:12:20 | efried | yes | |
| 17:12:23 | cdent | we keep having discussions about things knowing about things, and that makes me anxious. how does anything know? | |
| 17:13:02 | efried | it's the virt driver's job to know about the hardware resources it has the ability to assign to VMs. | |
| 17:13:35 | sean-k-mooney | right ad the provider.yamls would know about resoce that are not assinged to the vm but are indrecly consumed by it | |
| 17:13:43 | sean-k-mooney | e.g power | |
| 17:14:05 | sean-k-mooney | or cache if the cache is affiend outside the virt dirver | |
| 17:14:21 | sean-k-mooney | which you can do with rmd or sysfs and a crons script | |
| 17:14:21 | dansmith | efried: the validation becomes "is CUSTOM_ and not already in the stuff I got from the virt driver" right? | |
| 17:14:56 | sean-k-mooney | dansmith: i would hope so. or at least not signifcatly more complex | |
| 17:15:10 | sean-k-mooney | the majority fo the validate would be done when parsing the file | |
| 17:15:13 | dansmith | yeah | |
| 17:15:17 | dansmith | yeah | |
| 17:15:29 | efried | dansmith: yes, the concern I had was with idempotency. The second time through, the provider_tree we hand to upt will already contain the CUSTOM_ RCs from the last iteration when we processed providers.yaml. So upt has to *remove* those, or we'll blow up when we process the providers.yaml blob the second time. | |
| 17:16:00 | dansmith | ah I see | |
| 17:16:06 | efried | if we think of upt's responsibility as simply "completely overwite the inventories for the providers I own" then it works. | |
| 17:16:07 | dansmith | maybe just not fail if they're identical? | |
| 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 | |