| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-08 | |||
| 19:36:43 | melwitt | removes counting of shelved offloaded | |
| 19:36:43 | melwitt | ganso, sean-k-mooney: fwiw ganso's interpretation of my comment is correct, I think it could be debated whether usage should count shelved offloaded instances (same way it could be debated whether quota should count it). that said, I could see it making sense to keep both behaviors consistent (as long as default quota behavior counts shelved offloaded, so does usage). if/when default quota behavior turns to placement counting, usage | |
| 19:38:23 | sean-k-mooney | melwitt: where you in the team meeting when https://review.opendev.org/c/openstack/nova/+/711113 was discuessed | |
| 19:39:02 | sean-k-mooney | that attempted to cahnge the meaning of the usage api to only cound it when the vm was active and running | |
| 19:39:05 | melwitt | no, I missed that | |
| 19:39:12 | melwitt | ah ok | |
| 19:39:48 | sean-k-mooney | we decieded not to basically because we did not want to change its current meaning | |
| 19:40:12 | sean-k-mooney | it could be done but we did not really want too do it as a bug fix | |
| 19:40:46 | sean-k-mooney | its really an api change and im not sure how open we are to adding more uses of or enhanceing the simple tenant usage api | |
| 19:40:49 | melwitt | thanks for that link, that helps | |
| 19:40:59 | sean-k-mooney | personally i would be in favor of eventually removing it | |
| 19:41:17 | melwitt | I see, was just reading through the irc discussion linked on the abandoned patch | |
| 19:41:39 | sean-k-mooney | we could revisit this dicussion | |
| 19:41:50 | sean-k-mooney | if you think there is merit in it | |
| 19:42:13 | sean-k-mooney | but it feels to me that this should be a spec if we were to change the api behavior | |
| 19:42:30 | sean-k-mooney | with a new microverion to request the new behaivor | |
| 19:43:42 | melwitt | eh.. I don't feel that strongly about it. I hadn't considered the broader view that the simple tenant usage api is obsolete | |
| 19:44:25 | sean-k-mooney | melwitt: do you know what the status of unified limits is by the way? | |
| 19:44:32 | melwitt | I'd be ok with tweaking it to make more sense but I'm also ok if most people think it should be left alone as obsolete | |
| 19:45:11 | melwitt | sean-k-mooney: no, I have seen johnthetubaguy around occasionally but haven't seen any activity on unified limits | |
| 19:46:00 | ganso | melwitt, sean-k-mooney: AFAIK it is widely used, despite its falws. If there is no intention in enhancing it further or addressing it flaws, IMO the best way is to deprecate it is usage. Surely other sources of info are better for billing, but a lot of cloud admins use it anyways for billing because it is there and it is convenient | |
| 19:51:26 | melwitt | yeah, that's been my understanding as well. another layer about it is that horizon uses it | |
| 19:59:46 | sean-k-mooney | ganso: i belive cloudkitty was ment for billing | |
| 20:00:05 | sean-k-mooney | melwitt: it does but they are the ones that told us the performacne sucked | |
| 20:00:12 | sean-k-mooney | they use it for the tenant overview page | |
| 20:01:15 | sean-k-mooney | ganso: https://github.com/openstack/cloudkitty | |
| 20:01:25 | sean-k-mooney | CloudKitty aims at filling the gap between metrics collection systems like ceilometer and a billing system. | |
| 20:01:26 | melwitt | yeah... the performance is tied to the number of deleted instances (it uses those to do the usage over time) | |
| 20:01:52 | sean-k-mooney | melwitt: yep have you seen the performace of that page on PSI downstream | |
| 20:01:58 | melwitt | yes | |
| 20:02:03 | sean-k-mooney | its not pretty | |
| 20:02:15 | melwitt | that's why I told them they really need to have their archive cron dialed in | |
| 20:02:35 | sean-k-mooney | well yes that is one reason for that | |
| 20:02:44 | melwitt | yes, one of many | |
| 20:02:52 | sean-k-mooney | did you see the os-archive topic on the mailing list | |
| 20:03:23 | sean-k-mooney | https://github.com/ovh/osarchiver | |
| 20:03:33 | melwitt | ah, yeah | |
| 20:04:03 | sean-k-mooney | assuimg that becomes an offila project we shoudl perhaps exploer if that would be a better approch | |
| 20:04:17 | sean-k-mooney | e.g. move all archiving external to the services | |
| 20:05:00 | sean-k-mooney | they apparently dont use shadow tabels at all and that operats on a retention policy archiving/deleteing deleted instance after a period of time | |
| 20:05:19 | melwitt | re: usage, I think that one is a challenge for operators because if you don't use the "easy" way of nova's tenant usage which just uses soft deleted instances, you need something else to store the info on instances from the past, which means another service as you said. so simple tenant usage appeals in that way | |
| 20:05:58 | sean-k-mooney | ya the placment verion is point in time not a historic view | |
| 20:06:59 | sean-k-mooney | that said im still not conviece this should be an api provide by nova or placment | |
| 20:07:06 | sean-k-mooney | its nice to have | |
| 20:07:09 | melwitt | I wonder if horizon would be ok to have the tenant overview be point in time only | |
| 20:07:30 | sean-k-mooney | if they are then plamcent solves that usecase | |
| 20:07:36 | melwitt | right | |
| 20:07:38 | sean-k-mooney | that is more or less the only think i used that for | |
| 20:08:07 | sean-k-mooney | melwitt: placement does not have soft delete or shaddow tabels for alocations right | |
| 20:08:13 | melwitt | right | |
| 20:08:23 | sean-k-mooney | that proably the right choice | |
| 20:08:33 | sean-k-mooney | but also means we cant look at deleted allcoations | |
| 20:09:04 | melwitt | yeah | |
| 20:09:52 | sean-k-mooney | at the end of the day i think a small service that subsribes to the instance events versioned notifications | |
| 20:10:18 | sean-k-mooney | and maintains the usage externally is proably the way to go | |
| 20:10:30 | sean-k-mooney | but ya extra service | |
| 20:10:36 | melwitt | yeah, I agree. I assume that's what cloudkitty did/does | |
| 20:11:29 | sean-k-mooney | melwitt: im not sure if it pulled form celomiter or not | |
| 20:11:45 | sean-k-mooney | it has a data colector | |
| 20:12:21 | sean-k-mooney | https://github.com/openstack/cloudkitty/tree/master/cloudkitty/collector | |
| 20:12:35 | sean-k-mooney | so it pulls form gnocchi monasca or prometheus | |
| 21:39:14 | openstack | bug 1908075 in OpenStack Compute (nova) "Nova allows a non-multiattach volume to be attached to multiple instances *if* its volume state is reset by an admin" [Low,In progress] https://launchpad.net/bugs/1908075 - Assigned to Lee Yarwood (lyarwood) | |
| 21:39:14 | openstackgerrit | Merged openstack/nova master: Add regression test for bug #1908075 https://review.opendev.org/c/openstack/nova/+/766976 | |
| 22:45:14 | openstackgerrit | Merged openstack/nova master: api: Reject volume attach requests when an active bdm exists https://review.opendev.org/c/openstack/nova/+/768472 | |
| 22:45:45 | openstackgerrit | Merged openstack/nova master: fup: Merge duplicate volume attachment checks https://review.opendev.org/c/openstack/nova/+/773380 | |
| 22:49:57 | openstackgerrit | Ghanshyam proposed openstack/nova master: DNM: testing Tempest without 'member' role https://review.opendev.org/c/openstack/nova/+/774559 | |
| #openstack-nova - 2021-02-09 | |||
| 06:39:28 | openstackgerrit | Yongli He proposed openstack/nova master: smartnic support https://review.opendev.org/c/openstack/nova/+/758944 | |
| 07:59:24 | gibi | dansmith: thanks for the help with the gerrit groups | |
| 07:59:37 | gibi | sean-k-mooney: thanks for the answer on the multiple fixed ip question | |
| 07:59:51 | sean-k-mooney | o/ | |
| 07:59:58 | sean-k-mooney | i hope it made sense | |
| 08:00:05 | gibi | yeah it made | |
| 08:00:24 | gibi | one port is one l2 domain even if it has multiple ips | |
| 08:00:38 | gibi | the trunk port case is interesting but I agree to keep it out of scope | |
| 08:01:25 | sean-k-mooney | ya unless you put a vswitch in between and do some bridging/trunking 1 port can be at most 1 l2 domain | |
| 08:01:50 | sean-k-mooney | if this was real hardar you could only plug one cable into it after all | |
| 08:01:56 | gibi | yepp | |
| 08:02:10 | gibi | those nasty limitation of the physical world | |
| 08:02:31 | gibi | like speed of light | |
| 08:03:02 | gibi | and the pauli exclusion principle | |
| 08:09:01 | sean-k-mooney | :) | |
| 08:09:44 | sean-k-mooney | im +1 on the first two patches and the last 1 and have a question in the 3rd one but nothing minor | |
| 08:10:00 | sean-k-mooney | so hopefully we can get that feature done this week | |
| 08:11:12 | gibi | I hope too, it was a long drag | |
| 08:23:47 | bauzas | gibi: sean-k-mooney: hola | |
| 08:24:04 | sean-k-mooney | bauzas: o/ | |
| 08:24:13 | bauzas | yeah, having IPs from different segments for the same port looked to me weird | |
| 08:24:22 | bauzas | but, alas. | |
| 08:24:55 | bauzas | I've been teached that there are no limits to the creativity of a fooled brain, if this brain works on networking | |
| 08:25:03 | gibi | :) | |
| 08:25:23 | bauzas | anyway, there is a FIXME, I think we're good with this | |
| 08:26:01 | sean-k-mooney | yep | |
| 08:26:14 | bauzas | sean-k-mooney: you said you have a question in the patch, looking | |
| 08:26:23 | sean-k-mooney | multiple ips is fine but multiple ips from different segments not so much | |
| 08:26:30 | sean-k-mooney | patch 3 | |
| 08:26:54 | sean-k-mooney | the get segments by subnet function if i rememebr correctly | |
| 08:27:16 | bauzas | sean-k-mooney: multiple IPs is totally fine | |
| 08:27:21 | bauzas | think of v4 and v6 | |
| 08:27:44 | bauzas | but, indeed, from two different segments, really ? | |
| 08:27:47 | sean-k-mooney | there are cases where it is not. e.g. if they are form different segments on the same port and its not a trunk | |