| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-19 | |||
| 11:43:13 | elod | lyarwood: it is (again) a bit too big for my taste for stable, but it's more or less clean if I'm not mistaken.... | |
| 11:43:13 | elod | lyarwood: it is (again) a bit too big for my taste for stable, but it's more or less clean if I'm not mistaken.... | |
| 11:46:43 | lyarwood | elod: yeah agreed it's pretty large but while it's clean I thought it would be useful | |
| 11:46:43 | lyarwood | elod: yeah agreed it's pretty large but while it's clean I thought it would be useful | |
| 11:46:51 | lyarwood | elod: it's something we wanted downstream for Wallaby either way | |
| 11:46:52 | lyarwood | elod: it's something we wanted downstream for Wallaby either way | |
| 11:47:06 | lyarwood | elod: so if we can squeeze it in early this cycle it would be great :) | |
| 11:47:06 | lyarwood | elod: so if we can squeeze it in early this cycle it would be great :) | |
| 11:48:48 | elod | lyarwood: understood :) I'll try to go through the patches today | |
| 11:48:48 | elod | lyarwood: understood :) I'll try to go through the patches today | |
| 11:50:58 | lyarwood | many thanks | |
| 11:50:58 | lyarwood | many thanks | |
| 11:52:57 | gibi | elod: as far as I remember it is a clean cherr-pick all the way. I did a mistake when I first tried to cherry-pick it as I used some old unmereged version of a patch | |
| 11:52:57 | gibi | elod: as far as I remember it is a clean cherr-pick all the way. I did a mistake when I first tried to cherry-pick it as I used some old unmereged version of a patch | |
| 12:04:07 | sean-k-mooney | bauzas: i have been debating about getting an eletric car for a while but 1 i like my mini and 2 i driver maybe 5000KMs per year so its har to justtify spending more then a few grand on a car | |
| 12:04:07 | sean-k-mooney | bauzas: i have been debating about getting an eletric car for a while but 1 i like my mini and 2 i driver maybe 5000KMs per year so its har to justtify spending more then a few grand on a car | |
| 12:08:29 | elod | gibi: that part is OK then :) just have to think whether the series is valid for backport or not o:) (by looking at the code and patches yesterday it was a bit "featurish" for me, but probably there's no risk to backport... but haven't looked all of the patches yet) | |
| 12:08:29 | elod | gibi: that part is OK then :) just have to think whether the series is valid for backport or not o:) (by looking at the code and patches yesterday it was a bit "featurish" for me, but probably there's no risk to backport... but haven't looked all of the patches yet) | |
| 12:32:25 | gibi | elod: it does not change any external interfaces except the two new config options, but those can be removed, if you wish, from the backport. There is also no externally visible behavior change except the fix of the failure | |
| 12:32:25 | gibi | elod: it does not change any external interfaces except the two new config options, but those can be removed, if you wish, from the backport. There is also no externally visible behavior change except the fix of the failure | |
| 12:33:51 | gibi | I guess you feel it as a feature becuase we started using a different mechanism to talk to libvirt regarding the attachment, we went from polling to waiting for events. And waiting for events needed extra preparation in the code | |
| 12:33:51 | gibi | I guess you feel it as a feature becuase we started using a different mechanism to talk to libvirt regarding the attachment, we went from polling to waiting for events. And waiting for events needed extra preparation in the code | |
| 12:35:00 | sean-k-mooney | i dont think its a featue its just a refacotiong | |
| 12:35:00 | sean-k-mooney | i dont think its a featue its just a refacotiong | |
| 12:35:24 | gibi | sean-k-mooney: yes, it needed a sizeable refactoring to properly fix that bug | |
| 12:35:24 | gibi | sean-k-mooney: yes, it needed a sizeable refactoring to properly fix that bug | |
| 12:35:32 | sean-k-mooney | the behaivior before and after modulo bugs is identical from blackbox perspctive | |
| 12:35:32 | sean-k-mooney | the behaivior before and after modulo bugs is identical from blackbox perspctive | |
| 12:35:43 | gibi | yepp | |
| 12:43:51 | elod | yes... the refactor... o:) thanks for the details, it is useful for me to hear other opinions as well! | |
| 12:43:51 | elod | yes... the refactor... o:) thanks for the details, it is useful for me to hear other opinions as well! | |
| 12:44:13 | lyarwood | https://review.opendev.org/c/openstack/nova/+/790660 - core reviews on this bugfix would be appreciated if anyone has time this week | |
| 12:44:13 | lyarwood | https://review.opendev.org/c/openstack/nova/+/790660 - core reviews on this bugfix would be appreciated if anyone has time this week | |
| 12:44:23 | lyarwood | and the series below it sorry | |
| 12:44:23 | lyarwood | and the series below it sorry | |
| 12:44:37 | gibi | lyarwood: added to my queue | |
| 12:44:37 | gibi | lyarwood: added to my queue | |
| 12:44:43 | lyarwood | thanks | |
| 13:18:17 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add same_subtree field to RequestLevelParams https://review.opendev.org/c/openstack/nova/+/791503 | |
| 13:18:18 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Bump min placement microversion to 1.36 https://review.opendev.org/c/openstack/nova/+/791504 | |
| 13:18:18 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support same_subtree in allocation_canadidate query https://review.opendev.org/c/openstack/nova/+/791505 | |
| 13:18:19 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support the new port resource_request format https://review.opendev.org/c/openstack/nova/+/787208 | |
| 13:18:19 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transfer RequestLevelParams from ports to scheduling https://review.opendev.org/c/openstack/nova/+/791506 | |
| 13:28:32 | sean-k-mooney | ... https://twitter.com/freenodestaff https://fuchsnet.ch/freenode-resign-letter.txt | |
| 13:28:32 | sean-k-mooney | ... https://twitter.com/freenodestaff https://fuchsnet.ch/freenode-resign-letter.txt | |
| 13:33:52 | sean-k-mooney | os maybe moving to irc.libera.chat i guess although we will have to see how the topic plays out in the mailing list | |
| 13:33:52 | sean-k-mooney | os maybe moving to irc.libera.chat i guess although we will have to see how the topic plays out in the mailing list | |
| 13:36:32 | kashyap | Yeah; this whole episode seems bizarre | |
| 13:36:32 | kashyap | Yeah; this whole episode seems bizarre | |
| 13:41:07 | sean-k-mooney | its not the first time that this type of thing has happened. its similar to the whole mysql vs mariadb split after the sale to oracale. when legal entities assocaited with opensrouce comunities are sold and the aquiring company desides to put there stamp on comunity it can often result in a split | |
| 13:41:07 | sean-k-mooney | its not the first time that this type of thing has happened. its similar to the whole mysql vs mariadb split after the sale to oracale. when legal entities assocaited with opensrouce comunities are sold and the aquiring company desides to put there stamp on comunity it can often result in a split | |
| 13:42:23 | sean-k-mooney | kashyap: in this case it sound liek the new ownwer of freenode LTD wanted to moitise it in some way and as a result the people that actully ran it but were not employees rightly dont want to have there work or the comunity monitised | |
| 13:42:23 | sean-k-mooney | kashyap: in this case it sound liek the new ownwer of freenode LTD wanted to moitise it in some way and as a result the people that actully ran it but were not employees rightly dont want to have there work or the comunity monitised | |
| 13:44:08 | sean-k-mooney | reading between the lines there is also privacy concerns and perhaps lawful intercept or us law eleemnt to this too | |
| 13:44:08 | sean-k-mooney | reading between the lines there is also privacy concerns and perhaps lawful intercept or us law eleemnt to this too | |
| 13:49:57 | kashyap | I see. I haven't read their story in full, but it's annoying | |
| 13:49:57 | kashyap | I see. I haven't read their story in full, but it's annoying | |
| 14:24:36 | alexe9191 | Good day everyone:) . A while ago i had an issue with the nova scheduler in rocky and I was advised to use the placement api instead of filters. However, we are depending on the instance extra specs aggregate filter to match certain hosts properties. Like for instance, SSD. | |
| 14:24:37 | alexe9191 | Good day everyone:) . A while ago i had an issue with the nova scheduler in rocky and I was advised to use the placement api instead of filters. However, we are depending on the instance extra specs aggregate filter to match certain hosts properties. Like for instance, SSD. | |
| 14:24:59 | alexe9191 | I am wondering if such an option is available for placement? and if so, how to configure nova to use it? it's not clear in the documentation. | |
| 14:24:59 | alexe9191 | I am wondering if such an option is available for placement? and if so, how to configure nova to use it? it's not clear in the documentation. | |
| 14:31:03 | sean-k-mooney | alexe9191: there is a replacemnt yes | |
| 14:31:03 | sean-k-mooney | alexe9191: there is a replacemnt yes | |
| 14:31:24 | sean-k-mooney | https://docs.openstack.org/nova/latest/reference/isolate-aggregates.html | |
| 14:31:51 | sean-k-mooney | alexe9191: its not a direct replacment but it achive the same goal using trait in a slight better way | |
| 14:31:51 | sean-k-mooney | alexe9191: its not a direct replacment but it achive the same goal using trait in a slight better way | |
| 14:32:24 | sean-k-mooney | alexe9191: i say its not a direct replacment because you need update your flaovrs | |
| 14:32:24 | sean-k-mooney | alexe9191: i say its not a direct replacment because you need update your flaovrs | |
| 14:33:35 | alexe9191 | I am assuming I also need to update the hosts one by one to add that trait to each resource class? | |
| 14:33:35 | alexe9191 | I am assuming I also need to update the hosts one by one to add that trait to each resource class? | |
| 14:34:09 | alexe9191 | and also update the flavor to use trait instead of for instance hw:cpu_policy='dedicated' ? | |
| 14:34:09 | alexe9191 | and also update the flavor to use trait instead of for instance hw:cpu_policy='dedicated' ? | |
| 14:34:21 | alexe9191 | or quota:disk_write? something like that | |
| 14:34:22 | alexe9191 | or quota:disk_write? something like that | |
| 14:36:03 | sean-k-mooney | no you would have to create a new flavor with the trait e.g. traits:CUSTOM_SSD=required as an extra spec | |
| 14:36:03 | sean-k-mooney | no you would have to create a new flavor with the trait e.g. traits:CUSTOM_SSD=required as an extra spec | |
| 14:36:11 | sean-k-mooney | the resize the instance to use that trait | |
| 14:36:11 | sean-k-mooney | the resize the instance to use that trait | |
| 14:38:42 | alexe9191 | but that trait need to be saved to the hypervisor provider, correct? or would it be inherited from the aggregate the host is sitting in? | |
| 14:38:42 | alexe9191 | but that trait need to be saved to the hypervisor provider, correct? or would it be inherited from the aggregate the host is sitting in? | |
| 14:39:20 | alexe9191 | Creating new flavors it not the issue. I am wondering if I have to update 800x hypervisors with the new CUSTOM_SSD trait and all other custom traits that i need? | |
| 14:39:20 | alexe9191 | Creating new flavors it not the issue. I am wondering if I have to update 800x hypervisors with the new CUSTOM_SSD trait and all other custom traits that i need? | |
| 14:40:23 | alexe9191 | ah I see. I think you can add the trait to the aggregate as well? | |
| 14:40:23 | alexe9191 | ah I see. I think you can add the trait to the aggregate as well? | |
| 14:40:33 | sean-k-mooney | you add it to the aggreate yes | |
| 14:40:33 | sean-k-mooney | you add it to the aggreate yes | |
| 14:40:56 | sean-k-mooney | you do also have to add it too the compute node RP | |
| 14:40:57 | sean-k-mooney | you do also have to add it too the compute node RP | |
| 14:41:26 | sean-k-mooney | alexe9191: traits live on the resouce provider not the invetories | |
| 14:41:26 | sean-k-mooney | alexe9191: traits live on the resouce provider not the invetories | |
| 14:41:52 | sean-k-mooney | so you woudl put CUSTOM_SSD on all the compute nodes with an SSD | |
| 14:41:53 | sean-k-mooney | so you woudl put CUSTOM_SSD on all the compute nodes with an SSD | |
| 14:42:19 | sean-k-mooney | alexe9191: you can continue to use the old filter by the way | |
| 14:42:19 | sean-k-mooney | alexe9191: you can continue to use the old filter by the way | |
| 14:42:44 | alexe9191 | ah the --property in the flavor you mean? that would be translated to a trait? | |
| 14:42:44 | alexe9191 | ah the --property in the flavor you mean? that would be translated to a trait? | |
| 14:42:59 | sean-k-mooney | alexe9191: no | |
| 14:42:59 | sean-k-mooney | alexe9191: no | |
| 14:43:05 | sean-k-mooney | so there are two ways to do it sorry | |
| 14:43:05 | sean-k-mooney | so there are two ways to do it sorry | |