| *** tosky has quit IRC | 00:14 | |
| *** LinPeiWen46 has joined #openstack-sdks | 00:36 | |
| *** ricolin has joined #openstack-sdks | 00:37 | |
| *** iokiwi has joined #openstack-sdks | 01:28 | |
| * iokiwi waves | 01:29 | |
| iokiwi | Hi I am working on a fix for this, https://storyboard.openstack.org/#!/story/2007672. According to the docs, the default behavior for `openstack image save` should go to stdout, but recent changes / current implimentation makes it go to memory. | 01:31 |
|---|---|---|
| iokiwi | Is it still desireable that output go to stdout? Should I restore this as the default output? | 01:52 |
| *** enriquetaso has quit IRC | 02:32 | |
| openstackgerrit | Merged openstack/python-openstackclient master: Add "fields" parameter to ListPort query https://review.opendev.org/754117 | 05:08 |
| *** evrardjp has quit IRC | 05:33 | |
| *** evrardjp has joined #openstack-sdks | 05:33 | |
| frickler | iokiwi: it seems there are actually two issues here, both related to the switch from glanceclient to sdk: | 06:35 |
| frickler | a) the default output to stdout is broken | 06:36 |
| frickler | b) osc now tries to buffer the complete image in memory before saving it to a file or stdout, leading to an OOM when the image size is larger than available memory | 06:37 |
| frickler | waiting for gtema to be back online for further discussion | 06:37 |
| frickler | for me, while a) certainly is a regression that should be fixed, b) is the more severe issue | 06:38 |
| *** slaweq has joined #openstack-sdks | 07:00 | |
| openstackgerrit | Simon Merrick proposed openstack/python-openstackclient master: stop image downloads to memory https://review.opendev.org/763317 | 07:11 |
| *** gtema has joined #openstack-sdks | 07:23 | |
| iokiwi | frickler thanks my patch addresses both. Certainly agree that b) is the bigger issue (especially when downloading a 100gb image) | 07:32 |
| * iokiwi is Simon Merrick | 07:32 | |
| openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Complete compute.hypervisor functions https://review.opendev.org/763202 | 07:34 |
| frickler | iokiwi: thanks, that looks much simpler than I had expected. will test later today. it might be good to add a releasenote, though. | 07:36 |
| gtema | that is definitely needed | 07:37 |
| iokiwi | fickler sure I'll add one now | 07:37 |
| gtema | things go easy when you use SDK ;-) | 07:37 |
| iokiwi | Based on the docs, I am not sure sdk will do md5 checksum when stream=True | 07:38 |
| iokiwi | Do you think this will be a problem? | 07:38 |
| gtema | well, the checksum validation is anyway doomed, since many clouds do not do this properly | 07:38 |
| gtema | checking | 07:39 |
| iokiwi | I think the sdk just wont/can't try to do md5 sum so to be more specific, is the md5 checksum important enough to us to implement it? Based on your comment above, maybe not. | 07:40 |
| gtema | it is important that this possibility remains in SDK as is, since there are other users (except OSC) depending on it | 07:41 |
| gtema | well, looking to the code I don't see it would change the behaviour really. | 07:43 |
| gtema | it was initially designed to be either output or stream, not both together | 07:43 |
| *** ralonsoh has joined #openstack-sdks | 07:43 | |
| gtema | so as long as you download image into file I do not think there is effect of this change | 07:48 |
| gtema | (since my cloud disabled image download I can't really verify anything) | 07:48 |
| frickler | gtema: saving a 50g image to a file gives OOM for me with latest, works fine with 5.1.0. setting test up with the patch now | 07:50 |
| frickler | the patch fixes that and also the stdout issue. does get some not so nice output when pipe fails, but that might be fixed in a followup http://paste.openstack.org/show/800191/ | 07:54 |
| *** tremble has quit IRC | 07:55 | |
| openstackgerrit | Simon Merrick proposed openstack/python-openstackclient master: stop image downloads to memory https://review.opendev.org/763317 | 07:58 |
| *** nikparasyr has joined #openstack-sdks | 07:59 | |
| gtema | that's weird. I can't understand why it should change the behavior | 07:59 |
| openstackgerrit | Carlos Goncalves proposed openstack/openstacksdk master: Add ALPN support to load balancer pools https://review.opendev.org/752097 | 08:00 |
| gtema | aah, overseen where it goes also to | 08:00 |
| frickler | gtema: see the sdk docs, default downloads the complete image to memory before writing it to the file | 08:01 |
| gtema | I know, I was reworking this whole stuff heavily | 08:02 |
| gtema | just forgot where which param goes into - it's a spaghetti | 08:02 |
| *** rpittau|afk is now known as rpittau | 08:03 | |
| *** gtema has quit IRC | 08:05 | |
| *** gtema has joined #openstack-sdks | 08:06 | |
| *** tosky has joined #openstack-sdks | 08:44 | |
| *** tremble has joined #openstack-sdks | 09:05 | |
| *** jpich has joined #openstack-sdks | 09:08 | |
| *** holser has joined #openstack-sdks | 09:33 | |
| *** ricolin has quit IRC | 09:38 | |
| *** dtantsur|afk is now known as dtantsur | 09:41 | |
| *** frenzy_friday has joined #openstack-sdks | 09:44 | |
| openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Complete compute.hypervisor functions https://review.opendev.org/763202 | 10:27 |
| openstackgerrit | Sagi Shnaidman proposed openstack/ansible-collections-openstack master: Migrating routers_info from AnsibleModule to OpenStackModule https://review.opendev.org/763149 | 10:28 |
| openstackgerrit | Mark Chappell proposed openstack/openstacksdk master: Add support for Block Storage (v3) VolumeType Encyption resources https://review.opendev.org/756655 | 10:44 |
| *** tremble has quit IRC | 11:10 | |
| *** tkajinam has quit IRC | 11:29 | |
| *** tkajinam has joined #openstack-sdks | 11:30 | |
| *** enriquetaso has joined #openstack-sdks | 12:01 | |
| *** camelCaser has quit IRC | 12:15 | |
| *** ricolin has joined #openstack-sdks | 12:18 | |
| *** holser has quit IRC | 12:29 | |
| *** rpittau is now known as rpittau|brb | 13:16 | |
| *** holser has joined #openstack-sdks | 13:35 | |
| openstackgerrit | Merged openstack/ansible-collections-openstack master: Migrating routers_info from AnsibleModule to OpenStackModule https://review.opendev.org/763149 | 13:47 |
| gtema | how was that command to start meeting? | 14:01 |
| gtema | #startmeeting SDK/OSC | 14:02 |
| openstack | Meeting started Thu Nov 19 14:02:17 2020 UTC and is due to finish in 60 minutes. The chair is gtema. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:02 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:02 |
| *** openstack changes topic to " (Meeting topic: SDK/OSC)" | 14:02 | |
| openstack | The meeting name has been set to 'sdk_osc' | 14:02 |
| diablo_rojo | o/ | 14:02 |
| amotoki | hi | 14:02 |
| gtema | hey | 14:03 |
| stephenfin | o/ | 14:03 |
| gtema | ping gouthamr | 14:03 |
| gouthamr | o/ | 14:03 |
| gtema | do we want to use meetpad for voice meeting, or due to the time differences better in text ;-) | 14:03 |
| gtema | no opinions? | 14:04 |
| gtema | agenda for the meeting is under https://etherpad.opendev.org/p/openstacksdk-meeting-agenda | 14:05 |
| amotoki | I have no strong preference on it, but most openstack projects use irc meetings and text meeting would be preferred in general. | 14:05 |
| gtema | no problem | 14:05 |
| diablo_rojo | Please just text lol | 14:06 |
| gtema | oki, was thinking | 14:06 |
| gtema | #topic Add Resolution of TC stance on the OpenStackClient Patch | 14:06 |
| *** openstack changes topic to "Add Resolution of TC stance on the OpenStackClient Patch (Meeting topic: SDK/OSC)" | 14:06 | |
| diablo_rojo | This way we have logs and don't need to take notes. | 14:06 |
| gtema | I left my +1 (yet again) | 14:06 |
| gtema | I am (not actually really wondering) - even this way there is some resistance from the community | 14:07 |
| gtema | what is the plan of TC, to push on it or still try to get agreement from everyone | 14:08 |
| gtema | ? | 14:08 |
| gtema | https://review.opendev.org/#/c/759904/ | 14:08 |
| diablo_rojo | We are trying to get that merged as a way forward. | 14:08 |
| diablo_rojo | I do think its close, people just want more detail than we originally wanted to provide. | 14:08 |
| gtema | this is already expressed very "weak". Is there a plan to really have a harder control? | 14:09 |
| * gouthamr takes a note on reviewing ^ | 14:09 | |
| gtema | ok, moving next, since there is actually no further action points | 14:10 |
| gtema | #topic Gerrit Breach Audit | 14:10 |
| *** openstack changes topic to "Gerrit Breach Audit (Meeting topic: SDK/OSC)" | 14:10 | |
| gtema | I did audit immediately when it was announced, but most likely forgot to send info about that | 14:11 |
| diablo_rojo | the resolution is more of a stepping stone towards the end goal. A diplomatic way of starting to make progress. | 14:11 |
| gtema | I have updated the linked etherpad with the info as well | 14:11 |
| diablo_rojo | Oh cool, so all good then? | 14:11 |
| diablo_rojo | Perfect. | 14:11 |
| diablo_rojo | Thanks gtema! | 14:12 |
| gtema | welcome | 14:12 |
| stephenfin | gtema: You mean force patches for OSC? Not beyond the TC proposal, no. We need to rely on soft power more than hard power. It's not possible to force things through without the approval of the team, so we need to work to win those people over | 14:12 |
| amotoki | gtema: did you audit all repos under openstacksdk? | 14:12 |
| gtema | I reviewed both from gerrit side and from the attached commits. But due to the amount of projects under the SDK team ;-) I might have missed something | 14:12 |
| gtema | sdk, python-openstackclient, openstackclient, os-service-types | 14:12 |
| gtema | cliff, osc-lib | 14:13 |
| stephenfin | fwiw, I think only Glance have pushed back. Everyone else is onboard, though not everyone has allocated resources (my nova is purely spare time stuff) | 14:13 |
| amotoki | gtema: https://governance.openstack.org/tc/reference/projects/openstacksdk.html#deliverables lists our repos | 14:13 |
| gtema | oh yes. shade as well | 14:13 |
| stephenfin | tja | 14:13 |
| stephenfin | *that's effectively EOL though | 14:14 |
| gtema | will again ensure requestsexceptions and js-openstack-lib are covered | 14:14 |
| gtema | tja - sounds so "german" | 14:14 |
| gtema | don't tell me you are located in germany :) | 14:14 |
| gtema | #topic Manila SDK work in Wallaby | 14:15 |
| *** openstack changes topic to "Manila SDK work in Wallaby (Meeting topic: SDK/OSC)" | 14:15 | |
| gtema | as mentioned - I think we generally need to start merging Manila bits into SDK | 14:16 |
| gouthamr | hey! this was me. i had an update to share, and a couple of questions | 14:16 |
| gtema | I know from own experience it is extremely hard to both add new services (complete) | 14:16 |
| gtema | and also reviewing is terrible | 14:16 |
| gtema | thus suggestion - get small things with resource by resource | 14:16 |
| gouthamr | i agree, i saw your comment on | 14:17 |
| gouthamr | #link https://review.opendev.org/#/c/638782/ (WIP: Add support for shared file systems (manila)) | 14:17 |
| gouthamr | we'll break the patch down into individual resources | 14:17 |
| gtema | I would suggest you have a look yourself whether what is already there is working or not | 14:17 |
| gtema | if yes - remove WIP status and let the reviews start | 14:18 |
| stephenfin | gouthamr: Are you planning to work on OSC integration in parallel? | 14:18 |
| gouthamr | yeah, the WIP never fell off of it, because the original author has moved on; and we're trying to pick up the work this cycle | 14:18 |
| gtema | he - interesting question, since manila has own client | 14:18 |
| amotoki | gtema: will the OSC integration be implemented as a plugin, right? | 14:19 |
| gtema | afaik it is already a plugin | 14:19 |
| amotoki | no gtema. i would like to mention gouthamr | 14:19 |
| gouthamr | stephenfin: yes, the OSC work is ongoing - we've about 50% parity with the python-manilaclient | 14:19 |
| gtema | https://opendev.org/openstack/python-manilaclient | 14:19 |
| gouthamr | and yes, the native client houses the plugin ^ | 14:19 |
| amotoki | thanks. it is nice | 14:19 |
| stephenfin | gouthamr: okay, good to hear :) | 14:20 |
| gtema | I guess once the SDK part lands they can start consuming it to hopefully generally reduce efforts | 14:20 |
| gouthamr | +1 | 14:21 |
| gouthamr | great, my update is that we're working with a few new university contributors to submit the openstacksdk bits | 14:21 |
| gtema | I see manila is really evolving on the API part | 14:21 |
| gouthamr | hopefully, i'll have them here in the next meeting :) | 14:21 |
| gtema | are there lots of changes planned for this cycle? | 14:22 |
| gouthamr | gtema: yes, we do hope to finish the openstacksdk by X, so much of the user facing resources you see in https://review.opendev.org/#/c/638782/ are planned for wallaby | 14:22 |
| gtema | I mean on manila itself | 14:23 |
| gtema | when the change was initially started I know it was pretty close to cover all APIs | 14:23 |
| gouthamr | i don't anticipate changes in manila, wdym? | 14:23 |
| gtema | but since then lots of new APIs were added | 14:23 |
| gouthamr | oh | 14:23 |
| gtema | okay, I thought you might be knowing | 14:24 |
| gouthamr | that'll not stop happening though :) | 14:24 |
| gtema | okay then | 14:24 |
| gtema | moving on | 14:24 |
| amotoki | do we need functional test coverage in SDK in addition to unit test? it can be the next step though. | 14:24 |
| gtema | I think better to add those as well, but no objections of doing this in a follow-up | 14:25 |
| stephenfin | if we're doing functional tests, we need to think about how we do so | 14:25 |
| gtema | tests are taking sometimes 70% of the change itself | 14:25 |
| stephenfin | the functional tests in OSC are _very_ racy | 14:25 |
| gtema | that's absolutely correct stephenfin | 14:25 |
| gtema | mostly those racy tests are coming from nova ;-) | 14:26 |
| stephenfin | unfortunately so :( | 14:26 |
| gtema | for sure we would need to start using more projects not to really corrupt things | 14:26 |
| stephenfin | yup | 14:26 |
| stephenfin | work for the future though, once we've more gaps closed | 14:27 |
| gtema | oki | 14:27 |
| gouthamr | i had a couple of other questions | 14:27 |
| gouthamr | and gtema answered one of them in the etherpad | 14:27 |
| gtema | the remaining is about tracking, right? | 14:28 |
| gouthamr | does openstacksdk work need a spec? we intend to write one to plan our work | 14:28 |
| gtema | we do not use specs currenlty | 14:28 |
| gouthamr | ah | 14:28 |
| gtema | I do not know whether those were ever used in SDK/OSC | 14:28 |
| amotoki | I don't think we need a spec. what we need is just to be aware of the effort as impls would be straight-forward. | 14:29 |
| gtema | correct | 14:29 |
| amotoki | this kind of meetings would really help it :) | 14:29 |
| gtema | something like spec might be required for the discussion we had with stephenfin yesterday | 14:30 |
| gouthamr | ack - thanks; i'll not bother you with it then; the spec was more for project planning and some designing - if we write one, we'll keep it in manila-specs | 14:30 |
| gtema | about what is better in OSC | 14:30 |
| gtema | 'openstack aggregate cache image __aggregate__ __image1__ __image2__ ...' | 14:30 |
| gouthamr | (we did write a spec for our osc work too - we can argue endlessly about subcommand naming) :D | 14:30 |
| gtema | or 'openstack aggregate cache image __aggregate__ --image __image1__ --image __image2__ ...' | 14:31 |
| gouthamr | (^ and things like that) | 14:31 |
| gtema | there are 2 types currently used in different areas | 14:31 |
| gtema | and we might need to agree what is the standard | 14:31 |
| stephenfin | yes, this is a place where we're missing a BDFL (Benevolent Dictator For Life) to settle things for us | 14:31 |
| stephenfin | In the absence of dtroyer, we should probably put together a style guide? | 14:32 |
| gtema | hehe, I am not the one - tell you right now | 14:32 |
| amotoki | it is a topic on how our CLI command should be composed. i think it can be discussed as a document change proposal in OSC | 14:32 |
| stephenfin | Nonsense. All hail, gtema | 14:32 |
| stephenfin | :P | 14:32 |
| stephenfin | amotoki++ yeah, I think this would be a great addition to the docs | 14:32 |
| gtema | amotoki - right. We should start perhaps one | 14:32 |
| * stephenfin can do put together a strawman proposal | 14:33 | |
| stephenfin | s/do // | 14:33 |
| stephenfin | and then we can debate it on Gerrit | 14:33 |
| diablo_rojo | I look forward to reviewing :) | 14:33 |
| gtema | #action - start a style guide for osc | 14:33 |
| amotoki | :) | 14:33 |
| gouthamr | #link https://docs.openstack.org/python-openstackclient/latest/contributor/humaninterfaceguide.html | 14:34 |
| gouthamr | ^ this one already exists, though | 14:34 |
| gtema | right | 14:34 |
| gtema | I new I was seeing this once, but completely forgot | 14:34 |
| gouthamr | and specifically: https://docs.openstack.org/python-openstackclient/latest/contributor/command-options.html | 14:34 |
| gtema | great, might need some extension | 14:35 |
| amotoki | they are good starts. If there are something not covered, we can cover more cases. | 14:36 |
| stephenfin | yes, good call. I didn't know that existed | 14:36 |
| gouthamr | sometimes patterns there don't make sense in all situations; an optional parameter is really required: https://docs.openstack.org/python-openstackclient/latest/contributor/command-options.html#required-options | 14:36 |
| gouthamr | "required options" :D | 14:36 |
| stephenfin | bit on an oxymoron, yes /o\ | 14:37 |
| gtema | okay, moving next | 14:37 |
| gtema | #topic Status OSC to use SDK for nova part | 14:37 |
| *** openstack changes topic to "Status OSC to use SDK for nova part (Meeting topic: SDK/OSC)" | 14:37 | |
| gtema | I think we are progressing with stephenfin quite good on that | 14:38 |
| gtema | of course there is still lot to cover | 14:38 |
| gtema | I am explicitly afraid of starting changing 'server' operations - that would be a challenge | 14:39 |
| gtema | stephenfin, do you know whether this cycle we get something new from nova? | 14:39 |
| *** yolanda has quit IRC | 14:40 | |
| stephenfin | it shouldn't be _too_ bad - most server actions are implemented by POSTing a simply JSON body to the server actions API | 14:40 |
| stephenfin | gtema: There were no API changes in Victoria. There are only minor changes (to the os-hypervisors API) planned for Wallaby so far | 14:40 |
| gtema | yes, it is always _easy_, until you start working on it | 14:40 |
| stephenfin | True :) | 14:40 |
| gtema | oh, changes in hypervisor? | 14:40 |
| gtema | just working on switching it | 14:40 |
| stephenfin | Yes, but I'm doing that so I'll handle the SDK changes when I do it | 14:41 |
| gtema | with few cool things: until 2.53 you use 1 API to search, after - another | 14:41 |
| stephenfin | oh, there's also a spec proposed to remove the final references to 'tenant_id' from the API, in favour of 'project_id'. It's not approved yet but it will be I suspect | 14:41 |
| gtema | and then https://opendev.org/openstack/python-openstackclient/src/branch/master/openstackclient/compute/v2/hypervisor.py#L124 | 14:41 |
| stephenfin | yeah, there's been a lot of that /o\ | 14:42 |
| gtema | I guess tenant_id/project_id is not a big deal at all | 14:42 |
| gtema | wrt this mentioned renaming I am currently thinking to return DictColumn instead of this renaming | 14:42 |
| gtema | I do not think it is really useful to do this renaming, especially that it requires hacking | 14:43 |
| gtema | what do you think? | 14:43 |
| gtema | I agree this is a "breaking" change | 14:43 |
| gtema | but we anyway plan to bump a major release after this rework is done | 14:44 |
| stephenfin | no issues from me | 14:44 |
| gtema | okay, great | 14:44 |
| stephenfin | so long as we signal it with a major version bump, yes | 14:44 |
| gtema | I hope OSC part will arrive today | 14:44 |
| amotoki | from POV of consumers, it would be nice if both of project_id and tenant_id can be used transparently. | 14:44 |
| gtema | I guess since very long time those are everywhere translated to project_id | 14:45 |
| amotoki | I am not sure what part is discussed, nova API interaction or SDK abstraction? | 14:45 |
| gtema | well - more about switching OSC to use SDK for nova part | 14:45 |
| gtema | on the other hand stephenfin has also some UX improvents in head while we touch those | 14:46 |
| gtema | stephenfin - do you have ideas in which order we should touch remaining things? | 14:47 |
| gtema | I was thinking to leave server to be last | 14:47 |
| gtema | since it is huge | 14:47 |
| gtema | but might be better other way around | 14:47 |
| stephenfin | No ideas, no. Whatever suits, really | 14:47 |
| stephenfin | I'm planning to continue closing gaps with OSC and novaclient | 14:47 |
| gtema | okay. For server I will be definitely create smaller patches switching individual commands of the server or server action | 14:48 |
| gtema | since otherwise we will immediately get into some sort of long lock | 14:48 |
| stephenfin | Makes sense | 14:49 |
| stephenfin | I'll keep using the novaclient library to implement the CLIs until the necessary SDK bits are there to switch over | 14:49 |
| gtema | ok | 14:49 |
| stephenfin | because I don't yet understand SDK well enough /o\ | 14:49 |
| gtema | I am not sure what is really better - do switch first and extend, or first extend and then switch to SDK | 14:50 |
| gtema | SDK is a voodoo thanks to mordred ;-) | 14:50 |
| stephenfin | extend and switch means we have a known baseline | 14:51 |
| gtema | there are just few persons around the world probably who completely understand SDK | 14:51 |
| *** rpittau|brb is now known as rpittau | 14:51 | |
| gtema | agree on that, but | 14:51 |
| stephenfin | i.e. I know novaclient works. I don't necessarily know new OSC changes works | 14:51 |
| stephenfin | also, I'm adding missing options more so than missing commands | 14:51 |
| gtema | before the switch I go to SDK and verify it can do everything what API provides | 14:51 |
| gtema | so SDK should be supporting everything for OSC to be able to implement missing params | 14:52 |
| gtema | okay | 14:53 |
| gtema | diablo_rojo - do you have students already you were mentioning in PTG? | 14:53 |
| gtema | the ones who can support this work | 14:53 |
| diablo_rojo | Still working on the one from OSU. | 14:54 |
| diablo_rojo | But the BU students are already working with gouthamr | 14:54 |
| gtema | okay | 14:54 |
| diablo_rojo | I just got the email calling for projects for NDSU students in the spring so I will start working on putting that together tomorrow probably. | 14:55 |
| gtema | great | 14:55 |
| gtema | I think we would be in time with the switch for nova command toward SDK this cycle - we are maybe 40% through currently | 14:55 |
| gtema | maybe we can also start doing that for cinder as well, since I have a feeling those are now also a bit unhappy with OSC functionality | 14:56 |
| openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: Make use of comparable 'FormattableColumn' subclasses https://review.opendev.org/761447 | 14:56 |
| openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: compute: Fix 'server * -f yaml' output https://review.opendev.org/761205 | 14:56 |
| openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: compute: Fix 'usage * -f yaml' output https://review.opendev.org/761595 | 14:56 |
| openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: compute: Fix 'server group * -f yaml' output https://review.opendev.org/761596 | 14:56 |
| openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: compute: Fix 'hypervisor show -f yaml' output https://review.opendev.org/763004 | 14:56 |
| openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: compute: Add 'server group create --rule' option https://review.opendev.org/761597 | 14:56 |
| openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: compute: Add 'server show --topology' option https://review.opendev.org/680928 | 14:56 |
| openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: trivial: Use plural for appended parameters https://review.opendev.org/761598 | 14:56 |
| gtema | come on stephenfin - you want you work to be logged in the meeting minutes ;-)? | 14:56 |
| diablo_rojo | gtema, stephenfin if you want me to make the NDSU proposal geared toward Nova work I can do that, but I will need your help with the mentoring :) | 14:56 |
| stephenfin | gtema: Gerrit reviews wait for no meeting :) | 14:57 |
| gtema | :D | 14:57 |
| gtema | oh yes, mentoring | 14:57 |
| amotoki | hehe. it might be a good trick to raise your reviews :) | 14:57 |
| gtema | I guess in next couple of month this might be hard with the time for real mentoring | 14:58 |
| stephenfin | diablo_rojo: That's interesting and maybe possible, but I'd need to run it by folks internally first | 14:58 |
| gtema | no problem explaining/onboarding, but not really deeper mentoring | 14:58 |
| gtema | okay, let's see how it evolves | 14:59 |
| diablo_rojo | stephenfin, I think I have till the 30th to put together the project proposal, but I can get an extension if need be (I have in the past). | 14:59 |
| stephenfin | okay, I'll run it by people and see what they think. Should have an answer by EOW | 15:00 |
| diablo_rojo | In the past is been 3-4 students for a semester and I usually met with them once a week for an hour. | 15:00 |
| diablo_rojo | Perfect :) | 15:00 |
| gtema | if we get students we can actually also run in parallel work for cinder part, and not really nova | 15:01 |
| gtema | then we have 200% output in the cycle | 15:01 |
| stephenfin | Sounds good | 15:02 |
| stephenfin | gtema: I think we're at time? | 15:02 |
| diablo_rojo | Good meeting :) | 15:02 |
| gtema | yes, right | 15:02 |
| diablo_rojo | Over by a couple min. | 15:02 |
| gtema | sorry, long thinking | 15:02 |
| diablo_rojo | gtema, no worries :) | 15:02 |
| diablo_rojo | Thanks for hosting! | 15:02 |
| gtema | any questions unanswered? | 15:02 |
| gtema | #endmeeting | 15:03 |
| *** openstack changes topic to "Bug tracker for SDK and OSC is now at https://storyboard.openstack.org" | 15:03 | |
| openstack | Meeting ended Thu Nov 19 15:03:09 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:03 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/sdk_osc/2020/sdk_osc.2020-11-19-14.02.html | 15:03 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/sdk_osc/2020/sdk_osc.2020-11-19-14.02.txt | 15:03 |
| amotoki | thanks all. it is really a nice time to sync our efforts :) | 15:03 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/sdk_osc/2020/sdk_osc.2020-11-19-14.02.log.html | 15:03 |
| gtema | great | 15:03 |
| gtema | thanks everybody for joining | 15:03 |
| gtema | have a nice day/evening/night or whatever else you have now | 15:04 |
| *** tosky has quit IRC | 15:18 | |
| *** tosky has joined #openstack-sdks | 15:22 | |
| *** tosky has quit IRC | 15:26 | |
| *** Hybrid512 has joined #openstack-sdks | 15:40 | |
| dtantsur | gtema: do we have a calendar file for this meeting. I think I've just learned about it :) | 15:46 |
| *** tosky has joined #openstack-sdks | 15:50 | |
| gtema | uhm, it's every 3rd thursday of the month | 15:53 |
| gtema | I don't know whether there is some export | 15:53 |
| dtantsur | is it an official meeting? | 15:53 |
| gtema | yes | 15:53 |
| gtema | https://review.opendev.org/#/c/762590/ | 15:53 |
| dtantsur | aha, JFYI this is the information with an ICS file: http://eavesdrop.openstack.org/#OpenStackSDK | 15:54 |
| gtema | wow, that's a great find | 15:55 |
| gtema | uhm, I should have used different meeting name upon start | 15:56 |
| *** evrardjp has quit IRC | 16:17 | |
| *** nikparasyr has left #openstack-sdks | 16:32 | |
| *** mgariepy has quit IRC | 16:34 | |
| *** mgariepy has joined #openstack-sdks | 16:36 | |
| *** rpittau is now known as rpittau|afk | 16:52 | |
| *** bverschueren has quit IRC | 17:06 | |
| *** bverschueren has joined #openstack-sdks | 17:08 | |
| openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Complete compute.hypervisor functions https://review.opendev.org/763202 | 17:15 |
| *** bverschueren has quit IRC | 17:18 | |
| *** bverschueren has joined #openstack-sdks | 17:18 | |
| openstackgerrit | Artem Goncharov proposed openstack/python-openstackclient master: Switch hypervisor operations to SDK https://review.opendev.org/763414 | 17:21 |
| openstackgerrit | Artem Goncharov proposed openstack/python-openstackclient master: Switch hypervisor operations to SDK https://review.opendev.org/763414 | 17:23 |
| *** ralonsoh_ has joined #openstack-sdks | 17:27 | |
| *** gtema has quit IRC | 17:27 | |
| *** gtema has joined #openstack-sdks | 17:28 | |
| *** ralonsoh has quit IRC | 17:28 | |
| *** jpich has quit IRC | 17:28 | |
| *** gtema has quit IRC | 17:28 | |
| *** gtema has joined #openstack-sdks | 17:29 | |
| *** gtema has quit IRC | 17:54 | |
| *** gtema has joined #openstack-sdks | 17:55 | |
| *** gtema has quit IRC | 17:59 | |
| *** dtantsur is now known as dtantsur|afk | 18:23 | |
| *** ralonsoh_ has quit IRC | 18:53 | |
| *** gtema has joined #openstack-sdks | 19:11 | |
| *** gtema has quit IRC | 19:24 | |
| *** gtema has joined #openstack-sdks | 19:29 | |
| *** Hybrid512 has quit IRC | 19:53 | |
| *** gtema has quit IRC | 20:04 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!