| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-12 | |||
| 14:49:21 | stephenfin | What about version 0.6? | |
| 14:49:52 | ShilpaSD | 0.6 not yet checked, will do that in next 5 min and get back to you | |
| 14:49:56 | stephenfin | (y) | |
| 14:50:33 | ShilpaSD | should i use v v0.6.1 or v0.6.2? | |
| 14:53:58 | ShilpaSD | stephenfin: actually earlier we had 'vnc_auto.html', and that removed in currunt vnc 1.0 release, so we have to make configuration chnages | |
| 14:55:02 | stephenfin | ShilpaSD: Yup, that what's I found. What I'm suggesting is that maybe 'vnc.html' works in both 0.6 and 1.0. If so, we might start using that instead of 'vnc_auto' or 'vnc_lite' | |
| 14:55:26 | stephenfin | Also, use 0.6.2 I guess. Either would be OK though | |
| 14:56:29 | ShilpaSD | okay, will check on 0.6.0 with 'vn.html' and get back to you with outcome | |
| 14:56:43 | ShilpaSD | 'vnc.html'* | |
| 15:01:07 | jaypipes | bauzas, cdent: can you guys give me 45 minutes? | |
| 15:01:09 | bauzas | efried: I don't see why it could be "madness" to accept operator's defined traits | |
| 15:01:31 | cdent | jaypipes: you mean before continuing this topic? I can, sure | |
| 15:01:34 | bauzas | the munging logic should be very explicit | |
| 15:01:35 | jaypipes | yes | |
| 15:01:40 | bauzas | jaypipes: yup, I can hold | |
| 15:03:39 | gibi | jaypipes, stephenfin: so the scheduler meeting is over. I have about two hours left from my workday to jump on a hangouts about the numa aware vswitches | |
| 15:04:15 | stephenfin | gibi: I think jaypipes is busy for a bit so maybe once he's free? I've no other meeting scheduled for the day | |
| 15:04:34 | gibi | stephenfin: OK. I just noted down my boundaries :) | |
| 15:05:22 | stephenfin | gibi: Sure, we'll fit it in in that time :) | |
| 15:12:20 | ShilpaSD | stephenfin: Hi, for 'vnc.html' with noVnc version 0.6.2 and websockify-0.8.0, it failed to access, error at do_handshake() | |
| 15:12:40 | stephenfin | ShilpaSD: Is that the same issue you saw with 1.0? | |
| 15:13:09 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Standardize '_get_XXX_constraint' functions https://review.openstack.org/385071 | |
| 15:13:54 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Move availability zones opts to a group https://review.openstack.org/462469 | |
| 15:17:41 | ShilpaSD | for 1.0, https://github.com/novnc/noVNC/issues/967 | |
| 15:17:52 | ShilpaSD | actually issue for noVNC=v1.0.0-testing.2 | |
| 15:19:22 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: remove pagesize from __init__ of InstanceNUMATopology https://review.openstack.org/485553 | |
| 15:19:22 | ShilpaSD | for 1.0, token is not available as query parameter as well as it is not set in cookie. | |
| 15:19:22 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: remove related pinning from __init__ of InstanceNUMATopology https://review.openstack.org/485554 | |
| 15:19:23 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: remove cpuset_reserved from __init__ of InstanceNUMATopology https://review.openstack.org/466030 | |
| 15:20:06 | ShilpaSD | and if we configure 'vnc.html' | |
| 15:22:11 | stephenfin | ShilpaSD: So they're different issues? | |
| 15:26:24 | ShilpaSD | stephenfin: No, its same. token is not getting as query parameter as well as it is not set in cookie. | |
| 15:26:43 | ShilpaSD | for vnc.html configuration | |
| 15:27:34 | ShilpaSD | stephenfinr: please firstly confirm me that are we going to use vnc_lite.html or vnc_html for version 1.0? | |
| 15:28:10 | ShilpaSD | token unavailable issue is with vnc.html only | |
| 15:33:01 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Don't use single backticks in man pages https://review.openstack.org/540887 | |
| 15:33:02 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Start using openstackdoctheme's extlink extension https://review.openstack.org/540888 | |
| 15:33:49 | stephenfin | ShilpaSD: So, this is my idea. We fix the issue you're seeing and change the default to 'vnc.html'. That means people can use the same configuration file with both 0.6 and 1.0 | |
| 15:34:36 | stephenfin | I don't know if that's a good idea but, in my mind, this would make for the easiest upgrade path for operators | |
| 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? | |