| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-03-10 | |||
| 09:23:22 | bauzas | pong | |
| 10:05:41 | bauzas | gibi: sean-k-mooney: I would appreciate your comments on a PTL doc amendment https://review.opendev.org/c/openstack/nova/+/875730 | |
| 10:06:24 | bauzas | also, | |
| 10:06:43 | bauzas | gibi: sean-k-mooney: some operators would like to know which specs were implemented :) https://review.opendev.org/c/openstack/nova-specs/+/876887 | |
| 10:07:27 | bauzas | and eventually, a easy peasy for count_blueprints.py https://review.opendev.org/c/openstack/nova-specs/+/876888 | |
| 10:14:32 | bauzas | https://docs.openstack.org/infra/storyboard/gui/theory.html#the-rest-api looks like there is a REST API and a CLI, lovely | |
| 10:14:49 | bauzas | way better to play with than the web ui from what I've seen in the last 30 mins | |
| 10:35:28 | gibi | bauzas: I have only one small commment on the PTL guid patch | |
| 10:35:57 | bauzas | cool | |
| 10:36:20 | bauzas | btw. this isn't a simple task to leave Storyboard AFAIK | |
| 10:36:48 | bauzas | I'll need to discuss this with the infra folks and the storyboard team (if it still exists :) ) | |
| 10:47:43 | bauzas | gibi: that's fun but fwiw, I just noticed last week of takashi's diligence of creating those schedule wikipages every cyvcle | |
| 10:48:19 | gibi | :) | |
| 10:48:23 | bauzas | IMHO if we really want to add more nova-specific deadlines, we would need to stuff it into https://releases.openstack.org/bobcat/schedule.html | |
| 10:48:55 | bauzas | not sure a lot of us still checkouts the wiki besides the meeting agenda :) | |
| 10:49:14 | bauzas | (but don't get me wrong, I like the wiki for its convenience) | |
| 10:49:40 | bauzas | gibi: as you see, we can add project-specific deadlines https://releases.openstack.org/bobcat/schedule.html#project-specific-events | |
| 10:50:07 | gibi | cool that is then probably a better place than the wikipage | |
| 10:58:26 | bauzas | I'll then explain this in the PTL doc | |
| 10:58:35 | gibi | OK | |
| 10:58:57 | bauzas | and next week's meeting, I'll propose the usual times for spec freeze and feature freeze | |
| 10:59:09 | bauzas | so I could add them in the schedule page | |
| 12:02:19 | opendevreview | Sylvain Bauza proposed openstack/nova master: Update to the PTL guide https://review.opendev.org/c/openstack/nova/+/875730 | |
| 12:37:53 | opendevreview | Danylo Vodopianov proposed openstack/os-vif master: Openvswitch driver was extended https://review.opendev.org/c/openstack/os-vif/+/859574 | |
| 13:11:34 | zigo | Is it normal that the openstackclient now shows so many fields when doing "server show", with some fields looking like not useful at all?!? :) | |
| 13:11:50 | zigo | (many fields having no values at all...) | |
| 13:16:40 | zigo | (some being redondant too...) | |
| 13:25:55 | sean-k-mooney | thats more of a client question we dont really have any inflance over that | |
| 13:26:32 | sean-k-mooney | but on the otherhand some people might depend on some of the out put so it might not be wise to remove things | |
| 13:26:42 | sean-k-mooney | peopel will have differnt definitoin of userful | |
| 13:26:58 | sean-k-mooney | zigo: do you have an example out put | |
| 13:27:49 | zigo | sean-k-mooney: https://paste.opendev.org/show/b7FfjsIpFW6o5NS9slD9/ | |
| 13:28:08 | sean-k-mooney | this is what i get as an admin https://paste.opendev.org/show/bHaPZKj88T8mQ5uulgH7/ | |
| 13:28:25 | zigo | What's the point of accessIPv4, accessIPv6, access_ipv4, access_ipv6, private_v4, private_v6 for example? | |
| 13:28:40 | sean-k-mooney | that is not what i get with my version of osc | |
| 13:28:48 | zigo | I have a way more on my setup ... | |
| 13:29:08 | sean-k-mooney | accessIPv4, accessIPv6, are optional feilds that peopel can use to track the ip to use to access a vm | |
| 13:29:24 | sean-k-mooney | it just metadta on the instance that enduser can use it not used by nova | |
| 13:29:25 | zigo | Yeah, except that they are empty, and show twice ... | |
| 13:29:43 | sean-k-mooney | they are empty unless you set them in the server create/update | |
| 13:29:53 | sean-k-mooney | these used ot be used for nova-netowrks | |
| 13:30:27 | sean-k-mooney | what version of osc are you using | |
| 13:30:30 | sean-k-mooney | i was using 6.0.0 | |
| 13:30:39 | zigo | 6.1.0 | |
| 13:31:37 | zigo | The "location" field also looks weird ... | |
| 13:31:41 | sean-k-mooney | ok so ya i get the same now | |
| 13:31:43 | zigo | What's that Munch() thingy? | |
| 13:32:15 | sean-k-mooney | its a clase we use as part of the prtty prining of data | |
| 13:32:29 | sean-k-mooney | its part of how dicts are rendered using click/cliff | |
| 13:32:54 | zigo | All of this, I don't really mind much, but IMO, it's going to confuse users a lot ! | |
| 13:33:08 | sean-k-mooney | zigo: it kind of looks like someone wen through all the files that could be returned and rendered them by default | |
| 13:33:24 | sean-k-mooney | zigo: right but hte nova team is not really invovled in osc | |
| 13:33:26 | zigo | Also, why do we now have attached_volumes AND volumes_attached ? Do we need this *TWICE* ? :) | |
| 13:33:45 | sean-k-mooney | like we were not asked about any of these changes | |
| 13:34:41 | zigo | Ok. | |
| 13:35:19 | sean-k-mooney | https://github.com/openstack/python-openstackclient/commit/794334ec2405bcfe086b3a56c796a9b6c2f7c685 might be related | |
| 13:35:44 | sean-k-mooney | it may have incorectly resulting in --long effectilgy being always used | |
| 13:36:27 | sean-k-mooney | no its this https://github.com/openstack/python-openstackclient/commit/70dbb01ea3ed900a41092d46ed5ae1370d5771af | |
| 13:36:53 | sean-k-mooney | they swap to the sdk but they added a bunch of fields at the same time | |
| 13:39:53 | sean-k-mooney | i would proably have gated the sdk names behind a flag or somethign and doen it in two patchs | |
| 13:40:03 | sean-k-mooney | first just to swap to sdk with current behavior | |
| 13:40:42 | sean-k-mooney | also the client shoudl really use the names of the field n the api resopnce if possible | |
| 13:41:03 | sean-k-mooney | so im not sure we should use the sdk names at all | |
| 13:41:33 | sean-k-mooney | the ones that novaclient used are the ones form the api responce so i proably would have -1 that patch if we had been asked to review | |
| 13:41:49 | sean-k-mooney | stephenfin: ^ for awareness | |
| 13:42:55 | sean-k-mooney | give there have now been two release with that i assume its two late to revert it and disucss this with the wider nova team? | |
| 13:44:18 | sean-k-mooney | we should at least add it to the ptg adgenda i think to disucss this or have a mailing list thread on the topic | |
| 13:45:55 | sean-k-mooney | i dont nessicarly disagree that the new names are more consitent but it breaks the idea that if you want to include a coluem you use -c with the api field | |
| 13:55:31 | zigo | I agree with all you wrote above. :) | |
| 13:55:43 | sean-k-mooney | https://review.opendev.org/c/openstack/python-openstackclient/+/877017 | |
| 13:55:53 | sean-k-mooney | i propsoed a revert so we can discuss the way forward | |
| 13:56:01 | sean-k-mooney | ill add it to the ptg adgenda | |
| 13:56:41 | zigo | You may want to review your patch header (typoes...) :) | |
| 14:21:51 | gibi | bauzas: how do you feel about requiring that share_mapping.id is an sa.BigInteger from the start? | |
| 14:23:28 | bauzas | gibi: good question, I have a PTG topic about it | |
| 14:23:42 | bauzas | maybe not all the tables, but I dunno for this one | |
| 14:24:12 | gibi | bauzas: I will leave a comment to Uggla's but if there is no consensus yet on this then I will keep this optional | |
| 14:24:27 | Uggla | \o/ | |
| 14:24:34 | bauzas | gibi: afaik, all our FK ids are not BigInteger yet | |
| 14:25:41 | gibi | yeah, I just thought that if we already know that we want to increase the key space from sa.Integer to a bigger one to avoid the overflow we saw, then maybe want to have share_mapping with a big key from the start so that table does not need to be changed later | |
| 14:26:05 | bauzas | yup meh to me | |
| 14:32:24 | sean-k-mooney | if we are adding new id fiels i would prefer to use unsigned big ints | |
| 14:32:59 | sean-k-mooney | basically uint64_t in c++ terms | |
| 14:42:25 | bauzas | sean-k-mooney: SQLA doesn't support unsigned ints by default AFAIK https://docs.sqlalchemy.org/en/20/core/types.html | |
| 14:42:42 | bauzas | so you would need to setup an unsigned int object with a mysql variant | |
| 14:43:10 | bauzas | anyway, let's not open this can of worms on a Friday afternoon | |
| 14:44:28 | sean-k-mooney | you have ot use the dialect form yes i know | |
| 14:44:57 | sean-k-mooney | but but what if i want to ruine you weekend :P | |
| 14:45:40 | sean-k-mooney | we can talk about it next week or on the review but i would at least use a BigInteger field | |
| 14:45:51 | sean-k-mooney | 63 bits is still better then 31 | |
| 14:46:05 | bauzas | well, my weenkend is somehow already ruined, the snow isn't there here and the wind is acting like a hairdryer on the very few left snow | |
| 14:47:03 | sean-k-mooney | if we dont want to rely on https://docs.sqlalchemy.org/en/20/dialects/mysql.html#sqlalchemy.dialects.mysql.BIGINT.params.unsigned then im fine with just the generic bigint | |
| 14:47:12 | sean-k-mooney | this is going to be a ptg topic anyway | |
| 14:47:34 | sean-k-mooney | bauzas: we had snow here last night | |
| 14:47:44 | sean-k-mooney | your welcome to come take it back :P | |
| 14:56:04 | bauzas | sean-k-mooney: that depends, how many tracks do you have here ? | |
| 14:56:14 | bauzas | :p | |
| 14:57:08 | bauzas | https://webcams.lecollet.com/imageSC.jpg when I see this, I cry | |
| 15:00:07 | bauzas | dansmith: if you have a bit of time, could we discuss about https://review.opendev.org/c/openstack/nova/+/875621/2 ? | |
| 15:00:26 | bauzas | dansmith: I'm not really a grenade expert, so I need to make sure I understood it correctly | |