| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-10-10 | |||
| 16:11:43 | cdent | BUSINESS! | |
| 16:11:47 | elmiko | LOL | |
| 16:11:57 | elmiko | long time no talk, how's life? =) | |
| 16:13:00 | cdent | It's time to go to Healey's Cyder Farm and get a pumpkin | |
| 16:13:10 | elmiko | ooh, nice! | |
| 16:15:21 | cdent | I did a thing recently that might be of api-sig interest, let me see if I can locate it | |
| 16:16:20 | elmiko | lol | |
| 16:18:16 | cdent | can't find it | |
| 16:18:19 | cdent | i hate etherpads | |
| 16:18:30 | cdent | unless you bookmark them all, they are _gone_ | |
| 16:18:58 | elmiko | yeah, i've always wondered about some sort of etherpad indexing service, but i don't know if that goes against the spirit of etherpad | |
| 16:19:07 | cdent | there we go, yellow at the bottom: https://etherpad.openstack.org/p/PVG-u-series-goals | |
| 16:19:11 | elmiko | \o/ | |
| 16:20:04 | elmiko | cdent: if i read your intentions, are you suggesting we should have a "frameworks" guidance doc or something? | |
| 16:20:19 | cdent | I'm not sure if I have an intention | |
| 16:20:28 | cdent | It's more that there was a series of events: | |
| 16:20:29 | elmiko | ack, misread on my part then | |
| 16:20:48 | cdent | discussion in nova about how the api paste file is a pain | |
| 16:21:04 | cdent | led to me saying "hey, I maintain pastedeploy, except I don't, we should stop using it" | |
| 16:21:20 | cdent | then I saw http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010037.html which mentioned that etherpad | |
| 16:21:33 | cdent | so I hailed mary and added an old tune we've heard before | |
| 16:21:56 | cdent | it kind of goes (to a nice blues beat) "let's stop using old stuff" | |
| 16:22:08 | elmiko | lol, yeah | |
| 16:22:59 | elmiko | i was under the impression that refactoring nova away from wsme and paste was considered a task too insurmountable for mere mortals. does it seem more realistic these days? | |
| 16:23:58 | cdent | i went down to austin / for to make me some cloud / yeah I went down to austin / and that cloud was not bad ... | |
| 16:24:08 | cdent | hmmm I am not a blues musician | |
| 16:24:17 | cdent | nova doesn't use wsme, thank fully | |
| 16:24:29 | elmiko | ahh, gotcha | |
| 16:24:34 | elmiko | i'm so out of touch lol | |
| 16:24:40 | cdent | but it does use pastedeploy | |
| 16:24:49 | elmiko | got it | |
| 16:24:52 | cdent | it's just that paste* and wsme are in a class of "old stuff" | |
| 16:25:42 | elmiko | yeah | |
| 16:25:45 | cdent | but yes, to bring it back round to the hereness of the api-sig | |
| 16:26:08 | cdent | it might make sense to have a "for new projects and services use maintained tools, so don't use x, y, z" | |
| 16:26:31 | elmiko | i like the way that is worded | |
| 16:27:00 | elmiko | maybe like a general tech suggestion guideline | |
| 16:27:43 | elmiko | i really don't want to get the api-sig into the business of naming and shaming, but i do like promoting good decision making based on sound principles | |
| 16:29:17 | cdent | I think by saying "use maintained stuff and not these known dead things" avoids naming a champion and is factual about the dead things | |
| 16:31:49 | elmiko | yes! | |
| 16:31:51 | elmiko | totally agree | |
| 16:32:20 | cdent | most successful BUSINESS meeting ever | |
| 16:32:25 | elmiko | i've been trying to work through the existing open pull requests we have, it's slow, but i think i could add this doc to the list. | |
| 16:33:25 | elmiko | thanks for the suggestion cdent, i've added it to my notes | |
| 16:33:34 | cdent | \o/ | |
| 17:02:17 | elmiko | catch y'all later o/ | |
| 20:01:19 | enriquetaso | dtroyer, what do you think of this backport to stable/queens https://review.opendev.org/#/c/679120/1 ? Is it acceptable ? | |
| #openstack-sdks - 2019-10-12 | |||
| 06:41:31 | openstackgerrit | pengyuesheng proposed openstack/osc-lib master: Bump the openstackdocstheme extension to 1.20 https://review.opendev.org/688236 | |
| 06:43:42 | openstackgerrit | pengyuesheng proposed openstack/os-client-config master: Bump the openstackdocstheme extension to 1.20 https://review.opendev.org/688237 | |
| 07:19:07 | openstackgerrit | pengyuesheng proposed openstack/os-service-types master: Bump the openstackdocstheme extension to 1.20 https://review.opendev.org/688250 | |
| #openstack-sdks - 2019-10-14 | |||
| 08:32:43 | openstackgerrit | Bram Verschueren proposed openstack/openstacksdk master: Add support for additional volume backup options https://review.opendev.org/688353 | |
| 10:09:25 | openstackgerrit | Merged openstack/openstacksdk master: Update the constraints url https://review.opendev.org/683862 | |
| 12:06:30 | openstackgerrit | Bence Romsics proposed openstack/openstacksdk master: Add router add/remove route operations https://review.opendev.org/674324 | |
| 12:06:49 | openstackgerrit | Bence Romsics proposed openstack/openstacksdk master: Handle HTTP errors in add/remove router interface calls https://review.opendev.org/687304 | |
| 14:17:31 | openstackgerrit | Merged openstack/openstacksdk master: fix "How To Contribute" url https://review.opendev.org/682803 | |
| 21:10:09 | openstackgerrit | Merged openstack/os-client-config master: Stop testing python2.7 https://review.opendev.org/686589 | |
| #openstack-sdks - 2019-10-15 | |||
| 00:15:04 | openstackgerrit | Brin Zhang proposed openstack/python-openstackclient master: WIP: Add server migrate list CLI https://review.opendev.org/675304 | |
| 07:49:42 | openstackgerrit | Bence Romsics proposed openstack/openstacksdk master: Handle HTTP errors in add/remove router interface calls https://review.opendev.org/687304 | |
| 09:03:54 | openstackgerrit | Brin Zhang proposed openstack/python-openstackclient master: WIP: Add server migrate list CLI https://review.opendev.org/675304 | |
| 12:51:53 | openstackgerrit | Bram Verschueren proposed openstack/openstacksdk master: Add support for additional volume backup options https://review.opendev.org/688353 | |
| 13:06:04 | openstackgerrit | Jihad Dwidari proposed openstack/openstacksdk master: Fixes get_user when identity responses are paged https://review.opendev.org/688704 | |
| 17:57:18 | openstackgerrit | Jihad Dwidari proposed openstack/openstacksdk master: Use 'name' param if not UUID like https://review.opendev.org/688773 | |
| 19:04:31 | openstackgerrit | Jihad Dwidari proposed openstack/openstacksdk master: Fixes get_user when identity responses are paged https://review.opendev.org/688704 | |
| #openstack-sdks - 2019-10-16 | |||
| 02:21:54 | openstackgerrit | Brin Zhang proposed openstack/python-openstackclient master: Microversion 2.79: Add delete_on_termination to volume-attach API https://review.opendev.org/673725 | |
| 14:31:43 | openstackgerrit | Jihad Dwidari proposed openstack/openstacksdk master: Fixes get_user when identity responses are paged https://review.opendev.org/688704 | |
| 15:34:16 | openstackgerrit | Dan Smith proposed openstack/python-openstackclient master: WIP: Add aggregate cache images support https://review.opendev.org/688960 | |
| 15:35:08 | openstackgerrit | Dan Smith proposed openstack/python-openstackclient master: WIP: Add aggregate cache images support https://review.opendev.org/688960 | |
| 18:35:23 | openstackgerrit | Jihad Dwidari proposed openstack/openstacksdk master: Fixes get_user when identity responses are paged https://review.opendev.org/688704 | |
| 20:11:06 | openstackgerrit | Andreas Jaeger proposed openstack/os-api-ref master: Use Ussuri jobs https://review.opendev.org/689032 | |
| 21:01:51 | rm_work | in the SDK, there's two interfaces for clustering it seems, and for example the function `detach_policy_from_cluster` exists on both but has very different signatures | |
| 21:03:04 | rm_work | It seems like doing `sdk_cloud_obj.cluster.detach_policy_from_cluster(..)` uses `openstack.clustering.v1._proxy`, but I want to use `openstack.cloud._clustering` | |
| 21:03:34 | rm_work | any thoughts? mordred maybe? | |
| 21:14:44 | rm_work | ah! teammate found it. just directly do `sdk_cloud_obj.detach_policy_from_cluster` without the extra cluster step | |
| 21:16:37 | mordred | rm_work: yes - that's right. the cloud layer is what used to be shade - and that's totally the right way to use it | |
| 21:16:49 | rm_work | kk | |
| 21:17:03 | rm_work | so in general, avoid using the `.service.*` stuff | |
| 21:39:17 | mordred | rm_work: both are honestly fine to use 0 the service.* is a bit lower-level. the eventual goal is to have the cloud.* methods using the cloud.service.* methods under the covers | |
| 21:39:53 | rm_work | yeah k | |
| 21:40:31 | rm_work | just saw in the response to my ML thread about ospurge that the SDK folks wanted to include similar functionality *builtin*? | |
| 21:40:38 | rm_work | have you looked much at that? | |
| 22:29:28 | mordred | rm_work: yeah - it's actually a todo list item on my side that I was supposed to get started on this cycle but haven't managed to get to yet | |
| 22:29:47 | rm_work | cool | |
| 22:29:52 | rm_work | i'm interested | |
| 22:30:02 | rm_work | been working on ospurge | |
| 22:30:16 | mordred | sweet! | |
| 22:31:22 | rm_work | lol | |
| 22:31:22 | rm_work | though i wish this was further along... we're going to end up in a situation where we deploy a cleanup solution with ospurge internally and then the official solution happens and we have to ... ... spend like three years maintaining a legacy thing and spinning up a project to replace it | |
| 22:31:26 | mordred | I think the idea is that we'd put a call on the Connection object - maybe "purge_project" ? - and then we can have it call lower-level purge_project methods per-service or something like that | |
| 22:31:37 | mordred | rm_work: hah | |
| 22:31:49 | rm_work | i mean, ospurge actually does a pretty good job | |
| 22:31:58 | mordred | rm_work: well - maybe the answer there is to get the sdk purge support in - then make an ospurge release that just uses the purge call in sdk | |
| 22:32:02 | rm_work | could possibly look at lifting/merging some of that stuff in | |
| 22:32:05 | mordred | yeah | |
| 22:33:12 | mordred | I think one of the reasons people wanted it in sdk was so that we could re-consume it from non cli things more easily - so like expose it in heat and horizon and python-openstackclient and maybe adjutant? | |
| 22:33:25 | rm_work | yeah | |
| 22:33:31 | mordred | but I think lifting the ospurge logic in as a starting point would be *great* | |
| 22:33:49 | rm_work | discussion in Shanghai? | |
| 22:34:08 | rm_work | I can set aside some time if we have enough folks there | |
| 22:45:01 | mordred | rm_work: I *think* tobberydberg was gonna set something up | |
| 22:45:47 | rm_work | k | |