14:01:02 <apuimedo> #startmeeting kuryr
14:01:03 <openstack> Meeting started Mon Apr 24 14:01:02 2017 UTC and is due to finish in 60 minutes.  The chair is apuimedo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:06 <openstack> The meeting name has been set to 'kuryr'
14:01:37 <apuimedo> Welcome everybody to the weekly kuryr IRC meeting
14:01:41 <apuimedo> Who's here today?
14:01:41 <garyloug> o/
14:01:50 <mchiappero> o/
14:01:50 <dmellado> o/ Hi folks!
14:01:51 <ivc> o/
14:01:54 <limao> o/
14:02:15 <ltomasbo> o/
14:02:40 <apuimedo> oops
14:02:49 <alraddarla_> o/
14:02:50 <apuimedo> I just wanted to say hi limao
14:02:54 <kzaitsev_ws> o/
14:03:01 <dmellado> apuimedo: you were late
14:03:09 <hongbin> o/
14:03:27 <apuimedo> :-)
14:03:33 <apuimedo> let's get the party started
14:03:39 <apuimedo> #topic kuryr-libnetwork
14:04:49 <apuimedo> #info Last week we got some devstack fixes for when both kuryr-libnetwork and fuxi are selected
14:04:52 <apuimedo> thanks hongbin
14:05:06 <apuimedo> we are still pending the managed mode v2
14:05:08 <apuimedo> from limao
14:05:18 <apuimedo> mostly because I didn't get around to test it yet
14:05:47 <apuimedo> limao: how hard would it be (I know that we'd need to push to dockerhub) to have an option in devstack to run it in v2 mode?
14:06:41 <dmellado> are there major config options differences between the current mode and v2?
14:06:45 <apuimedo> kzaitsev_ws: I saw you performed some necromancy and resurrected https://review.openstack.org/#/c/374315/
14:06:57 <limao> apuimedo: Do you mean in the devstack build plugin v2 and push into docker, then download it and run test with it?
14:07:04 <kzaitsev_ws> ah sorry =)
14:07:27 <kzaitsev_ws> I just use a gerrit-dashboard, that list me patches I haven't reviewed
14:07:37 <kzaitsev_ws> so yeah, sometimes this happens )
14:07:37 <apuimedo> kzaitsev_ws: no, that's fine
14:07:37 <limao> dmellado: for kuryr.conf itself, they are almost same.
14:07:58 <apuimedo> kzaitsev_ws: I wanted to ask if you think you can take it over to target the pike goal of uwsgi compliance
14:08:08 <dmellado> kzaitsev_ws: gertty? :D
14:08:15 <dmellado> limao: thanks for the clarification ;)
14:08:44 <apuimedo> limao: Is there the possibility of just building it and then have docker run the container locally?
14:08:49 <kzaitsev_ws> yeah, that shouldn't be hard and I should have enough time to get it done =)
14:09:05 <apuimedo> thanks kzaitsev_ws
14:09:14 <limao> dmellado: I tested pluginv2 works well for me if you run in scope local, when it  run in swarm mode, it still have some problem.
14:09:19 <limao> apuimedo: Yes
14:09:22 <apuimedo> #action kzaitsev_ws to take over https://review.openstack.org/#/c/374315/ to target uwsgi compliance
14:09:31 <apuimedo> kzaitsev_ws: remember to add a reno note when you fix it
14:09:41 <kzaitsev_ws> sure =)
14:09:52 <apuimedo> limao: so then we can have it in devstack without pushing to dockerhub
14:09:59 <apuimedo> I think it would be a great addition to the patch
14:10:05 <limao> apuimedo : https://review.openstack.org/#/c/451479/5/README.rst
14:10:09 <apuimedo> (and would make it easier for reviewers to reproduce)
14:10:10 <dmellado> limao: got it, +1 to apuimedo question
14:10:23 <dmellado> but I guess it'll be easier if I just get there and review the patch
14:10:38 <dmellado> which is on my TODO xD
14:11:21 <apuimedo> limao: is it able to do the plugin install from the local container if you do the docker build -t kuryr/libnetworkv2 ?
14:11:23 <limao> apuimedo: let me update the patch, I seperate the doc in https://review.openstack.org/#/c/451479/5
14:11:38 <apuimedo> and then you do docker plugin install kuryr/libnetworkv2
14:11:40 <apuimedo> ?
14:11:41 <limao> apuimedo: Yes , it can
14:11:43 <apuimedo> cool
14:12:07 <apuimedo> limao: do you agree to change it to that and putting it in devstack for this patch, or you prefer a follow-up patch?
14:12:32 <irenab> apuimedo: better to have it easily testable as it merges
14:12:37 <apuimedo> agreed
14:12:48 <limao> apuimedo: irenab: let me update it in this patch
14:12:52 <apuimedo> perfect
14:12:56 <apuimedo> thanks a lot limao!
14:13:08 <apuimedo> limao: btw, the name in dockerhub will be kuryr/libnetworkv2
14:13:19 <apuimedo> so change it to that
14:13:29 <limao> apuimedo: Sure
14:14:04 <apuimedo> #action limao to update the libnetwork v2 patch to enable it on devstack
14:14:07 <apuimedo> perfect!
14:14:12 <apuimedo> anything else on kuryr-libnetwork?
14:14:17 <limao> apuimedo: did you get any chance to ask kolla member how to upload to dockerhub?
14:14:34 <apuimedo> limao: nope
14:14:39 <apuimedo> I'll repeat the action
14:14:52 <apuimedo> and open the kolla irc channel so I make sure to remember
14:15:05 <apuimedo> #action apuimedo to ask inc0 about pushing the images to dockerhub
14:15:09 <limao> apuimedo: so in devstack patch do you mind I build pluginv2 locally and install it locally?
14:15:14 <dmellado> apuimedo: limao I've a friend who's kolla-core, I'll ping him
14:15:15 <apuimedo> limao: right
14:15:32 <limao> apuimedo: get it, thanks dmellado!
14:16:43 <apuimedo> done
14:16:49 <apuimedo> I just sent the question
14:16:54 <apuimedo> #topic fuxi
14:16:58 <hongbin> hi
14:17:00 <apuimedo> #chair hongbin
14:17:01 <openstack> Current chairs: apuimedo hongbin
14:17:02 <apuimedo> Hi hongbin
14:17:10 <apuimedo> I +2ed the spec
14:17:15 <hongbin> thx
14:17:29 <hongbin> for others, would appreciate your reviews on this spec: https://review.openstack.org/#/c/452554/10
14:17:33 <irenab> hongbin: I will review as well
14:17:37 <apuimedo> I find the fact that the first stage will be having a fuxi rest server on master and worker nodes good
14:17:39 <hongbin> apuimedo: i will address your comment in the next PS
14:17:47 <dmellado> hongbin: I'll review that too, hopefully I'll be able to allocate some time
14:17:54 <apuimedo> hongbin: but yes, please make an image to reflect that
14:18:03 <hongbin> apuimedo: sure
14:18:07 <apuimedo> hongbin: also, I suggest to have the rest server bind to only localhost
14:18:25 <hongbin> apuimedo: ok, i can specify this part
14:18:26 <apuimedo> since there is no auth between the k8s fuxi components and the rest server
14:18:30 <apuimedo> thanks hongbin!
14:18:43 <hongbin> yes, that is fro the spec
14:18:52 <hongbin> in addition, there are several patches on the fuxi side
14:19:00 <hongbin> #link https://review.openstack.org/#/c/457694/
14:19:07 <hongbin> #link https://review.openstack.org/#/c/457363/
14:19:18 <hongbin> these two patches need reviews as well :)
14:19:26 <hongbin> apuimedo: that is all from my side
14:20:03 <apuimedo> #action apuimedo to review the above links
14:20:09 <apuimedo> thanks hongbin
14:20:16 <apuimedo> #topic kuryr-kubernetes
14:20:43 <apuimedo> #info last week we held a videoconf meeting about an actor refactor proposal
14:21:08 <apuimedo> #info The meeting touched mostly on "flavors/profiles", leaving the actor part for a later time
14:21:19 <dmellado> apuimedo: irenab regarding that I was thinking that maybe we can have a follow-up on that so we can include people who couldn't attend
14:21:22 <apuimedo> #action apuimedo to upload the darned video once and for all
14:21:29 <dmellado> + including fullstack testing discussion
14:21:37 <apuimedo> dmellado: I have to upload the video so they can have more context
14:21:38 <apuimedo> :/
14:21:54 <irenab> apuimedo: any decision?
14:22:11 <ivc> apuimedo are you still transcoding? :)
14:22:29 <ltomasbo> apuimedo, good idea, as I would like to re-check ivc explanations
14:22:34 <apuimedo> ivc: in some way
14:22:36 <apuimedo> :/
14:22:40 <irenab> apuimedo: in addition to recording, please provde a short summary of the main raised points
14:22:46 <apuimedo> irenab: no decision taken. Mostly it was agreeing that we want to do flavors
14:22:53 <apuimedo> or profiles
14:22:55 <apuimedo> or mediums
14:23:04 <apuimedo> (all three names refer to the same)
14:23:10 <ivc> irenab its covered in the first minute of the video
14:23:19 <irenab> can you elaborate more?
14:23:25 <apuimedo> so that we take drivers and handlers, group them into supportable configs
14:23:43 <ivc> apuimedo medium was a stub, pls stop using it :)
14:23:50 <apuimedo> ivc: :-)
14:23:59 <apuimedo> ivc: next time call it mediumstub
14:24:01 <apuimedo> :-)
14:24:05 <dmellado> lol
14:24:27 <ivc> apuimedo it was to highlight the role and to provide context and then give it a name
14:24:30 <irenab> so next step is another discussion or spec/devref?
14:24:42 <ivc> apuimedo it sounded smart on paper, turns out it wasnt :)
14:24:49 <apuimedo> #link https://bluejeans.com/s/9X1Z2/
14:25:02 <apuimedo> this is the pre-edited recording
14:25:09 <apuimedo> I'll post a shorter nicer version later
14:25:54 <apuimedo> irenab: well, maybe spec, maybe a bit of discussion after you and others see the video
14:26:02 <apuimedo> and give feedback on ml/irc
14:26:37 <irenab> apuimedo: I think better to have follow-up meeting, written comments may be misunderstood
14:26:53 <apuimedo> irenab: sounds good to me
14:26:58 <apuimedo> let me know when you watch it
14:27:14 <irenab> great, thanks
14:27:25 <apuimedo> #info kuryr-kubernetes had its first release last week. It finally enables services!
14:27:40 <apuimedo> now we can do some changes we were holding off
14:28:01 <apuimedo> although the ovsdbapp change I'll still hold off until otherwiseguy packages ovsdbapp
14:28:17 <apuimedo> at least rdo and ubuntu
14:29:10 <apuimedo> dmellado: your patch failed https://review.openstack.org/#/c/459292/
14:29:11 <apuimedo> :-)
14:29:30 <dmellado> apuimedo: saw it, weird, I'll ask you something after the meeting
14:29:39 <apuimedo> irenab: I see some flakiness on the dragonflow job lately
14:29:43 <dmellado> take a look at http://logs.openstack.org/92/459292/3/check/gate-install-dsvm-default-kuryr-kubernetes/6a1af9c/logs/devstacklog.txt.gz
14:29:52 <apuimedo> irenab: are you aware of what could cause it?
14:29:53 <irenab> apuimedo: same in the ovs job as well
14:30:40 <irenab> it seems to be not related to the neutron at all
14:30:42 <apuimedo> dmellado: seems like a race with the docker socket perms
14:30:54 <apuimedo> maybe also what plagues the df and ovs tasks
14:30:56 <apuimedo> bleh
14:31:13 <dmellado> apuimedo: I'll recheck for now, will follow up with you after seeing what happens
14:32:22 <irenab> Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.28/images/create?fromImage=quay.io%2Fcoreos%2Fetcd&tag=v3.0.8: dial unix /var/run/docker.sock: connect: permission denied
14:33:00 <apuimedo> dmellado: thanks!
14:33:17 <apuimedo> evil perms
14:33:55 <apuimedo> ivc: https://review.openstack.org/#/c/458413/ has already addressed kzaitsev_ws's comments
14:34:16 <apuimedo> ltomasbo: I saw you updated your pool patchsets
14:34:24 <apuimedo> I'll try to take a look tomorrow
14:34:30 <ltomasbo> yes, I wanted to give it another push
14:34:38 <apuimedo> cool
14:34:50 <ltomasbo> as in the conf discussion we forecast the actor changes for next cycle
14:34:52 <irenab> ltomasbo: I will recheck, saw you adressed my comments
14:35:00 <ltomasbo> I address some
14:35:12 <ltomasbo> but would like to quickly discuss about one
14:35:13 <apuimedo> mchiappero: ivc: irenab: how did the discussion end up?
14:35:18 <apuimedo> I saw some back and forth
14:35:24 <mchiappero> apuimedo: still waiting
14:35:25 <ltomasbo> https://review.openstack.org/#/c/436875/5
14:35:37 <ltomasbo> apuimedo, ivc, irenab
14:35:43 <irenab> apuimedo: discussion regarding?
14:36:04 <ivc> apuimedo https://review.openstack.org/#/c/458413/ done
14:36:06 <ltomasbo> how should we proceed for now, until we decide on what ivc explained the other day
14:36:10 <apuimedo> irenab: I think mchiappero and ivc were going back and forth on stevedore related stuff
14:36:17 <mchiappero> in general I think the whole design of that part might be reconsidered, however I think it's best to find a reasonable compromise for the time being
14:36:28 <irenab> mchiappero: +1
14:36:49 <ltomasbo> this is what apuimedo also proposed, and ivc seems to be ok with it (for now, with a TODO/REVISIT)
14:37:03 <ltomasbo> do we agree on this (for now)?
14:37:09 <irenab> I thik the best would be to follow the current approach and then rework the all
14:37:12 <apuimedo> ltomasbo: on what?
14:37:16 <mchiappero> the main problem imho is that there are two competing mechanisms, the translator and the driver for pretty much the same purpose
14:37:33 <ivc> guys what are we discussing? ltomasbo patch or mchiappero patch?
14:37:41 <ivc> im confused
14:37:47 <irenab> lets keep on mchiappero for now
14:37:48 <apuimedo> ivc: mchiappero
14:37:50 <apuimedo> :-)
14:37:53 <ltomasbo> yep, we went from one to another too fast...
14:38:23 <apuimedo> ltomasbo: sorry, sometimes I lack filter
14:38:30 <ltomasbo> :D
14:38:47 <ltomasbo> I was referring all the time to the port pools (if that helps)
14:38:48 <ivc> in mchiappero patch i dont like how the same vif translator is used by 2 different drivers
14:39:14 <irenab> ivc: driver on Host or Controller?
14:39:16 <ivc> i don't like how the ovs translator (native/hybrid) turned out too, but at least it is for the same driver
14:39:21 <ivc> irenab controller
14:39:28 <apuimedo> ltomasbo: sorry about that
14:39:39 <mchiappero> ivc: the main problem is that some code expect the translation to be depending on the binding in neutron (which is one of the first approaches I tried)
14:39:52 <mchiappero> ivc: the current design is largely broken though
14:40:07 <ltomasbo> apuimedo, no problem!
14:40:09 <mchiappero> otherwise it would have been straightforward to add macvlan
14:40:23 <irenab> apuimedo: you keep on 2 conversations :-)
14:40:25 <mchiappero> and BTW it follows the same approach as vlan
14:40:30 <mchiappero> which has been accepted
14:40:59 <ivc> mchiappero you can do macvlan with no issues, i even gave you a 1.2.3. list of steps :)
14:41:13 <mchiappero> ivc: what is the purpose of the driver and what is the purpose of the translators, if you can answer this question we have a solution :)
14:41:35 <mchiappero> ivc: i don't need your list of steps
14:41:50 <ivc> mchiappero translator converts neutron port into os-vif
14:41:59 <mchiappero> i need you to see the problem and tell me what was the rationale behind it
14:42:09 <ivc> mchiappero driver performs low-level neutron stuff
14:42:18 <mchiappero> ivc: what is then the purpose of the vif drivers?
14:42:28 <mchiappero> they try to solve the same issue
14:42:37 <ivc> mchiappero handler is sort of orchestrator and is an adapter between k8s and vif driver
14:42:42 <mchiappero> some code uses the drivers, some other doesn't
14:42:44 <ivc> mchiappero they dont solve the same issue
14:42:54 <mchiappero> ok, elaborate :)
14:43:00 <irenab> translator transform one type of the object to another, driver performs operations. Correct?
14:43:06 <ivc> yes
14:43:13 <ivc> <3 irenab
14:43:15 <mchiappero> but they are the same thing
14:43:24 <ivc> they are not :)
14:43:34 <mchiappero> they do
14:43:36 <mchiappero> so
14:43:41 <apuimedo> irenab with the perfect def
14:43:41 <mchiappero> one approach I tried
14:43:59 <mchiappero> yes but there is one major point
14:44:09 <mchiappero> operations are bound to a specific oject
14:44:12 <mchiappero> object
14:44:26 <mchiappero> so you decide the operations by a config file setting
14:44:37 <mchiappero> but wait for the object type from neutron
14:44:47 <mchiappero> (which is not true BTW for nested ports)
14:44:58 <mchiappero> you have two hierachies for the same thing
14:45:02 <ivc> mchiappero generic and both nested cases are different
14:45:24 <mchiappero> yes, ideally you should be able to tell by the neutron port
14:45:28 <mchiappero> not the vif drivers
14:45:30 <ivc> mchiappero for nested translators do not seem necessary since you it is fixed
14:45:45 <mchiappero> which is btw an approach I tried and doesnt work because of permission issues
14:46:06 <ivc> mchiappero for the non-nested case the translator is driven by neutron and you don't know it beforehand - thats the reason why those 'translators' have seen the light
14:46:26 <mchiappero> what operations and conversions you need to do depend on what you get from neutron, ideally, not the driver
14:46:35 <apuimedo> May I suggest to take this to a short videoconf?
14:46:51 <irenab> apuimedo: good idea
14:47:08 <apuimedo> mchiappero: ivc: irenab: do you have time this week?
14:47:10 <mchiappero> ivc: no, the translator is not driven by neutron for the nested case
14:47:17 <mchiappero> indeed your steps change that!
14:47:40 <mchiappero> having that said, let's agree on something that works
14:47:43 <mchiappero> for the time being
14:47:46 <ivc> mchiappero thats what i said - translator is fixed for nested BUT driven by neutron for non-nested
14:48:08 <ivc> mchiappero and since you are focused on nested case, you prolly missing the non-nested case issues
14:48:21 <mchiappero> ivc: it shouldn't be that way, again, you have two hierarchies for the same related set of things
14:48:33 <mchiappero> not at all
14:48:47 <irenab> ivc: we should clarify how it should work for nested
14:48:53 <mchiappero> either you have the generic vif, and translators
14:48:57 <ivc> irenab but i did
14:49:05 <ivc> irenab its in our channel logs
14:49:10 <mchiappero> or you have drivers (the generic would be the ovs one) and drop the translators
14:49:40 <mchiappero> they try to solve the same problem
14:49:43 <mchiappero> anyway
14:49:48 <irenab> ivc: mchiappero : shall we set shor chat for alignment?
14:50:40 <mchiappero> ok, fine with it. I'm just saying, this is the problem I see, and the code I proposed is the result of the current design, I'm happy to see the code merged first of all
14:50:41 <apuimedo> please agree to that
14:50:54 <mchiappero> and I'm okay to accept whatever is reasonable
14:50:55 <apuimedo> so we can converge faster
14:51:07 <apuimedo> mchiappero: agree to the meeting, not to a result
14:51:10 <irenab> there are many fragments to make a complete support on new added flavor
14:51:10 <mchiappero> what I'm saying though is: the design wasn't right
14:51:55 <irenab> mchiappero: I think we agree on that. Therefor the refactoring brainstorming
14:52:15 <apuimedo> right
14:52:21 <apuimedo> ok. I'll send an invite
14:52:25 <irenab> we should clarify the Role and Resp of each entity
14:52:26 <apuimedo> #topic general
14:53:14 <ltomasbo> apuimedo, no discussions about my patch :(
14:53:18 <irenab> apuimedo: there was some point ltomasbo wanted to raise
14:53:33 <apuimedo> ltomasbo: sorry. We need to tackle two organizational items
14:53:40 <apuimedo> ping me tomorrow
14:53:44 <apuimedo> https://wiki.openstack.org/wiki/StoryBoard/Vision
14:53:47 <apuimedo> First of all
14:53:57 <apuimedo> We were asked about moving to storyboard
14:54:01 <ltomasbo> ok, irenab, ivc, can we discuss it later at the kuryr channel?
14:54:12 <apuimedo> as I put last week
14:54:23 <ivc> #link http://eavesdrop.openstack.org/irclogs/%23openstack-kuryr/%23openstack-kuryr.2017-04-20.log.html#t2017-04-20T14:39:27
14:54:24 <irenab> apuimedo: which projects already moved to it?
14:54:30 <ivc> just for the reference
14:54:35 <apuimedo> smaller
14:54:41 <apuimedo> or small similar like us
14:54:58 <irenab> ltomasbo: yes
14:55:08 <ltomasbo> irenab: thanks
14:55:23 <dmellado> apuimedo: weren't you going to send an email summarizing the pros/cons?
14:55:25 <dmellado> xD
14:55:34 <irenab> apuimedo: what are benetits versus launchpad?
14:55:42 <irenab> dmellado: :-)
14:55:55 <apuimedo> well, it's the new tool from the community, an openstack project
14:56:15 <apuimedo> Monasca, Infra, and Refstack are using it already
14:56:38 <apuimedo> dmellado: I didn't find the info :(
14:56:56 <dmellado> apuimedo: heh xD
14:57:04 <apuimedo> but they told me they have scripts that move all the bugs and items to storyboard automatically
14:57:13 <apuimedo> it's also more trelloesque
14:57:16 <apuimedo> which is a good thing
14:57:25 <apuimedo> no more of my attempts to have both launchpad and trello
14:57:52 <dmellado> I was taking a look at https://storyboard.openstack.org/#!/page/about
14:57:54 <ivc> apuimedo trello has better ux tho
14:57:54 <irenab> apuimedo: does it provide back trace from the patches as with launchpad?
14:58:07 <apuimedo> irenab: I think they move them all
14:58:07 <dmellado> irenab: ;) that was going to be my question too
14:58:10 <apuimedo> not just the open ones
14:58:51 <apuimedo> I quote "we have scripts that we can run to move all of your open bugs & bps over to Storyboard. It doesn't take very long either. After that point you simply discontinue using Launchpad for task tracking. We have tested Kuryr against our sandbox environment and it migrates without issue."
14:58:53 <irenab> apuimedo: I do not have enough info to provide my opinion …
14:59:33 <dmellado> apuimedo: any chance to have a look at that sandbox environment
14:59:41 <ivc> apuimedo irenab we can give it a try
14:59:41 <dmellado> maybe that would help when taking a decission
14:59:49 <irenab> do you want to decide now ?
15:00:05 <apuimedo> dmellado: that's a good point
15:00:18 <apuimedo> no, you can contact me with the vote individually
15:00:24 <apuimedo> once there is quorum I'll give an answer
15:00:33 <apuimedo> dmellado: I'll ask about access to it
15:00:37 <irenab> apuimedo: I mean when is the deadline
15:00:38 <dmellado> apuimedo: thanks!
15:00:44 <apuimedo> no deadline
15:00:57 <irenab> I want to have a look and check the UX
15:01:13 <dmellado> irenab: I was checking i.e. refstack@ https://storyboard.openstack.org/#!/story/2001001
15:01:18 <dmellado> just in case you want to have a look there too
15:01:27 <irenab> dmellado: thanks!
15:01:34 <apuimedo> Final topic
15:01:38 <apuimedo> sorry for taking longer
15:01:51 <apuimedo> OpenStack Queens PTG
15:02:04 <apuimedo> September 11-15th in Denver
15:02:08 <irenab> apuimedo: keeping on virtual?
15:02:15 <apuimedo> we are asked if we'll participate
15:02:20 <apuimedo> as a team there
15:02:22 <dmellado> +1 on virtual, at least from my side
15:02:30 <apuimedo> irenab: it all depends on the community
15:02:32 <apuimedo> :-)
15:02:47 <apuimedo> irenab: I take it you prefer virtual
15:03:00 <irenab> I have a feeling it will be easier to decede than with storyboard :-)
15:03:04 <apuimedo> ivc: kzaitsev_ws: ltomasbo: limao: ?
15:03:06 <ltomasbo> if virtual, can the dates be moved?
15:03:08 <ivc> +1 on virtual, but then its also too early to plan 5 months ahead :)
15:03:08 <apuimedo> hongbin: ?
15:03:15 <hongbin> o/
15:03:20 <ltomasbo> I liked the virtual one!
15:03:26 <apuimedo> ltomasbo: if virtual, there's no way I work on september 11th, catalan holiday
15:03:35 <ltomasbo> :D
15:03:35 <dmellado> ltomasbo: I guess so, just recall last time
15:03:39 <apuimedo> very well
15:03:51 <apuimedo> I think it's going to be virtual one
15:03:54 <apuimedo> irenab was right
15:03:56 <apuimedo> :-0
15:03:58 <apuimedo> :-)
15:04:04 <apuimedo> easier to decide
15:04:14 <apuimedo> alright. Thank you all for joining
15:04:27 <ltomasbo> bye!
15:04:29 <irenab> bye
15:04:31 <dmellado> cya!
15:04:32 <ivc> bb
15:04:35 <apuimedo> #info we'll wait for a couple more answers, but most likely we'll not be part of PTG as a team
15:04:36 <garyloug> bye
15:04:37 <apuimedo> #endmeeting