| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-22 | |||
| 15:29:53 | efried | cdent It calls _ensure_resource_provider first thing. | |
| 15:29:57 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add the nova-multiattach job https://review.openstack.org/532689 | |
| 15:30:06 | efried | cdent Which creates the provider if it doesn't exist, but in any case populates/refreshes the cache | |
| 15:31:02 | cdent | okay, that's the missing piece of the pie, thank you. | |
| 15:31:16 | mgoddard_ | efried: good call, I'll add a comment | |
| 15:31:31 | efried | cdent The other code path, update_compute_node, does the same (_ensure_resource_provider) | |
| 15:31:43 | cdent | I just wanted to be sure, because of what people had said earlier about the potential for confusion | |
| 15:32:27 | cdent | those comments about potential for confusion had made it seem like there was a chance that the provider tree could either be wrong or even not exist | |
| 15:32:37 | cdent | but since it is established by _ensure_* is cool | |
| 15:32:51 | efried | cdent I doubt it's perfect | |
| 15:33:30 | cdent | and how does that make you feel? | |
| 15:34:36 | efried | cdent Dirty. So dirty. | |
| 15:34:52 | cdent | woot | |
| 15:35:03 | efried | cdent For one thing, as noted above, I've convinced myself that concurrency isn't an issue YET. | |
| 15:35:33 | efried | cdent And we're also working on the theory of merge big stuff early so we can shake out the bugs. | |
| 15:35:50 | efried | cdent Not that I think it's a great policy to count on shaking out bugs later rather than avoiding them by careful inspection beforehand... | |
| 15:36:13 | efried | cdent But we also can't get into analysis paralysis. Gotta walk the line. | |
| 15:36:22 | cdent | i like merge big stuff early | |
| 15:36:33 | cdent | as long as we actually exercise | |
| 15:36:54 | edleafe | "early" != "days before feature freeze" | |
| 15:37:04 | johnthetubaguy | mriedem: gibi: apologies, lots of things been getting in my way, but I am +2 on the multi-attach now, went back though the merged chain, I don't feel qualified for +W for some reason, but gibi you might be happy with that? | |
| 15:37:16 | efried | Well, unless feature freeze is deliberately early in the cycle, to allow time to exercise. | |
| 15:38:49 | mriedem | johnthetubaguy: thanks; just cleaning up the patch that adds the CI job so it's run in the check/gate queue | |
| 15:39:11 | johnthetubaguy | mriedem: ah, cool, I did see the -1 on there | |
| 15:39:23 | mriedem | i think zuul got lost in the long chain of deps | |
| 15:39:24 | mriedem | rechecking it | |
| 15:39:34 | johnthetubaguy | cool | |
| 15:40:30 | mriedem | johnthetubaguy: sdague: we'll need this bug fix to get the multiattach job in - relies on not using pike UCA https://review.openstack.org/#/c/532214/ | |
| 15:40:42 | mriedem | which means you can't snapshot a paused instance with older libvirt | |
| 15:43:39 | gibi | johnthetubaguy: thanks for the review | |
| 15:45:56 | gibi | mriedem: is it OK for you that I +W the multiattach api patch as john is +2 on it or I should wait for new job to run? | |
| 15:46:03 | efried | rgerganov If you're willing to have https://review.openstack.org/#/c/536348/ rebased onto https://review.openstack.org/#/c/535517/ instead of https://review.openstack.org/#/c/531260/ I'll keep it up to date as I work on those WIPs. | |
| 15:46:17 | mriedem | gibi: should be fine to +W - the CI results have already passed for awhile now | |
| 15:46:19 | efried | rgerganov At the moment you're off on a side branch | |
| 15:46:21 | mriedem | i'm just changing the job config | |
| 15:46:32 | gibi | mriedem: OK, thanks | |
| 15:47:41 | efried | gibi Thanks for the reviews! Knocking 'em out today | |
| 15:50:55 | mriedem | edleafe: looks like https://review.openstack.org/#/c/526436/ needs a rebase? | |
| 15:51:32 | jaypipes | cdent: I see you liked my country music song joke. | |
| 15:51:42 | cdent | quite | |
| 15:52:02 | jaypipes | there's been a plethora of jokes and movie references in reviews on efried's latest patch series. | |
| 15:52:11 | jaypipes | I've been having quite a bit of fun. | |
| 15:52:16 | edleafe | mriedem: working on it | |
| 15:52:39 | edleafe | multiattach stepped on RPC versions | |
| 15:53:31 | mriedem | oh yeah | |
| 15:53:34 | mriedem | it was a race | |
| 15:53:47 | amorin | hello everybody | |
| 15:54:36 | jaypipes | amorin: mornin. | |
| 15:54:59 | amorin | I'd like to know if there is a reason of this if iso9660 line: | |
| 15:55:02 | amorin | https://github.com/openstack/nova/blob/stable/newton/nova/virt/libvirt/driver.py#L6602 | |
| 15:55:12 | amorin | I mean, other possibility is vfat afaik | |
| 15:55:34 | amorin | what if nova is transfering the config drive from remote if it is vfat? | |
| 15:56:31 | amorin | jaypipes: evenin :p | |
| 15:56:39 | amorin | (almost 5 pm here) | |
| 15:56:45 | tovin07 | mriedem, hi | |
| 15:57:59 | jaypipes | amorin: well, evening then :) | |
| 15:58:13 | amorin | :) | |
| 15:59:44 | efried | UGT | |
| 16:00:11 | jaypipes | amorin: as for your question... no idea. perhaps mdbooth or lyarwood might know the answer on that one. | |
| 16:00:42 | amorin | jaypipes mdbooth thanks | |
| 16:02:12 | mdbooth | amorin: What's the question? | |
| 16:02:46 | mdbooth | amorin: Ah, you're wondering why the handling difference between iso9660 and vfat? | |
| 16:02:49 | amorin | what if we copy the config-drive no matter its kind (vfat or iso) | |
| 16:02:55 | amorin | yup | |
| 16:03:04 | efried | cdent "For future reference, in the future this loop could be replaced with a single request to POST /allocations, clearing the allocations for all the consumers." <== This must have been a difficult comment to write. The war between "use lots of little API calls" and "use stuff I wrote!" :P | |
| 16:03:13 | amorin | I understand that libvirt is able to copy it if its vfat | |
| 16:03:28 | amorin | but it seems that if nova copy it first, | |
| 16:03:30 | mdbooth | It was (is? but I doubt it) a bug in libvirt/qemu in the handling of iso9660 disks | |
| 16:03:34 | amorin | then libvirt will do nothing | |
| 16:03:46 | efried | cdent Only joshing you of course. The POST is a great idea there. | |
| 16:03:50 | mdbooth | Did you look at the referenced lp bug? | |
| 16:03:56 | amorin | mdbooth: yes | |
| 16:04:12 | amorin | seems that libvirt is still failing with iso | |
| 16:04:39 | amorin | I was just wondering if copying vfat with nova is a bad idea or not | |
| 16:05:26 | sean-k-mooney | amorin: mdbooth i would guesss the bug in libvirt is related to iso beeing treated as cdroms and vfat ect disk being considered hdds or somthin in that vain? | |
| 16:06:12 | sean-k-mooney | amorin: well one way to check would be remove that line and look at the livemigration gate jobs. it might result in both nova and neutron coping the config drive | |
| 16:06:18 | openstackgerrit | Mark Goddard proposed openstack/nova master: Send traits to ironic on server boot https://review.openstack.org/508116 | |
| 16:06:18 | openstackgerrit | Mark Goddard proposed openstack/nova master: Add get_traits() method to ComputeDriver https://review.openstack.org/532290 | |
| 16:06:19 | openstackgerrit | Mark Goddard proposed openstack/nova master: Implement get_traits() for the ironic virt driver https://review.openstack.org/532288 | |
| 16:06:20 | amorin | problem is, imagine you already spawn instances with iso kind, nova needs to copy it before (because of libvirt bug), but in the meantime, you updated the nova config, so CONF.config_drive = vfat | |
| 16:06:32 | amorin | then you never enter this if, and live-migration fail | |
| 16:07:11 | mdbooth | sean-k-mooney: Pretty sure it's something like that. Long time since I had this cached. | |
| 16:07:55 | mdbooth | amorin: So, the other thing that happened since then is that we explicitly specify which disks to migrate using migrateToURI3 | |
| 16:07:56 | amorin | sean-k-mooney: I did try to remove it in my lab, seems to work, I'll try to submit and patch and see the results in gate jobs | |
| 16:08:46 | amorin | mdbooth: ok, got it, migrateToURI3 is then able to migrate the vfat config-drive | |
| 16:10:10 | amorin | mdbooth: but are we sure that migrateToURI3 is able to handle the iso kind? | |
| 16:10:12 | amorin | i'll check | |
| 16:10:13 | mdbooth | IIRC it's because cd-rom drives are read-only, and qemu won't let us write to a read-only disk, even during live migration | |
| 16:10:43 | mdbooth | amorin: The pertinent point about migrateToURI3 is that we specify a list of disks to block migrate explicitly | |
| 16:10:46 | zzzeek | jaypipes: my connection monitoring thing currently lets you put ?plugin=connmon on the SQLAlchemy URL. But Nova Cells shoves DB urls into the database the first time it runs and then they never change :(. So need to add a config flag to oslo.db. But then Nova hardcodes all the oslo flags :) | |
| 16:10:50 | mdbooth | Whereas before it was all disks | |
| 16:11:03 | sean-k-mooney | amorin: is there a reason we migate configdirve instead of recreating on remote side our of interest. technically with vfat it can be readwrite but they are intended to be readonly | |
| 16:11:11 | sean-k-mooney | mdbooth: ^ | |
| 16:11:18 | mdbooth | amorin: So previously we didn't avoid the problematic disks, iirc | |
| 16:11:44 | mdbooth | sean-k-mooney: I believe we do recreate it now | |
| 16:14:07 | tovin07 | this patch passed all zuul gate (had 2+2, A+1). however, it's still open. https://review.openstack.org/#/c/519664/ | |
| 16:14:09 | jaypipes | zzzeek: that is indeed the suck :( | |
| 16:14:20 | zzzeek | jaypipes: this "nova puts the URLs into the DB | |
| 16:14:27 | zzzeek | " thing has been a really huge problem | |
| 16:14:43 | jaypipes | zzzeek: as opposed to, say, a config management system? :) | |