| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-15 | |||
| 14:09:41 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/432001 | |
| 14:09:42 | johnthetubaguy | mriedem: sure :) | |
| 14:19:23 | oomichi | johnthetubaguy: can you take a look at https://review.openstack.org/#/c/389338/ ? I replied to your question on PS5 | |
| 14:21:44 | johnthetubaguy | oomichi: sorry, I don't see any emails from gerrit right now, I just get noise from the system, I must attempt to fix that again | |
| 14:23:12 | oomichi | johnthetubaguy: no problem. gerrit emails tend to be just noise in many cases :-) | |
| 14:32:25 | openstackgerrit | Davanum Srinivas (dims) proposed openstack/nova master: Tolerate WebOb===1.7.1 https://review.openstack.org/434285 | |
| 14:34:59 | mordred | sdague: the add-flavor-to-server thing we were talking about a few days ago - has there been any discussion of doing the same thing with image? (I'm guessing not, since that's proxy info, but thought I'd ask) | |
| 14:35:38 | sdague | mordred: there has not been | |
| 14:35:58 | sdague | the difference with add-flavor-to-server is we actually do that internally already | |
| 14:36:06 | mordred | nod | |
| 14:36:21 | sdague | to protect you from a class of errors, all the flavor info is copied into the instance on boot | |
| 14:36:34 | sdague | and that's the data that is operated on from there on out | |
| 14:37:04 | mordred | ahhhh. so that makes adding it actually quite easy then :) | |
| 14:37:10 | sdague | right | |
| 14:37:12 | mordred | sdague: it came to mind because of the random email I read and answered on the openstack@ list ... someone was asking if there was a rest api to find the os of a server - and I responded that the best chance was looking at the image, but that it might be gone | |
| 14:37:21 | mordred | and it reminded me of the flavor thing | |
| 14:37:24 | sdague | yeh | |
| 14:38:39 | openstackgerrit | Hironori Shiina proposed openstack/nova master: Remove mox from tests/unit/conductor/tasks/test_live_migrate.py(4) https://review.openstack.org/312589 | |
| 14:40:11 | sdague | mordred: that just gets into the realm where we split up the concerns a while ago | |
| 14:40:42 | johnthetubaguy | mordred: for image stuff, this spec nicely hints on some of the problems we have right now: http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/virt-image-props-boot-override.html | |
| 14:40:51 | johnthetubaguy | I wish we had been able to get that one done | |
| 14:41:10 | sdague | if we want to be able to interogate nova for these things, you start asking the question about whether glance really should remain an independent concern | |
| 14:41:14 | mordred | johnthetubaguy: zomg. can I mention how crazy I think it is that image props affect instance booting? | |
| 14:41:37 | sdague | mordred: why? | |
| 14:42:35 | mordred | sdague: because to me an image is a filesystem, not a machine. the machine is the thing I ask nova to create at boot time | |
| 14:42:46 | johnthetubaguy | there was that lib that would help us kill half of them | |
| 14:42:53 | johnthetubaguy | mordred: but that image has requirements in order to work | |
| 14:42:57 | mordred | so having some random property have magic effects that are not expected is very weird | |
| 14:44:13 | mordred | but that's lkely just a problem in my brain | |
| 14:44:56 | mordred | but it's also a super weird experience for those of us who upload our own images rather than using provider provided images | |
| 14:45:12 | sdague | mordred: things also get a bit more complicated when you mix in windows | |
| 14:45:37 | mordred | because there are operational things, like whether or not the hypervisor should try to do things with agents or whatnot that as a user I have no way of really knowing - and as an unpriviledged user I likely should not be able to set | |
| 14:45:49 | mordred | but that are requirements for working booting of an image | |
| 14:46:00 | mordred | sdague: I'm sure they do | |
| 14:47:09 | mordred | like - in rackspace I have to set "vm_mode: hvm" on an image to make that image work on the performance flavors (or at least, I used to need to do that, I do not know if it's still required) | |
| 14:47:43 | mordred | and I also have to set xenapi_use_agent: false to avoid the hypervisor barfing when my image doesn't do callbacks to the xenapi agent | |
| 14:52:49 | sdague | mordred: is your concern that those nobs exist? | |
| 14:52:59 | openstackgerrit | Roman Podoliaka proposed openstack/nova master: WIP: check if the problem is reproduced in the gate https://review.openstack.org/434327 | |
| 14:55:48 | johnthetubaguy | mordred: thats because we have images that work best with lots of those combinations, and they get inherited by parent snapshots, etc | |
| 14:56:24 | johnthetubaguy | mordred: now I am tempted to hide most of those from users, but if you upload your own image, you will need it | |
| 14:57:35 | johnthetubaguy | mordred: FWIW, the upstream default is for xenapi_use_agent to be False, but thats doesn't work when most of your snapshots never had that set | |
| 14:58:20 | johnthetubaguy | (thats me saying, it sure sucks, but not sure how to make it better) | |
| 14:59:11 | mordred | yah - I hear that - it's just an implementation detail leaking through. as a user, I am of the belief that I should not need to know that you run xen at all | |
| 15:00:15 | mordred | but that likely stems from not being a person who has access to hypervisors or a background with managing virtualization infrastructure | |
| 15:01:03 | mordred | sdague: I think my concern is mostly around the fact that most if not all of the image properties that affect compute opertaion are hypervisor specific and therefore fundamentally not interoperable | |
| 15:01:37 | johnthetubaguy | we have actively tried to standardise the ones that are cross hypervisor | |
| 15:01:40 | mordred | that said - when we talk about discovery - this is an area to add to the bucket "what knobs does this cloud have for images that I might should be setting" | |
| 15:01:44 | johnthetubaguy | there is the libvirt lib effort thing | |
| 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 | |