| *** rcastillo_ is now known as rcastill | 00:10 | |
| *** rlandy|bbl is now known as rlandy | 01:08 | |
| *** rlandy is now known as rlandy|out | 01:13 | |
| *** ysandeep|out is now known as ysandeep | 04:53 | |
| *** ysandeep is now known as ysandeep|afk | 07:30 | |
| *** ysandeep|afk is now known as ysandeep | 09:20 | |
| opendevreview | Jakob Meng proposed openstack/ansible-collections-openstack master: Refactored endpoint module and explained region attribute https://review.opendev.org/c/openstack/ansible-collections-openstack/+/847293 | 09:34 |
|---|---|---|
| opendevreview | Jakob Meng proposed openstack/ansible-collections-openstack master: [DNM] keypair_info test https://review.opendev.org/c/openstack/ansible-collections-openstack/+/847299 | 10:07 |
| *** rlandy_ is now known as rlandy | 10:34 | |
| jm1 | arxcruz, frenzy_friday, rcastill: looks like we have a gate blocker in aoc due to a change in ansible. sshnaidm submitted a patch but it has not been merged yet https://github.com/ansible/ansible/pull/78054 | 10:40 |
| *** rlandy_ is now known as rlandy | 10:49 | |
| sshnaidm | jm1, worth to pin to 2.13? | 10:57 |
| jm1 | sshnaidm: lets see how fast ansible guys merge this patch? | 10:58 |
| sshnaidm | anyway it will be only in the next release (if will be merged soon) | 10:58 |
| opendevreview | Jakob Meng proposed openstack/ansible-collections-openstack master: [DNM] keypair_info test https://review.opendev.org/c/openstack/ansible-collections-openstack/+/847299 | 11:06 |
| *** rlandy_ is now known as rlandy | 11:08 | |
| jm1 | noonedeadpunk: i am trying to clean up our review backlog. arxcruz' fix for endpoint module https://review.opendev.org/c/openstack/ansible-collections-openstack/+/840640 landed in master, do mind abandoning https://review.opendev.org/c/openstack/ansible-collections-openstack/+/836351 ? | 11:17 |
| noonedeadpunk | jm1: sure, abandoned | 11:18 |
| jm1 | noonedeadpunk: thanks :) | 11:18 |
| noonedeadpunk | btw question since you've summoned me :D Any idea how far collection is from supporting sdk 0.99 ? | 11:19 |
| jm1 | noonedeadpunk: far 🙈 https://hackmd.io/7NtovjRkRn-tKraBXfz9jw?view | 11:19 |
| *** dviroel|afk is now known as dviroel | 11:20 | |
| noonedeadpunk | ouch | 11:20 |
| noonedeadpunk | ok. | 11:20 |
| gtema | noonedeadpunk: do you have a specific usecase/list of required modules? | 11:21 |
| gtema | jm1: looking through the list it is bit more then simply update to latest SDK, it feels like a complete analysis of what is right and what is wrong there | 11:22 |
| noonedeadpunk | we use a lot of them. Probably most used are keystone ones, which seems to be fixed. Then goes image upload, net/subnet/router creation. I believe we also handle creation of magnum cluster templates | 11:23 |
| noonedeadpunk | But hard to recall everything tbh | 11:23 |
| noonedeadpunk | We also lack volume type creation plugin, never found time to write one... | 11:24 |
| gtema | I feel it may be helpful to track your particular cases and try maybe prioritize the modules you require | 11:24 |
| gtema | but even in that case ensure it work now with new sdk like with old sdk without other improvements | 11:25 |
| jm1 | gtema: the list of modules is annotated with bug reports. but RFEs are not considered before we havent ported to new sdk. | 11:27 |
| noonedeadpunk | So to express pain a bit. We just branched yoga (thankfully we're trailing and can afford late releases). And now we need to switch everything to master. And sdk 0.99 comes with uc- | 11:28 |
| jm1 | gtema: we already priorize, e.g. tripleo and bifrost modules come first. | 11:28 |
| noonedeadpunk | So things fail badly as you can imagine. | 11:28 |
| gtema | right, but not all of the mentioned reports are related to sdk 0.99 | 11:28 |
| noonedeadpunk | https://review.opendev.org/c/openstack/openstack-ansible/+/847272 | 11:28 |
| noonedeadpunk | I will try to look where we fail and propose some easy fixes | 11:29 |
| jm1 | noonedeadpunk: tell us which modules openstack-ansible wants to be ported first and we can priorize those as well | 11:30 |
| noonedeadpunk | hm. weird. seems I forgot to push some change to mentioned patch | 11:30 |
| gtema | perhaps, was just going to ask that failures are not seem coming from ansible collection | 11:31 |
| noonedeadpunk | yeah, they do, but I forgot to switch collection to master :) | 11:31 |
| noonedeadpunk | Or well, I did, but haven't pushed that :D | 11:31 |
| jm1 | gtema: initially we were hoping to get some bugs fixed while porting to new sdk. with the original plan of releasing sdk 1.0.0 after zed we had plenty of time 😉 | 11:32 |
| gtema | yeah, sure | 11:32 |
| noonedeadpunk | ok, I will come up with list and try to help out with some fixes | 11:33 |
| gtema | can we assume that in order to support sdk 0.99 we need to uncomment remaining bits in https://opendev.org/openstack/ansible-collections-openstack/src/branch/master/.zuul.yaml#L106? | 11:33 |
| gtema | I mean something failing with latest SDK. Surely there might be uncovered issues | 11:34 |
| jm1 | gtema: we have to go through all modules in https://hackmd.io/7NtovjRkRn-tKraBXfz9jw?view | 11:35 |
| jm1 | gtema: unless we want to release a surprise box ^^ | 11:35 |
| gtema | the point is that not everything is by default not working with latest sdk | 11:35 |
| gtema | what you do now is a great job, but it is more like a complete review of the module and tests | 11:36 |
| gtema | and this is what is necessary, but makes it much longer | 11:36 |
| gtema | do not think I want to hurry you up - not the sense of the statement | 11:36 |
| jrosser_ | with this "with the original plan of releasing sdk 1.0.0 after zed" what should the expectations be for a project like openstack-ansible where we need to make a working Zed release? | 11:38 |
| jrosser_ | just so i am understanding what the Zed cycle looks like for us | 11:38 |
| jm1 | noonedeadpunk: we have a large doc on how we port modules, on what to look out for, on how we do reviews etc.: https://hackmd.io/szgyWa5qSUOWw3JJBXLmOQ | 11:40 |
| jm1 | gtema: in aoc we have ci tests only for a fraction of the modules. so we know little of what really breaks with new sdk. a proper release requires looking at each module. | 11:42 |
| jm1 | gtema: what would you propose instead to speed up? | 11:42 |
| gtema | maybe (just maybe): fix all known things that are broken now with 0.99 (based on current tests), fix issues blocking concrete tripleo/bifrost/whichever and release 2.0.0 | 11:44 |
| gtema | afterwards continue going the effort you do now with target of 3.0 | 11:44 |
| noonedeadpunk | I kind of like that idea | 11:44 |
| jm1 | dtantsur, sshnaidm: can you give your opinions on gtema's idea above? | 11:45 |
| dtantsur | you mean, releasing the stuff when we don't know if it works or not? | 11:47 |
| dtantsur | not exactly thrilled as you may expect :) | 11:47 |
| gtema | nope, I mean once we know all current tests are fine and bifrost/tripleo are working | 11:48 |
| dtantsur | yeah, if we have serious reasons to assume the rest of the stuff works - sure | 11:48 |
| gtema | but not explicitly reviewing every particular module for eventual bugs not even related to sdk change | 11:48 |
| sshnaidm | gtema, the fact is that we don't actually know what is broken, the current tests are mostly very "lite" and some modules don't even have them | 11:49 |
| gtema | I know, this is correct | 11:49 |
| sshnaidm | so I wouldn't rely on tests to show module broken or not | 11:50 |
| gtema | but if we focus on things that are definitely broken for 2 known users may be sufficient for some interim cut | 11:50 |
| noonedeadpunk | dtantsur: btw looking on https://github.com/openstack/bifrost/blob/7271695714739af10d741a39dc4acd5e68465cb5/playbooks/roles/bifrost-ironic-install/tasks/keystone_setup.yml and https://opendev.org/openstack/openstack-ansible-plugins/src/branch/master/roles/service_setup/tasks I wonder if it might make sense to move that "role" to sdk so we can both use it? | 11:50 |
| gtema | and this definitely broken for me means - ensure their jobs are running | 11:50 |
| sshnaidm | but you still need to check it, to run module, to test - you do this work anyway, it doesn't save us a lot | 11:50 |
| gtema | aren't we have jobs from bifrost and tripleo that fail in the current state? | 11:51 |
| gtema | at least that was my assumption | 11:51 |
| sshnaidm | I think tripleo is fine now(?) | 11:52 |
| noonedeadpunk | It failed when I set depends-on on latest collection version fwiw | 11:52 |
| dtantsur | noonedeadpunk: probably? never thought about it | 11:52 |
| gtema | I know for sure there is non addressed bug in server module (but it is not ported) - there is bug reported. Once we address known blockers we could cut interim state to unblock "majority" | 11:53 |
| gtema | noonedeadpunk: we could both try to put more generalization logic into sdk and/or add roles in AOC itself with such repeated tasks | 11:54 |
| noonedeadpunk | sshnaidm: good example was https://review.opendev.org/c/openstack/ansible-config_template/+/846391/2 until patchset 4 where I dropped dependency on latest collection | 11:55 |
| sshnaidm | I'm not so comfortable to release a probably broken modules. It's better for user to install an old sdk and use old modules, than install a new sdk and have "probably working" ones | 11:55 |
| noonedeadpunk | and latest release is totally broken with sdk 0.99 | 11:55 |
| noonedeadpunk | latest tagged collection release | 11:55 |
| noonedeadpunk | and you _must_ use sdk 0.99 for zed development | 11:56 |
| noonedeadpunk | likely triplo doesn't do that though.... | 11:56 |
| sshnaidm | why _must_? | 11:56 |
| dtantsur | upper-constraints | 11:56 |
| gtema | I honestly dislike must as well - this seem wrong from sdk concept | 11:56 |
| sshnaidm | I don't think it's a _must_ | 11:57 |
| dtantsur | for better or worse, openstack has agreed to maintain a common set of Python dependencies | 11:57 |
| noonedeadpunk | because otherwise you're fall of requirements set by https://docs.openstack.org/project-team-guide/dependency-management.html ? | 11:57 |
| noonedeadpunk | As upper-constraints strightfully say that sdk 0.99 should be used | 11:57 |
| sshnaidm | And not all users of sdk and collections are developers, I think (hope :)) most of them are operators, and they would install whatever sdk they need | 11:58 |
| dtantsur | and any project using sdk is within its rights to start doing openstacksdk>=0.99 | 11:58 |
| dtantsur | making it no longer co-installable with aoc | 11:58 |
| gtema | isn't upper constraint meant to be really "you can't use anything newer then 0.99"? | 11:58 |
| dtantsur | no, it means literally this version | 11:58 |
| noonedeadpunk | yes^ | 11:58 |
| sshnaidm | what is word "upper" meaning then? :) | 11:58 |
| dtantsur | sshnaidm: the desire to keep it as close to the latest versions as possible | 11:59 |
| dtantsur | which is the crux of the problem here :) | 11:59 |
| gtema | uhm, I was feeling requirements.txt can pick up something between lower-constraint and upper-constraint | 11:59 |
| noonedeadpunk | nope, you should use u-c | 11:59 |
| noonedeadpunk | lower constraints were just project-wise constraints, that are not limited | 11:59 |
| noonedeadpunk | Like for test tooling versions or smth | 11:59 |
| sshnaidm | I'm fine with releasing master every patch for dev version of collections, not "released" one, if it helps someone | 12:00 |
| noonedeadpunk | I mean, if you pass u-c as --constraint to the pip, `openstacksdk===0.99.0` won't give you any choice | 12:00 |
| dtantsur | or you start doing ugly stuff like this https://opendev.org/openstack/bifrost/src/commit/8fa29d9834dcc0eb0f58ff6c6ff69888a0408131/playbooks/roles/bifrost-create-vm-nodes/tasks/prepare_libvirt.yml#L170-L177 | 12:02 |
| noonedeadpunk | I have better example of how unhappy I am with current state of u-c for stable branches: https://opendev.org/openstack/openstack-ansible-os_neutron/src/branch/master/tasks/neutron_install.yml#L70 | 12:03 |
| noonedeadpunk | as how in the world `neutron` appears in u-c.... | 12:04 |
| dtantsur | wow | 12:04 |
| dtantsur | yeah, because it's a dependency of networking-* | 12:04 |
| noonedeadpunk | I bet it should be in lower constraints then tbh.... | 12:05 |
| dtantsur | it has to be in upper constaints OR projects have to have an upper cap for it | 12:05 |
| noonedeadpunk | as then if you follow "guide" you don't have any option which version of neutron to install | 12:05 |
| gtema | world of py deps is a real mess | 12:05 |
| dtantsur | yeah | 12:05 |
| gtema | and in OpenStack it only gets even worse | 12:05 |
| noonedeadpunk | not sure it's worse them nmp though | 12:06 |
| gtema | most likely comparable | 12:06 |
| gtema | just npm usually is not coming with cli, while in py it is very common | 12:06 |
| sshnaidm | The other option is to go quickly over the modules and to look where it can be fixed, w/o doing much changes, sdk fixes only. After a first release - to go over again with more solid approach. But I don't think we will ever get to it after a release.. | 12:08 |
| dtantsur | This is a good point. There is a chance that whatever you release as 2.0 will stay with you for a long time :) | 12:09 |
| dtantsur | simply because of the team's capacity | 12:09 |
| gtema | on demand - once a bug report arrives | 12:09 |
| gtema | for me it looks like that: if you can get your "stakeholder" accept delay - we should do this reasonably. Once this is not possible - we may want to have a faster workaround with a big chance to never address issue without real bug report | 12:10 |
| sshnaidm | operators are not such people that easily open bugs, they mostly stop using tools :) | 13:01 |
| gtema | also true | 13:01 |
| sshnaidm | also we put a quite high barrier to submit a bug - to use storyboard | 13:01 |
| gtema | but now blocking them for so long may have same effect | 13:01 |
| sshnaidm | people desperate just to register there | 13:01 |
| gtema | yes, that is basically unmanageable | 13:01 |
| *** rcastill is now known as rcastillo | 13:02 | |
| gtema | I can't wait for opendev to enable gitea issues | 13:02 |
| opendevreview | Jakob Meng proposed openstack/ansible-collections-openstack master: Update project_info module to new sdk https://review.opendev.org/c/openstack/ansible-collections-openstack/+/837276 | 13:12 |
| jm1 | dtantsur, gtema, noonedeadpunk, sshnaidm: so we have a stalemate here. | 13:30 |
| jm1 | on the one hand we want to get a release out quickly: 0.99.x is part of zed coinstalling an older sdk with zed will be difficult or impossible. so people might be blocked because the old aoc release wont work with new 0.99.x and once we release a new stable release aoc will even refuse to work with new sdk. | 13:30 |
| jm1 | on the other hand if we rush out a release god-knows-what could still be broken in aoc because our ci coverage is suboptimal. we do not know what will break. bifrost/openstack-ansible/tripleo would work because we cover required modules in the new aoc release. once we publish that aoc release, dev velocity will probably slow down to maintenance-mode. | 13:30 |
| noonedeadpunk | sounds like valid overview, yes | 13:31 |
| noonedeadpunk | But, what makes things even worse for Zed, is that system scopes should be supported there for sure. They're even supposed to be present in Yoga | 13:32 |
| noonedeadpunk | But sdk/aoc do not match to have that | 13:32 |
| noonedeadpunk | or well, it goes to this stalemate you wrote | 13:33 |
| sshnaidm | when is Zed out? | 13:37 |
| *** ysandeep is now known as ysandeep|afk | 13:39 | |
| noonedeadpunk | 2022-10-05 | 13:46 |
| *** ysandeep|afk is now known as ysandeep | 13:47 | |
| noonedeadpunk | so like 3 month | 13:47 |
| sshnaidm | and I think it's fine to release 2.0.0 just before Zed is released, right? | 13:52 |
| noonedeadpunk | I think it should be fine, yes. As deployment projects are mostly trailing, so they have some more time to adopt | 13:52 |
| *** ysandeep is now known as ysandeep|out | 15:21 | |
| *** frenzy_friday is now known as frenzyfriday|PTO | 16:21 | |
| *** rcastillo_ is now known as rcastillo | 18:28 | |
| *** dviroel is now known as dviroel|out | 21:14 | |
| *** rlandy is now known as rlandy|bbl | 22:30 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!