| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-22 | |||
| 18:03:04 | melwitt | jaypipes: more the latter. I'm not a heat expert, maybe there's a way to tell it to keep retrying a definition | |
| 18:03:29 | jaypipes | melwitt: yeah, I'm not a Heat expert either. | |
| 18:17:08 | cdent | jaypipes, melwitt: if want to play the odds, it is more likely that a "keep retrying orchestrator" (that actually does the job well) will come into existence if we do not include bad orchestration in nova. | |
| 18:17:36 | jaypipes | cdent: ++ | |
| 18:17:54 | cdent | it is also the case that the odds of "good orchestration" merging sooner (in nova) than something else trying to do it (outside of nova's constraints) are low | |
| 18:20:43 | melwitt | cdent: maybe. I'm not sure how many people would want to use an orchestrator-less system, but that works as long as no other viable options are available | |
| 18:21:37 | cdent | melwitt: Is what we have today orchestrator-less or bad-orchestrator? | |
| 18:22:25 | melwitt | cdent: bad-orchestrator | |
| 18:22:51 | cdent | as in makes a half hearted effort at retrying and then bails..., yeah? | |
| 18:23:23 | melwitt | yes | |
| 18:25:47 | jaypipes | dansmith: you were +2 previously. I'm good on https://review.openstack.org/#/c/460177/ now with bauzas' latest revision. | |
| 18:26:48 | melwitt | cdent: with the half hearted effort, an operators can detect a bad baremetal node and take it out of rotation without exposing end users to the fail. without it, the end user would have to suffer the failure at least once before the operator can take it out of rotation. unless the operator builds a porcelain API that maybe uses heat behind it and has end users point at that. is what I'm thinking | |
| 18:29:43 | melwitt | I can also see the point of, you can't serve everybody perfectly, and if it's really only 5% of people that would be affected, then I get that. we'll see what they say on the ML | |
| 18:35:38 | mriedem | melwitt: ok https://review.openstack.org/#/c/446239/ | |
| 18:35:44 | mriedem | melwitt: i didn't go through tests | |
| 18:36:38 | melwitt | mriedem: thanks. reading through | |
| 18:38:56 | mriedem | i have successfully finished a 60+ ounce bag of tootsie rolls from halloween | |
| 18:39:02 | mriedem | it was a grind, but it's done | |
| 18:40:47 | cdent | my jaw hurts now | |
| 18:54:07 | jaypipes | melwitt: hmm, I wonder if some combination of beer and cat toys will be enough to bribe your James into my worldview... | |
| 18:55:47 | mriedem | jaypipes: not until you can chug a beer faster than him | |
| 18:56:04 | mriedem | which from fenway we know isn't going to happen without proper training with a montage | |
| 18:56:52 | melwitt | heh | |
| 19:02:12 | melwitt | mriedem: replied on quotas | |
| 19:18:09 | cdent | mriedem, jaypipes, melwitt, dansmith: Does the idea that was bounced around on the call of claim in the scheduler, re-claim (when things are bad) in the conductor address the issues james is pointing out? Trying to clarify my confused brain. | |
| 19:18:42 | mriedem | cdent: yes and is what we discussed in boston | |
| 19:19:08 | mriedem | super conductor passes alternate hosts to the cell; if something fails, we reschedule via conductor within the cell using those alternate hosts | |
| 19:19:10 | cdent | i knew that the boston plan did, but wasn't clear on if the claim from two different places idea did | |
| 19:19:20 | cdent | gotchya, thanks | |
| 19:19:44 | mriedem | claiming in two places has the same long-term functionality if we have to retry within a cell | |
| 19:20:26 | mriedem | i think the idea of doing claims in the scheduler AND conductor is if we do it in the scheduler, we have (a) tighter retry loop and (b) if we eventually drop reschedules in the cell, then we've already got the work done in the scheduler - as dan pointed out on the call | |
| 19:20:26 | cdent | I think I'm leaning that way because of the "claim as early as possible" stuff I mentioned in one of my comments | |
| 19:20:30 | mriedem | the short-term downside is you have duplication | |
| 19:21:01 | mriedem | i do'nt really see how that's not hidden in the scheduler report client though | |
| 19:21:07 | cdent | DRY is what breeds and deeply nested object hierarchies and that makes me cry | |
| 19:21:10 | mriedem | or some utility method shared between conductor and scheduler | |
| 19:21:13 | cdent | yes | |
| 19:22:38 | cdent | woot! I managed a whole 4 things off my to do list today. That's less than 4%. ossum. | |
| 19:22:54 | cdent | goodnight | |
| 19:23:08 | mriedem | melwitt: did you give up halfway? | |
| 19:23:34 | melwitt | mriedem: did I miss some comments? I didn't mean to | |
| 19:23:47 | melwitt | argh, sorry | |
| 19:27:40 | larsks | Howdy. I have an instance that is attached both ipv4 and ipv6 networks. The ipv4 networks show up in network_data.json on the config drive, but there is no trace of the ipv6 network. I see the same thing with a single network that has both ipv4 and ipv6 subnets...only the ipv4 information shows up. What could be causing this? | |
| 19:33:39 | dansmith | mriedem: I may be remembering wrong, but wasn't there a thing in the last six months or something about us not including ipv6 stuff in network.json in certain circumstances? re ^ | |
| 19:33:54 | fungi | larsks: that's a known issue. i gather there's an open bug, mailing list thread and proposed change(s) addressing it, though i don't have references handy at the moment | |
| 19:34:40 | mriedem | dansmith: i vaguely remember sdague and jaypipes reviewing something in there recently, but don't know if it was for this | |
| 19:35:12 | larsks | fungi: thanks. do you happen to know in which release it should work right now? E.g. was this a regression in ocata or master or something? | |
| 19:35:23 | larsks | And would I expect it to work in release N-1? | |
| 19:35:43 | mriedem | https://github.com/openstack/nova/commit/ccebded0cbb654be18db5b4e0e7f8b8a3a7cacdb ? | |
| 19:35:58 | mriedem | ^ is what i was thinking of | |
| 19:36:02 | mriedem | but does'nt look like the right thing | |
| 19:36:39 | larsks | Hmmm, I found https://bugs.launchpad.net/nova/+bug/1514082 which suggests this is just a configuration issue. | |
| 19:36:39 | openstack | Launchpad bug 1514082 in OpenStack Compute (nova) "network_data.json does not provide information about ipv6 addresses." [Undecided,Invalid] | |
| 19:38:46 | fungi | larsks: on another channel, clarkb pointed me to bug 1676363 | |
| 19:38:46 | openstack | bug 1676363 in OpenStack Compute (nova) "The network metadata should be more useful" [Medium,In progress] https://launchpad.net/bugs/1676363 - Assigned to Dan Peschman (dpeschman) | |
| 19:39:04 | mriedem | dansmith: why do we need with instance.obj_alternate_context on https://review.openstack.org/#/c/458634/12/nova/compute/api.py@1802 ? | |
| 19:39:05 | fungi | larsks: related ml thread starts at http://lists.openstack.org/pipermail/openstack-dev/2017-March/114563.html | |
| 19:39:15 | larsks | fungi: thanks for both pointers. I like the bug title. I'm going to see if it was just a config issue. | |
| 19:40:05 | dansmith | mriedem: because the instance has the ctxt inside not the cctxt | |
| 19:40:42 | dansmith | mriedem: well, actually, maybe not there I guess | |
| 19:40:58 | dansmith | mriedem: might be able to remove that one I guess | |
| 19:41:05 | mriedem | hold up | |
| 19:41:08 | mriedem | still going through this | |
| 19:41:53 | dansmith | I need food anyway | |
| 19:43:09 | mriedem | this is probably tied to get_instance stashing the targeted context on the instance object | |
| 19:43:17 | mriedem | that's probably something that deserves a comment in the code then | |
| 19:49:12 | jaypipes | mriedem: and it's that "get me alternate hosts" thing that I am really against. | |
| 19:49:24 | jaypipes | mriedem: in the conductor that is.. | |
| 19:52:09 | bauzas | sorry folks, was afk for dinner purposes | |
| 19:52:51 | jaypipes | dansmith: the diaper exception. nice. | |
| 19:53:36 | dansmith | jaypipes: that | |
| 19:53:48 | melwitt | mriedem: replied to the rest of the comments | |
| 19:53:49 | dansmith | is definitely not my term, but someone used it around me recently and I made note to use it again | |
| 19:54:22 | bauzas | jaypipes: dansmith: unfortunatly, I think it's related to the thread mriedem created about the pendulum switching | |
| 19:54:41 | bauzas | ie. should nova be tolerant to misconfig? | |
| 19:55:11 | bauzas | if we assume the answer be no, then I agree, case c) is probably not worth it for rescheduling | |
| 19:55:56 | mriedem | bauzas: that's not really why i started that thread | |
| 19:56:04 | bauzas | mriedem: that I know | |
| 19:56:10 | bauzas | mriedem: but I think the outcome is related | |
| 19:57:16 | mriedem | i think eventually disabling reschedules by default will make things that cause (c) to get exposed more clearly so that we can determine if they are things we should reschedule on, or handle as just bug fixes, i.e. some race we can handle | |
| 19:57:40 | mriedem | but it's a wild west of who knows | |
| 19:57:46 | bauzas | yup | |
| 19:57:51 | mriedem | b/c it's python and anything raised up from below goes in there | |
| 19:58:27 | mriedem | dansmith: left some comments/questions in https://review.openstack.org/#/c/458634/ | |
| 19:58:34 | dansmith | mriedem: thanks | |
| 19:58:36 | mriedem | dansmith: am i correct in stating that's all prep work for the next change in the series? | |
| 20:00:19 | mriedem | melwitt: ok looking | |
| 20:01:04 | bauzas | mriedem: dansmith: mmm, that https://review.openstack.org/#/c/458634/ is something I wondered when I was looking at my branch | |
| 20:02:00 | bauzas | mriedem: dansmith: correct me if I'm misunderstanding, but the problem is that we mutate the context so that when we exit the contextmanager, it's still having the new MQ ? | |
| 20:02:48 | bauzas | because if so, that explains what I discovered, ie. the fact that I was able to ComputeNodeList.get_all() without needing to scope my target | |
| 20:05:50 | mriedem | melwitt: replied to your replies, i don't get the point about old compute code calling count() | |
| 20:05:55 | mriedem | because it's not a separate service, | |
| 20:06:00 | mriedem | the old compute code will call the old count() code | |
| 20:06:17 | melwitt | mriedem: the count() function is accessible through the Quotas.count() remotable method | |
| 20:06:21 | mriedem | because it's all bundled together i think, unless maybe you have like a nova-common package and that gets updated before this or something? | |
| 20:06:47 | melwitt | I don't think compute actually calls count. but if something old did, then the new code would have to work | |
| 20:07:33 | mriedem | i don't see anything calling it | |
| 20:08:06 | mriedem | besides the api, | |
| 20:08:08 | mriedem | which you've changed here | |
| 20:08:26 | melwitt | I don't think anything is, dansmith was saying because the remotable method is there, we can't just change the format of what it returns | |