| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-10-23 | |||
| 12:41:31 | bauzas | this is more a licensing problem than a gerrit problem | |
| 12:41:57 | opendevreview | Takashi Kajinami proposed openstack/nova master: Drop remaining deprecated upgrade_levels option for nova-cert https://review.opendev.org/c/openstack/nova/+/898613 | |
| 12:42:01 | bauzas | so I guess the whole hour will just be about defining the scope of that discussion :) | |
| 12:42:03 | sean-k-mooney | ai generated content is not copyrightable at least under us law | |
| 12:42:36 | sean-k-mooney | more boadly it was establised as a leagl precidnet a few years ago that copyright can only be created for works crated by a human | |
| 12:42:42 | bauzas | yeah I know and that's why I think this is not something solvable on our level | |
| 12:42:58 | sean-k-mooney | that was esablised after a chim too a selfie with a photograper camra | |
| 12:43:18 | bauzas | sean-k-mooney: the problem is more about AI generated content that infrigues copyrights due to its training model | |
| 12:43:53 | bauzas | but again, not something TC can solve or even the board IMHO | |
| 12:43:56 | sean-k-mooney | well they person who submits the patch is atesting that they have the rights to the code that is submited | |
| 12:44:35 | sean-k-mooney | so in practic today that falls on the commiter to ensure they commit they authered with or without assicance is compient with the liscenes ectra | |
| 12:44:45 | bauzas | sure, I guess the board session will be about identifying threats | |
| 12:44:59 | sean-k-mooney | to be clear this would also apply to any non api generated content form variios tools | |
| 12:45:28 | bauzas | yeah I had the color word in my mind | |
| 12:45:56 | bauzas | any assistance to writing some code implies that it doesn't infrigue the copyright | |
| 13:25:36 | artom | https://ptg2023.openinfra.dev/a/ is completely broken for me | |
| 13:26:28 | artom | https://imgur.com/a/52vtguD | |
| 13:26:45 | bauzas | artom: you shouldn't be looking at this website | |
| 13:27:06 | artom | There are many things I shouldn't be doing ;) | |
| 13:27:15 | bauzas | https://ptg.opendev.org/ptg.html is the source | |
| 13:28:03 | artom | Thanks - annoying that that link is completely undiscoverable | |
| 13:28:15 | artom | So Nova "proper" doesn't start until tomorrow, then | |
| 13:43:46 | gibi | artom: yepp | |
| 13:44:09 | gibi | today is rbac, tc, board, and similar discussions are expected | |
| 14:00:38 | kashyap | The infra session is starting now: https://www.openstack.org/ptg/rooms/diablo | |
| 14:06:54 | bauzas | artom: that's why I wrote an email telling about our agenda :) | |
| 14:24:49 | artom | bauzas, not a dig at you, just frustration that literally every vPTG I have the same problem, of not being able to find the schedule and list of room from the official website | |
| 14:31:49 | sean-k-mooney | bauzas: ill be afk for a bit but do you get where i was coming form regardign the config option | |
| 14:32:20 | sean-k-mooney | bauzas: basically i just want to avoid having to make two call to neutron one with the service token and falling back to admin client for port binding | |
| 14:32:47 | sean-k-mooney | so eiter we document that the nova user shoudl also have the service role | |
| 14:33:24 | sean-k-mooney | when neutron is configured to reqiure it or we have a config option to say use_service_tokens | |
| 14:33:33 | sean-k-mooney | in the neutron section until that becomes required | |
| 14:34:40 | sean-k-mooney | i dont really like the documention approch since it may result in passing a token with both admin and service roles when only one of the two should be required | |
| 14:34:49 | sean-k-mooney | but it could work | |
| 14:35:17 | sean-k-mooney | so i would prefer a config option that told use to either use the admin client or not for the transition period | |
| 14:35:54 | sean-k-mooney | ok ill be back at the top of the hour o/ | |
| 14:40:45 | kashyap | Ominous, "the end times", dansmith | |
| 15:09:29 | sean-k-mooney | oh wait there are two board calls | |
| 15:09:38 | sean-k-mooney | did they already disucss the ai topic | |
| 15:09:56 | bauzas | yup | |
| 15:10:17 | bauzas | looks like all the teams are using Zoom | |
| 15:10:32 | bauzas | so I think I'll revert to using it for tomorrow | |
| 15:11:35 | clarkb | kolla is using meetpad | |
| 15:11:39 | kashyap | sean-k-mooney: The etherpad captured some meeting minutes | |
| 15:11:54 | kashyap | sean-k-mooney: It was a good discussion. (I frankly expected less signal; but there was more of it) | |
| 15:12:04 | kashyap | ("Good", but distressing for me.) | |
| 15:12:28 | sean-k-mooney | kashyap: ok i was going to contibnute too that but tought it was at the later slot today | |
| 15:13:07 | sean-k-mooney | i have had good expericne useing copiolt since i paid for a one year subscriptiong in september | |
| 15:13:10 | kashyap | sean-k-mooney: Minutes: https://etherpad.opendev.org/p/oct2023-ptg-openinfra-board | |
| 15:13:28 | sean-k-mooney | i still need to leverage my core review skill set to be critical of the suggestions it makes | |
| 15:13:36 | kashyap | sean-k-mooney: I see. Jay Faulkner also noted his (very interesting to me) exerience w/ a paid co-pilot sub | |
| 15:13:38 | sean-k-mooney | but for an experinced contibutor it has benifit | |
| 15:14:40 | sean-k-mooney | ill read back the comments but i tought this was goign to happen at the na board slot at 21:00 utc | |
| 15:14:46 | kashyap | Yeah, for very new people, he called it [generative AI] as an "extremely attractive nuisance". I'm glad there was a clear distinction between "generative AI" vs. "assissted AI" | |
| 15:14:52 | clarkb | sean-k-mooney: it is at 21:00 as well | |
| 15:14:59 | clarkb | there are two sessions schedueld for the topic | |
| 15:15:16 | kashyap | I see, didn't know that | |
| 15:15:24 | sean-k-mooney | clarkb: ah ok ill try to joint that one if im still online around that time | |
| 15:16:16 | kashyap | s/assisted/assistive/ | |
| 16:18:48 | hamburgler | bauzas: yes you were correct ty :) my oversight | |
| 16:58:00 | bauzas | haleyb: good news, we do have a cross-project item ! | |
| 16:58:13 | bauzas | haleyb: fancy finding a timeslot in common ? | |
| 16:58:59 | haleyb | bauzas: we have timeslots on thursday, one later one on wednesday | |
| 17:00:02 | bauzas | thursday would fit | |
| 17:01:09 | haleyb | bauzas: thursday 15:00 ? | |
| 17:01:30 | bauzas | wfm | |
| 17:01:45 | bauzas | haleyb: don't you mind if we use our etherpad and our room ? | |
| 17:02:32 | haleyb | that works, i'll add the link in our etherpad | |
| 17:02:47 | bauzas | haleyb: https://etherpad.opendev.org/p/nova-caracal-ptg#L300https://etherpad.opendev.org/p/nova-caracal-ptg#L59 | |
| 17:02:50 | bauzas | doh | |
| 17:02:52 | bauzas | https://etherpad.opendev.org/p/nova-caracal-ptg#L59 | |
| 17:40:21 | gmann | bauzas: I added the Nova rbac service role discussion continuation at the bottom in etherpad, https://etherpad.opendev.org/p/nova-caracal-ptg | |
| 17:40:34 | bauzas | gmann: saw it yeah | |
| 18:23:52 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Deprecate use_cow_images and 'default' images_type https://review.opendev.org/c/openstack/nova/+/898229 | |
| 18:23:52 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Fix image conversion check in finish_migration https://review.opendev.org/c/openstack/nova/+/897842 | |
| 19:04:54 | simondodsley | Is there a way to remove a boot volume from a shutdown instance and replace it with a new boot volume (created from an earlier snapshot)? | |
| 19:11:58 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Fix image conversion check in finish_migration https://review.opendev.org/c/openstack/nova/+/897842 | |
| 19:11:59 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Deprecate use_cow_images and 'default' images_type https://review.opendev.org/c/openstack/nova/+/898229 | |
| 20:34:13 | sean-k-mooney | bauzas: there has been a very "interesting" bug that has been evolving over the last few days which i added to the ptg | |
| 20:34:33 | sean-k-mooney | bauzas: https://bugs.launchpad.net/nova/+bug/2038898 https://etherpad.opendev.org/p/nova-caracal-ptg#L444 | |
| 20:35:44 | sean-k-mooney | it woudl be good to read back over that wehn you have time and for others. the reporter has done a lot of testing at my request to determinthe corrent beahvior fo nova and its very much not what i expect | |
| 20:36:58 | sean-k-mooney | images_type=raw is still jsut an aliase fo images_type=flat and does not force convertion to raw. i was aware of th history between those two backend but i tough thwen we renamed raw to flat and added raw as an alais it woudl force image convertion but it does not | |
| 20:37:39 | sean-k-mooney | use_qow_images=true is bacially ignored if you use images_type=flat in that it never force the vm to be qcow | |
| 20:37:59 | sean-k-mooney | if you use image_type=default then use_qow_images=true request in us using image_type=qcow | |
| 20:42:38 | simondodsley | Is this spec ever going to be implemented... https://blueprints.launchpad.net/nova/+spec/detach-boot-volume | |
| 20:43:12 | sean-k-mooney | simondodsley: i dont belive anyone is working on it and i belvie there are still some desgin isues with enabling that | |
| 20:43:27 | sean-k-mooney | simondodsley: so its very unlikely | |
| 20:47:13 | simondodsley | sean-k-mooney it's a pretty fundamental requirement, especially if we want to be able to compete more with VMware. There are a lot of people looking to pivot at the moment and not having a "simple" thing like this won't help | |
| 20:50:05 | clarkb | I think you can emulate it by booting off of a new volume and moving neutron ports over / using fips? | |
| 20:50:59 | clarkb | that said we tend to avoid boot from volume as much as possible and instead prefering to attach volumes for persistent data and then let the OS be more ephemeral | |
| 21:03:00 | simondodsley | clarkb: not convinced that is the main implementation when there are highly intelligent external arrays being used under cinder. All of our customers are either only using boot from volume, or are migrating to it to get away from limitations of local nova disk, or limitations of ceph | |
| 21:04:58 | clarkb | I'm not saying its the main implementation/ I'm just giving my experience as a user. boot from volume is more problematic than the value we get out of it so we try to use volumes more explicitly for where the data lives rather than our operating systems which are actually quite ephemeral | |
| 21:05:11 | clarkb | which is similar to how containers deal with this stuff too | |
| 21:05:57 | clarkb | For example rescuing boot from volume instances is still a bit of an ordeal | |
| 21:08:11 | clarkb | I shouldtest that again actually | |
| 21:13:34 | simondodsley | using boot from volume can be highly advantagous to users as external arrays can both deduplicate and compress volumes on the array and so 100s of VMs can boot from snapshot clones of the boot image, thereby actually using only the size of the source volume on the array. | |
| 21:13:52 | simondodsley | this is why we need features like changing the boot volume to be available. | |
| 21:14:27 | simondodsley | yes, cinder can do restore from snapshot, but that is limited as well. | |
| #openstack-nova - 2023-10-24 | |||
| 01:10:28 | sean-k-mooney[m] | simondodsley: one thing to keep in mind is openstack and nova in particular is not an enterprise virtualisation platform and vmware is not a compator, aws or azure is a better comparison | |
| 01:12:50 | sean-k-mooney[m] | ignoreing the fact ware are likely to remove the vmware driver shortly, vmware is one of the backend hyperviors you can use with nova. but nova is a cloud compute project so feature parity with enterpirse virtualisation software is not a goal for nova | |