Earlier  
Posted Nick Remark
#openstack-nova - 2018-03-12
14:45:04 edmondsw stephenfin I had to manually rebase after you +Wd... can you take another look at https://review.openstack.org/#/c/539314/ ?
14:47:19 stephenfin edmondsw: Sure
14:47:27 efried melwitt: The "runways" thing - is that going to be tracked on https://etherpad.openstack.org/p/rocky-nova-priorities-tracking or is there a separate etherpad?
14:47:33 edmondsw stephenfin ty sir
14:48:42 ShilpaSD stephenfin: Hi, tested vnc console access using 'vnc_lite.html' for version 1.0, its working without any changes at nova-compute services, and able to access console
14:49:07 stephenfin ShilpaSD: Excellent. So there's nothing more needed, if we decide to use that?
14:49:11 ShilpaSD but if configured 'vnc.html' for version 1.0, then require changes at nova-compute service
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 related pinning from __init__ of InstanceNUMATopology https://review.openstack.org/485554
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 pagesize from __init__ of InstanceNUMATopology https://review.openstack.org/485553
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 overridden or deleted by an external actor.
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: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?

Earlier   Later