| noonedeadpunk | > wrap usage of rust cli by ansible | 06:38 |
|---|---|---|
| noonedeadpunk | that somehow makes a very little sense to me | 06:38 |
| noonedeadpunk | I am really confused by attempts to fix speed of python-based toolings with rust wrapping | 06:39 |
| noonedeadpunk | as they won't make tooling any faster, just break behaviour and will make quite some uscases impossible | 06:40 |
| noonedeadpunk | also I really wonder how idempotency is gonna be ensured that way... | 06:41 |
| noonedeadpunk | fungi: it is just very messy and complicated and involves a lot of history | 06:42 |
| noonedeadpunk | and it's tough to bring any bugfixes or patches at the moment, and for the last 2-3 cycles at the very least | 06:43 |
| noonedeadpunk | as I think generating modules is in the air for at least 1.5 year. And under this argument improvements, new modules and patches used to be blocked | 06:44 |
| noonedeadpunk | but I'm not sure we're getting any closer to the goal | 06:44 |
| noonedeadpunk | also I've really never seen a rust being a requirement for any ansible module so far | 06:47 |
| noonedeadpunk | so if we're going to return back to conversation about tooling and communities around tooling - that's pretty much would a precedent I guess | 06:48 |
| noonedeadpunk | pretty much why I'm that concerned, is that in OSA we do have a role to create and manage openstack resources, and I personally use it quite a bit: https://opendev.org/openstack/openstack-ansible-plugins/src/branch/master/roles/openstack_resources | 06:56 |
| noonedeadpunk | with the idea that a resulting deployment will have all kind of required setup to be fully operational | 06:59 |
| noonedeadpunk | and then further manage images, flavors, compute aggregates, etc | 06:59 |
| noonedeadpunk | but actually auto-generating modules is a good idea overall | 07:07 |
| noonedeadpunk | and I think it also can resolve a licensing issue, as then we are not obliged to license it as GPL anymore I guess | 07:07 |
| noonedeadpunk | but again, I'd love to raise these all dicussions and concerns not on tc channel but withing the SIG on some a meeting or smth | 07:36 |
| *** elodille1 is now known as elodilles | 10:11 | |
| opendevreview | Dr. Jens Harbott proposed openstack/openstack-manuals master: Revert "Region / Availability Zone - update Glossary" https://review.opendev.org/c/openstack/openstack-manuals/+/947256 | 12:34 |
| frickler | fungi: spotz[m]: noonedeadpunk: ^^ rebased and changed the commit message | 12:34 |
| noonedeadpunk | frickler: I think we will still have to update it after we revert it | 12:36 |
| frickler | noonedeadpunk: I'm not opposed to that, but I want to avoid the mass-translation-deletions | 12:37 |
| noonedeadpunk | as ultimnatelly - I don't think that we should avoid touching something just not to break translations. But I agree that this should be communicated and better planned | 12:41 |
| noonedeadpunk | and way better executed | 12:42 |
| frickler | I agree for real content changes, not for "alpha" -> "Alpha" | 12:42 |
| frickler | tc-members: since we didn't get to CI issues yesterday: the current master oslo.middleware release causes CI failures, my pings in the oslo channel have not been responded to so far https://review.opendev.org/c/openstack/requirements/+/947557 | 12:43 |
| noonedeadpunk | well... we should never have had things like ` access control list (ACL)` - it's jsut wrong | 12:43 |
| noonedeadpunk | You don't do abbreviations like that | 12:43 |
| frickler | well it is openstack-ansible and you still abbreviate as OSA | 12:44 |
| noonedeadpunk | I _always_ write it as OpenStack-Ansible | 12:44 |
| noonedeadpunk | so if it's written anywhere in docs as `openstack-ansible` - I'd be willing to fix that | 12:45 |
| noonedeadpunk | Actually, just yesterday I've spotted that somewhere in list of projects it's renderring as `Openstackansible` even | 12:46 |
| frickler | ok, disregard that example. "access control list" to me is a normal english term, with "ACL" as acronym, I don't see anything wrong with that | 12:46 |
| noonedeadpunk | why we have then `Domain Name System (DNS)`? | 12:47 |
| noonedeadpunk | I think I am fine with any rule, as long as it is consistent | 12:47 |
| frickler | I didn't say that the glossary is consistent in itself | 12:48 |
| frickler | the current rule is: terms that include an acronym "may" be capitalized | 12:48 |
| noonedeadpunk | So for me the inconsistency is what is annoying a bit | 12:48 |
| noonedeadpunk | but anyway | 12:49 |
| noonedeadpunk | we can agree to disagree here I guess :) | 12:49 |
| spotz[m] | Keep in mind some OpenStack-Ansible mentions refers to the project and others to the output of the SiG | 12:50 |
| spotz[m] | Grammar/writind wise, you should always do a first mention like Domain Name System(DNS) before referring to DNS in a doc | 12:51 |
| frickler | spotz[m]: we are talking about the keys in the glossary here. introducing acronyms before using them is not questioned. the issue is whether "domain name system (DNS)" is a valid alternative to "Domain Name System (DNS)" | 12:53 |
| spotz[m] | Oh cap vs noncap, in that instance no. But unless you have a specific guide that gets hard. For the longest time I did SiG vs SIG:) | 12:57 |
| fungi | yeah, also if the glossary entry name gets switched from "Domain Name System" to "Domain Name System (DNS)" then every single reference to that entry in any other document has to be updated for the new url (unless backward-compatible aliases are inserted, which the author of the patch recommended for revert did not do) | 12:58 |
| spotz[m] | frickler: With your -2 on https://review.opendev.org/c/openstack/openstack-manuals/+/947180 it's unclear if you want them to just abandon that as the revert will make it obsolete | 12:58 |
| spotz[m] | Atleast that's how I read your comment | 12:59 |
| frickler | spotz[m]: no need to abandon, the bot will generate a new update once the revert is merged which should look better | 12:59 |
| spotz[m] | Ahh ok:) | 12:59 |
| frickler | I just want to avoid that change to incidentally get merged in the current state | 13:00 |
| spotz[m] | Sounds good | 13:01 |
| frickler | gouthamr: do you want to chime in on https://review.opendev.org/c/openstack/openstack-manuals/+/947256 ? or do we need some more TC discussion so that we can get a consensus vote on it? | 13:49 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: install-guide: 2023.2 Bobcat to End of Life https://review.opendev.org/c/openstack/openstack-manuals/+/948425 | 14:29 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: install-guide: 2023.2 Bobcat to End of Life https://review.opendev.org/c/openstack/openstack-manuals/+/948425 | 14:32 |
| gmaan | +2 on 947256. I prefer a justified commit msg even for such formatting changes on how it helps in term of doc readability. | 17:01 |
| opendevreview | Elod Illes proposed openstack/openstack-manuals master: [www] Set 2023.2 Bobcat as End of Life https://review.opendev.org/c/openstack/openstack-manuals/+/948577 | 19:33 |
| opendevreview | Merged openstack/governance master: [resolution] Extend scope of VMT to cover all project teams https://review.opendev.org/c/openstack/governance/+/944817 | 20:35 |
| gouthamr | sorry, i lacked the bandwidth to look at https://review.opendev.org/c/openstack/openstack-manuals/+/947256 . i workflowed it, frickler | 22:21 |
| gouthamr | noonedeadpunk (and others): thanks for suggesting a plan, and explaining things | 22:23 |
| gouthamr | i hate reverts too, and especially something that's been vetted/approved by two reviewers over multiple iterations.. but, in our complicated world we don't understand all the impact, all the time.. | 22:23 |
| opendevreview | Merged openstack/openstack-manuals master: Revert "Region / Availability Zone - update Glossary" https://review.opendev.org/c/openstack/openstack-manuals/+/947256 | 22:27 |
| opendevreview | OpenStack Proposal Bot proposed openstack/security-doc master: Updated from openstack-manuals https://review.opendev.org/c/openstack/security-doc/+/948597 | 22:32 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!