| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-26 | |||
| 09:54:45 | tobias-urdin | there is a lot of stuff in between there though, having the data left but removing the instance for example | |
| 10:00:43 | lyarwood | tobias-urdin: as a migration path between the two? | |
| 10:01:14 | tobias-urdin | yeah | |
| 10:01:21 | lyarwood | tobias-urdin: I'm not sure it would tbh, you would need cinder to know about the volumes in the original images pool, their metadata etc | |
| 10:01:36 | lyarwood | tobias-urdin: I guess we could get that from nova but it's kinda awkward | |
| 10:02:02 | tobias-urdin | iirc cinder can import a ceph rbd volume i would just need to boot the instance from that, is what i was thinking atleast | |
| 10:02:23 | tobias-urdin | but i'm unsure how i would get nova to detach (read: remove instance) without deleting that rbd volume | |
| 10:02:29 | lyarwood | tobias-urdin: yeah, you can boot from a volume that imports the original image | |
| 10:02:49 | lyarwood | tobias-urdin: there's a boot root disk spec up for review at the moment that would help there | |
| 10:03:21 | lyarwood | tobias-urdin: snapshot the instance into an image, detach the root disk, create a volume from the snapshot image, attach it as the new root disk. | |
| 10:03:40 | lyarwood | tobias-urdin: that's without images_type=cinder btw | |
| 10:04:20 | tobias-urdin | yeah, so if i place images_type=rbd instances on the same pool as cinder creates it's volumes i would (hopefully) be able to snapshot like that and spawn a new instance from that | |
| 10:04:25 | tobias-urdin | and dont have to migrate a whole ceph pool | |
| 10:05:04 | tobias-urdin | that is, when images_type=cinder is available so I somehow could move over images_type=rbd instances | |
| 10:05:39 | tobias-urdin | until then I'll simply hide the option to not spawn from a volume in horizon and instruct API users to spawn from volume-backed but I will assume there will be some stuff spawned with images_type=rbd | |
| 10:06:11 | tobias-urdin | lyarwood: which is what I wanted to plan for, having images_type=cinder would have been awesome right about now :D | |
| 10:11:30 | lyarwood | tobias-urdin: going to summit? https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22786 we should add that to the list | |
| 10:14:43 | tobias-urdin | lyarwood: unfortunately not, i'm pushing for backing to go to next summit and ptg, but right now no :( | |
| 10:15:18 | tobias-urdin | our use case(s) is pretty much bfv only | |
| 10:15:35 | k_mouza | thanks for the help lyarwood! | |
| 10:16:04 | tobias-urdin | second that, thanks lyarwood! :) | |
| 10:16:30 | lyarwood | np | |
| 10:50:43 | openstack | Launchpad bug 1763181 in OpenStack Compute (nova) "test_parallel_evacuate_with_server_group intermittently fails" [Medium,Confirmed] | |
| 10:50:43 | mdbooth | efried: Are you involved at all with https://bugs.launchpad.net/nova/+bug/1763181 btw? (test_parallel_evacuate_with_server_group) | |
| 10:51:05 | mdbooth | I only ask because you mentioned it the other day, and a patch I was looking at just hit it | |
| 11:08:50 | openstackgerrit | Radoslav Gerganov proposed openstack/nova master: VMware: Live migration of instances https://review.openstack.org/270116 | |
| 11:11:38 | openstackgerrit | Radoslav Gerganov proposed openstack/nova master: VMware: Live migration of instances https://review.openstack.org/270116 | |
| 11:12:56 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: Pick next minimum libvirt / QEMU versions for "T" release https://review.openstack.org/605060 | |
| 11:30:53 | pooja-jadhav | hi team, I am facing issue for AMQP driver issue, can anyone help me to sort it out | |
| 12:22:52 | mdbooth | Eurgh | |
| 12:27:40 | sean-k-mooney | mdbooth: is there a six compatiblity shim you can use? | |
| 12:27:54 | mdbooth | sean-k-mooney: Looked, didn't see one | |
| 12:31:37 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: consumer gen: support claim_resources https://review.openstack.org/583667 | |
| 12:31:37 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: consumer gen: more tests for delete allocation cases https://review.openstack.org/591811 | |
| 12:32:34 | sean-k-mooney | mdbooth: well looking at the pull request that intoduced it its a its a trival thing to implement yourself https://github.com/python/cpython/pull/4464/files#diff-edbcdd20abc32f8b018deb2353ae925aR474 | |
| 12:33:42 | mdbooth | sean-k-mooney: Right. It's just messy. | |
| 12:34:01 | sean-k-mooney | mdbooth: infact it look like itss python2 compatiable so just copy past it somewhere under a utils moduel or in common and a test for the python versions and eiterh user our veriosn or the upstream | |
| 12:34:08 | mdbooth | The only reason I even went looking for one is because it's such an obvious thing to want which is likely duplicated all over the place. | |
| 12:34:38 | mdbooth | If you don't need everything, presumably you don't need more than: | |
| 12:34:46 | mdbooth | @contextlib.contextmanager: | |
| 12:34:48 | mdbooth | def null() | |
| 12:34:50 | mdbooth | yield | |
| 12:35:06 | mdbooth | But still... python3-- | |
| 12:35:23 | mdbooth | For pointlessly dividing effort | |
| 12:35:44 | sean-k-mooney | mdbooth: ya we already have this https://github.com/openstack/nova/blob/957f4818b0d89cd71552effb8b5a5b231a68de7b/nova/test.py#L79-L85 so i think its fine to add the same for null | |
| 12:35:45 | jroll | you could also blame it on py2 not being dead yet :P | |
| 12:36:28 | mdbooth | jroll: py2 was a vibrant language with bazillions of lines written. Why kill it and create a new language at all? | |
| 12:37:42 | mdbooth | Fortunately that community has more sense | |
| 12:40:05 | mdbooth | Argh, contextlib.nested() went away in py3 | |
| 12:40:23 | mdbooth | And the new with syntax doesn't support composition | |
| 12:41:13 | sean-k-mooney | mdbooth: i mean if i had the choice then i would depercate C in favor of c++ but that ship has sailed | |
| 12:41:55 | mdbooth | sean-k-mooney: Indeed. The python answer to that was to fire a missile at the departed ship over the horizon anyway. | |
| 12:45:06 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Enable nested allocation candidates in scheduler https://review.openstack.org/585672 | |
| 12:46:59 | openstackgerrit | Chen proposed openstack/nova master: doc: update availability zone doc https://review.openstack.org/605306 | |
| 12:48:44 | mdbooth | Oh, ffs. contextlib.ExitStack looks like what I want, but it's py3 only | |
| 12:54:32 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Use provider tree in virt FakeDriver https://review.openstack.org/604083 | |
| 12:58:44 | efried | mdbooth: No. I've just hit it a bazillion times. | |
| 12:59:45 | mdbooth | efried: I can see a relatively simple solution, but I'm currently trying to formulate a syntax which would work in both py2 and py3 | |
| 13:00:20 | mdbooth | efried: Not related to the other thing I'm working on, btw | |
| 13:00:58 | mdbooth | Amusingly, the bug is called out explicitly in a comment to the other caller of _validate_instance_group_policy: | |
| 13:01:03 | efried | mdbooth: what are you trying to do? | |
| 13:01:05 | mdbooth | # the host is set on the instance. | |
| 13:01:05 | mdbooth | # *after* the resource tracker instance claim, as that is where | |
| 13:01:05 | mdbooth | # NOTE(russellb) It's important that this validation be done | |
| 13:01:19 | mdbooth | efried: Have an optional context manager | |
| 13:01:37 | efried | optional based on what? | |
| 13:01:47 | mdbooth | Whether or not a lock is required | |
| 13:02:21 | efried | can't you have the context manager itself contain the condition? | |
| 13:02:56 | efried | do things | |
| 13:02:56 | efried | if lock_required: | |
| 13:02:56 | efried | yield | |
| 13:02:56 | efried | def cm(...): | |
| 13:02:56 | efried | @contextmanager | |
| 13:02:57 | efried | ? | |
| 13:03:09 | mdbooth | Then I'd have to refactor that whole method to be a context manager | |
| 13:03:44 | efried | do things | |
| 13:03:44 | efried | with cm: | |
| 13:03:44 | efried | if lock_required: | |
| 13:03:44 | efried | or the callers? | |
| 13:03:45 | efried | ? | |
| 13:03:45 | efried | do things | |
| 13:03:45 | efried | else: | |
| 13:04:50 | mdbooth | efried: Anyway, there are a bunch of obvious ways to do this. It's frustrating that they're all ugly though as they're deprecated/removed in py2 and not available in py3, or available only in py2 | |
| 13:04:53 | mdbooth | py3 even | |
| 13:05:03 | efried | okay | |
| 13:05:15 | efried | I'm sure I'll understand better when I see it | |
| 13:05:30 | mdbooth | Some language/library designers failed to consider their users | |
| 13:05:39 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Block automatic transport_url update for cell0 https://review.openstack.org/605414 | |
| 13:08:26 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Skip more rebuild tests for cells v1 job https://review.openstack.org/605416 | |
| 13:08:38 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Block automatic transport_url update for cell0 https://review.openstack.org/605414 | |
| 13:08:48 | edleafe | mdbooth: more likely is that someone proposed the ExitStack addition after py2 was put into maintenance mode. The mistake was OpenStack starting with py2 just because some vendors didn't distribute py3 yet | |
| 13:08:59 | sean-k-mooney | mdbooth: well to be fair they have said they will continue to support it byond 2020 if enough people have not migrated to py3 earlier this year and python3 is 10 years old in december so we have had time to stop using it | |
| 13:09:36 | mdbooth | edleafe: py3 wasn't a safe choice in 2010 :/ | |
| 13:09:48 | edleafe | Sure it was | |
| 13:10:01 | mdbooth | Ok | |
| 13:10:01 | sean-k-mooney | mdbooth: it was not in 2010 but it was in 2014 when 3.4 shipped | |
| 13:10:10 | edleafe | It's just that Ubuntu didn't include it by default, and Xen required py2.4 | |
| 13:10:26 | mdbooth | edleafe: That's 2 reasons right there | |
| 13:10:40 | mdbooth | There were many, many more | |
| 13:10:52 | edleafe | Right, so it isn't python that's the issue; it's the vendors dragging their butts | |