15:00:02 #startmeeting kolla 15:00:02 Meeting started Wed Nov 3 15:00:02 2021 UTC and is due to finish in 60 minutes. The chair is mnasiadka. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:02 The meeting name has been set to 'kolla' 15:00:09 #topic rollcall 15:00:14 o/ 15:02:40 \o 15:02:51 o/ 15:03:10 \o 15:04:43 o/ 15:05:00 o/ 15:05:13 mnasiadka: remember about the extra agenda in etherpad :-) 15:05:22 #topic agenda 15:06:10 * Announcements 15:06:10 * Review action items from the last meeting 15:06:10 * CI status 15:06:10 * Release tasks 15:06:10 * Yoga cycle planning 15:06:12 * Security bugs to squash 15:06:12 * Switch docs to recommend installing from git repo; re: https://review.opendev.org/c/openstack/kolla-ansible/+/815043 15:06:14 * New core-reviewer 15:06:14 * Open discussion 15:06:33 #topic Announcements 15:06:46 I'm off next week, any volunteer to run the meeting next Wed? 15:07:11 let me check 15:07:25 ok, I'm available 15:07:32 Ok then 15:07:45 #action yoctozepto to run the meeting next week 15:07:48 Thanks! 15:07:53 yw :-) 15:07:57 #topic Review action items from the last meeting 15:08:19 Seems none last week 15:08:33 #topic CI status 15:09:02 seems green 15:09:08 Kayobe is amber on Wallaby (disk issues) 15:09:32 change was merged, should we update back to green? 15:10:26 I'll check history later and see if it's green again (and check with priteau) 15:10:35 #topic Release tasks 15:10:46 mgoddard, yoctozepto: is it time to cut RC2? 15:10:56 sure 15:11:10 https://review.opendev.org/c/openstack/kolla-ansible/+/814942 this was merged (mentioned on last weeks meeting) 15:11:18 and I think we reverted the problematic patch 15:11:20 ok then 15:11:39 what about mariadb patch? 15:11:45 which one? 15:11:54 the one I mentioned yesterday 15:11:55 https://review.opendev.org/c/openstack/kolla-ansible/+/814276 15:12:31 Ah, I did not look into that, since mgoddard reviewed that earlier - so I waited for him to act upon it ;-) 15:13:06 I'll try to have a look later 15:13:16 so wait for this for rc2 15:13:27 this should get mariadb to its regular glory 15:13:38 added rc2-blocker hashtag and will keep an eye for that 15:13:56 and once it merges (and is backported) will post rc2 releases patches 15:14:14 ok, let's move on 15:14:26 #topic Yoga cycle planning 15:14:41 I haven't been able to populate Priorities on the whiteboard yet 15:15:36 But will do at latest tomorrow 15:15:50 Any other things that we need to consider at this point? 15:17:26 nothing specific from me 15:18:17 Other day I was thinking if we shouldn't follow what some other projects do - post ,,bugs'' with [RFE] prefix and target them to Yoga milestone in Launchpad - but I think priorities on the whiteboard worked quite OK 15:19:36 yoctozepto, mgoddard: opinions? (sometimes I feel the whiteboard is a bit ,,overcrowded'') 15:20:48 mnasiadka: you're basically reintroducing the blueprints that we dropped the other week? 15:21:04 not really reintroducing, but fair point - let's stick to whiteboard for now :) 15:21:18 #topic Security bugs to squash 15:21:28 yoctozepto: do we have any? 15:22:05 Whiteboard is crashing Chrome on Android :) and some prefixes or tags (in a similar idea like in Gitlab https://ibb.co/RpRjNng ) could be useful 15:22:57 mnasiadka: we do 15:23:51 mnasiadka: this topic to make you look at them 15:24:17 well, where do I find them in launchpad? 15:24:43 gimme a sec 15:25:05 kolla https://bugs.launchpad.net/kolla/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.informat 15:25:05 ion_type%3Alist=PRIVATESECURITY&field.information_type%3Alist=USERDATA&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_ 15:25:05 branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on 15:25:19 kolla-ansible https://bugs.launchpad.net/kolla-ansible/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONS 15:25:19 E&field.information_type%3Alist=PRIVATESECURITY&field.information_type%3Alist=USERDATA&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch. 15:25:19 used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on 15:26:08 I'm open to explaining/discussing mine in there if you need more details 15:26:20 as for the others, I guess we should decide whether not to open them 15:26:26 or close entirely (-: 15:26:42 oh boy, nice links - I'll make some shortened urls and look through them ;-) 15:27:03 that's launchpad for ye 15:27:44 ok, the first two (haproxy and horizon dir listings) seem self explanatory 15:27:56 do we have any volunteers to work on those? 15:28:04 yeah, need to check if they happen still 15:28:35 I hoped you could spend some resources :-) I'm overloaded these days 15:28:46 and the last time seems not so trivial, because we would need to skim the logs in search of those passwords 15:28:52 yoctozepto, can you please shorten that URL? I can't concat it to something meaningful 15:29:15 Ok, let me at least triage those - and get back with some updates to those bugs. 15:29:25 adrian-a: it's a private list, I don't think you have access. 15:29:34 o, mkay 15:29:53 yeah, he does not 15:29:55 #action mnasiadka to triage security bugs and update them with resolution plan (if needed) 15:30:06 great, mnasiadka :-) 15:30:13 #topic Switch docs to recommend installing from git repo; re: https://review.opendev.org/c/openstack/kolla-ansible/+/815043 15:30:18 yoctozepto: that's yours? 15:30:26 mnasiadka: always mine 15:30:56 there is some discussion as to how to handle the recommendation on the source of kolla-ansible code 15:31:08 I argue we are better off recommending git 15:31:33 as this is what we test and I guess also run in production as we don't release often enough 15:31:44 moreover, the versioning is confusing 15:32:09 each component has a different version so hard to tell what has been installed from the version only 15:32:12 unless reading renos 15:32:17 which folks don't do (-: 15:32:29 or at least not often enough to make me glad they do 15:33:03 well, from one perspective I'm ok with that, from other - maybe we should do releases more often 15:34:38 but it's fine for the docs to point to git instead of pypi 15:34:42 any other voices of reason? 15:34:57 sounds good 15:35:23 mgoddard, frickler? 15:35:54 fine by me 15:36:06 git is good 15:36:31 #agreed to recommend installing from git repo in the docs 15:36:37 frickler: I'll print that quote and frame it 15:36:50 "git is good" 15:36:59 yoctozepto: are you going to follow up? 15:37:16 yeah, action me on that to keep this flowing on 15:37:23 well, I think the author is adrian-a, right? 15:37:38 I'll add a comment to the review and link to IRC log and I'll complete the commit with git 15:37:47 great, case solved 15:38:08 let's move on 15:38:22 #topic New core-reviewer 15:39:22 I think it's time to add a new core reviewer - especially if that person is outside of StackHPC - out of the list of contributors - I think kevko is a good candidate (with proper review stats and good knowledge of kolla/kolla-ansible code) 15:40:01 adrian-a: many thanks! 15:40:17 yoctozepto, yw :) 15:40:23 If there are no objections - I'll propose him through the mailing list. 15:40:41 And the question is - first kolla or kolla-ansible or both? 15:40:49 both 15:40:52 mnasiadka: both 15:41:16 +2 ... oh wait, I can only +1 ... ;) 15:41:46 ok then, both 15:41:47 frickler needs to work a bit more to gain the core title :-) 15:42:11 yes, I plan on doing that, but that'll take some time I agree 15:42:29 no rush, quality over quantity :-) 15:42:37 yup 15:43:03 #topic Open discussion 15:43:14 Phew, we made to open discussion this time ;-) 15:43:41 oh noez 15:43:49 let's check if we have not missed some point in the agenda (-: 15:44:05 c'est impossible ! 15:44:16 we have gone through all of 'em 15:44:21 congrats mnasiadka 15:46:15 ok, no open discussion points from anybody? ;-) 15:48:49 c'est impossible aussi ! 15:49:01 well, I have a FYI that I'm trying to make a minimal change for switching over service configs in keystone_authtoken from project scoped tokens to system scope. 15:49:18 should be ready soon 15:49:22 I see 3 options on this (last comment), what do you think? https://review.opendev.org/c/openstack/kolla-ansible/+/816076 15:50:17 headphoneJames: sounds wonderful 15:50:58 adrian-a: A2 or C 15:51:02 yoctozepto: haven't we tried to get rid of init-runonce from tools/ at some point? 15:51:33 where C is pip install python-openstackclient -c 15:51:35 mnasiadka: we did 15:51:48 mgoddard: ++, in docs only though 15:51:51 adrian-a: ^ 15:52:03 mnasiadka: I guess we should then hurry 15:52:27 and amend the docs not to recommend that as something necessary 15:52:32 Well, hurry or not - I think we should discuss if init-runonce is the toolset we want to maintain and if users should be really running it ;-) 15:53:06 well, it kind of works, and we recommend against running it in production 15:53:17 but we need something like it for testing 15:53:17 mnasiadka: let's discuss then - we should not recommend it :D who objects? 15:55:00 no objections 15:55:02 I think we already recommend against it, I'm fine in adding a message to post-deploy to install python-openstackclient (and some other clients - preferably in a venv ) or in docs 15:55:17 but not really to automate that part 15:55:24 action me to hide it properly 15:55:28 and go-go-go 15:56:00 #action yoctozepto hide properly init-runonce 15:56:03 (whatever that means) 15:56:13 So should I leave pip install python-openstackclient + maybe add a note this installs the latest stable client and some example pip commands with git URL and tags for other releases? 15:56:14 lol 15:56:20 *in docs (leave) 15:56:27 adrian-a: see mgoddard's message about -c 15:56:39 mnasiadka since i really automated a lot of this in the last 3 weeks. I find installing the client is entirely mandatory since openstack is useless with GUI only. init-runonce i ack that it is just not the right thing and instead of running it (what i did in the start) i did something like 15:56:39 https://github.com/EugenMayer/openstack-lab/blob/stable/ovn/README.setup.md 15:56:54 leave in docs, add upper constraints 15:56:56 yoctozepto: I haven't found a '-c' flag in pip, not sure what that does 15:57:13 adrian-a: constrains versions 15:57:20 it will do the right thing (TM) 15:57:40 and it's not documented? haven't found it, e.g. https://manpages.debian.org/stretch/python-pip/pip.1 15:57:42 yoctozepto: kayobe uses init-runonce, so at a minimum please add a symlink to avoid breaking us 15:57:42 EugenMayer: sure, but it depends on users environment - we can fix the example in docs how to install the openstack client - but I don't think we should be automating that in post-deploy 15:58:10 mgoddard: oh my, you mean in CI, right? 15:58:15 RIGHT?! :D 15:58:22 mnasiadka: i would say, that installing the openstack client,when using kolla, on the deployer is an key concept. It cannot be really optional IMHO 15:58:23 yoctozepto: well, testing, yes 15:58:30 mgoddard: ok 15:58:57 EugenMayer: but we can't cover all cases, and sometimes you don't use the deployment host as the client host, I still prefer docs :) 15:59:10 ok then, I think it's enough for today 15:59:12 EugenMayer: it can, the deployment machine might not ever be used as the client 15:59:15 Thanks for attending! 15:59:16 ;-) 15:59:19 #endmeeting