Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-15
15:02:02 johnthetubaguy were you say its this standard type X, and the hypervisor just picks what is best for that
15:02:15 mordred that sounds lovely!
15:02:29 johnthetubaguy (tries to find the spec for that)
15:02:49 johnthetubaguy http://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/libvirt-hardware-policy-from-libosinfo.html
15:03:14 johnthetubaguy that stops a chunk of the hurt ^
15:03:26 sdague mordred: yeh, there is also a place where if you know more about the details of what is in the image vs it being a black box, you can be more efficient.
15:03:44 mordred johnthetubaguy: yes! that seems wonderful
15:03:45 BobBall It's libvirt only - it wouldn't stop any of mordred's XenAPI-based hurt...
15:03:54 sdague if the user can't upload images, the user never has to know that, the metadata can be annotated on the image, and hid from the user
15:04:18 mordred sdague: this is true - but if the user can't upload images the cross-cloud interop story is much much worse
15:04:26 sdague but if the user does upload images, there does become a point where you either expose things, or have them run in lowest common denominator state
15:04:34 sdague it is a leaky abstraction for sure
15:04:49 sdague I just don't know how it gets eliminated and not just turn into mud
15:04:58 mordred sdague: having a spec for annotating information about this image "this image runs ubuntu" seems non-weird
15:05:22 mordred or having that be discoverable even - but just a known standard for things that are facts about the image that I can be expected to know as an image creator
15:05:24 mordred seems great
15:05:54 mordred having the annotations be instrucitons to the hypervisor about what to do, on the other hand, is where I believe things fall apart a bit
15:06:09 mordred "this image runs ubuntu and does not run any boot agents" is a totally fair thing for me to assert as a user
15:06:42 mordred "please boot this using the pvm mode of the hypervisor" less so
15:07:01 johnthetubaguy mordred: thats fine, then run it in the default mode, and it should work
15:07:27 BobBall How would you distinguish between a PV and HVM-type guest? In Xen they are fundamentally different things (PV being co-operatively booted with the host's kernel and HVM being fully isolated)
15:07:53 mordred BobBall: that's just the thing - I'm an openstack user, not a xen user - I have no clue what pv vs hvm even means
15:07:57 BobBall HVM should be the default and should almost always work - but we do still need a way to say it's a PV guest
15:07:58 johnthetubaguy BobBall: we took out the code that attempted that, it was evil (used pygrub)
15:07:59 mordred I have an image that contains an installation of ubuntu
15:08:35 BobBall I thought the default was to boot HVM if neither were specified - perhaps I am mistaken?
15:08:45 BobBall If that's not the case, it should be.
15:08:57 mordred at least at some point in the past I have had to specify that on images explicitly
15:09:06 johnthetubaguy BobBall: so funny thing, HVM for windows, PV for linux, becuase.... history
15:09:08 mordred (so we just continue to specify it - I have not checked if it's still actually required)
15:09:11 BobBall Yes, true.
15:09:13 sdague mordred: I think the issue here is that xen pv mode is closer conceptually to a container (it's not really, but it does have cooperation with host)
15:09:39 sdague and, sure, the logic should probably be inverted to default to "no host coop"
15:09:41 BobBall johnthetubaguy: So let's fix that now - we can notify a change in Pike and fix it after?
15:09:50 sdague and you annotate if your image can host coop
15:09:53 johnthetubaguy BobBall: it breaks every existing image from booting
15:10:08 mordred sdague: and I think that's the sort of thing I'd personally love to see in a magical world
15:10:31 mordred "this image can boot cooperatively with a host" is a thing I could see asserting
15:10:38 mordred or "this images needs to run its own kernel"
15:11:12 sdague this image needs this network device model
15:11:15 mordred yah
15:11:49 sdague so, I think that is where we are headed, there is some rax specific stuff that's predated standardizing all of this
15:12:09 mordred and if there was just a catalog of those that was known (and they were all phrased as describing qualities of the image and not the hypervisor behavior) I think it woudl be much less cognitavely dissonant
15:12:12 mordred woot!
15:12:20 mordred (I'm fine dealing with hysterical raisins)
15:12:30 sdague but, rax is enough of a fork, don't paint the rest of nova in that light :)
15:12:32 mordred turns out rax also ran this stuff in produciton way before anyone else
15:12:40 sdague yep
15:12:43 mordred so even though I complain I think they also get a little more rope
15:13:08 mordred I mostly just want to make sure that the bitching is at least a little productive eventually :)
15:13:51 johnthetubaguy its just a case of deprecating and find a path forward
15:14:03 johnthetubaguy but most of that is there right now for libvirt, I believe
15:15:07 mordred fwiw - this conversation has helped me understand why having a property on an image that relates to hypervisor behavior is not crazy
15:15:12 mordred so thanks to you all
15:17:12 openstackgerrit Jordan Pittier proposed openstack/nova master: api/metadata/vendordata_dynamic: don't import Requests for its constants https://review.openstack.org/434339
15:21:44 hongbin alex_xu: ping
15:37:10 mriedem1 lyarwood: the ocata change for this is merged now https://review.openstack.org/#/c/429416/
15:40:52 lyarwood mriedem: ack thanks
15:44:32 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova master: Optimize time during PCI alias parsing process https://review.openstack.org/427145
15:44:58 BobBall dansmith: Any chance you can re-review https://review.openstack.org/#/c/424428/ ? I understand a backport is v.tricky so we'd dearly love to get the fix in Ocata.
15:55:25 dansmith BobBall: yesterday I said I had looked at the object stuff and was okay with it, but didn't have time to really do the rest... I was kinda punting to mriedem at that point.. did he say yay or nay about it?
15:56:38 BobBall Ah, no, mriedem hasn't looked at it.
15:57:21 dansmith mriedem: for your benefit:
15:57:23 BobBall I guess you don't expect time to look at the rest of the patch today?
15:57:26 dansmith 07:55:24] <dansmith>BobBall: yesterday I said I had looked at the object stuff and was okay with it, but didn't have time to really do the rest... I was kinda punting to mriedem at that point.. did he say yay or nay about it?
15:57:57 dansmith BobBall: I've got something going on for the next couple hours but could probably look at it after that if mriedem agrees that we should get it into rc2
15:58:05 mriedem BobBall: i planned on reviewing it today
15:58:22 mriedem i'm in meetings for the next couple of hours
15:58:24 BobBall Ah - awesome. Thanks both.
15:58:38 mriedem it's the last thing i'm trying to get into rc2 before we cut it
15:59:19 BobBall Cool. I'll keep my eyes open for any changes or feedback that's needed.
16:09:07 openstackgerrit Balazs Gibizer proposed openstack/nova master: Transform missing delete notifications https://review.openstack.org/410297
16:12:59 openstackgerrit Sergey Nikitin proposed openstack/nova master: Change parent of diagnostics objects to NovaObject class https://review.openstack.org/394480
16:13:00 openstackgerrit Sergey Nikitin proposed openstack/nova master: Standardization of VM diagnostics info API. https://review.openstack.org/355540
16:13:01 openstackgerrit Sergey Nikitin proposed openstack/nova master: Completed implementation of instance diagnostics for Xen https://review.openstack.org/399613
16:13:02 openstackgerrit Sergey Nikitin proposed openstack/nova master: Add RPC version aliases for Ocata https://review.openstack.org/425958
16:24:48 openstackgerrit Roman Podoliaka proposed openstack/nova master: Make eventlet hub use a monotonic clock https://review.openstack.org/434327
16:42:31 mordred sdague, mriedem did anything change in the last couple of days related to nova usage?
16:42:47 mordred specifically, did total_hours go away?
16:44:00 mriedem simple tenant usage?
16:44:18 sdague still looks like it's in master to me
16:44:30 mriedem which microversion?
16:52:09 mordred latest
16:52:34 mordred so there was a change to remove that in latest microversion? /me goes to look at microversion docs
16:53:51 mordred the only change I see is the 2.40 one which adds pagination ... does the text there https://docs.openstack.org/developer/nova/api_microversion_history.html#id36 mean that the total fields are just gone now?
16:54:32 diana_clarke mordred: totals should still be there, but they only reflect a "page" of data and may need to be stitched back together
16:54:57 diana_clarke mordred: pastebin an api response, so I can see what you're seeing?
16:54:59 mordred diana_clarke: hrm. well - I'm getting this: http://logs.openstack.org/44/434344/1/check/gate-shade-dsvm-functional-libs-nv/495b14a/console.html#_2017-02-15_16_10_01_704583
16:55:29 mordred diana_clarke: but unfortunately there is no nova api in the log there ... I'm making a patch now to try to capture more things
17:05:32 jroll hey nova, this refactor has been sitting for a while, if you'd like an easy-ish review :) https://review.openstack.org/#/c/399022/
17:05:41 jroll +13, -285 btw :D
17:06:53 mriedem jroll: that reminds me, how do we ci test the hashring stuff? weren't there ideas on that with a multinode job?
17:07:26 openstackgerrit Maciej Szankin proposed openstack/nova master: conf: remove *_topic config opts https://review.openstack.org/433924
17:07:41 jroll mriedem: yeah, we've been working on a multinode job, which I believe has two computes
17:07:54 jroll idk if we want to do anything fancy like bring on compute host down
17:08:18 mriedem probably not if yo'ure running tempest on it at the same time
17:08:24 jroll right
17:08:28 mriedem jroll: the ironic networking one
17:08:32 openstackgerrit Sujitha proposed openstack/nova master: Adding tags field to InstancePayload https://review.openstack.org/407228
17:08:38 jroll we could do something in setup, though

Earlier   Later