| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-19 | |||
| 19:42:25 | cfriesen | which actually means that the "vanilla" numbers for the neutron utilization would be much worse, since I had duplicate event removal in there. | |
| 19:42:46 | mriedem | do i get a large beer in denver for this? | |
| 19:42:52 | mriedem | s/beer/ginger ale/ | |
| 19:42:54 | cfriesen | oh, definitely | |
| 19:43:38 | melwitt | I don't understand why I would get "This change depends on a change that failed to merge." on a set where when I rebase it locally, I don't see any merge conflicts or auto-merging | |
| 19:43:50 | dansmith | melwitt: depends-on? | |
| 19:44:07 | melwitt | I don't think I have any but I'm checking again | |
| 19:44:42 | mriedem | melwitt: there used to be a thing with zuul where if you rebased a large series, it couldn't keep up with the stream of events, | |
| 19:44:46 | melwitt | yeah, I don't have any Depends-On. ugh, wtf | |
| 19:44:50 | mriedem | and you'd get a merge conflict, even though there wasn't one | |
| 19:44:59 | mriedem | i saw that happening on artom's series the otherday | |
| 19:45:06 | mriedem | it was fixed for months, but might be back | |
| 19:45:08 | mriedem | in black | |
| 19:45:16 | melwitt | okay, I think it's still a thing then. there's 18 patches | |
| 19:45:41 | artom | mriedem, you mean the tagged attach series? | |
| 19:45:48 | mriedem | artom: is there any other? | |
| 19:45:50 | artom | Yeah, anything but the bottom patch gives merge conflict | |
| 19:46:06 | artom | mriedem, it's a secret that I'll reveal when I'm ready | |
| 19:46:22 | melwitt | haha | |
| 19:46:23 | mriedem | artom "tagged attach" lifshitz | |
| 19:46:34 | mriedem | is your new name when i give credits in my album | |
| 19:46:48 | artom | Yey credits! | |
| 19:47:10 | mriedem | right next to seymour duncan pickups | |
| 19:47:54 | artom | So I'll be in the 'Tools' section, gotcha | |
| 19:47:59 | cfriesen | mriedem: you play guitar? | |
| 19:49:29 | mriedem | cfriesen: in the long ago | |
| 19:49:56 | mriedem | they sit in cases in a closet in the basement next to a box of books and yankee candles | |
| 19:49:57 | cfriesen | this guy makes fan-fret basses in my city...I've visited his shop: http://www.dingwallguitars.com/ | |
| 19:50:00 | mriedem | like a true suburbanite | |
| 19:51:15 | nic | Are there party hats? | |
| 19:51:22 | openstackgerrit | Dan Smith proposed openstack/nova master: Fix live migration devstack hook for multicell environment https://review.openstack.org/458537 | |
| 19:51:23 | openstackgerrit | Dan Smith proposed openstack/nova master: Target cell on local delete https://review.openstack.org/464059 | |
| 19:52:36 | melwitt | haha, yup | |
| 19:53:58 | artom | Speaking of party, we're not doing Hawaiian-nick Friday? | |
| 19:54:04 | artom | Not that I ever did it, personally | |
| 19:57:16 | artom | Dammit, length limit cut off the last letter | |
| 20:01:40 | melwitt | wear a hawaiian shirt | |
| 20:01:42 | melwitt | and jeans | |
| 20:01:45 | melwitt | if you want to | |
| 20:01:57 | mriedem | except peter | |
| 20:02:01 | mriedem | he has to come in on saturday | |
| 20:02:02 | openstackgerrit | Matt Riedemann proposed openstack/nova master: nova-manage: Deprecate 'log' commands https://review.openstack.org/453176 | |
| 20:02:03 | openstackgerrit | Matt Riedemann proposed openstack/nova master: nova-manage: Deprecate 'project', 'account' commands https://review.openstack.org/453174 | |
| 20:02:03 | openstackgerrit | Matt Riedemann proposed openstack/nova master: nova-manage: Deprecate 'host' commands https://review.openstack.org/453175 | |
| 20:02:27 | melwitt | hah | |
| 20:07:53 | openstackgerrit | Matt Riedemann proposed openstack/nova master: nova-manage: Deprecate 'log' commands https://review.openstack.org/453176 | |
| 20:08:24 | mriedem | https://review.openstack.org/#/c/453174/ and up are easy +Ws | |
| 20:11:14 | openstackgerrit | Eric Fried proposed openstack/nova master: Adopts keystoneauth with glance client. https://review.openstack.org/412634 | |
| 20:15:36 | melwitt | mriedem: on the first and last of those, the bp isn't mentioned in the commit message. point being, I wondered if they are part of a bp that explains what's going on and why | |
| 20:16:19 | melwitt | the second one links to a non existing bp | |
| 20:16:27 | mriedem | the 2nd one's bp is completed | |
| 20:16:30 | mriedem | the os-hosts removal thing, | |
| 20:16:34 | mriedem | i noted it after that bp was completed | |
| 20:16:42 | mriedem | the series itself is a precursor to move-nova-cmds-to-cliff in queens | |
| 20:16:55 | mriedem | sfinucan wants to deprecate as much as possible from nova-manage before moving the infra for it over to cliff | |
| 20:17:03 | mriedem | making the work he needs to do in queens smaller | |
| 20:17:20 | mriedem | i asked him to remove the bp links for that though since it's not approved for pike, so would have been confusing | |
| 20:19:14 | melwitt | oh, I see. thanks | |
| 20:22:23 | mriedem | another easy one https://review.openstack.org/#/c/463065/ | |
| 20:23:06 | mriedem | and https://review.openstack.org/#/c/391060/ | |
| 20:23:38 | mriedem | ^ is less easy i guess | |
| 20:26:25 | efried | johnthetubaguy mriedem Can I get a sense of the scope of remaining work for bp/use-service-tokens-pike? | |
| 20:26:54 | efried | It appears to be at least driving https://review.openstack.org/412634 to completion - but... is that it? | |
| 20:26:55 | mriedem | efried: i haven't looked | |
| 20:27:11 | mriedem | i think using it for glance is the big one | |
| 20:27:20 | efried | Okay, cause it looks like neutron & cinder are done. | |
| 20:27:25 | mriedem | yes those were done in ocata | |
| 20:27:55 | mriedem | efried: or just look at the spec :) https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/use-service-tokens.html | |
| 20:28:07 | mriedem | https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/use-service-tokens.html#work-items | |
| 20:28:09 | efried | mriedem Well, yeah, I did that | |
| 20:28:12 | mriedem | everything in there is done except for the glance one | |
| 20:28:29 | efried | Okay, just making sure I understood correctly. Thanks. | |
| 20:32:45 | melwitt | mriedem: hm, that reqspec delete one, the commit message points out that it's okay to delete it even if instance destroy fails. I'm thinking of a case where destroy fails, the user decides to just keep the instance around and then things will fail if they do a resize or something that will invoke the scheduler, right? | |
| 20:33:26 | melwitt | bc that reqspec will be gone | |
| 20:33:53 | mriedem | melwitt: did you see the comment i just put in there? | |
| 20:34:07 | melwitt | I just read it a few seconds after I typed in here heh | |
| 20:34:13 | mriedem | b/c i thought about that yesterday or something | |
| 20:34:19 | mriedem | but just remembered to point it out | |
| 20:34:28 | mriedem | we can be sure it's gone if we do a local delete, | |
| 20:34:34 | mriedem | we're less sure if we cast to the compute to delete it | |
| 20:34:39 | melwitt | yeah, it feels like a bit more thought should be put into it | |
| 20:35:41 | mriedem | removed my +2 | |
| 20:35:53 | mriedem | we could delete the reqspec if we are doing a local delete in the api, | |
| 20:36:10 | mriedem | we're going to need a periodic or nova-manage CLI to cleanup orphans from the api db for req spec and instance mappings, | |
| 20:36:28 | mriedem | so we could leave that to cleanup the req spec in the case of soft delete or when we cast to the compute to delete the req spec | |
| 20:36:40 | mriedem | i don't know where a periodic would run, we don't have periodics in the api or conductor, only scheduler | |
| 20:37:19 | mriedem | reqspecs are for scheduling so cleaning up orphans in a periodic task in the scheduler might be ok, but instance mappings don't fit that as nicely | |
| 20:38:56 | melwitt | I was just thinking, as long as the instance has disappeared from the user's perspective (deleted=1) then it's okay to delete the reqspec, since at that point they aren't able to do requests with it anyway (other than listing deleted instance I think) | |
| 20:40:00 | mriedem | but we don't deleted=1 until we're in the compute in most cases, | |
| 20:40:06 | melwitt | I just can't remember where that happens, if it's in compute/api in the case of a cast to compute, or if it's in compute. I guess for the cast it's in compute, which sucks | |
| 20:40:06 | mriedem | and deleted the reqspec there is an upcall, | |
| 20:40:08 | mriedem | which we want to avoid | |
| 20:40:17 | melwitt | yeah | |
| 20:44:44 | openstackgerrit | Eric Fried proposed openstack/nova master: Add service_token for nova-glance interaction https://review.openstack.org/419662 | |
| 20:45:24 | openstackgerrit | Eric Fried proposed openstack/nova master: DNM: Test service token in Glance https://review.openstack.org/419666 | |
| 21:08:08 | mriedem | mordred: what is flavor extra_info? do you mean extra_specs? | |
| 21:14:40 | mordred | mriedem: yes. sorry - was typing from memory | |
| 21:15:04 | mordred | mriedem: some clouds have hundreds of flavors - so it gets expensive :) | |
| 21:15:06 | mriedem | ok, not totally sure why you'd need extra specs, we don't expose those to non-admins by default | |
| 21:16:00 | mordred | I mean- the call works on all of the clouds ... but I was told it was important to have them at some point | |