| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-31 | |||
| 18:25:17 | mriedem | https://review.openstack.org/#/c/441696/ | |
| 18:25:18 | sdague | how did that go? | |
| 18:25:21 | mriedem | not well | |
| 18:25:35 | mriedem | i didn't spend much time on it | |
| 18:25:45 | mriedem | i was hoping the searchlight devstack plugin would configure nova, but it doesn't | |
| 18:26:10 | mriedem | and now the logs are gone so i don't remember what was failing, i'll recheck it | |
| 18:26:26 | mriedem | also, searchlight doesn't have a dsvm job, so they didn't have something i could copy really | |
| 18:26:28 | sdague | so, it feels like one of those things were could define a direction here as we're going to try, but there should be a bit more POC before we commit (and especially punt on doing any of this in nova) | |
| 18:26:34 | sdague | mriedem: ah, bummer | |
| 18:26:59 | mriedem | sdague: the spec is about the general plan | |
| 18:27:12 | mriedem | just like the original resource providers spec was about the general plan, and changed a lot over time | |
| 18:27:28 | sdague | ok | |
| 18:28:08 | mriedem | i also have http://forumtopics.openstack.org/cfp/details/31 proposed | |
| 18:28:40 | mriedem | i agree poc would be ideal | |
| 18:29:15 | mriedem | chances are this won't happen in nova in pike anyway, since there are dependencies on changes in searchlight first | |
| 18:29:17 | mriedem | which don't have owners | |
| 18:29:40 | mriedem | but it's The Plan (tm) | |
| 18:32:27 | sdague | yeh, I guess I'd just soften it further from the recommended mode, given we have no idea if it's going to work. Just say, we think this is going to be a better search approach, and we want to implement an optional backend to get it into the field. | |
| 18:32:46 | sdague | I don't think this is nearly as straight forward an aggressive cut over as placement | |
| 18:32:57 | openstackgerrit | Ken'ichi Ohmichi proposed openstack/nova master: WIP: Add the specified microversion into error msg https://review.openstack.org/451986 | |
| 18:32:58 | openstackgerrit | Ken'ichi Ohmichi proposed openstack/nova master: Remove unnecessary duplicated NOTE https://review.openstack.org/452284 | |
| 18:33:25 | mriedem | i wouldn't say integrating placement has been straightforward | |
| 18:40:23 | mriedem | melwitt: so, i hate to talk about this, but before i fix the bug that's shown in https://review.openstack.org/#/c/449334/ - i'm thinking about what you said where were are committing the quota usage decrement in the api before we delete the instance, and on failure we try to rollback, but that doesn't work | |
| 18:40:52 | mriedem | i noticed something funny in the quota object | |
| 18:41:07 | melwitt | okay | |
| 18:41:10 | mriedem | on commit and rollback, if the reservation is not set, it's a noop | |
| 18:41:11 | mriedem | https://github.com/openstack/nova/blob/master/nova/objects/quotas.py#L100 | |
| 18:41:16 | mriedem | https://github.com/openstack/nova/blob/master/nova/objects/quotas.py#L111 | |
| 18:41:22 | mriedem | i was wondering why we didn't fail | |
| 18:41:38 | mriedem | but those are really invalid operations, if you're trying to commit or rollback reservations before you made the reservation, it's a bug | |
| 18:41:40 | mriedem | right? | |
| 18:41:51 | melwitt | fwiw, I think it's a no-op at the db/api level too, so I don't think it matters | |
| 18:42:06 | mriedem | i'm not sure that's a good reason though | |
| 18:42:13 | melwitt | sure | |
| 18:42:27 | mriedem | but yeah, in the db api methods, if they don't find a reservation, they don't do anything | |
| 18:42:36 | melwitt | yeah, it's not valid to do a commit/rollback without a reserve first | |
| 18:42:36 | mriedem | i was wondering why we didn't get a NotFound error on delete | |
| 18:42:55 | mriedem | https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L3934 | |
| 18:43:11 | mriedem | https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L3922 | |
| 18:43:13 | melwitt | I'm not sure what the reasoning is to do a no-op, if there's some case where that would be a thing | |
| 18:43:15 | mriedem | reservations are just uuids right? | |
| 18:43:29 | melwitt | reservations are records in the reservations tables | |
| 18:43:32 | melwitt | *table | |
| 18:43:36 | mriedem | yeah | |
| 18:43:36 | mriedem | with a uuid | |
| 18:43:40 | mriedem | filter(models.Reservation.uuid.in_(reservations)).\ | |
| 18:44:00 | mriedem | https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L3866 | |
| 18:44:03 | mriedem | is on reserve | |
| 18:44:06 | mriedem | we get the list of uuids back | |
| 18:44:09 | mriedem | and store that in the Quota object | |
| 18:44:20 | artom | Can an instance have multiple fixed IPs? | |
| 18:44:36 | mriedem | so maybe i'll tinker with making commit/rollback w/o a reservation in the object a failure | |
| 18:44:42 | melwitt | artom: I think so, if it's on multiple networks | |
| 18:44:43 | mriedem | and see what falls out | |
| 18:44:49 | artom | melwitt, thanks :) | |
| 18:44:51 | mriedem | artom: yeah definitely | |
| 18:44:53 | clarkb | mriedem: artom also ipv4 + ipv6 | |
| 18:44:54 | mriedem | multinic | |
| 18:45:03 | clarkb | er melwitt artom ^ | |
| 18:45:08 | mriedem | and ipv8 | |
| 18:45:11 | mriedem | it's secret | |
| 18:45:12 | mriedem | and new | |
| 18:45:19 | mriedem | full of tomatoe | |
| 18:45:27 | artom | Are we running out of quarks to give IPv6s to? | |
| 18:45:38 | artom | IoSAP? | |
| 18:45:47 | artom | Internet of SubAtomic Particles... | |
| 18:47:05 | artom | Eesh, one bad joke and everyone shuts up? | |
| 18:47:52 | artom | Wear a bib next time ;) | |
| 18:48:05 | mriedem | you'd have to warn me | |
| 18:48:12 | mriedem | unless i start wearing one full time | |
| 18:48:49 | melwitt | mriedem: yeah, might be worth it to do an experiment. I can't imagine why no-op would be valid other than some sort of race where commit could possibly hit before the reserve and that leaving an orphan reservation is okay | |
| 18:49:12 | melwitt | I can't think of such a race, but I have heard of having a lot of orphaned reservations in the db. so that implies it happens somehow | |
| 18:49:16 | mriedem | maybe comstud is lurking | |
| 18:51:44 | mriedem | interesting https://github.com/openstack/nova/blob/master/nova/quota.py#L1401 | |
| 18:52:09 | mriedem | same with rollback https://github.com/openstack/nova/blob/master/nova/quota.py#L1425 | |
| 18:52:11 | mriedem | we just ignore exceptions | |
| 18:52:13 | mriedem | any exceptions | |
| 18:52:25 | mriedem | no matter how much Vek says that's safe, it seems unsafe | |
| 18:52:40 | melwitt | heh | |
| 18:52:48 | mriedem | " because the usage resynchronization will resolve the issue" | |
| 18:52:53 | mriedem | we don't re-sync by default do we? | |
| 18:53:00 | melwitt | we do. on every reserve | |
| 18:53:39 | melwitt | it will do a sync for that project/user combo | |
| 18:53:56 | melwitt | it doesn't help if some other user in your project is out of sync though | |
| 18:54:34 | mriedem | https://github.com/openstack/nova/blob/master/nova/conf/quota.py#L278 | |
| 18:54:37 | mriedem | i was thinking of ^ | |
| 18:54:40 | melwitt | also a reminder that quota counting will remove reservations and usages | |
| 18:54:56 | melwitt | oh, hm | |
| 18:54:59 | mriedem | and https://github.com/openstack/nova/blob/master/nova/conf/quota.py#L267 | |
| 18:55:05 | mriedem | so i think by default, we don't refresh any of that stuff | |
| 18:55:07 | mriedem | or resync | |
| 18:55:19 | melwitt | yeah, okay. I didn't realize that defaulted to off | |
| 18:55:19 | mriedem | so maybe the comment from Vek was more about, it will fix it, because we at rackspace turn those on... | |
| 18:55:38 | melwitt | if it's on, then on every reserve it does a refresh if needed | |
| 18:55:48 | mriedem | https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L3647 | |
| 18:55:50 | mriedem | yeah if needed | |
| 18:56:00 | mriedem | based on age and until_refresh count | |
| 18:56:05 | melwitt | I think most operators turn it on, since going out of sync happens a fair bit | |
| 18:56:45 | mriedem | so if blindly handling all exceptions https://github.com/openstack/nova/blob/master/nova/quota.py#L1425 and assuming we're ok is dependent on those config options, which default to not doing the thing that comment says we do automatically, | |
| 18:56:52 | mriedem | it seems we should reraise the exception if those options aren't set | |