| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-12 | |||
| 15:36:26 | sean-k-mooney | stephenfin: since upgrades of openstack servers are supposed to be doable without any config changes from n to n+1 i think it makes sense | |
| 15:37:21 | stephenfin | sean-k-mooney: Right. We could conceivably backport that fix too to make things even easier for the N to N+M cases | |
| 15:37:38 | ShilpaSD | stephenfin: but earlier its 'vnc_auto.html' for 0.6, so configuration file changes are require with my fixes too | |
| 15:38:26 | sean-k-mooney | stephenfin: well for n to n+2 it is expect that config change could be required but that should be achive via an itermediate change during n+1 | |
| 15:38:40 | stephenfin | ShilpaSD: True. However, operators could make that change incrementally and keep noVNC versions the same. When they do decide to update noVNC, the same config file will work with both | |
| 15:38:57 | stephenfin | Otherwise they need to both update the config file and noVNC version in lockstep | |
| 15:39:13 | stephenfin | Then again, maybe I'm overthinking this and the operator could just place a redirect in place, as sean-k-mooney suggested :) | |
| 15:40:11 | sean-k-mooney | stephenfin: redirect for appache/nginx or simlink for python webserver "should" work | |
| 15:47:38 | sean-k-mooney | stephenfin: looking at the two i think the lite version just uses less css/javascript effects | |
| 15:48:11 | stephenfin | sean-k-mooney: So maybe the redirect is the best option? | |
| 15:48:15 | stephenfin | i.e. leave it to the deployment tool | |
| 15:50:15 | ShilpaSD | stephenfin: understood what you want to mentioned here, so for fix i am updating access URL at https://github.com/openstack/nova/blob/d7c46b279686308f5431410bfccb3e40031e380a/nova/compute/manager.py#L5058 | |
| 15:50:19 | ShilpaSD | as below | |
| 15:50:30 | ShilpaSD | access_url = '%s?path=websockify?token=%s' % (CONF.vnc.novncproxy_base_url, token) | |
| 15:50:50 | sean-k-mooney | stephenfin: perhaps. the vnc.html seams to support audio and addtional key bindings + some transitions. | |
| 15:51:02 | ShilpaSD | stephenfin: adding '?path=websockify', in access URL, is it okay? | |
| 15:51:18 | sean-k-mooney | stephenfin: also i think it adds copy past support | |
| 15:51:20 | ShilpaSD | its resolve my issue with 'vnc.html' | |
| 15:52:48 | stephenfin | ShilpaSD: If that works, push up a patch and I can review | |
| 15:53:08 | stephenfin | ShilpaSD: Does that also work with 'vnc_lite.html'? | |
| 15:53:13 | stephenfin | If so, we could make it the default | |
| 15:53:26 | stephenfin | noVNC 0.6 is quite old. We could say we require it | |
| 15:54:32 | sean-k-mooney | stephenfin: at least in devstack the version of novnc is set here https://github.com/openstack-dev/devstack/blob/master/stackrc#L606 so you could add a new config option that would set the defualt html file based on this | |
| 15:56:11 | jaypipes | cdent, bauzas: hey, back now. thanks for your patience. | |
| 15:56:22 | cdent | hola | |
| 15:56:44 | jaypipes | stephenfin, gibi: we could discuss stephenfin's thing tomorrow my morning if that works for you | |
| 15:56:51 | stephenfin | sean-k-mooney: I had a patch up to change the devstack default but it's failing for reason's I haven't investigated | |
| 15:57:13 | ShilpaSD | stephenfin: yes, it works with 'vnc_lite.html' also, will upload patch for you review and get back to you on same ASAP | |
| 15:57:25 | gibi | jaypipes: it works for me | |
| 15:58:05 | stephenfin | jaypipes: Works for me too. Wanna stick something in someone's calendar | |
| 15:59:09 | jaypipes | stephenfin: go for it. | |
| 15:59:19 | jaypipes | stephenfin: jaypipes@gmail.com | |
| 15:59:30 | gibi | stephenfin: gibizer@gmail.com | |
| 16:00:16 | stephenfin | Ta! | |
| 16:02:08 | cdent | jaypipes: was the stuff you wanted to talk with me about on friday eve this traits stuff, or something else? | |
| 16:02:37 | jaypipes | cdent: yeah | |
| 16:02:47 | ShilpaSD | stephenfin: bye, leaving for the day | |
| 16:03:09 | stephenfin | ShilpaSD: Ciao. Let me know when you have that review up and I can review it | |
| 16:03:57 | ShilpaSD | stephenfin: yes sure, working on TOX, once done, will do so | |
| 16:05:18 | gibi | Kevin_Zheng: I just noticed that you published a spec https://review.openstack.org/#/c/551982/ for add-request-id-to-instance-action-notifications I think the bp is already approved as specless so we don't need to have a spec | |
| 16:05:25 | gibi | Kevin_Zheng: you can go for the implementation | |
| 16:07:01 | cdent | jaypipes: I guess bauzas is still in his pile of paperwork. I don't really have much to add to the topic than what was said on Friday and in those comments I menionted in the meetings. | |
| 16:07:50 | bauzas | cdent: well, I can stop paperworking, y'know | |
| 16:08:09 | jaypipes | cdent: my primary concern is how do we prevent situations where different actors are constantly overwriting each other... | |
| 16:08:21 | bauzas | honestly, in between writing silly stuff and discussing with you folks, you got my opinion I guess | |
| 16:09:22 | bauzas | MHO is that I agree with jaypipes and dansmith, I'd like to see the compute service reconciling traits provided by operators with traits set by the virt driver | |
| 16:09:29 | bauzas | if that's the question | |
| 16:09:39 | cdent | jaypipes: are we able to enumerate who the legit actors are? | |
| 16:09:53 | dansmith | I thought we were going to have a hangout about this? | |
| 16:10:00 | jaypipes | cdent: for both traits and allocation ratios. either we have some agreement about what is always the source of truth for certain attributes, or we never have the automated agents (like resource tracker in compute manager) ever *delete* things... only add them. and then rely on manual deletes to remove things. but then we still need to solve the case of an agent continually adding some trait or setting some allocation ratio when it's been | |
| 16:10:00 | jaypipes | overridden or deleted by an external actor. | |
| 16:10:13 | dansmith | IMHO, if the operator removes a trait owned by the virt driver directly in placement, the proper thing to do is overwrite that change | |
| 16:10:38 | dansmith | the operator has configured the virt driver with details about the supported cpu model, for example, and it makes no sense for her to then go tweak placement after the fact | |
| 16:10:49 | efried | Meaning the trait gets restored, yes? | |
| 16:11:06 | jaypipes | dansmith: so the virt driver should know not to write CPU traits in that case, yes? | |
| 16:11:22 | bauzas | I was only thinking about additive traits | |
| 16:11:24 | dansmith | jaypipes: no, the virt driver should be authoritative for cpu flag traits | |
| 16:11:27 | efried | No, the opposite. The virt driver is the Source of Truth for CPU traits. | |
| 16:11:32 | efried | (and others, for that matter) | |
| 16:11:32 | dansmith | efried: right | |
| 16:11:56 | jaypipes | dansmith, efried: ok. fair enough about cpu traits. what about allocation ratios? | |
| 16:12:12 | bauzas | if the operator wants to remove a trait, why shouldn't we not accepting that ? | |
| 16:12:24 | bauzas | it's his responsibility | |
| 16:12:32 | dansmith | jaypipes: today, compute owns those, but I think who owns it in the future depends on what we do with our current config | |
| 16:12:48 | jaypipes | bauzas: dansmith and efried are saying that the virt driver should own the cpu traits. and I don't disagree with that, BTW. | |
| 16:12:48 | bauzas | the compute service *is* the source of truth, not the virt driver IMHO | |
| 16:13:00 | bauzas | that's where I see the difference | |
| 16:13:06 | dansmith | bauzas: compute does not own cpu flag traits | |
| 16:13:10 | bauzas | meaning that some operator could want to hide a trait if they'd like | |
| 16:13:11 | jaypipes | dansmith: right, and aggregate stuff complicates that a bit, too. | |
| 16:13:27 | dansmith | bauzas: it does the setting based on what virt says, but it doesn't own the decision about which ones to set | |
| 16:14:08 | efried | ++ | |
| 16:14:14 | bauzas | dansmith: the problem I see with that approach is that we have different traits | |
| 16:14:14 | dansmith | jaypipes: yup, but the ratio thing is pretty straightforward I think.. we just decide what we're going to do at first startup, and what to do on subsequent ones | |
| 16:14:31 | bauzas | dansmith: some that we don't want the operator to modify, some we accept that | |
| 16:14:36 | jaypipes | dansmith: ack. and I'm cool with your default_xxx_allocation_ratio suggestion. | |
| 16:14:47 | bauzas | anyway, it's a set, right | |
| 16:14:47 | bauzas | ? | |
| 16:14:51 | dansmith | bauzas: I don't understand what you're saying | |
| 16:15:09 | bauzas | so, it's either an additive or a removal operation for a trait | |
| 16:15:26 | jaypipes | dansmith: do you think the default_xxx_allocation_ratio solution warrants a spec? | |
| 16:15:35 | dansmith | jaypipes: I bet mriedem does | |
| 16:15:45 | jaypipes | yeah, makes sense | |
| 16:15:51 | jaypipes | I'll hack one together quick. | |
| 16:16:01 | jaypipes | scoped only to this narrow use case. | |
| 16:16:09 | dansmith | maybe it would help if I wrote some example code for how I think we should handle the trait thing? | |
| 16:16:14 | bauzas | dansmith: the point I'm saying is that if we don't accept operators to remove a trait for a specific usecase (here a CPU feature), we shouldn't accept that for *any* trait too | |
| 16:16:16 | dansmith | between virt traits, compute traits, and operator-set traits? | |
| 16:16:27 | dansmith | bauzas: that makes no sense to me | |
| 16:16:33 | jaypipes | dansmith: sure, that would help | |
| 16:16:35 | efried | It seems to be a requirement for the admin to be able to set/unset at least *certain* traits. And I personally don't want to get into a situation where we treat some traits differently from others. Having to figure out and enforce which is which == nightmare. So we need the admin-override mechanism to be generic. And if they want to remove something that clearly should be owned by the virt driver (like a CPU trait), th | |
| 16:16:39 | jaypipes | (the sample code) | |
| 16:16:47 | dansmith | bauzas: virt can be authoritative for TRAIT_VMX and not be involved in TRAIT_SOMETHINGELSE | |
| 16:17:18 | bauzas | dansmith: so the compute would know which resource is authoritative for a trait, then ? | |
| 16:17:29 | jaypipes | efried: did you cut off that last sentence? | |
| 16:17:33 | efried | dansmith: IMO that's crazypants, to try to make lists of traits that can or can't be controlled by the admin, or are "owned" by virt vs. not, etc. | |
| 16:17:35 | dansmith | bauzas: does't need to be by any set of complex rules, IMHO | |
| 16:17:47 | dansmith | efried: I don't think we need a set of rules | |
| 16:18:05 | dansmith | efried: I think the virt driver and compute services can just be authoritative for the ones they need to care about, and any others will be left alone | |
| 16:18:09 | edleafe | efried: if the virt driver sets traits A,B,C, and the admin sets traits X,Y,Z, there is no problem, right? It's only when the admin wants to set/clear one of A, B, or C | |