| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-15 | |||
| 13:21:07 | mriedem | snikitin: soon. we can do the rpc aliases after we cut rc2 | |
| 13:21:10 | mriedem | which should be tomorrow | |
| 13:21:25 | snikitin | great, thanks | |
| 13:23:23 | mriedem | lyarwood: do we need this? https://review.openstack.org/#/c/416557/ | |
| 13:24:20 | mriedem | johnthetubaguy: bauzas: for rc2 https://review.openstack.org/#/c/433932/ | |
| 13:29:08 | lyarwood | mriedem: going over this again I don't think we do, sorry about that | |
| 13:30:05 | johnthetubaguy | mriedem: I did still wonder about getting this into rc2: https://review.openstack.org/#/c/430400/ | |
| 13:32:41 | bauzas | mriedem: roger, looking | |
| 13:32:45 | lyarwood | mriedem: actually, that does make https://review.openstack.org/#/c/416558/ possible so we do need it as a dependancy | |
| 13:34:23 | bauzas | mriedem: https://bugs.launchpad.net/nova/+bug/1663317 seems to me rather a new feature for supporting IPv6 than a bug, agreed ? | |
| 13:34:23 | openstack | Launchpad bug 1663317 in OpenStack Compute (nova) "IPv6 neighbor discovery not getting through qbr bridge" [Undecided,New] | |
| 13:35:07 | bauzas | mriedem: we did cut IPv6 for the bridge because of the security issue, but we don't had yet a solution for the above point | |
| 13:35:38 | bauzas | mriedem: either way, I'm about to mark it invalid unless you have other thoughts | |
| 13:39:40 | mriedem | johnthetubaguy: isn't that latent? | |
| 13:40:17 | johnthetubaguy | mriedem: yeah, thats true, I have live-migrate on the brain a bit right now | |
| 13:40:35 | mriedem | johnthetubaguy: yeah i'd rather just backport that after ocata is released | |
| 13:41:40 | mriedem | bauzas: i don't really know anything about that ipv6 bug | |
| 13:46:07 | mriedem | lyarwood: ok +2 | |
| 13:46:11 | mriedem | lyarwood: can you get this in? https://review.openstack.org/#/c/433922/ | |
| 13:48:14 | mriedem | johnthetubaguy: we've got a +2 on https://review.openstack.org/#/c/433257/ if you're happy with it, then i'm going to backport for rc2 | |
| 13:48:26 | bauzas | mriedem: okay, no worries, I have enough knowledge and understanding for at least replying to the reporter | |
| 13:48:39 | mriedem | on top of https://review.openstack.org/#/c/432954/ | |
| 13:48:42 | johnthetubaguy | mriedem: ah, looking | |
| 13:49:19 | lyarwood | mriedem: yup looking, the fix for the CI failure landed already right? | |
| 13:49:27 | bhagyashris | mriedem: Hi, Could please review the patch: https://review.openstack.org/#/c/409644/ ? if you get time | |
| 13:49:31 | mriedem | lyarwood: yeah | |
| 13:50:24 | mriedem | bhagyashris: that's an api change, so probably need alex_xu to also look at that | |
| 13:53:52 | bhagyashris | mriedem: ok. Thanks for review. | |
| 14:02:45 | openstackgerrit | Davanum Srinivas (dims) proposed openstack/nova master: Tolerate WebOb===1.7.1 https://review.openstack.org/434285 | |
| 14:07:44 | mriedem | johnthetubaguy: the ci failure on https://review.openstack.org/#/c/433257/ is due to the cells v1 test_stamp_pattern blocking bug from yesterday | |
| 14:07:46 | mriedem | already rechecked | |
| 14:08:26 | mriedem | sorry to push but i've got meetings most of the day so won't have a ton of time for dealing with thi | |
| 14:08:27 | mriedem | *this | |
| 14:08:47 | johnthetubaguy | mriedem: yeah, was just thinking about waiting for the recheck, but happy to +W it if you are happy thats likely to work | |
| 14:09:00 | mriedem | i guarantee it :) | |
| 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 | |