| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-21 | |||
| 15:31:14 | bauwser | dansmith: mriedem: so this https://review.openstack.org/#/c/458668/1 is just for a mitaka>newton migration right? | |
| 15:31:36 | bauwser | dansmith: mriedem: I mean, since we say to use the latest .z version, we're fine | |
| 15:31:54 | openstackgerrit | Lee Yarwood proposed openstack/nova master: encryptors: Switch to os-brick encryptor classes https://review.openstack.org/391597 | |
| 15:32:03 | mriedem | bauwser: who is we? | |
| 15:32:05 | mriedem | red hat? | |
| 15:32:06 | bauwser | just wanted to make sure it wasn't needing a new db sync if you already applied a newton install | |
| 15:32:16 | mriedem | bauwser: it's for an upgrade | |
| 15:32:22 | mriedem | not a new install | |
| 15:32:45 | mriedem | select([func.count()]).select_from(pci_devices) | |
| 15:32:49 | bauwser | ok, so no db sync for updating to that new package if already newton ? | |
| 15:32:51 | mriedem | if you don't have pci devices (new install), then it's not a bug | |
| 15:33:05 | bauwser | no db sync *required* | |
| 15:33:23 | bauwser | if the answer is yes, then +W | |
| 15:33:26 | mriedem | if you already got to newton you don't have this issue | |
| 15:33:59 | bauwser | okay, that's what I thought, just double-checked | |
| 15:34:01 | mriedem | because 330 was in newton | |
| 15:34:04 | mriedem | https://github.com/openstack/nova/blob/stable/newton/nova/db/sqlalchemy/migrate_repo/versions/330_enforce_mitaka_online_migrations.py | |
| 15:38:41 | lyarwood | mriedem: ah sorry didn't see your check experimental | |
| 15:38:55 | lyarwood | mriedem: any idea why the encrypted volume tests were moved there? | |
| 15:41:17 | mriedem | lyarwood: a bunch of scenario tests were marked slow to take them out of the main gate runs, | |
| 15:41:32 | mriedem | because the scenario tests were taking up a ton of time, and randomly failing and causing resets, which takes more time | |
| 15:41:42 | mriedem | it was a big QA effort around the time of the PTG | |
| 15:43:50 | lyarwood | mriedem: understood, me-- for not checking that the tests were still present in the gate in the recent CI runs. | |
| 15:46:11 | mriedem | me-- :) | |
| 15:46:14 | mriedem | never seen that before | |
| 15:46:42 | mriedem | this isn't c lee | |
| 15:47:09 | mriedem | if you're going to decrement yourself, me -= me, please | |
| 15:49:53 | lyarwood | mriedem: always reviewing ;) | |
| 15:50:24 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add BDM to InstancePayload https://review.openstack.org/448779 | |
| 15:53:06 | dansmith | mriedem: me -= me = 0, not me-1 right? | |
| 15:55:06 | mriedem | dansmith: you've got me there | |
| 15:55:18 | mriedem | superdan | |
| 15:56:05 | bauwser | if me = -1, is me a square root of myself ? | |
| 15:56:46 | me | always wanted a friday nick | |
| 15:57:06 | Guest41383 | dude | |
| 15:57:14 | bauwser | heh, registered | |
| 15:57:17 | mdbooth | Haha | |
| 15:57:29 | Guest41383 | aaaaaaaaaand that's not going to be it | |
| 15:57:42 | bauwser | I did registered both my casual nick *and* my friday one :) | |
| 15:58:17 | openstackgerrit | Eric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #3: TaskFlow https://review.openstack.org/438729 | |
| 15:59:21 | bauwser | anyway, let's call it a week-end | |
| 16:19:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: move createBackup to server-actions https://review.openstack.org/452971 | |
| 16:19:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: 2.43: Remove Location header from createImage and createBackup responses https://review.openstack.org/455443 | |
| 16:21:51 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/458834 | |
| 16:46:55 | openstackgerrit | Dan Smith proposed openstack/nova master: Tell people that the nova-cells man page is for cells v1 https://review.openstack.org/456925 | |
| 16:46:56 | openstackgerrit | Dan Smith proposed openstack/nova master: Add release note and update cell install guide for multi-cell limitations https://review.openstack.org/456923 | |
| 17:01:31 | coffee_cat | lyarwood: I had that thought rushing through my head as well re swap volume and reserve the new one | |
| 17:02:38 | coffee_cat | coffee_cat: it was my laziness at this point that I didn't think it through, I just wanted to get something up what we can argue over :) | |
| 17:16:19 | cfriesen | does it make sense to allow a rebuild of a boot-from-volume to a different image, given that we don't write the new image to the volume? | |
| 18:02:19 | mnestratov | sdague: hi, around? | |
| 18:02:26 | sdague | mnestratov: yeh, what's up? | |
| 18:02:39 | mnestratov | can you take a look at https://review.openstack.org/#/c/458912/ | |
| 18:08:54 | sdague | mnestratov: my only concern with that is that we're going to need to add it back in as soon as we roll to packages | |
| 18:09:10 | sdague | and we're going to fail some upgrades in the process | |
| 18:10:48 | mnestratov | sdague: hmm, and when do we plan this? as soon as packages are ready? | |
| 18:14:07 | sdague | mnestratov: yeh, centos already has new enough packages in epel, it might switch back over if epel comes back on | |
| 18:14:27 | sdague | ubuntu has packages, but the socket interface isn't stable yet in them | |
| 18:15:54 | mnestratov | I see, well, looks we shouldn't merge this at all then | |
| 18:31:20 | openstackgerrit | Matt Riedemann proposed openstack/nova master: encryptors: Switch to os-brick encryptor classes https://review.openstack.org/391597 | |
| 18:33:27 | openstack | Launchpad bug 1685333 in OpenStack Compute (nova) "Fatal Python error: Cannot recover from stack overflow. - in py35 unit test job" [High,Confirmed] | |
| 18:33:27 | mriedem | i don't know how to debug this https://bugs.launchpad.net/nova/+bug/1685333 | |
| 18:43:11 | mriedem | interesting | |
| 18:43:26 | mriedem | live migration job failed because the destination said the guest wasn't found | |
| 18:43:37 | mriedem | but on the source side, the logs say "You may see the error "libvirt: QEMU error: Domain not found: no domain with matching name." This error can be safely ignored." | |
| 18:47:43 | mriedem | oh fun that info message is in the compute manager | |
| 18:47:48 | mriedem | where i might not be using libvirt at all | |
| 18:54:53 | mriedem | oh no wonder this goes back to diablo in a commit with no explanation | |
| 18:56:46 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove archaic reference to QEMU errors during post live migration https://review.openstack.org/458935 | |
| 18:57:39 | mriedem | also | |
| 18:57:40 | mriedem | Post live migration at destination ubuntu-xenial-2-node-osic-cloud1-s3500-8527282 failed | |
| 18:57:51 | mriedem | Migrating instance to ubuntu-xenial-2-node-osic-cloud1-s3500-8527282 finished successfully. | |
| 18:58:00 | mriedem | wtf | |
| 18:58:59 | kashyap | mriedem: Oops - that error message, specific to driver | |
| 18:59:11 | mriedem | kashyap: well, it's probably from when libvirt was the only driver | |
| 18:59:38 | kashyap | Hmm. Are other drivers, besides Xen, are well-maintained? | |
| 19:00:59 | mriedem | hypev | |
| 19:01:01 | mriedem | *hyperv | |
| 19:01:27 | kashyap | Yeah. | |
| 19:01:53 | kashyap | So, will Nova support Moby Containers? :P | |
| 19:03:42 | kashyap | Was debugging a "fun" issue where exposing a CPU "L3" cache (via QEMU's "-cpu host,l3-cache=on") to a guest will improve performance by 10% or so for some SAP workloads! | |
| 19:04:04 | mriedem | kashyap: you should talk to cfriesen then | |
| 19:04:11 | mriedem | he's been looking for someone that loves qemu and libvirt for the last 3 days | |
| 19:04:13 | kashyap | mriedem: Found out the root cause, actually | |
| 19:04:21 | kashyap | But luckily, no action item needed for upstream Nova, Because: | |
| 19:04:46 | kashyap | We "get it for free", with QEMU 2.8 and above. | |
| 19:04:52 | kashyap | As it is part of the _default_ machine type | |
| 19:05:19 | kashyap | So, if anyone is hitting it with Nova, using an older QEMU, still "no problem", we could use the always-handy (but voids support warranty) workaround: | |
| 19:05:46 | kashyap | Libvirt's XML namespace <qemu:commandline> [...] </qemu:commandline> | |
| 19:06:44 | kashyap | While upstream libvirt is trying to wire it into its QEMU command-line generator. So all good. And I can wind up for the night | |
| 19:06:50 | mriedem | is that like injecting stuff into rabbit at runtime using erlang? | |
| 19:07:00 | kashyap | Hehe | |
| 19:07:08 | kashyap | cfriesen: You might be interested in this -- https://www.redhat.com/archives/libvir-list/2017-April/msg00815.html | |
| 19:07:18 | kashyap | Unfortunately, the link won't work :-( | |
| 19:07:29 | kashyap | As there's a major outage in one of the critical datacenters | |
| 19:08:21 | kashyap | But rest assured, somewhere some tired admin is sweating to hell and back trying to fix the outage ... | |
| 19:09:17 | kashyap | mriedem: But more seriously, that namespace is very handy -- we (Nova) could test interesting features and can decide: "Okay, this and that combination of QEMU command-line gives Nova users some advantage -- so let's file an RFE to get that wired up into official libvirt APIs" | |
| 19:09:22 | mriedem | kashyap: maybe it's down b/c he was injecting stuff via qemu command line to the infra running the server | |
| 19:09:41 | kashyap | mriedem: Yeah, that workaround should be a one-off hack only. | |
| 19:10:01 | kashyap | Because, when using that workaroud, in logs, you'd see the instances to be marked as "tainted" (rightfully) | |
| 19:10:19 | kashyap | Warning the opertors that: "Look, your libvirt / QEMU upgrade might break your existing guests" | |