Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-15
11:07:27 stephenfin But yeah, </rant> :)
11:07:36 stephenfin stupid Gerrit :mutter mutter:
11:07:43 kashyap stephenfin: Yeah, I hear the pain, I just try to focus on the core content, and the formatting not to be egregious
11:08:05 stephenfin kashyap: Do. It would be a good thing to finally resolve
11:08:05 kashyap stephenfin: BTW, slightly related: Some people seem to think 'patchwork' is "dead"
11:08:18 stephenfin Oh, really?
11:08:23 kashyap stephenfin: And QEMU folks have written their own: http://patchew.org/
11:08:32 kashyap There's a bit of overlap with 'patchwork'
11:08:56 kashyap stephenfin: See this snippet:
11:08:56 kashyap 17:59 < kashyap> bonzini: Isn't there some overlap between 'patchew' and 'patchwork'?
11:08:59 kashyap 17:59 < bonzini> kashyap: yeah, but patchwork seemed dead when patchew was started
11:09:02 kashyap From a week or so ago
11:09:09 kashyap (On OFTC, #qemu)
11:09:24 stephenfin Yup, that's been around for a while. At the time Patchwork _was_ dead
11:09:40 kashyap Ah-ha, I see
11:09:43 stephenfin Was only when I and another Intel dev started working on it (for freedesktop) that it started moving forward again
11:10:03 kashyap Most people used 'patchwork' as just a "tracker" of patches, though
11:10:03 stephenfin Guess the two could be folded in but meh, I've barely any time to work on Patchwork of late
11:11:30 Spaz-Work Nova meeting is 2100 today right?
11:17:32 kashyap Spaz-Work: Not sure the hour; there are two timings
11:18:00 Spaz-Work Yeah think this week is the 2100.. sitting here late in the day trying to convert that to CDT. Guess i'll read the logs :D
11:18:03 Spaz-Work Poor night shift hours.
11:32:31 openstackgerrit Zhenyu Zheng proposed openstack/nova master: WIP https://review.openstack.org/553288
11:33:11 mdbooth johnthetubaguy, any chance you might be able to squint at this bugfix for me: https://review.openstack.org/#/c/551302/
11:33:47 mdbooth Incidentally, who has anything to do with Hyper-V?
11:35:11 stephenfin mdbooth: claudiub is your man
11:35:26 mdbooth claudiub, Any chance you could look at ^^^ for me?
11:36:38 mdbooth lyarwood, it deletes a bunch of connection_info-related libvirt driver code in live migration if you'd care to look
11:37:20 mdbooth claudiub, I don't think it's an issue for Hyper-V, except that it might potentially fix bugs. It's a change, though, which is why I highlight it.
11:38:56 openstackgerrit Surya Seetharaman proposed openstack/nova master: Add disabled column to cell_mappings table. https://review.openstack.org/552505
11:40:15 lyarwood mdbooth: ack, will look
11:58:00 openstackgerrit Hironori Shiina proposed openstack/nova master: ironic: Get correct inventory for deployed node https://review.openstack.org/553367
11:59:27 ameeda Hello, I am trying to upload image from server1 to openstack "server2" using rest api. when I did that I got error message "504 Gateway Time-out The server didn't respond in time."
12:02:15 lyarwood mdbooth: LGTM, however there's no volume backed LM tests at present http://logs.openstack.org/02/551302/6/check/legacy-grenade-dsvm-neutron-multinode-live-migration/3e0cf62/job-output.txt.gz#_2018-03-13_19_30_46_058750 - due to https://bugs.launchpad.net/nova/+bug/1524898
12:02:16 openstack Launchpad bug 1524898 in OpenStack Compute (nova) "Volume based live migration aborted unexpectedly" [High,In progress] - Assigned to Lee Yarwood (lyarwood)
12:03:25 openstackgerrit Lee Yarwood proposed openstack/nova master: Enable test_volume_backed_live_migration in tempest https://review.openstack.org/528104
12:04:23 lyarwood mdbooth: ^ you can use this change from melwitt to test LM with volume backed instances
12:28:14 mdbooth lyarwood, Will do, thanks!
12:30:09 mdbooth lyarwood: Short of adding a depends on to my patch, what's the best way to run against that?
12:30:52 mdbooth lyarwood: Not that I'd mind adding a depends on if the test patch is likely to get some priority.
12:31:41 lyarwood mdbooth: another change on top of https://review.openstack.org/528104 that depends on your change?
12:31:59 mdbooth lyarwood: Good idea, thanks.
12:33:44 openstackgerrit Matthew Booth proposed openstack/nova master: DNM: Run volume-backed live migration tests https://review.openstack.org/553377
12:55:46 openstackgerrit Andrey Volkov proposed openstack/osc-placement master: Get resource provider by uuid or name https://review.openstack.org/527791
13:02:10 lpetrut mdbooth: Hi, thanks for letting us know. I took a look over the patch and it looks good, it shouldn't affect the Hyper-V driver. High chance is that we'd only have issues with the Dell iSCSI driver that you're mentioning in the commit (which should be fixed by it).
13:02:53 mdbooth lpetrut: What changes is that I'm now passing the *old* bdms to post_live_migration instead of the new ones
13:03:10 mdbooth So connection_info will relate to the source host, which is where it's actually running, rather than the destination
13:03:12 lpetrut mdbooth: do you know by any chance if there are any other iSCSI drivers that would return different connection info among hosts (i.e. have a different conn info on the destination)?
13:03:37 mdbooth lpetrut: Potentially a lot, I think
13:03:47 mdbooth That particular issue has been around for ages
13:03:54 lpetrut for FC it would look different but that's fine as disconnect_volume is a noop for FC in our case
13:04:15 mdbooth The new issue is that there's one driver where initialize_connection doesn't return the same value if you call it a second time for the *same* host
13:04:37 lpetrut got it
13:05:50 mdbooth lpetrut: This was the original bug: https://bugs.launchpad.net/nova/+bug/1475411
13:05:52 openstack Launchpad bug 1475411 in nova (Ubuntu Trusty) "During post_live_migration the nova libvirt driver assumes that the destination connection info is the same as the source, which is not always true" [Undecided,Fix released]
13:06:05 mdbooth That's obviously from 2015
13:06:54 mdbooth Affects 3par, apparently: https://bugs.launchpad.net/nova/+bug/1288039
13:06:55 openstack Launchpad bug 1288039 in OpenStack Compute (nova) "live-migration cinder boot volume target_lun id incorrect" [High,Fix released] - Assigned to Anthony Lee (anthony-mic-lee)
13:08:14 mdbooth Anyway, if Hyper-V uses that cinder driver, my expectation is that my new change will fix it
13:08:27 lpetrut thanks for the link, indeed, that should fix it
13:09:36 lpetrut I was thinking about submitting a bug report against our driver for posterity reasons, marking your patch as a fix
13:10:54 lpetrut I was not aware of the 3par issue, high chance is that we were leaking volume connections and nobody noticed
13:11:56 mdbooth Is anybody aware of a way to make devstack do git checkouts, install pip dependencies, and then stop?
13:23:37 kashyap mtreinish might know ^
13:24:58 cdent mdbooth: is this in a session you're running by hand or something you want to automate
13:28:44 cdent mdbooth: if the former, probably just hack an exit in stack.sh
13:29:02 ameeda any help? Hello, I am trying to upload image from server1 to openstack "server2" using rest api. when I did that I got error message "504 Gateway Time-out The server didn't respond in time."
13:29:22 ameeda I set glance conn timeout to 0 , with no lucks
13:30:04 cdent mdbooth: also grep on TRACK_DEPENDS; let's you bail out after install
13:30:32 openstackgerrit Matt Riedemann proposed openstack/nova master: Make nova-cells-v1 run with neutron https://review.openstack.org/549789
13:30:32 openstackgerrit Matt Riedemann proposed openstack/nova master: Cleanup tempest-dsvm-cells-rc blacklist https://review.openstack.org/553401
13:31:16 tssurya mriedem : owe you one for the NewtonCellCheck patch, thanks
13:31:43 openstackgerrit Matt Riedemann proposed openstack/nova master: Cleanup tempest-dsvm-cells-rc blacklist https://review.openstack.org/553401
13:31:49 mriedem tssurya: np
13:32:21 ameeda mriedem: Hello :) , could you please help me with my issue ?
13:32:59 mriedem ameeda: um, check the logs
13:33:36 ameeda mriedem: let me check , thanks
13:36:28 mdbooth cdent: Automate. I'm trying to build a base devstack image with all the config-agnostic stuff pre-done. Will look at TRACK_DEPENDS, thanks.
13:36:59 kholkina hi all! could you please review the spec? https://review.openstack.org/#/c/547964
13:40:20 claudiub|2 mdbooth: sorry, I was out for a bit. Will look at it.
13:41:05 mdbooth claudiub|2: Thanks. lpetrut already looked, btw.
13:44:30 ameeda mriedem: I check this log /var/log/glance/api.log, I didn't find anything helpful , also this command journalctl -u openstack-glance-api.service -f
13:45:51 SamYaple ameeda: how did you deploy glance? uwsgi? apache? eventlet?
13:46:53 mriedem kholkina: -2 on that idea, you can already update user-data via rebuild now
13:47:03 mriedem a lot of thought and discussion already went into adding that to rebuild
13:47:05 mriedem see http://lists.openstack.org/pipermail/openstack-operators/2017-October/014309.html
13:47:12 ameeda SamYaple: I create python project to use contact with openstack via rest api, I use http requests as rest client
13:47:47 mriedem ameeda: this isn't really the channel for this type of question - try #openstack or #openstack-glance
13:49:14 ameeda everything working on my project, also I test the project on packstack, its working, but this case have to copy image file from server1 to openstack server, so the image file not exists on the same openstack
13:50:41 ameeda mriedem: I will try the other channels, thank you
13:52:15 efried jaypipes, cdent: Opinion on https://review.openstack.org/#/c/548975/5/nova/scheduler/client/report.py@592 ?
13:52:38 cdent efried: explicit is better than implicit
13:52:52 cdent some version ought to be listed there
13:52:58 kholkina mriedem, the spec means to update user-data on booted instance, without rebuild. It may be useful to provide a cloud-config
13:54:15 efried cdent: Even if it's '1.0'?
13:54:18 jaypipes efried: yeah, agree with alex_xu_ it would be good to be consistent there.
13:54:25 cdent efried: yes
13:54:30 jaypipes efried: no biggie though, really
13:55:01 efried cdent: Okay. Note that there's places we don't do that, elsewhere in the report client. A big enough deal to put up a patch to fill those in?
13:55:08 cdent no

Earlier   Later