| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-05 | |||
| 17:38:26 | bauzas | cdent: jaypipes: which microversion patch ? | |
| 17:38:26 | jaypipes | cdent: link to that patch pls? | |
| 17:38:34 | jaypipes | bauzas: jinx :) | |
| 17:38:39 | cdent | https://review.openstack.org/#/c/407742/ | |
| 17:38:56 | bauzas | oh heh | |
| 17:39:04 | bauzas | nice potential conflict to mine \o/ | |
| 17:39:08 | jaypipes | bauzas: that is the patch I *thought* had already merged. | |
| 17:39:19 | bauzas | jaypipes: no, I checked when rebasing | |
| 17:39:49 | bauzas | I need to bail out for a few hours for social and parental reasons | |
| 17:39:53 | jaypipes | bauzas: no, I mean, when I said cdent's patch had merged, that was the one I thought had merged, not the object change one. | |
| 17:39:56 | bauzas | but I should be back | |
| 17:40:00 | jaypipes | k | |
| 17:40:14 | cdent | I think this sort of thing is bound to happen with the way we've (or maybe just I've) habitually separated object change with http change | |
| 17:40:18 | bauzas | jaypipes: but the change of allowed_filters impacts the API, right? | |
| 17:40:36 | bauzas | jaypipes: because we verify that object field at the API level | |
| 17:40:47 | bauzas | so we changed our contract when we modified that list | |
| 17:40:55 | cdent | we're not really in any current danger from that contract change | |
| 17:40:57 | bauzas | another reason like you said to have proper schemas | |
| 17:41:17 | jaypipes | bauzas: yes, unfortunatgely there'll be one or two commits that will have an API change that is technically different from the published microversion 1.3 change. | |
| 17:41:28 | bauzas | :/ | |
| 17:41:36 | bauzas | either way, /me drops | |
| 17:41:43 | openstackgerrit | Matt Riedemann proposed openstack/nova: Update docstring of _schema_validation_helper https://review.openstack.org/417118 | |
| 17:41:54 | jaypipes | bauzas: for a couple commits, GET /resource_providers will accept a member_of param that doesn't use in: | |
| 17:42:00 | cdent | which is not really a big deal is it? anyoe who is a trunk chaser will chase trunk and never notice. and anyone else will never notice | |
| 17:42:13 | jaypipes | cdent: yes, that is my thought as well. | |
| 17:42:37 | cdent | and above and beyond that: the only real user is the resource tracker at this point and it doesn't send anything we don't control | |
| 17:42:48 | jaypipes | right | |
| 17:42:49 | cdent | so the exposure is conceptually bad and but reality-wise not so uch | |
| 17:42:54 | cdent | s/uch/much/ | |
| 17:42:56 | jaypipes | right | |
| 17:42:59 | cdent | cool | |
| 17:44:05 | mriedem | btw, we have query parameter json schema validation now | |
| 17:44:17 | mriedem | but would have to be duplicated in the placement API i guess to use it? | |
| 17:46:46 | cdent | mriedem: jay's added something very similar in the patch bauzas is working on | |
| 17:48:22 | jaypipes | cdent: reviewed. -1 for wording. | |
| 17:48:44 | cdent | roger than jaypipes, will look | |
| 17:50:59 | sdague | mriedem: the upgrade script does the service restart as well at the end, so it could be worked in there one way or another | |
| 17:51:45 | mriedem | sdague: ok i was thinking that grenade was calling devstack to deploy the new code and restart the services in a single shot, contained within devstack, | |
| 17:51:51 | mriedem | which i wouldn't have a hook into possibly | |
| 17:52:00 | mriedem | between install and start of services i mean | |
| 17:53:42 | melwitt | nic: hey, are you around? we've been looking at a rbd bug recently where after shelve/unshelve, the snapshot that was made, can't be deleted from glance. have you run into the same problem? https://bugs.launchpad.net/nova/+bug/1653953 | |
| 17:53:42 | openstack | Launchpad bug 1653953 in OpenStack Compute (nova) "Unable to remove snapshots after an instance is unshelved when using the rbd imagebackend" [Undecided,New] | |
| 17:55:47 | openstackgerrit | Chris Dent proposed openstack/nova: HTTP interface for resource providers by aggregates https://review.openstack.org/407742 | |
| 17:56:33 | cdent | jaypipes: ^ better? | |
| 17:57:30 | cdent | btw, I made your suggested array slice change. I rarely use that, not sure why. I guess I find it semantically ugly. Meaning: I don't like to count. I guess. | |
| 17:58:35 | mriedem | i for one hate slice notation | |
| 17:58:42 | mriedem | because i suck at it | |
| 17:58:56 | jaypipes | +2 from me cdent. mriedem https://review.openstack.org/#/c/407742/ could use your eyes. | |
| 17:59:08 | mriedem | ok i need food first | |
| 17:59:08 | dansmith | slices are the best thing | |
| 17:59:13 | dansmith | since at least, I dunno, sliced bread | |
| 17:59:21 | jaypipes | lol :) | |
| 17:59:24 | mriedem | *rimshot* | |
| 17:59:45 | dansmith | slices are usually the first thing I miss in other languages | |
| 17:59:58 | jaypipes | and since we're going to be rewriting everything in Golang, and slices are a full-fledge type in Golang, we really should use them to their fullest. | |
| 18:00:54 | mriedem | maybe i'll get a slice of pizza | |
| 18:01:01 | dtp | is the [reply done] feature in gerrit used/useful for reviewers? | |
| 18:01:47 | mriedem | dtp: yes | |
| 18:01:52 | mriedem | as an ack that you saw the comment and handled it | |
| 18:01:53 | cfriesen | any chance of getting a second +2 on https://review.openstack.org/#/c/393487 ? Pretty trivial backport to newton, fixes a real issue. (I just tripped over it in Mitaka) | |
| 18:01:55 | dtp | k | |
| 18:02:06 | jaypipes | dtp: yeah, I use it. | |
| 18:02:17 | dtp | coo | |
| 18:04:35 | edleafe | jaypipes: cdent: not crazy about the slice change, since we might need to support "nin" too ("not in") | |
| 18:05:05 | jaypipes | edleafe: meh? :) | |
| 18:05:09 | cdent | edleafe: likely all that hoopa joop is gonna change as a result of the switch to jsonschema validation of query params | |
| 18:05:12 | edleafe | for anti-affinity and such | |
| 18:05:15 | cdent | and nin is yagni talk | |
| 18:05:21 | jaypipes | edleafe: what cdent said :) | |
| 18:05:38 | jaypipes | about the jsonschema thing, not the yagni thing. | |
| 18:05:54 | cdent | won't someone please think of the yagni | |
| 18:06:14 | edleafe | cdent: I am, as in "you ARE gonna need it" :) | |
| 18:07:14 | cdent | [t 25H] | |
| 18:07:14 | purplerbot | <jaypipes> edleafe: meh? :) [2017-01-05 18:05:05] [n 25H] | |
| 18:15:40 | dtp | what is soft delete? | |
| 18:17:08 | dtp | tentative delete but kept on disk for a bit? | |
| 18:17:46 | melwitt | dtp: yeah. "soft delete" as a feature is a deferred delete where there's a config option for low long before it gets really deleted forever. in the meantime, it can be restored | |
| 18:18:15 | dansmith | dtp: soft delete is an abomination | |
| 18:18:19 | dtp | thanks | |
| 18:18:24 | dtp | oh? | |
| 18:20:06 | melwitt | dtp: we often say "soft delete" to mean the way the "deleted" column is used in a lot of the database schemas too, fyi. in the code though, soft_delete means the feature | |
| 18:20:37 | dansmith | yes, there are two soft deletes | |
| 18:20:40 | dansmith | and they're both abominations | |
| 18:20:45 | dansmith | but in different ways | |
| 18:20:55 | dansmith | i.e. two roads to hell | |
| 18:21:16 | dtp | better bring a cooler | |
| 18:21:18 | dtp | when a soft-deleted instance is deleted for realzies, does it go through task_state=DELETING like normal? | |
| 18:21:51 | dansmith | and, that's why it's an abominaton | |
| 18:22:03 | dansmith | because to answer that, I'd have to look at the code, get the answer wrong once, then try again, etc | |
| 18:22:25 | dtp | i see. lets leave that alone for now | |
| 18:22:46 | dtp | i detect no emotional anomalies | |
| 18:23:01 | dansmith | heh | |
| 18:24:51 | mriedem | btw, | |
| 18:24:53 | mriedem | BTW, | |
| 18:25:09 | mriedem | soft delete in the API is configured via a config option that is actually only used on the compute that the instance is running on | |
| 18:25:14 | mriedem | and if those are different, oops! | |
| 18:25:26 | mriedem | s/configured/toggled/ in the api | |
| 18:25:33 | mriedem | so a config-driven API feature | |
| 18:26:34 | mriedem | not that we dont already have crap like that based on which virt driver is on the compute host the instance is running on...but that's more of a known evil | |
| 18:26:36 | melwitt | that's even worse than I thought | |