14:00:57 #startmeeting kayobe 14:00:57 Meeting started Mon Apr 15 14:00:57 2019 UTC and is due to finish in 60 minutes. The chair is mgoddard. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:01 The meeting name has been set to 'kayobe' 14:01:14 #topic rollcall 14:01:33 o/ 14:01:41 \o 14:01:48 |o| 14:04:24 #topic agenda 14:04:30 * Roll-call 14:04:32 * Announcements 14:04:34 * Review actions from last meeting 14:04:36 * Kayobe whiteboard https://etherpad.openstack.org/p/kayobe-whiteboard 14:04:38 * Discussion 14:04:40 ** Denver Summit Forum https://etherpad.openstack.org/p/DEN-19-kayobe-feedback-roadmap 14:04:42 ** Switching to kolla master branch 14:04:44 ** Stein release planning https://etherpad.openstack.org/p/kayobe-stein-release 14:04:46 ** Bug review & squash 14:04:48 * Open Discussion 14:04:50 #topic announcements 14:05:10 #info OpenStack Stein was released last week 14:05:21 Kolla are still working on their release 14:05:31 Anyone else have any? 14:06:39 #topic review actions from last meeting 14:06:40 None from me 14:07:36 hmm, last meeting logs are from 18/03 14:07:54 We cancelled the last meeting due to Open Infra Days UK 14:08:20 so we did priteau. Memory like a sieve 14:08:28 #topic Kayobe whiteboard https://etherpad.openstack.org/p/kayobe-whiteboard 14:08:44 #link https://etherpad.openstack.org/p/kayobe-whiteboard 14:09:19 The kolla whiteboard has had some good input from the team, we should bring some things across to ours 14:09:51 After the nightmare Tenks on nested virt issue, we seem to be ok again with CI 14:10:59 does anyone have patches they'd like to receive attention in the next couple of weeks? 14:11:09 please add them to the review priorities if so 14:13:16 #topic Discussion 14:13:28 Denver Summit Forum https://etherpad.openstack.org/p/DEN-19-kayobe-feedback-roadmap 14:13:59 This is the last meeting before the summit, I'll be away for the next one 14:14:19 Last chance to populate the above etherpad with discussion items 14:14:38 The content is a copy of the Berlin etherpad I assume? 14:14:57 priteau: it's based on that, yes 14:16:14 To put it differently, is there anything can ask our users to improve the project? 14:16:28 *to help us improve :) 14:17:49 let's move on 14:17:53 From a couple of discussions I've had recently, making it easy to work with pre-provisioned nodes is important. 14:18:06 I see we have https://storyboard.openstack.org/#!/story/2004912 for it 14:18:12 priteau: with an external provisioning system? 14:19:04 In one case, Foreman. In another case, an admin with a USB stick. 14:19:21 I think pre-provisioned can mean different things 14:19:42 the use case in that RFE seems to be about skipping host configure 14:20:15 or is it just about skipping 'kayobe overcloud provision'? 14:20:38 I think it's the latter 14:20:50 looks like 'overcloud provision' to me. Wouldn't this work if you didn;t add it to the overlcoud group? 14:20:50 ok, that shouldn't be too hard, could add a flag 14:21:11 we rely on the overcloud group for quite a few things 14:21:26 I also think it's the latter in the discussions I've had 14:21:47 ok, makes sense. 14:22:15 In this case I was given a VM to deploy Monasca on with Kayobe 14:22:29 (pre-provisioned VM) 14:22:30 should just be a case of adding a per-host flag, then skipping the provision/deprovision tasks 14:22:50 how hard can it be? (TM) 14:22:58 👍 14:24:09 Do we need some integration with the `overcloud inventory discover` step as well? 14:24:44 I think that would be tough - the source of that info is in ironic 14:25:27 we could add docs on how to put hosts in a second inventory file, alongside the autogenerated one 14:25:42 I mean so you could mix in nodes from Bifrost, and external ones. Maybe it's already supported? I haven't tried it. 14:26:36 Second inventory file, that's a good idea. 14:26:51 👍 14:26:54 added some notes to that RFE 14:27:08 thanks 14:27:29 we could even test it using https://github.com/stackhpc/a-universe-from-nothing 14:28:10 onwards and upwards 14:28:12 #topic Stein release planning https://etherpad.openstack.org/p/kayobe-stein-release 14:28:41 oops, think I missed the 'switch to master' topic 14:28:47 it's essentially the same thing 14:29:04 The switch to master patch should be in the gate now 14:29:18 After which we immediately switch to stable/stein :) 14:29:54 but then we can revert the stein patch to go back to master once we've created an RC1 release candidate and a stable/stein branch 14:30:57 I think we have some issues with bifrost in stable/stein, I'm turning the handle to get some new releases out, and updating the versions in kolla, then when the new images pop out, it may or may not start working 14:31:28 #link https://review.openstack.org/652670 14:31:33 #link https://review.openstack.org/652668 14:32:07 I'll be away, but if in 2-3 days time someone could recheck the Stein patch, that would be grand 14:32:38 I'll set a reminder 14:32:40 I think we're at the point where we ought to start setting some dates to aim for, and getting last features in 14:32:43 thanks priteau 14:33:13 hard blocker is the kolla stein release, I expect that to be at least 2 weeks out 14:33:34 does anyone have features they want to get into stein? 14:34:10 If I have time by the end of the week I'd like to get the Cumulus patch updated to be merged in Stein 14:35:07 that would be nice 14:35:30 I'd like to see the Swift change go in. Please help Scott if he needs it while I'm away 14:37:38 Merged openstack/kayobe master: Use master version of dependencies https://review.openstack.org/615596 14:37:47 Would it be worth trying to get: https://storyboard.openstack.org/#!/story/2004367 in as well? 14:37:49 \o/ 14:38:13 jovial[m]: I'd certainly like to see that 14:38:24 jovial[m]: do you know where to start with it? 14:38:37 jovial[m]: we could always start simple and iterate 14:38:44 NOt really thought about it. How do you see it working? 14:38:59 minimal dependencies, python or bash 14:39:18 allow specification of kayobe version via requirements.txt 14:39:43 not sure whether we should add a default kayobe dependency in there 14:39:56 could be nice - just pip install your kayobe-config 14:40:26 seems like quite a nice way to do it 14:40:33 do we really need a script then? 14:40:47 I think we should do that, as it would also indicate which minimal kayobe version is required for the available features in -config. 14:41:15 But is it so complex that a script is required? 14:41:31 well lets try without and find out 14:42:14 users have complained about the multiple steps required to create an environment and keep it in sync 14:42:30 Would you use something like `package>=5.0.0,<6.0.0` or specify an exact version? 14:42:32 I was thinking a script could do it in one command 14:42:48 jovial[m]: upstream we'd use a range like that 14:44:30 lets iterate on it - it will hopefully be obvious if it needs to be scripted 14:44:48 and we can always script later, harder to remove 14:45:13 jovial[m]: think you'll have time to look at that in the next week or two? 14:45:33 I'll give it a shot 14:45:57 I'll update the ticket 14:45:59 could we make kayobe pick up the config path from the pip install of the config? 14:46:15 it'll need to be easy to use a downstream fork of kayobe in requirements.txt 14:46:40 you can put a git url in requirements.txt 14:46:50 yeah, -e git+https:// 14:48:15 any more on this? 14:48:48 #topic Open Discussion 14:48:59 Anyone have anything? 14:50:36 ok, everyone back to your l33t hacking 14:50:40 thanks for attending 14:50:50 #endmeeting