| *** dviroel|out is now known as dviroel | 00:21 | |
| opendevreview | Ronelle Landy proposed openstack/ansible-collections-openstack master: Revert "Raise minimum OpenStack SDK version to 0.99.0" https://review.opendev.org/c/openstack/ansible-collections-openstack/+/843192 | 00:45 |
|---|---|---|
| *** dviroel is now known as dviroel|out | 01:24 | |
| *** rcastillo_ is now known as rcastillo | 02:56 | |
| *** ysandeep|out is now known as ysandeep|rover | 04:35 | |
| *** ysandeep|rover is now known as ysandeep|rover|brb | 05:25 | |
| *** ysandeep|rover|brb is now known as ysandeep|rover | 05:32 | |
| opendevreview | Jakob Meng proposed openstack/ansible-collections-openstack master: Revert "Raise minimum OpenStack SDK version to 0.99.0" https://review.opendev.org/c/openstack/ansible-collections-openstack/+/843238 | 06:33 |
| opendevreview | Jakob Meng proposed openstack/ansible-collections-openstack master: Revert "Raise minimum OpenStack SDK version to 0.99.0" https://review.opendev.org/c/openstack/ansible-collections-openstack/+/843192 | 06:34 |
| *** ysandeep|rover is now known as ysandeep|rover|lunch | 07:44 | |
| *** ysandeep|rover|lunch is now known as ysandeep|rover | 08:33 | |
| opendevreview | Merged openstack/ansible-collections-openstack master: Revert "Raise minimum OpenStack SDK version to 0.99.0" https://review.opendev.org/c/openstack/ansible-collections-openstack/+/843192 | 09:08 |
| dtantsur | folks, is it your intention to make 1.0.0 incompatible with OpenStack Zed? If not, please revert https://review.opendev.org/c/openstack/ansible-collections-openstack/+/839693 | 10:39 |
| dtantsur | if yes, please let me know the next 1.0.* version in which ^^^ will be released, so that we can exclude it in bifrost | 10:40 |
| dtantsur | cc jm1 | 10:40 |
| *** arxcruz is now known as arxcruz|off | 10:52 | |
| jm1 | dtantsur: openstacksdk 0.99.x/1.x.x introduces backward incompatible changes which forces us to release a new ansible openstack collection 2.x.x which is incompatible to 1.x.x | 11:24 |
| jm1 | dtantsur: master branch of aoc is tracking 2.x.x releases and will be compatible to sdk 1.x.x (and 0.99.x to some degree) only. our stable/1.0.0 branch is compatible to sdk pre-0.99.x releases only. | 11:25 |
| *** dviroel|out is now known as dviroel | 11:30 | |
| *** ysandeep|rover is now known as ysandeep|rover|afk | 12:41 | |
| dtantsur | jm1: okay, to clarify: Bifrost Zed must NOT use collection 1.x.x? what should it use? 0.x.x? | 12:53 |
| dtantsur | or will 2.x.x be available really soon? | 12:54 |
| dtantsur | and which 1.x.x version will the requirements change go in? I assume 1.0.0 because you need a major version bump for a breaking change? | 12:56 |
| dtantsur | hold on, you have released 1.8.0 already. you cannot release such a huge breaking change as part of 1.0.0 branch, assuming you care about sem-ver even a bit | 13:00 |
| dtantsur | which, I guess, begs the question: is it possible to fix openstacksdk instead? cc gtema | 13:01 |
| gtema | what exactly do you mean? I know perfectly nobody want to have backward incompatibility, but keeping inconsistencies forever is not a solution either | 13:30 |
| gtema | and we were trying to prepare this for so long | 13:31 |
| *** ysandeep|rover|afk is now known as ysandeep|rover | 13:31 | |
| dtantsur | I see a problem in the fact that the newest versions of openstacksdk and ansible collections don't work with each other.. | 13:38 |
| gtema | they do, but only newest with newest. newest AC should work with older SDK (not 100%, but still). Older AC will not properly work with new SDK indeed (but also here - not everywhere) | 13:42 |
| opendevreview | Jan Horstmann proposed openstack/ansible-collections-openstack master: Return details in baremetal_node_info when iterating over all machines https://review.opendev.org/c/openstack/ansible-collections-openstack/+/839776 | 14:07 |
| jm1 | dtantsur: ansible openstack collection 1.8.0 should not break backward compatibility with older aoc releases (1.x.x). if it does, it is a bug. | 14:23 |
| dtantsur | jm1: the next version with patch in question will break anyone who co-installs it with openstacksdk from Zed | 14:25 |
| gtema | okay, that may be the case, but it's not due to SDK. We tried to request 1.0.0.rc1 (b1, or else), but this is not possible by RM. Thus now we have this 0.99 madness | 14:25 |
| dtantsur | jm1: this includes bifrost, as you can see from the failing job you noticed | 14:25 |
| jm1 | dtantsur: ansible openstack collection 1.x.x must only be used with openstacksdk <0.99.0. if openstacksdk 0.99.x or 1.x.x is going to be released with Zed, then iiuc Bifrost Zed should not be using Ansible OpenStack collection 1.x.x. This is not something AOC can really change. we have no manpower to keep backward compatibility in aoc with new sdk | 14:26 |
| jm1 | dtantsur: let me try to rephrase: openstacksdk 0.99.x/1.x.x introduced breaking changes (which make sense btw) to sdk<0.99.0. we have no manpower to add a compatibility layer in aoc for old and new sdk to keep our collection backward compatible. we barely have the manpower to port aoc the new sdk... | 14:29 |
| dtantsur | jm1: it's not going to, 0.99 is already in upper-constraints | 14:29 |
| gtema | it's not going to, 0.99 is already in upper-constraints - I would say this is the problem | 14:29 |
| gtema | this should not actually happen | 14:29 |
| jm1 | dtantsur, gtema: oha, this adds extra pressure for us (aoc) | 14:29 |
| dtantsur | upper-constraints is updated automatically for all new releases from the corresponding branch | 14:30 |
| dtantsur | you can ask the requirements team to withhold 0.99 but only if you plan to release 0.99.1 that somehow fixes it soon | 14:30 |
| gtema | then either we suggest to undo this or every project facing problem cap it requirements (this should be still possible to have dep lower then whatever in upper-constraints) | 14:31 |
| gtema | 0.99.1 will not solve the issue | 14:31 |
| dtantsur | capping can only be done on the global-requirements level | 14:31 |
| gtema | only once AOC is ready (and we do not hear other complains) we would be able to make R1.0.0 | 14:31 |
| dtantsur | meaning, nobody will get the new openstacksdk. at all. | 14:31 |
| dtantsur | you're also going to receive a lot of pushback IMO | 14:32 |
| gtema | hmm, I always thought you can have lower cap in requirements.txt then in upper-constraints | 14:32 |
| gtema | and it must be >= then whatever in lower-constraints | 14:32 |
| dtantsur | lower version is not a cap :) | 14:33 |
| gtema | okay, name it as you want | 14:33 |
| dtantsur | I think any exclusions are done centrally, and the reason is that otherwise it's easy to produce software that is not co-installable | 14:33 |
| dtantsur | imaging, ironic does openstacksdk>=0.99, nova does openstacksdk>=0.1.0,<0.99 | 14:34 |
| gtema | yes, but nobody is going to limit one lib due to one project failing to update fast | 14:34 |
| gtema | at least this should not happen | 14:34 |
| dtantsur | I don't think it will happen. which brings us back to square one: latest versions of aoc and sdk are not usable together | 14:35 |
| gtema | uhm | 14:35 |
| gtema | I am sad | 14:35 |
| dtantsur | what is even much worse, I don't think it's enforced at install time | 14:37 |
| dtantsur | so, pip will happily install sdk 0.99 from upper-constraints, galaxy will happily install 1.9.0 (or what is it going to be). boom. | 14:37 |
| gtema | what is not working currently in AOC? | 14:38 |
| gtema | maybe we can shift efforts to fix those issues explicitly (to unblock bifrost, etc) | 14:38 |
| sshnaidm | how is bifrost broken..? | 14:45 |
| dtantsur | it installs stuff from upper-constraints. including openstacksdk 0.99 | 14:46 |
| sshnaidm | what does it use from ansible openstack collection? | 14:47 |
| dtantsur | baremetal and identity stuffs | 14:47 |
| sshnaidm | let's prioritize them then | 14:50 |
| sshnaidm | dtantsur, do you have a list? | 14:50 |
| gtema | dtantsur: can you list particular modules used? | 14:50 |
| dtantsur | gimme a minute | 14:51 |
| gtema | no hurry | 14:51 |
| dtantsur | https://paste.opendev.org/show/btQRHBPVqHOjINSIcx6t/ | 14:53 |
| sshnaidm | catalog_service is in progress: https://review.opendev.org/c/openstack/ansible-collections-openstack/+/839352 | 14:55 |
| sshnaidm | endpoint is in progress: https://review.opendev.org/c/openstack/ansible-collections-openstack/+/836351 | 14:55 |
| sshnaidm | project is in progress: https://review.opendev.org/c/openstack/ansible-collections-openstack/+/839640 | 14:57 |
| sshnaidm | that's all in progress atm, I think | 14:58 |
| sshnaidm | others need to prioritize | 14:58 |
| jm1 | sshnaidm, dtantsur: bifrost pulls aoc from galaxy during setup, doesn't it? | 15:01 |
| jm1 | sshnaidm, dtantsur: we probably want to release aoc 2.0.0 when all modules have been ported, else we would release something which works partly with old sdk and partly with new sdk, which means its just broken. | 15:02 |
| sshnaidm | jm1, of course | 15:03 |
| jm1 | sshnaidm, dtantsur: priotizing some modules would thus only make sense if bifrost would pull aoc from git instead of galaxy | 15:03 |
| gtema | maybe do similar to SDK 1.99.0 (or something similar) | 15:03 |
| jm1 | gtema: because we made good experience with that decision? 😋 (just kidding) | 15:04 |
| sshnaidm | gtema, it will be still half-broken | 15:04 |
| gtema | sure, but somehow signals it is pre-release | 15:04 |
| gtema | sdk 0.99 is also "broken" from that angle | 15:04 |
| sshnaidm | yeah, it is :) | 15:04 |
| jm1 | gtema: sdk 0.99 is still in better shape than aoc with a handful of fixed modules only | 15:05 |
| sshnaidm | I'd rather to stick to semver, to put breaking changes in major release only | 15:05 |
| jm1 | sshnaidm: agree, and not release a known broken version | 15:06 |
| jm1 | dtantsur: will it be possible for bifrost to use master branch for sdk>=0.99.0? | 15:07 |
| sshnaidm | how crazy is idea to release sdk 0.99.1 with a code of 0.62? | 15:08 |
| sshnaidm | to return to a old good times | 15:09 |
| *** dviroel is now known as dviroel|lunch | 15:09 | |
| sshnaidm | btw, ansible-galaxy has an ability to have non-released versions like 2.0.0-dev or whatever, they won't be installed usually if user doesn't specify it explicitly. | 15:10 |
| sshnaidm | idk if it helps, but anyway | 15:10 |
| gtema | undoing sdk will be my personal disaster (a final nail on a coffin) ;-) | 15:11 |
| jm1 | sshnaidm, gtema: that non-released version idea might be a good idea | 15:11 |
| sshnaidm | gtema, yeah, I see :) | 15:12 |
| jm1 | sshnaidm: somehow i am blind, where do i find info about these dev releases on ansible galaxy? | 15:18 |
| sshnaidm | jm1, it's mostly "tribal knowledge", but it complies with semver https://galaxy.ansible.com/docs/contributing/version.html | 15:21 |
| sshnaidm | unlike openstack versions, which don't comply with semver | 15:21 |
| sshnaidm | I had long discussions with infra team while trying to tag a dev release of collections... | 15:22 |
| sshnaidm | Example: 1.0.0-alpha < 1.0.0. - https://semver.org/ | 15:23 |
| dtantsur | jm1: there is nothing preventing us from using aoc from git if needed | 15:23 |
| dtantsur | 2.0.0-dev1 would work as well | 15:23 |
| dtantsur | bifrost is operating in a venv, which makes certain things easier :) | 15:24 |
| sshnaidm | the best way would be just using sdk 0.6x in venv | 15:24 |
| dtantsur | sshnaidm: we don't want to diverge from upper-constraints | 15:25 |
| dtantsur | won't help if some project decides to go >=0.99 | 15:25 |
| jm1 | dtantsur: valid point, others will have the same issue | 15:25 |
| sshnaidm | yeah, I mean as a temporary workaround, not the solution | 15:26 |
| jm1 | sshnaidm: would a galaxy release with semver "2.0.0-something+001" not be larger than our latest 1.8.0 and thus choosen? | 15:27 |
| sshnaidm | any 2.0.0-something won't be installed at all if it's not specified explicitly | 15:30 |
| sshnaidm | jm1, you can play with some dummy collections in your space to test | 15:30 |
| jm1 | sshnaidm: ack, we will definitely test that before releasing that. but i think such a dev version on galaxy would require least effort for users | 15:35 |
| sshnaidm | probably, or they just can install from master | 15:35 |
| jm1 | sshnaidm: a right, that is easy: ansible-galaxy collection install git+https://github.com/org/repo.git,devel | 15:37 |
| jm1 | dtantsur: are you fine with us fixing your modules asap and you installing from git directly? | 15:38 |
| dtantsur | yep, thank you! | 15:46 |
| *** dviroel|lunch is now known as dviroel | 16:16 | |
| *** ysandeep|rover is now known as ysandeep|out | 17:00 | |
| opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack master: Adds mechanisms to extend OpenstackModule behaviors https://review.opendev.org/c/openstack/ansible-collections-openstack/+/843324 | 18:01 |
| opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack master: Update baremetal_node_info to use new sdk https://review.opendev.org/c/openstack/ansible-collections-openstack/+/843325 | 18:01 |
| opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack master: Update baremetal_node_info to use new sdk https://review.opendev.org/c/openstack/ansible-collections-openstack/+/843325 | 18:03 |
| opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack master: Update baremetal_inspect to be compatible with new sdk https://review.opendev.org/c/openstack/ansible-collections-openstack/+/843334 | 18:48 |
| opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack master: Adds mechanisms to extend OpenstackModule behaviors https://review.opendev.org/c/openstack/ansible-collections-openstack/+/843324 | 18:55 |
| opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack master: Update baremetal_inspect to be compatible with new sdk https://review.opendev.org/c/openstack/ansible-collections-openstack/+/843334 | 19:01 |
| opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack master: Update baremetal_inspect to be compatible with new sdk https://review.opendev.org/c/openstack/ansible-collections-openstack/+/843334 | 19:17 |
| *** dviroel is now known as dviroel|afk | 20:07 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!