*** slaweq has joined #openstack-sdks | 00:11 | |
openstackgerrit | Merged openstack/openstacksdk master: Handle old status-less placement service https://review.opendev.org/711328 | 00:20 |
---|---|---|
*** slaweq has quit IRC | 00:27 | |
*** slaweq has joined #openstack-sdks | 01:11 | |
*** slaweq has quit IRC | 01:16 | |
*** tkajinam has quit IRC | 01:49 | |
*** tkajinam has joined #openstack-sdks | 01:50 | |
*** slaweq has joined #openstack-sdks | 02:11 | |
*** enriquetaso has joined #openstack-sdks | 02:14 | |
*** slaweq has quit IRC | 02:16 | |
*** enriquetaso has quit IRC | 02:31 | |
*** slaweq has joined #openstack-sdks | 03:11 | |
*** slaweq has quit IRC | 03:16 | |
*** slaweq has joined #openstack-sdks | 04:11 | |
*** slaweq has quit IRC | 04:16 | |
*** slaweq has joined #openstack-sdks | 05:11 | |
*** evrardjp has quit IRC | 05:35 | |
*** evrardjp has joined #openstack-sdks | 05:35 | |
*** slaweq has quit IRC | 05:38 | |
*** factor has quit IRC | 05:47 | |
*** factor has joined #openstack-sdks | 05:48 | |
*** efried has quit IRC | 06:07 | |
*** efried1 has joined #openstack-sdks | 06:07 | |
*** efried1 is now known as efried | 06:09 | |
*** efried has quit IRC | 07:22 | |
*** efried has joined #openstack-sdks | 07:22 | |
*** efried has quit IRC | 07:23 | |
*** efried has joined #openstack-sdks | 07:23 | |
*** iurygregory has joined #openstack-sdks | 07:56 | |
*** tkajinam has quit IRC | 08:16 | |
*** ralonsoh has joined #openstack-sdks | 08:22 | |
*** jpena|off is now known as jpena | 08:26 | |
*** jpich has joined #openstack-sdks | 09:01 | |
*** Shrews has quit IRC | 09:07 | |
*** dayou has quit IRC | 09:07 | |
*** iokiwi has quit IRC | 09:08 | |
*** irclogbot_2 has quit IRC | 09:08 | |
*** gtema has joined #openstack-sdks | 09:08 | |
*** gtema has quit IRC | 09:15 | |
*** tosky has joined #openstack-sdks | 09:25 | |
*** sshnaidm|afk is now known as sshnaidm | 09:37 | |
*** Shrews has joined #openstack-sdks | 09:43 | |
*** dayou has joined #openstack-sdks | 09:43 | |
*** iokiwi has joined #openstack-sdks | 09:43 | |
*** irclogbot_2 has joined #openstack-sdks | 09:43 | |
*** openstackstatus has quit IRC | 09:45 | |
*** dtantsur|afk is now known as dtantsur | 10:24 | |
dtantsur | mordred: yep, as far as I remember, futurist extends stdlib | 10:26 |
*** slaweq has joined #openstack-sdks | 11:18 | |
openstackgerrit | Merged openstack/openstacksdk master: Add port property: ip_allocation https://review.opendev.org/711237 | 11:43 |
mgoddard | I think ansible 2.9.6 has broken openstack modules | 12:06 |
mgoddard | we're seeing this everywhere in kolla: | 12:06 |
mgoddard | https://b317bafa0db642d61e9b-babe6b68bec526aecbe80deed799da2b.ssl.cf2.rackcdn.com/711295/3/check/kolla-ansible-centos-source/b02cb5e/primary/logs/ansible/deploy | 12:06 |
mgoddard | py2 and py3 | 12:06 |
*** jpena is now known as jpena|lunch | 12:09 | |
*** slaweq has quit IRC | 12:18 | |
*** slaweq has joined #openstack-sdks | 12:30 | |
*** slaweq has quit IRC | 12:34 | |
*** jpich has quit IRC | 12:40 | |
*** jpich has joined #openstack-sdks | 12:41 | |
*** dave-mccowan has joined #openstack-sdks | 13:09 | |
*** enriquetaso has joined #openstack-sdks | 13:25 | |
openstackgerrit | Merged openstack/openstacksdk master: Implement If-Match support for Neutron resources https://review.opendev.org/710030 | 13:30 |
frickler | mordred: you just got me slightly confused by adding sdk core to osc core, doesn't that preempt the governance patch a bit? | 13:45 |
*** mgariepy has quit IRC | 13:46 | |
*** mgariepy has joined #openstack-sdks | 13:52 | |
openstackgerrit | Merged openstack/openstacksdk master: Include "fields" to "SecurityGroup" query parameters https://review.opendev.org/710820 | 14:00 |
mgoddard | odyssey4me: hi | 14:22 |
*** jpena|lunch is now known as jpena | 14:29 | |
*** ccamel has joined #openstack-sdks | 14:41 | |
*** camelCaser has quit IRC | 14:42 | |
mordred | mgoddard: AWESOME. I'm poking and trying to reproduce the traceback at the moment but havne't been able to yet - might need to hold a test node | 14:50 |
mgoddard | mordred: I have more info | 14:50 |
mordred | frickler: yeah - I was in there doing core team update from the mailing list and figured I just go ahead and take care f that too ... might be a little ahead of myself | 14:50 |
mgoddard | mordred: see my comment on https://github.com/ansible/ansible/pull/67577/files | 14:50 |
mgoddard | it's an easy fix | 14:50 |
mgoddard | just patching up kolla then I'll raise a bug in ansible and push a fix | 14:51 |
mgoddard | seems like everything is breaking this week | 14:51 |
mordred | aha! cool. and yes - it does seem that way | 14:51 |
mordred | mgoddard: fwiw - once we've switched the modules to the collection, we can co-gate them on kolla | 14:51 |
mordred | and prevent stuff like that | 14:52 |
mgoddard | mordred: I think the existing jobs would have caught it. It was a bit of custom code for 2.8 in a backport | 14:52 |
mordred | AH | 14:52 |
mgoddard | looks like no CI for 2.8? | 14:52 |
mordred | yeah - I don't think we run openstack jobs on stable-2.8 - which is probably a mistake :) | 14:53 |
mordred | let me go see if I can rectify that | 14:53 |
mgoddard | that would be nice | 14:54 |
openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Add ansible stable-2.9 job and run 2.8 and 2.9 https://review.opendev.org/711471 | 14:57 |
mordred | mgoddard: ^^ that - and remote: https://review.opendev.org/711474 Run openstacksdk functional jobs on ansible 2.8 and 2.9 | 14:58 |
mordred | and yeah - if the tests had been hooked up that should have caught that | 14:59 |
mordred | mgoddard: ping me when you push up the ansible fix and I can lgtm it | 14:59 |
openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Switch to futurist for concurrency https://review.opendev.org/711301 | 15:06 |
mordred | dtantsur: that one ^^ should be green now | 15:07 |
openstackgerrit | Monty Taylor proposed openstack/ansible-collections-openstack master: Deal with collection build modifying tree https://review.opendev.org/711033 | 15:08 |
openstackgerrit | Monty Taylor proposed openstack/ansible-collections-openstack master: Fix license metadata https://review.opendev.org/711035 | 15:08 |
openstackgerrit | Monty Taylor proposed openstack/ansible-collections-openstack master: Clean up minor build quibbles https://review.opendev.org/711036 | 15:08 |
dtantsur | nice! | 15:12 |
mordred | brtknr: the magnum function tests for sdk seem to always be failing - and it seems to be related to detecting magnum: https://4689b6461ef076a1f80e-32e19aab5c30ebc59039fa10c249436d.ssl.cf5.rackcdn.com/711301/1/check/openstacksdk-functional-devstack-magnum/9a10a15/testr_results.html | 15:12 |
mordred | brtknr: this makes me think our devstack job is not configured properly ... do you know anything about magnum devstack job config? | 15:13 |
mordred | dtantsur: and yeah - I think that's a nice improvement and should let us make things nicer without making sdk unuable in the services | 15:14 |
Shrews | oh good. i was also trying to reproduce the strictversion thing without success. glad to page irc back in and see the issue was found | 15:17 |
*** efried is now known as efried_gone | 15:18 | |
mgoddard | mordred: https://github.com/ansible/ansible/pull/68043 | 15:18 |
rm_work | what is the plan for the next SDK release? | 15:20 |
mgoddard | mordred, Shrews: I'll send something to the ML about ansible 2.8.9. Any [tags] I should use? | 15:22 |
rm_work | (I ask about the next release, because I need to use the feature I just added in a client change) | 15:23 |
mordred | brtknr: https://zuul.opendev.org/t/openstack/build/9a10a15e2a2e4af18021948078429d1c/log/job-output.txt#50351 this might have something to do with it - from what I can tell magnum IS running in that cloud | 15:26 |
mordred | rm_work: I think we're pretty good for a next release - all of the recent things people need have landed - let me double check that | 15:26 |
* Shrews refrains from grumbling outloud about magnum testing | 15:27 | |
Shrews | though maybe i just did | 15:27 |
mordred | Shrews: yeah - although this one seems weird - it seems like the magnum is completely there and operational - and we're detecting that it's been disabled by config | 15:32 |
mordred | Shrews: check https://zuul.opendev.org/t/openstack/build/9a10a15e2a2e4af18021948078429d1c/log/job-output.txt#50351 | 15:33 |
Shrews | yep, that's what i saw when i looked at it last. until we make other groups care about supporting their services into sdk/osc instead of expecting us to have deep knowledge on all-the-things, it probably doesn't matter that it's broken | 15:34 |
mordred | yeah - except randomly today I'm worried that there's some basic sdk bug | 15:35 |
mordred | because it's _no_ disabled by config in the clouds.yaml | 15:35 |
mordred | so even if magnum is broken - we're at the very least returning the wrong error here | 15:35 |
openstackgerrit | Sagi Shnaidman proposed openstack/ansible-collections-openstack master: Add Openstack guidelines spec from Ansible https://review.opendev.org/704558 | 15:40 |
elmiko | API SIG office hour now open \o/ | 16:00 |
mordred | elmiko: does that mean it's time to start drinking? | 16:01 |
elmiko | hmm, not a bad idea XD | 16:01 |
tosky | from the flam^H^H^H^Hdiscussion on the list and dtantsur's comment, it seems to me that having OSC autonegotiating the last possible microversion is a good thing, because the high level clients should be user-focused and hide the details | 16:12 |
tosky | do I get it correctly? | 16:12 |
dtantsur | o/ | 16:12 |
* dtantsur agrees with dtantsur | 16:12 | |
elmiko | tosky: that makes sense to me, fwiw | 16:14 |
elmiko | one question though, by "last possible microversion" do you mean the highest version or lowest? | 16:15 |
tosky | highest - as in "I want all the supported features" | 16:16 |
*** KeithMnemonic1 has joined #openstack-sdks | 16:19 | |
mordred | so ... | 16:20 |
elmiko | tosky: ack, thanks | 16:20 |
mordred | there's some good scrollback in here from yesterday between me and umbSublime where I explained a slightly altered view of that but which mostly agrees with dtantsur | 16:20 |
mordred | but the tl;dr is that a) I agree with that as a goal but b) sdk needs to know what the 'latest' microversion it can undersatnd without blowing up is - because if it's expecting a response and a microversion radically changes it, it needs to know how to deal with that | 16:22 |
mordred | to me this means that we should in fact strict to always get the latest microversion - and in a perfect world part of the process of adding a new microversion to a service would also be coming and adding a quick mv bump to sdk | 16:22 |
mordred | in many cases those patches to sdk are trivial | 16:22 |
mordred | and *much* less work than the corresponding work to add the new api feature | 16:23 |
*** KeithMnemonic has quit IRC | 16:23 | |
mordred | but in some cases they might be more complex - and will require a conversation about how to expose the feature in a way that doesn't break people | 16:23 |
mordred | in some places we're behind and we need to catch up. in other places, like ironic - people like dtantsur are really good about coming in and bumping the max_microversion and adding fields really quickly | 16:25 |
openstackgerrit | Monty Taylor proposed openstack/python-openstackclient master: Build utility image for using osc https://review.opendev.org/711246 | 16:28 |
tosky | thanks | 16:31 |
tosky | one thing I'd like to point out for the (probably) upcoming goal of making OSC on par with the custom clients: I think it may makes sense in some cases to decouple the improvements OSC and the migration to SDK, if the latter means waiting on a tons of non-implemented feature | 16:34 |
tosky | features* | 16:34 |
tosky | that's it | 16:34 |
dtroyer | tosky: that point seems to get blurred a lot when this topic comes up so thanks for pointing it out. It may not be the last time it is required | 16:38 |
openstackgerrit | Merged openstack/ansible-collections-openstack master: Deal with collection build modifying tree https://review.opendev.org/711033 | 16:39 |
openstackgerrit | Merged openstack/ansible-collections-openstack master: Fix license metadata https://review.opendev.org/711035 | 16:39 |
openstackgerrit | Merged openstack/ansible-collections-openstack master: Clean up minor build quibbles https://review.opendev.org/711036 | 16:39 |
openstackgerrit | Merged openstack/ansible-collections-openstack master: Add Openstack guidelines spec from Ansible https://review.opendev.org/704558 | 16:39 |
mordred | dtroyer, tosky: totally agree. I mostly bring up the SDK parts so that as we work on that upcoming goal we keep in mind the above behavior so that we don't add any enw complications | 16:43 |
mordred | I think it should be fine | 16:43 |
mordred | because by and large people are already keepig python-*client up to date with their latest microversions - so the process of "add mv to server and also make sure client isn't going to bomb out" is a process humans are already following | 16:43 |
dtroyer | mordred: right, it isn't so much the mv work itself, more of the way folks have talked about the larger goals and mixing sdk transition with other osc needs, ie cli parity. the goal talk got bogged down a couple of times previously because of that. | 16:45 |
tosky | mordred: the point is: moving to OSC is one thing; changing the internal implementation of OSC is another process, which is important for the developers, but definitely less relevant for the users (as it should be transparent) | 16:45 |
tosky | IMHO | 16:45 |
dtroyer | I have not followed the latest round closely at all so no idea if it has happened again this time | 16:46 |
mordred | tosky: yes, I agree | 16:46 |
mordred | although I will add there is _one_ user-facing thing about sdk transition - and that's that it results in less depends being installed, so it's not a completely irellevant for users | 16:46 |
mordred | but in terms of osc operational functionality - yeah - it's largely an impl detail that if we do our jobs right nobody will notice | 16:47 |
tosky | reduced dependency footprint is veeery nice, but really, either you go with distro packages, or pip, or containers, and it's not as important as the functionalities | 16:49 |
mugsie | mordred: will it though? designate users still have to install the python-designateclient package to get the OSC plugin, same for octavia / trove / $<project> | 16:50 |
tosky | right, that's different for plugins | 16:51 |
tosky | but let's not go into the "make everything a plugin" thing :D | 16:51 |
mordred | I'd like to see less plugins, not more. but I think we've got enough on our plate for now than to think about that for now | 16:51 |
mugsie | tosky: it is almost like you have seen my newsletter :) | 16:52 |
mugsie | mordred: yeah, it is a can of worms that is not useful right now I suppose | 16:52 |
mordred | yup. one thing at a time :) | 16:52 |
openstackgerrit | Tom Stappaerts proposed openstack/openstacksdk master: Support for stateless security groups https://review.opendev.org/711513 | 16:54 |
openstackgerrit | Tom Stappaerts proposed openstack/python-openstackclient master: Support for stateless security groups https://review.opendev.org/711515 | 16:57 |
dtroyer | mugsie: fwiw I've bought in to the notion that as APIs transition to the SDK putting the CLI in-repo is much less of an obstacle for user experience, which was one of the primary drivers for the plugins. The other driver of course was team autonomy, that part of the decision lies with each team | 17:00 |
mordred | ++ | 17:01 |
mordred | we've also been having good success in sdk so far with giving core to project-specific people so teams can keep taking care of their own stuff - turns out pepole have large review loads anyway so they don't tend to go reviewing patches broadly where they don't know what's going on | 17:02 |
elmiko | i'm stepping out, hope you all have a lovely weekend =) | 17:03 |
mordred | so - over time I think these are areas ripe for exploration - but certainly we shouldn't block parity goals on any of it | 17:03 |
mordred | dtroyer: I thnik that's a good way to think of potentially pulling thing in tree - as plugins get reworked to be sdk-based, pulling them in tree starts to be less of a combinatorial burden | 17:13 |
tosky | uhm, why would they be a problem for frige plugins like manila or octavia? It's not like they would need core changes | 17:20 |
*** jpich has quit IRC | 17:22 | |
brtknr | mordred: sorry just saw your ping from earlier, I am not super familiar with the CI side of things | 17:23 |
brtknr | mordred: have you cut a new release yet? | 17:26 |
brtknr | im just about to propose another fix | 17:26 |
smcginnis | mordred, dtroyer, tosky: Since getting things into the SDK does simplify things, and as a way to break things into smaller pieces, would it actually make sense to try to have one cycle goal to get everything into the SDK, then another cycle goal after that to have OSC parity and start deprecating the per-service CLIs? | 17:29 |
tosky | smcginnis: from what I hear around one cycle for SDK parity may not be enough and the current effort may lose momentum, but not up to me | 17:30 |
dtroyer | smcginnis: I recall that exact discussion previously, I think in Vancouver. I was a bit distracted that week by the introduction of stalingx so I don't recall the particulars. I do agree that keeping those things distinct is important to make community-wide progress | 17:34 |
*** evrardjp has quit IRC | 17:35 | |
mordred | brtknr: I havne't - go for it! | 17:35 |
*** evrardjp has joined #openstack-sdks | 17:35 | |
mordred | smcginnis: yeah - I think the most important thing is keeping them distinct - otherwise it's too much | 17:36 |
mordred | smcginnis: I could see value in both directions - there's value in sdk-parity-first - because that also allows exposing to things like ansible and salt- but it has the drawback of not increasing tim bell's happiness | 17:36 |
mordred | doing osc-parity first would make tim bell happy and would likely be less work for a chunk of people (I think therea re more people with osc plugins than people with comprehensive sdk code) ... but it might result in increasing the surface area of work for a future "now convert osc plugins to sdk" - since there would potentially be _more_ osc plugin code to convert | 17:38 |
smcginnis | True. But seems like it could make it a little easier for some folks if that got done. | 17:38 |
mordred | smcginnis: I honestly don't know which I think is the better choice - or would give people the greatest amount of "job well done" satisfaciton | 17:39 |
smcginnis | And part of my thought was avoiding that extra work too. | 17:39 |
mordred | yeah | 17:39 |
smcginnis | Honestly, I'd rather not have a cycle goal for it and just have a clear plan to work towards. Then when things get closer to actually being something that could even be accomplished in one cycle, then make it a goal. | 17:39 |
*** dtantsur is now known as dtantsur|afk | 17:40 | |
mordred | smcginnis: ++ | 17:43 |
mordred | I thnk very much that | 17:43 |
openstackgerrit | Bharat Kunwar proposed openstack/openstacksdk master: Normalise create_coe_cluster{,_template} results https://review.opendev.org/711526 | 18:04 |
brtknr | mordred: Shrews ^ | 18:04 |
mordred | brtknr: cool. also - please see mailing list - I mayhave just mentioned you ... | 18:06 |
brtknr | mordred: will do | 18:08 |
brtknr | btw why is the json encapsulated inside baybodel= in https://review.opendev.org/#/c/711526/1/openstack/tests/unit/cloud/test_coe_clusters.py line 66 | 18:08 |
mordred | brtknr: the validate parameter is for validating json sent to the api call | 18:09 |
mordred | the normal json parameter is for specifying what the fake http call should return | 18:10 |
brtknr | the fake http call should return a thing without the baymodel bit | 18:10 |
mordred | oh- I get yourquestion now | 18:10 |
mordred | it's entirely possible it's a bug in the test then | 18:11 |
brtknr | and the validate part i removed because it didnt seem to matter whether it was there or not | 18:11 |
*** slaweq has joined #openstack-sdks | 18:11 | |
mordred | brtknr: we might want to keep the validate portion though - the call will still work - but you can see the results if you change the contents of it it should break | 18:11 |
mordred | it's testing the other side of the interaction - that the sdk call produces the correct payload to send to the server | 18:12 |
mordred | it's probably not super important in this case since we're not really transforming the input | 18:12 |
brtknr | ah makes sense | 18:13 |
*** jpena is now known as jpena|off | 18:26 | |
brtknr | mordred: here's the weird thing, if i remove the baymodels= in the GET requests, tox -e py36 fails as it expects baymodels= part to be there | 18:30 |
brtknr | but in post requests, it would rather it was not there | 18:30 |
mordred | brtknr: does magnum not have a top level baymodels: [] in its list response? | 18:38 |
mordred | brtknr: https://docs.openstack.org/api-ref/container-infrastructure-management/?expanded=list-all-baymodels-detail#id34 | 18:39 |
*** umbSublime has quit IRC | 18:39 | |
mordred | brtknr: GET /baymodels returns {'baymodels': [ {}, {} ] } | 18:39 |
mordred | so we need the baymodels= there | 18:39 |
mordred | I agree - inthe response for the POST - there should be no top level baymodel or baymodels | 18:40 |
mordred | nor in teh request | 18:40 |
mordred | https://docs.openstack.org/api-ref/container-infrastructure-management/?expanded=create-new-baymodel-detail#id25 | 18:41 |
*** slaweq has quit IRC | 18:47 | |
brtknr | mordred: nice to see it confirmed | 18:55 |
openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Fix service_type test for magnum in gate https://review.opendev.org/711533 | 18:56 |
openstackgerrit | Bharat Kunwar proposed openstack/openstacksdk master: Normalise create_coe_cluster{,_template} results https://review.opendev.org/711526 | 18:56 |
mordred | brtknr, Shrews: ^^ that should fix the magnum tests in the gate | 18:56 |
*** ralonsoh has quit IRC | 18:57 | |
brtknr | Wow thats a mouthful, I did not know that | 18:57 |
mordred | (711533 that is) | 18:57 |
Shrews | mordred: are we taking bets that the tests still work? ;) | 18:58 |
mordred | Shrews: nope! | 18:58 |
mordred | Shrews: but - they should at least RUN now and fail as tests :) | 18:58 |
mordred | brtknr: https://service-types.openstack.org/service-types.json | 18:58 |
mordred | or more specifically: https://opendev.org/openstack/service-types-authority/src/branch/master/service-types.yaml#L41 | 18:59 |
*** slaweq has joined #openstack-sdks | 18:59 | |
mordred | for normal users it should work to refer by official type or any of the aliases | 18:59 |
mordred | but we wrote the has_service to be strict :) | 18:59 |
*** slaweq has quit IRC | 19:04 | |
brtknr | mordred: ouch | 19:08 |
mordred | yah | 19:30 |
*** stingrayza has quit IRC | 20:18 | |
*** stingrayza has joined #openstack-sdks | 20:19 | |
*** slaweq has joined #openstack-sdks | 20:48 | |
*** sshnaidm is now known as sshnaidm|afk | 20:48 | |
*** umbSublime has joined #openstack-sdks | 20:50 | |
*** enriquetaso has quit IRC | 20:54 | |
umbSublime | Hey another quick question related to os-client-config. I just noticed from the README that it was superceded by the sdk, but I'm not sure how I can reproduce even a basic call like `os_client_config.OpenStackConfig().get_all_clouds()` I just want to have an object representing the clouds.yaml without having to parse it myself | 20:56 |
*** johnsom has left #openstack-sdks | 21:02 | |
umbSublime | derr nvm just found it under openstack.config ... | 21:02 |
openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Set max_microversion to 2.53 for hypervisors https://review.opendev.org/711294 | 21:08 |
mordred | umbSublime: \o/ | 21:09 |
mordred | umbSublime: yeah - os_client_config moved to openstack.config ... perhaps we should update the readme to point more specifically | 21:09 |
openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Normalise create_coe_cluster{,_template} results https://review.opendev.org/711526 | 21:11 |
mordred | Shrews, brtknr: my patch above fixed the magnum functional tests - so I added a depends-on between brtknr's patch and mine so we can make sure that doesnt' break functional tests (I'm pretty sure it's ok - but we have green functional tests - so why not!) | 21:12 |
*** gtema has joined #openstack-sdks | 21:17 | |
*** gtema has quit IRC | 21:22 | |
*** stingrayza has quit IRC | 21:31 | |
*** stingrayza has joined #openstack-sdks | 21:31 | |
umbSublime | tbh If I would've searched 2 minutes more before posting, it would've been fine. It wouldn't hurt though. (btw thanks for updating topic on the chan) | 21:32 |
*** slaweq has quit IRC | 21:33 | |
umbSublime | is cliff also maintained by the SDK team ? | 21:56 |
Shrews | no | 22:13 |
mordred | Shrews: well ... | 22:14 |
mordred | umbSublime: there is a proposal up to merge the sdk and osc teams - so assuming that goes through (there is currently no dissent) the answer becomes "yes" | 22:14 |
Shrews | osc team maintained cliff? heh | 22:15 |
Shrews | TIL | 22:16 |
*** iurygregory has quit IRC | 22:18 | |
brtknr | mordred Shrews: thanks for the merge! | 22:22 |
brtknr | glad you fixed the ci too! | 22:22 |
brtknr | What does the magnum job do out of interest? | 22:23 |
mordred | brtknr: it makes sure that there is a magnum running in the devstack and then runs the openstacksdk functional tests against that devstack | 22:24 |
mordred | brtknr: so - you can totally add magnum related functional tests and they'll run in that job | 22:24 |
mordred | obviously nested virt makes doing a _lot_ in functional tests somewhat heavy weight - so I don't think we have many magnum related functional tests today | 22:25 |
*** tkajinam has joined #openstack-sdks | 22:45 | |
*** enriquetaso has joined #openstack-sdks | 23:56 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!