14:00:24 #startmeeting tripleo 14:00:24 Meeting started Tue May 21 14:00:24 2019 UTC and is due to finish in 60 minutes. The chair is mwhahaha. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:24 #topic agenda 14:00:24 * Review past action items 14:00:24 * One off agenda items 14:00:24 * Squad status 14:00:25 * Bugs & Blueprints 14:00:25 * Projects releases or stable backports 14:00:26 * Specs 14:00:26 * open discussion 14:00:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:27 Anyone can use the #link, #action and #info commands, not just the moderatorǃ 14:00:27 Hi everyone! who is around today? 14:00:28 The meeting name has been set to 'tripleo' 14:00:44 o/ 14:00:50 o/ 14:01:09 o/ 14:01:09 o/ 14:01:15 «o/ 14:01:34 o/ 14:01:35 o/ 14:01:41 o/ 14:01:56 o/ 14:03:50 alright looks like we've got a few people here 14:03:59 and a light agenda so let's go 14:04:00 #topic review past action items 14:04:05 \o/ 14:04:07 None. 14:04:25 o/ 14:04:44 o/ 14:04:47 #topic one off agenda items 14:04:52 #link https://etherpad.openstack.org/p/tripleo-meeting-items 14:04:57 (fmount|fultonj) ceph-dashboard blueprint: we have the blueprint and the first PRs merged on ceph-ansible 14:05:03 #link https://blueprints.launchpad.net/tripleo/+spec/ceph-dashboard/ 14:05:24 o/ 14:05:30 o/ 14:05:35 o/ 14:05:40 hi, we have the first ceph-ansible code merged, so I think we can review the ceph-dashboard bp to move forward 14:05:42 \o 14:05:44 fultonj: ^ 14:05:50 can the blueprint be approved? 14:06:31 i'll take a look today 14:06:42 mwhahaha: ok thx 14:06:45 o/ 14:07:02 o/ 14:07:35 mwhahaha: if you have question about the bp ping me and let's discuss about it 14:07:39 k 14:07:44 (or anyone ^) 14:07:55 fultonj: so did you add the question abotu the ansible bits? 14:07:59 i think it depends on what it looks like 14:08:23 on what the embeded ansible looks like :) 14:08:24 ? 14:08:29 yea 14:08:42 https://review.opendev.org/#/c/657166/1/deployment/ceph-ansible/ceph-mon.yaml 14:09:03 mwhahaha: before we dive into the embded ansible... 14:09:12 is that a pattern we want to move to? 14:09:31 you mean using a role? 14:09:32 yes 14:09:35 scale down tasks and wanting simple re-use is driving this 14:09:45 Chandan Kumar (raukadah) proposed openstack/tripleo-quickstart master: [fs017]Remove member role from auth.tempest_roles overrides https://review.opendev.org/660351 14:09:52 and i see a pattern similar to how we're using validations 14:10:05 mwhahaha: but we ship validations ansible as a package 14:10:15 tripleo-ansible isn't installed by default AFAICT 14:10:25 i'm not sur eit's packaged yet? 14:10:31 i think that's something we can try and get to this cycle 14:10:33 mwhahaha: yeah, it's probably not 14:10:38 it should just be a dep for the undercloud 14:10:41 or THT 14:11:38 well it should be packaged 14:11:40 https://bugzilla.redhat.com/show_bug.cgi?id=1645311 14:11:40 bugzilla.redhat.com bug 1645311 in Package Review "Package review: tripleo-ansible - Ansible project for TripleO" [Unspecified,Closed: rawhide] - Assigned to jpena 14:11:41 gfidente: ^ fyi 14:12:07 https://github.com/rdo-packages/tripleo-ansible-distgit 14:13:02 yay it's packaged 14:13:15 ' yum install tripleo-ansible' "just works" 14:13:18 though looking at the contents, it seems to be a module 14:13:40 i think the original intent of that repo was for like day2 ops stuff 14:13:53 tripleo-common might be the best bet for any roles (i hate saying this) 14:14:38 https://github.com/openstack/tripleo-common/tree/master/playbooks/roles 14:14:43 ha 14:15:17 so i can make a ceph dir and get started 14:15:33 mwhahaha: having tripleo-ansible and keeping piling ansible stuff into tripleo-common would be a weird strategy 14:15:46 just wanted to ask before i got started if i was heading in the right general direction 14:15:50 so we can populate playbooks/roles in tripleo-common? 14:16:07 yea but if you look at the layout of tripleo-ansible, it doesn't really seem like a great place to put roles 14:16:07 bogdando: agree 14:16:35 the original goal was to use the ansible-role-tripleo-* things for these types of thing 14:16:40 so i can make a ceph dir and get started (in tripleo-common) 14:16:44 i meant common 14:16:45 but in this case it's like a tripleo-ceph role that's needed 14:16:55 o/ 14:17:19 it's for deployments but will have day2 overlap 14:17:23 right now it's more deployments leaning 14:17:31 yea that's the awkwardness 14:18:16 I'm tempted to say we start using tripleo-ansible 14:18:23 though not sure what that layout should be 14:18:31 fultonj: I guess the cache mgmt ansible is similar... could we just restructure tripleo-ansible? 14:18:45 owalsh: right, i assume you'll hit this question too 14:19:39 fultonj: this could be a good opportunity to restructure tripleo-ansible 14:19:59 mwhahaha: wdyt ^ 14:20:03 sure 14:20:26 AFAICT tripleo-ansible isn't really used. e.g. it's not shipped by default. 14:20:30 it was going to be 14:20:37 so now what do we do with it 14:20:38 ? 14:21:07 slagle: ^ ? 14:21:13 ship it ? 14:21:28 it had podman related modules 14:21:34 which we might actually want to use at some point 14:21:40 which isn't used anywhere nor tested 14:22:04 (molecule is needed for testing :D) 14:22:06 and we could as well collaps ansible-role-tripleo-* things into it 14:22:46 if someone wants to do the work, let's do it 14:22:55 i would like to eventually look at replacing paunch the cli with an ansible version 14:23:05 so maybe that could be handled in tripleo-ansible as well 14:23:11 sounds to me like, unless someone's going to restructure tripleo-ansible the place today would be common. 14:23:35 also what if we want to backport any of the ansible stuff? 14:24:06 are roles in tripleo-common include_role'd in tht already? 14:24:10 does that pattern exist? 14:24:19 we could punt the move until later 14:24:37 i think they are 14:24:39 would need to check the THT 14:24:59 techincally we have two sets of roles in tripleo-common 14:25:04 the octavia stuff and https://opendev.org/openstack/tripleo-common/src/branch/master/roles 14:26:38 do we want to do the move during train OR put new stuff in common and differ the move to post-train? 14:27:33 it seems that pretty all roles importes/includes in tht are from the tripleo-common 14:27:36 fultonj: yes include_role is used already 14:27:54 (at least for tripleo-containers-rm) 14:27:55 so let's keep it as is perhaps 14:28:54 perhaps for train it would be too much to make this change and it sounds like i can use an existing pattern without messing with the existing deployment framework 14:29:01 Merged openstack/tripleo-ci master: Add another nodepool provider ID https://review.opendev.org/660138 14:29:24 and if backports wanted as per owalsh it would work from there 14:29:26 thanks 14:29:34 ack 14:30:23 fultonj: +1 14:30:31 k so i guess propose in tripleo-common and we'll punt on the tripleo-ansible bits for now 14:31:49 thanks all, next topic? 14:31:58 mathieu bultel proposed openstack/tripleo-heat-templates master: Force ansible serial to 1 for the controller https://review.opendev.org/658814 14:32:49 If there is no any other topic in queue I want to discuss about this blueprint https://blueprints.launchpad.net/tripleo/+spec/os-client-config-switch 14:33:15 meh 14:33:42 so we already partially implemented that for standalone 14:33:48 since we have added support for clouds.yaml for standalone and undercloud 14:33:54 we'd need to create a workflow for generating that for the overcloud 14:34:00 I am about to start working on overcloud 14:34:07 I would just generate both for now 14:34:15 and we can remove the *rc files in a later release 14:34:30 but the question is https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/extraconfig/post_deploy current code and tht stuff resides here 14:34:52 can we move the same https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/extraconfig/post_deploy/clouds_yaml.py script to python-tripleoclient 14:35:02 it wouldn't be tripleoclient 14:35:05 it would be in tripleo-common 14:35:09 and tripleoclient 14:35:23 and generate the clouds.yaml for stdanlone overcloud and undercloud 14:35:25 you'll want to find the existing stackrc generation and either modify it or duplicate it 14:35:41 the undercloud would be using the post_deploy method 14:35:43 the overcloud is different 14:35:55 there was a bug about the fact we generate this info in like 3 places 14:36:47 is it this one https://bugs.launchpad.net/tripleo/+bug/1801927 14:36:48 Launchpad bug 1801927 in tripleo "[RFE] Set up clouds.yaml in undercloud stack user" [Medium,Fix released] - Assigned to Harald Jensås (harald-jensas) 14:36:49 ? 14:36:53 https://opendev.org/openstack/tripleo-common/src/branch/master/workbooks/deployment.yaml#L720 14:37:15 no different one 14:37:58 https://bugs.launchpad.net/tripleo/+bug/1719369 14:37:59 Launchpad bug 1719369 in tripleo "multiple methods for generating openrc files" [High,Triaged] 14:39:08 anyway feel free to workon that 14:39:33 just do it with the existing openrc files in place and we can deprecate those 14:39:35 ok, then we need to make changes in the tripleo-common and trigeer clouds.yaml step just after rc file generation 14:40:44 mwhahaha: one more question, if it is a multinode deployment, do we used a single clouds.yaml file for storing undercloud and overcloud os_cloud name? 14:41:01 we would need to 14:41:15 which makes this all the trickier :D 14:41:26 ok, then I will work on that, thanks :-) 14:41:31 that's it from my side 14:41:34 alright moving on 14:41:42 #topic Squad status 14:41:42 ci 14:41:42 #link https://etherpad.openstack.org/p/tripleo-ci-squad-meeting 14:41:42 upgrade 14:41:42 #link https://etherpad.openstack.org/p/tripleo-upgrade-squad-status 14:41:43 edge 14:41:43 #link https://etherpad.openstack.org/p/tripleo-edge-squad-status 14:41:44 integration 14:41:44 #link https://etherpad.openstack.org/p/tripleo-integration-squad-status 14:41:45 validations 14:41:45 #link https://etherpad.openstack.org/p/tripleo-validations-squad-status 14:41:46 networking 14:41:46 #link https://etherpad.openstack.org/p/tripleo-networking-squad-status 14:41:49 any status things to highlight? 14:44:27 Tengu: are we still planning to have integrated step validations in train? 14:44:50 we talked about it, i think so 14:44:59 fultonj: well the code for that is already present, so yes. 14:45:33 Tengu: didn't you already activate some on a few jobs the simple containerd/service ones? 14:45:33 ack 14:45:58 marios|ruck|call: it's not in the tripleo-validations, it's still in tripleo-quickstart-extras 14:46:01 Tengu: oh step validations... sorry that is diffferent 14:46:16 :) 14:46:50 alright if there are no more status related things, moving on 14:47:30 #topic bugs & blueprints 14:47:30 #link https://launchpad.net/tripleo/+milestone/train-1 14:47:30 For Train we currently have 20 blueprints and 490 (+2) open Launchpad Bugs. 488 train-1, 2 train-2. 104 open Storyboard bugs. 14:47:30 #link https://storyboard.openstack.org/#!/project_group/76 14:47:49 Bogdan Dobrelya proposed openstack/tripleo-specs master: Add a spec for K8s Metal3 baremetal operator https://review.opendev.org/659288 14:47:54 any bugs to highlight? 14:50:12 Merged openstack/tripleo-heat-templates stable/stein: Set arp_notify to match ndisc_notify https://review.opendev.org/660209 14:50:32 sounds like nope 14:50:38 #topic projects releases or stable backports 14:50:47 we EOL'd pike last week 14:50:48 just fyi 14:50:52 so there was a final release for that 14:51:11 I need to sync up with the release folks and get them to EOL ocata as well as I don't think it was ever completed for us 14:51:17 any backports that need reviewing? 14:53:09 https://review.opendev.org/#/c/658745/ PTAL (backport to stein) 14:54:04 k 14:54:06 done 14:54:13 #topic specs 14:54:14 #link https://review.openstack.org/#/q/project:openstack/tripleo-specs+status:open 14:54:20 please take a moment to review teh specs 14:54:30 we want to get them reviewed/merged by M! which is coming up in a few weeks 14:54:34 also M1 14:54:51 https://blueprints.launchpad.net/tripleo/+spec/undercloud-minion there is an idea to extend this to a particular Ironic Conductor deployment role not limited to UC 14:55:08 mwhahaha, thanks 14:55:24 any spec related items? 14:55:30 mwhahaha: ^^ 14:55:46 can we design it the way it won't be UC limited 14:55:47 ? 14:55:57 that is not the goal 14:56:05 so no 14:56:12 we're not working on an standalone ironic 14:56:15 well, I was thinking a role can be applied to a node you know... 14:56:26 we already have an ironic conductor role 14:56:27 not necessary to undercloud 14:56:33 ok got it 14:56:36 so the undercloud minion is it's own seperate thing 14:56:51 it'll have just heat-engine and ironic-conductor roles that can be enabled/disabled 14:56:59 but it has to talk to an undercloud (for db/messaging) 14:57:05 do you think allowing that existing Ironic conductor role to be used as a minion may fit that spec scope? 14:57:15 it's already in the reviews 14:57:22 not UC minion, just a minion 14:57:27 no 14:57:30 :( 14:57:53 maybe i'm not understanding the target architecture 14:58:01 ironic-conductor is not a standalone thing 14:58:04 what would it talk to? 14:58:41 the case is doing pretty same, but not against undercloud. But some deployed-server to co-locate the Ironic conductor and assisting undercloud as a minion 14:58:56 that's would be the overcloud compute 14:58:59 just pre-deployed 14:59:06 think of it as undercloud minion :) 14:59:11 ... 14:59:11 just mixed roles 14:59:25 no because you have to wire up the endpoint against the undercloud 14:59:30 you can't mix under/overcloud roles 14:59:34 lesigh 14:59:37 ok then 15:00:00 #topic open discussion 15:00:11 alright we have like 0 time left, any other items? 15:01:12 Emilien Macchi proposed openstack/tripleo-common stable/stein: fix 404 when requesting empty tripleo container image catalog https://review.opendev.org/660418 15:01:18 alright thanks everyone 15:01:19 #endmeeting