Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-12
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?
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 dansmith efried: right
16:11:32 efried (and others, for that matter)
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 bauzas the compute service *is* the source of truth, not the virt driver IMHO
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: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 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:14 bauzas dansmith: the problem I see with that approach is that we have different traits
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 ?
16:14:47 bauzas anyway, it's a set, right
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
16:18:15 bauzas dansmith: I mean, how the compute can know whether it can accept an operator's defined list of traits to remove if one of those traits is TRAIT_VMX for example ?
16:18:16 jaypipes efried: dansmith is saying "whatever the virt driver returns as traits should be authoritative for *those* traits"
16:18:25 dansmith jaypipes: exactly
16:18:27 efried I don't see how that can work in practice.
16:18:30 edleafe jaypipes: yes
16:18:37 efried Thinking about how the virt driver is going to discover traits...
16:19:07 efried In the general case, it gets its info from the platform and translates to trait strings.
16:19:17 dansmith efried: the virt driver is write-only for traits, right? it doesn't care what traits are currently set, it only generates a list of traits that *should* be set based on talking to the hypervisor
16:19:45 efried Yes, but we're talking about the virt driver having to *know* about things it simply doesn't get from the platform as still being under its control.
16:20:20 dansmith I'm not sure I understand what you mean, but.. I don't think I agree
16:20:23 bauzas dansmith: so, if we accept some mechanism for the operator to remove some trait, it would just be a conditional in the compute service that would say 'don't touch what the virt driver returns", right?

Earlier   Later