17:02:33 <dustymabe> #startmeeting fedora_atomic_wg
17:02:33 <zodbot> Meeting started Wed Oct 18 17:02:33 2017 UTC.  The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:33 <zodbot> The meeting name has been set to 'fedora_atomic_wg'
17:02:35 <dustymabe> #topic roll call
17:02:39 <dustymabe> .hello dustymabe
17:02:40 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dustymabe@redhat.com>
17:02:41 <jbrooks> .hello jasonbrooks
17:02:42 <ashcrow> .hello smilner
17:02:43 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <JBROOKS@REDHAT.COM>
17:02:45 <zodbot> ashcrow: smilner 'None' <smilner@redhat.com>
17:02:51 <maxamillion> .hello maxamillion
17:02:51 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
17:02:58 * maxamillion jumped the gun :)
17:04:01 <jberkus> .hello jberkus
17:04:02 <zodbot> jberkus: jberkus 'Josh Berkus' <josh@agliodbs.com>
17:04:13 <kushal> .hellomynameis kushal
17:04:14 <zodbot> kushal: kushal 'Kushal Das' <mail@kushaldas.in>
17:05:54 <dustymabe> #topic previous meeting action items
17:06:07 <dustymabe> jberkus i'm going to start with yours
17:06:12 <dustymabe> * jberkus to follow-up on adding/removing Atomic WG members via
17:06:14 <dustymabe> atomic-devel
17:06:15 <jberkus> ok
17:06:16 <dustymabe> * jberkus to identify and create issue with list of blog posts we want
17:06:18 <dustymabe> for f27 release
17:06:20 <dustymabe> * jberkus to follow up on images from Flock container workshop
17:06:22 <dustymabe> * jberkus to follow up on docs from Flock workshop
17:06:24 <dustymabe> * jberkus to raise kube installation issues with openshift installer
17:06:26 <dustymabe> team
17:06:50 <ttomecek> .hello ttomecek
17:06:51 <zodbot> ttomecek: ttomecek 'Tomas Tomecek' <ttomecek@redhat.com>
17:07:02 <dustymabe> davdunc: around?
17:07:08 <jberkus> atomic WG members: we did add/remove a few, I need to put out a general call, though
17:07:22 <jberkus> list of blog posts .... that will be under meeting issues, later
17:07:30 <jberkus> those issues are all filed and I tagged them #meeting
17:08:05 <jberkus> docs/containers still in progress.  docs is blocked on building infra, currently in progress
17:08:16 <jberkus> I haven't heard back from installer folks yet
17:08:33 <dustymabe> jberkus: what do we need to re-action?
17:08:47 <jberkus> containers, docs, installer
17:09:23 <dustymabe> #action jberkus to follow up on images from Flock container workshop
17:09:27 <maxamillion> jberkus: is there anything in the realm of nagging the openshift installer folks I can help with or are you just waiting on an email/
17:09:35 <dustymabe> #action jberkus to follow up on docs from Flock workshop
17:09:45 <dustymabe> #action jberkus to raise kube installation issues with openshift installer team
17:09:52 <jberkus> maxamillion: waiting on an email.  if you're in a meeting with the right folks, then you can ask in person
17:10:15 <jberkus> maxamillion: really we're trying to figure out which of our various kube installer options is the most likely to converge with their efforts
17:10:46 <dustymabe> ok other action items
17:11:10 <dustymabe> * dustymabe to update the rolling release plan with info about f27ah
17:11:12 <dustymabe> * dustymabe to update the ticket regarding rawhide atomic-ci stream
17:11:16 <dustymabe> i need to reaction one of them
17:11:21 <dustymabe> #action dustymabe to update the rolling release plan with info about f27ah
17:11:28 <maxamillion> jberkus: rgr
17:11:52 <dustymabe> I did update the atomic CI ticket for dennis gilmore
17:11:54 <dustymabe> https://pagure.io/atomic-wg/issue/349#comment-472028
17:12:07 <dustymabe> i'll follow up with him and close it
17:12:13 <dustymabe> ok other action items:
17:12:16 <maxamillion> jberkus: if I can, I'd like to be roped into that discussion ... my focus when I join the Ansible Team officially will be the intersection of ansible and k8s/openshift in various capacities so I have a long-term vested interest in that
17:12:25 <dustymabe> * davdunc to blog AWS MP availability of FAH/Cloud.
17:12:31 <dustymabe> * strigazi to do some testing around upgrades from f26 to f27 with
17:12:32 <jberkus> maxamillion: I'll send a new email
17:12:32 <dustymabe> kubernetes
17:12:37 <maxamillion> jberkus: thank you
17:12:38 <dustymabe> * jbrooks to email fedora-devel with issue of needed deps for
17:12:40 <dustymabe> asciibinder container
17:13:19 <jbrooks> dang, I haven't done that yet -- I'll send a message after the meeting
17:13:32 <dustymabe> #action jbrooks to email fedora-devel with issue of needed deps for asciibinder container
17:13:42 <dustymabe> is strigazi or davdunc around?
17:13:44 <jbrooks> The question there is basically, hey, does anyone care if we just use gems in the atomic doc pipeline vs rpms?
17:14:01 <dustymabe> #chair maxamillion jbrooks ashcrow jberkus kushal ttomecek
17:14:01 <zodbot> Current chairs: ashcrow dustymabe jberkus jbrooks kushal maxamillion ttomecek
17:14:21 <dustymabe> jbrooks: yeah I think the broader question to fedora devel is:
17:14:50 <dustymabe> "hey i want to package this thing but there a bunch of deps that are missing and I don't want to be a maintainer for them all, what do you do in a situation like this"?
17:15:34 <jbrooks> All right, and, does it really matter is asciibinder is packaged?
17:15:37 <walters> the current answer is "spend a lot of time writing a tool like gofed to automate all of the steps we've designed to be manual by default"
17:15:39 <jberkus> for reference, the current "official" asciibinder container, maintained by the openshift docs team, uses gems
17:15:42 <jberkus> on CentOS
17:15:42 <jbrooks> I mean, I personally don't care
17:15:59 <walters> rather than e.g. driving autogenerating specs into the default pipeline
17:16:30 <jberkus> walters: if that's the answer, then our answer will be to use the CentOS-based container
17:17:07 <dustymabe> what's funny is i think the copr guys have automated building rpms from gems
17:17:14 <jberkus> but we should get that answer officially
17:17:31 <dustymabe> anywho, the discussion on fedora devel certainly won't hurt
17:17:34 <walters> dustymabe, not just copr, there's a *vast* set of these tools
17:17:38 <dustymabe> many people feel this pain
17:17:54 <jbrooks> I was able to build the deps easily in coprs
17:17:58 <jberkus> we can't use copr?
17:18:06 <jbrooks> But officially maintaining them is a whole other thing
17:18:30 <dustymabe> jberkus: sure we can use whatever we want. but this is a general problem that blocks software from getting into fedora
17:18:34 <jbrooks> But if no rpms, gems alone works... I don't see the value of rpms there
17:18:38 <dustymabe> it's worth a discussion
17:18:50 <dustymabe> re-actioning other items now
17:18:52 <jbrooks> OK, agreed
17:18:58 <dustymabe> #action strigazi to do some testing around upgrades from f26 to f27 with kubernetes
17:19:06 <dustymabe> #action davdunc to blog AWS MP availability of FAH/Cloud.
17:19:35 <dustymabe> #topic re-evaluate atomic working group meeting time
17:19:41 <dustymabe> #link https://pagure.io/atomic-wg/issue/346
17:19:53 <dustymabe> so we have some times that have most people able to be there
17:20:15 <dustymabe> i'm thinking maybe create a new doodle with just a few options and have people vote on that one
17:20:29 <dustymabe> i.e. narrow it down to 4 options and then we can go from there
17:20:34 <dustymabe> objections?
17:20:43 <ttomecek> do you also want to prioritize?
17:20:55 <dustymabe> in what way?
17:20:58 <jbrooks> Do we not have a leader from the existing doodle?
17:20:59 <ttomecek> e.g. the time should probably fit the WG members
17:21:09 <dustymabe> ahh i see
17:21:19 <dustymabe> so care more about the votes from actual members of the WG
17:21:59 <dustymabe> i was considering most people eqal at this point
17:22:13 <jberkus> I'm not seeing any consensus in that doodle
17:22:31 <dustymabe> jberkus: there are a few times that have 'all but three people'
17:22:40 <jberkus> ok
17:22:58 <dustymabe> and we don't really know if the "no" is a "I absolutely can't make it" or a "I can make it, but I'd prefer not"
17:23:09 <jberkus> dustymabe: yah, that's a limitation of doodle
17:23:23 <jbrooks> We can say, these are the top three times, vote
17:23:27 <dustymabe> I figure the next doodle i make we can ask people to weigh that
17:23:31 <dustymabe> jbrooks: right
17:23:36 <dustymabe> ok that's enough on that topic
17:23:44 <jbrooks> Doing another doodle seems to risk losing some people who just don't fill it out again
17:23:57 <dustymabe> #action dustymabe to make new doodle with top 3 or 4 possible times and have people re-vote
17:24:34 <dustymabe> jbrooks: same issue if you ask them to vote on it any other way
17:24:46 <dustymabe> #topic The Future of AutoCloud
17:24:52 <dustymabe> #link https://pagure.io/atomic-wg/issue/361
17:25:55 <dustymabe> so..
17:26:17 <dustymabe> autocloud is in a bit of a questionable state
17:26:34 <dustymabe> luckily it has been running fine lately, and I guess sayan is maintaining it
17:26:50 <dustymabe> with roshi gone I'm not too confident about it moving to taskotron
17:27:18 <dustymabe> s/roshi gone/roshi not as involved in Fedora/
17:27:54 <dustymabe> My thoughts are that the Fedora CI objective is where autocloud like tests should live in the future
17:28:09 <maxamillion> agreed
17:28:10 <dustymabe> there is a gap there, which is autocloud was being refitted to be able to test AWS instances
17:28:12 <davdunc> .hello davdunc
17:28:13 <zodbot> davdunc: davdunc 'David Duncan' <davdunc@amazon.com>
17:28:25 <ashcrow> that makes sense
17:28:27 <maxamillion> I think the CI effort is supposed to supercede the efforts of AutoCloud
17:28:29 <dustymabe> so we could ask the Fedora CI effort about that
17:28:37 <davdunc> Ack dustymabe
17:28:59 <dustymabe> davdunc: i re-actioned. if you have an update we'll get it from you in open floor :)
17:29:27 <dustymabe> kushal: sayan: do you have any input about AutoCloud and the Fedora CI efforts?
17:29:57 <maxamillion> I think with all the upstream-first test stuff that's going on, it just makes sense to join that effort
17:30:03 <tflink> dustymabe: which autocloud tests?
17:30:09 <maxamillion> https://upstreamfirst.fedorainfracloud.org/
17:30:20 <dustymabe> tflink: all of them??
17:30:31 <dustymabe> https://apps.fedoraproject.org/autocloud/compose
17:30:35 <tflink> IIRC, roshi migrated most of the tests a while back but there's a remaining snag that hasn't been figured out yet
17:31:04 <tflink> ie, the fedmsg is emitted before the images are actually available and the tests fail because they can't find an image
17:31:22 <dwalsh> jberkus, Present
17:31:48 <jberkus> yay
17:31:51 <dustymabe> dwalsh: welcome. we'll get to the issue in just a moment
17:32:32 <dustymabe> tflink: ok. the question is, does having autcloud around at all any more help us *after* the Fedora CI pipeline is set up ?
17:32:44 <tflink> coudn't tell you
17:32:55 <dustymabe> tflink: ok
17:33:05 <dustymabe> i think that is the question maxamillion is asking in the ticket
17:33:20 <dustymabe> maxamillion: i think we know the answer to that?
17:33:22 <maxamillion> tflink: which fedmsg?
17:33:41 <tflink> I don't recall off the top of my head
17:33:58 <maxamillion> dustymabe: do we? can Fedora CI run the AutoCloud tests? do we need to migrate them? what's that scope of work?
17:34:34 <dustymabe> maxamillion: i think the Fedora CI should be able to run the equivalent (or better) of the autocloud tests
17:34:47 <dustymabe> we will need to make sure that we have feature parity between the two
17:35:04 <dustymabe> but that should answer the question of "what is the future of Autocloud"
17:35:27 <dustymabe> unless I am missing anything
17:35:47 <tflink> it's one of the fedmsgs which indicates that the images are done, I'll look for the exact fedmsg. it's been a while since I was looking into this
17:35:51 <maxamillion> dustymabe: agreed, I just want to make sure this isn't hand-waived over and then it falls off the map without anyone doing the work
17:36:11 <dustymabe> well until the work is done, we still have autocloud running
17:36:34 <maxamillion> correct, but the tests still aren't authoritative which is unfortunate
17:37:22 <tflink> org.fedoraproject.prod.pungi.compose.status.change is the fedmsg that we listen for
17:37:27 <dustymabe> sure
17:37:35 <dustymabe> maxamillion: do you want to update the ticket, or do you want me to?
17:38:07 <gholms> Sorry I'm late.  Double-booking is the worst.
17:38:19 <dustymabe> #chair dwalsh gholms
17:38:19 <zodbot> Current chairs: ashcrow dustymabe dwalsh gholms jberkus jbrooks kushal maxamillion ttomecek
17:38:24 <maxamillion> dustymabe: do we have a conclusion to add to the ticket as an update?
17:40:15 <dustymabe> #info While autocloud has served us well in the past we don't have anyone working on new features for it and if it were to need serious maintainence we'd probably have trouble managing it. The Fedora CI pipeline (from the Fedora CI objective) should provide feature parity with Autocloud in the future and we should leverage that pipeline as soon as it does. This can eventually become our
17:40:16 <dustymabe> authoritative source of test results
17:40:39 <dustymabe> objections?
17:41:19 <maxamillion> +1
17:41:27 <dustymabe> tflink: kushal ?
17:41:43 <dustymabe> sayan? thoughts/concerns?
17:42:43 <dustymabe> moving to next topic in 20
17:42:58 <tflink> that sounds like the plan, yes
17:43:09 <dustymabe> #topic Decide strategy for including container runtimes in Atomic Host
17:43:11 <dwalsh> dustymabe, Where are the topics
17:43:15 <dustymabe> #link https://pagure.io/atomic-wg/issue/360
17:43:22 <dustymabe> dwalsh: this one
17:43:42 <dustymabe> I don't expect we'll fully decide on a strategy today, but it's worth a discussion
17:44:18 <dustymabe> dwalsh: walters jberkus jbrooks - weigh in :)
17:44:38 <jbrooks> I'm +1 to runtimes via system container
17:44:46 <jbrooks> Perhaps pre-pulled, for convenience
17:44:56 <jberkus> the question is, do we want to include container runtimes (other than runc) in the base image, or pull them by system cotnainer
17:44:58 <maxamillion> dustymabe: thanks
17:45:02 <jberkus> the pros and cons are outlined in that issue
17:45:08 <dwalsh> Ok, when talking to potential users of Atomic Host, the topic of minimization always comes up.  People want less on Atomic Host.  Currently I believe we ship docker/etcd/flanneld and perhaps kubernetes?
17:45:12 <jberkus> that feeds directly into "include CRI-O in atomic host"
17:45:22 <jberkus> dwalsh: we removed kubernetes recently
17:45:28 <jbrooks> Yes, but in 27 etcd flannel and kube are going
17:45:52 <dwalsh> I would only ship atomic and runc on the base image.
17:46:31 <dwalsh> I think atomic should be Container Runtime agnostic.  There is a potential issue around not having the docker CLI, which could be problematic.
17:46:32 <jbrooks> One issue is that we need to be really confident about FLIBS
17:46:45 <jbrooks> The releases have to be very predictable
17:47:01 <ashcrow> dwalsh: with docker and cri-o being provided via system containers if/when needed?
17:47:07 <dwalsh> yes
17:47:24 <ashcrow> jbrooks: can you explain a bit more about that point?
17:47:25 <jberkus> dwalsh: we install other clis with system containers
17:47:44 <walters> the upstream cri-o CI jobs seem to install directly on the host
17:47:49 <dwalsh> The problem we have now is not just docker, but you also need etcd and flannel, or some kind of VPN tool to setup networks installed and running before the container runtime.
17:47:50 <walters> https://github.com/kubernetes-incubator/cri-o/blob/master/.travis.yml#L13
17:48:00 <jbrooks> ashcrow, The FLIBS is very manual at this point, and maxamillion is the point person for it, and he's moving depts
17:48:27 <maxamillion> I'm currently transitioning that to someone in Fedora RelEng, we'll have a new point person in the coming weeks
17:48:29 <jbrooks> If containers are the way we deliver core parts of the atomic host, we need that delivery to be solid
17:48:53 <ashcrow> jbrooks / maxamillion: OK I follow now, thanks!
17:48:53 <jbrooks> It's just something we must consider, because we'll be leaning harder on it
17:48:56 <maxamillion> jbrooks: agreed
17:48:58 <dwalsh> jberkus, Ok, if you can install the docker CLI from the docker runtime onto some place like /usr/local/bin/docker,  And similarly /usr/local/bin/kpod from crio
17:49:13 <jbrooks> dwalsh, That should totally work
17:49:55 <dwalsh> Allowing system containers makes it less opinionated and more flexible going forward.
17:50:10 <maxamillion> +1
17:50:15 <dustymabe> ok, i have some concerns
17:50:25 <dustymabe> - first off, I feel like system containers are a bit of an "advanced user" feature
17:50:30 <ashcrow> walters: Are you noting that our CI jobs are not testing cri-o the way we'd be using it in Atomic?
17:50:38 <dwalsh> Someone might want to install a complete stack based on Origin that brings in etcd, openshift-vpn, CRI-O and origin as system containers.
17:50:39 <walters> ashcrow, AFAICS, yes
17:50:51 <dustymabe> if someone wants to spin up atomic host and run an apache container
17:51:01 <dustymabe> i don't think they should have to find a docker system container first
17:51:17 <dwalsh> dustymabe, Couldn't this be handled via playbooks?
17:51:22 <jberkus> dustymabe: why not?  if someone wants to do this on Fedora Workstation, they have to install docker first.
17:51:24 <dustymabe> i also don't think we have the story of 'updating system containers' very polished
17:51:40 <ashcrow> dustymabe: how different is that from someone having to install docker via yum on Fedora?
17:51:41 <walters> does anyone know where the cri-o jenkins job definitions live?
17:51:46 <jbrooks> It's actually pretty smooth, just not well documented
17:51:57 <dustymabe> ashcrow: it's different because you aren't using "yum" to install it
17:51:57 <walters> (for obvious reasons this is really hard to google)
17:52:01 <dustymabe> which is what people are used to
17:52:01 <ashcrow> :-)
17:52:30 <dustymabe> they have to search for 'how do i install docker on atomic host' which is an OS designed to run containers
17:52:31 <dwalsh> walters, Aren't they in the github?
17:53:03 <dwalsh> dustymabe, atomic install docker versus dnf install docker.
17:53:24 <jberkus> dustymabe: that sounds like a "getting started docs" problem, not a technical problem
17:53:28 <dustymabe> dwalsh: and for upgrades?
17:53:34 <dwalsh> atomic upgrade docker
17:53:38 <walters> dwalsh, where?
17:53:41 <dustymabe> now they are decoupled, good for power users, bad for beginners
17:54:13 <dustymabe> if we do choose system container as the route. I'll vote for baking a system container into the media we ship
17:54:14 <dwalsh> walters, Where is the github? https://github.com/kubernetes-incubator/cri-o
17:54:45 <dustymabe> but then we'll essentially make our media quite a lot bigger
17:54:50 <walters> dwalsh, where are the jenkins jobs that power https://github.com/kubernetes-incubator/cri-o/pull/1029#issuecomment-337663158
17:54:53 <dustymabe> so there are no easy answers here
17:55:11 <jberkus> dustymabe: I'm not buying the idea that adding "atomic install docker" as a *single step* is significantly harder for new users
17:55:33 <ashcrow> It's not harder, but it's not what people are used to doing
17:55:38 <ashcrow> I think that's more dustymabe's point
17:55:40 <walters> ah found them
17:55:52 <jbrooks> To the extent that people are used to running atomic
17:55:56 <jberkus> ashcrow: they're used to doing it on every other OS
17:55:58 <dustymabe> ashcrow: it also cannot tied to any other update mechanism
17:56:05 <jbrooks> It's status quo for regular fedora or centos or ubuntu, etc
17:56:11 <walters> dwalsh, yep, looks like these tests aren't running on AH: https://github.com/kubernetes-incubator/cri-o/blob/master/contrib/test/integration/system.yml#L3
17:56:22 <dwalsh> Yes under contrib/test
17:57:10 <jberkus> now, upgrade issues are potentially a significant problem, in that we lose some of the atomicity.
17:57:22 <dwalsh> walters, Yes we are just getting to the point of packaging in an RPM, next step is to try to test the build artifacts.
17:57:44 <jberkus> an "rpm-ostree rollback" won't roll back an "atomic docker upgrade"
17:57:58 <dwalsh> Right those are independent.
17:58:02 <jberkus> but that is balanced against breaking our deadlock around docker versions
17:58:08 <dwalsh> But I think you can roll back a system container.
17:58:08 <walters> jberkus, *that* is a whole big thing...
17:58:10 <jberkus> which is a significant problem right now
17:58:16 <dustymabe> here's the thing though
17:58:34 <dustymabe> i don't see why we can't bake in docker, but allow people who want independence to run a system container
17:58:43 <ashcrow> Yes, you can roll back a system container ... atomic containers rollback $NAME
17:58:53 <dustymabe> flexibility + batteries included
17:59:06 <jbrooks> We should bake in crio if we're baking in docker
17:59:07 <jberkus> dustymabe: because baked-in docker as we have it now is broken for users
17:59:13 <dustymabe> why?
17:59:19 <dustymabe> why is that broken for users?
17:59:39 <jberkus> dustymabe: because you need different versions depending on what you want to put on top of it, and we provide no way to do that
17:59:48 <dustymabe> jberkus: system containers
17:59:58 <ashcrow> It's not so much broken as that some systems pin to docker versions and the version that comes with AH may or may not be what they want. System Containers gets round it either way.
17:59:59 <dustymabe> we did that with kube in fedora 26
18:00:01 <dwalsh> dustymabe, Maybe do it in stages, where you ship docker system container preinstalled.
18:00:23 <ashcrow> dwalsh: +1
18:00:33 <dustymabe> jberkus: so we have baked in docker (which is what we test with) and then if someone wants something else we have system containerized docker for other versions
18:00:33 <jbrooks> Docker preinstalled is not the norm
18:00:38 <jbrooks> Let's not forget that
18:00:43 <jbrooks> Ppl expect to install docker
18:00:58 <dustymabe> unless it's an operating system for running containerized workloads
18:01:06 <dustymabe> i know people who only use atomic because it's already installed
18:01:16 <dwalsh> The real solution is to have dnf understand (system) containers.
18:01:20 <dustymabe> just had this conversation with vbatts today
18:01:35 <jberkus> dustymabe: wait, so you're suggesting that we have one version of docker baked in, and tell the user to install a 2nd version if they need somethign different?  With the understanding that 70% of users *will* need something different?  That doesn't seem user-friendly to me.
18:01:37 <dwalsh> Having dnf install docker on an atomic host, prefer a docker system container.
18:01:37 <dustymabe> dwalsh: yes, something like that would give us a better story
18:01:51 <jberkus> dustymabe: what are those people using docker for?
18:02:01 <dwalsh> Has anyone looked into a plugin for dnf to handle this?
18:02:24 <dustymabe> oh man - looks like we have run off the rails a bit
18:02:25 <dwalsh> dnf install docker hits the plugin which ends up doing a atomic install docker, and now dnf would list the package.
18:02:30 <dustymabe> we're over time
18:02:35 <jberkus> oh, yeah, we're over schedule
18:02:53 <dustymabe> i really want to pick up this discussion again
18:03:03 <dustymabe> should we schedule a one off meeting or something?
18:03:05 <ashcrow> dwalsh: https://github.com/ashcrow/dnf-plugin-container <-- the closest I've seen is what I wrote the other day but it's not the same thing
18:03:05 <jberkus> well, let's continue it on #atomic
18:03:07 <walters> we could take this to the mailing list?
18:03:26 <ashcrow> yeah, mailing list or the issue
18:03:28 <dustymabe> ok there were other meeting tickets
18:03:31 <dustymabe> anything urgent?
18:03:34 <dustymabe> #topic open floor
18:04:36 <dustymabe> anyone with anything urgent for open floor
18:04:42 <dustymabe> will close meeting in 2 minutes if not
18:05:50 <dustymabe> #endmeeting