Friday, 2020-08-21

*** aprice has joined #openstack-meeting00:01
*** sri_ has joined #openstack-meeting00:02
*** csatari has joined #openstack-meeting00:02
*** evrardjp has quit IRC00:05
*** evrardjp has joined #openstack-meeting00:06
*** aprice has quit IRC00:12
*** aprice has joined #openstack-meeting00:14
*** sri_ has quit IRC00:16
*** patrickeast has quit IRC00:17
*** sri_ has joined #openstack-meeting00:18
*** patrickeast has joined #openstack-meeting00:19
*** _erlon_ has quit IRC00:21
*** rfolco has quit IRC00:24
*** zbitter is now known as zaneb01:06
*** Liang__ has joined #openstack-meeting01:26
*** ykatabam has quit IRC01:30
*** yamamoto has joined #openstack-meeting01:31
*** ykatabam has joined #openstack-meeting01:32
*** hongbin has quit IRC01:36
*** ijw has quit IRC01:45
*** rh-jelabarre has quit IRC01:54
*** gyee has quit IRC01:55
*** jgriffith has quit IRC01:56
*** hongbin has joined #openstack-meeting02:06
*** jmasud has quit IRC02:23
*** rcernin has quit IRC02:37
*** jmasud has joined #openstack-meeting02:37
*** rcernin has joined #openstack-meeting02:58
*** rcernin has quit IRC03:04
*** rcernin has joined #openstack-meeting03:04
*** evrardjp_ has joined #openstack-meeting03:12
*** evrardjp has quit IRC03:15
*** psachin has joined #openstack-meeting03:37
*** manpreet has quit IRC03:45
*** manpreet has joined #openstack-meeting03:50
*** jgriffith has joined #openstack-meeting03:54
*** hyunsikyang has quit IRC04:10
*** Liang__ has quit IRC04:24
*** Liang__ has joined #openstack-meeting04:24
*** evrardjp_ has quit IRC04:33
*** evrardjp has joined #openstack-meeting04:35
*** hongbin has quit IRC04:36
*** hyunsikyang has joined #openstack-meeting04:44
*** vishalmanchanda has joined #openstack-meeting05:07
*** Liang__ has quit IRC05:56
*** yonglihe has joined #openstack-meeting05:57
*** Liang__ has joined #openstack-meeting05:58
*** moguimar has quit IRC06:01
*** slaweq has joined #openstack-meeting06:34
*** rubasov has quit IRC06:38
*** icey has quit IRC06:38
*** kopecmartin|pto has quit IRC06:38
*** SotK has quit IRC06:38
*** number80 has quit IRC06:38
*** moguimar has joined #openstack-meeting06:41
*** jmasud has quit IRC06:42
*** rubasov has joined #openstack-meeting06:43
*** icey has joined #openstack-meeting06:43
*** kopecmartin|pto has joined #openstack-meeting06:43
*** SotK has joined #openstack-meeting06:43
*** number80 has joined #openstack-meeting06:43
*** jmasud has joined #openstack-meeting06:44
*** ociuhandu has quit IRC06:56
*** ociuhandu has joined #openstack-meeting06:57
*** belmoreira has joined #openstack-meeting06:57
*** ricolin has quit IRC06:59
*** ociuhandu has quit IRC07:01
*** hyunsikyang__ has joined #openstack-meeting07:20
*** rcernin has quit IRC07:22
*** hyunsikyang has quit IRC07:23
*** e0ne has joined #openstack-meeting07:24
*** Lucas_Gray has joined #openstack-meeting07:25
*** jkulik has joined #openstack-meeting07:28
*** hongbin has joined #openstack-meeting07:36
*** priteau has joined #openstack-meeting07:41
*** hongbin has quit IRC07:41
*** Lucas_Gray has quit IRC07:50
*** hyunsikyang__ has quit IRC07:50
*** slaweq has quit IRC07:50
*** gibi_pto_24th has quit IRC07:50
*** ricolin has joined #openstack-meeting08:12
*** tosky has joined #openstack-meeting08:22
*** Lucas_Gray has joined #openstack-meeting08:22
*** hyunsikyang__ has joined #openstack-meeting08:22
*** slaweq has joined #openstack-meeting08:22
*** gibi_pto_24th has joined #openstack-meeting08:22
*** lpetrut has joined #openstack-meeting08:22
*** arne_wiebalck has quit IRC08:44
*** tdasilva has quit IRC08:45
*** arne_wiebalck has joined #openstack-meeting08:46
*** tdasilva has joined #openstack-meeting08:46
*** dklyle has quit IRC08:49
*** ykatabam has quit IRC09:01
*** rcernin has joined #openstack-meeting09:08
*** baojg has joined #openstack-meeting09:43
*** ociuhandu has joined #openstack-meeting09:53
*** ociuhandu has quit IRC09:53
*** ociuhandu has joined #openstack-meeting09:54
*** Lucas_Gray has quit IRC09:58
*** yamamoto has quit IRC09:58
*** baojg has quit IRC09:59
*** Lucas_Gray has joined #openstack-meeting10:03
*** belmoreira has quit IRC10:07
*** yamamoto has joined #openstack-meeting10:09
*** rcernin has quit IRC10:13
*** Liang__ has quit IRC10:48
*** jhesketh has quit IRC10:53
*** jhesketh has joined #openstack-meeting10:55
*** rcernin has joined #openstack-meeting10:59
*** rcernin has quit IRC11:12
*** rfolco has joined #openstack-meeting11:14
*** rfolco has quit IRC11:15
*** rfolco has joined #openstack-meeting11:15
*** raildo has joined #openstack-meeting11:22
*** Lucas_Gray has quit IRC11:40
*** yonglihe has quit IRC11:54
*** _erlon_ has joined #openstack-meeting11:57
*** rh-jelabarre has joined #openstack-meeting11:59
*** e0ne has quit IRC12:04
*** e0ne has joined #openstack-meeting12:05
*** number80 has quit IRC12:18
*** masahito has joined #openstack-meeting12:30
*** yamamoto has quit IRC12:39
*** number80 has joined #openstack-meeting12:47
*** baojg has joined #openstack-meeting12:49
*** yamamoto has joined #openstack-meeting13:13
*** e0ne_ has joined #openstack-meeting13:25
*** e0ne has quit IRC13:25
*** yamamoto has quit IRC13:26
*** TrevorV has joined #openstack-meeting13:37
*** jiaopengju2 has quit IRC13:39
*** jiaopengju2 has joined #openstack-meeting13:40
*** jiaopengju2 has quit IRC13:42
*** jiaopengju2 has joined #openstack-meeting13:42
*** apetrich has quit IRC13:47
*** baojg has quit IRC13:48
*** baojg has joined #openstack-meeting13:49
*** pprincipeza_ has joined #openstack-meeting13:52
*** pprincipeza_ has quit IRC13:55
*** pprincipeza_ has joined #openstack-meeting13:56
*** pprincipeza_ has quit IRC13:58
*** pprincipeza_ has joined #openstack-meeting13:59
slaweq#startmeeting neutron_drivers14:00
openstackMeeting started Fri Aug 21 14:00:12 2020 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.14:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
slaweqhi14:00
*** openstack changes topic to " (Meeting topic: neutron_drivers)"14:00
openstackThe meeting name has been set to 'neutron_drivers'14:00
dosaboyo/ hi14:00
pprincipeza_Hello.14:00
dosaboyslaweq: im @hopem (from lp 1892200) fwiw14:00
openstackLaunchpad bug 1892200 in neutron "Make keepalived healthcheck more configurable" [Wishlist,New] https://launchpad.net/bugs/189220014:00
*** mlavalle has joined #openstack-meeting14:01
mlavalleo/14:01
haleybhi14:01
amotokihi14:01
slaweqwelcome dosaboy :)14:01
pprincipeza_slaweq, and I'm pprincipeza from lp 1891334. :)14:01
openstackLaunchpad bug 1891334 in neutron "[RFE] Enable change of CIDR on a subnet" [Wishlist,New] https://launchpad.net/bugs/189133414:01
slaweqwelcome pprincipeza_ :)14:01
slaweqhi mlavalle haleyb and amotoki14:01
slaweq:)14:02
slaweqralonsoh and njohnston are on pto this week14:02
slaweqso lets just wait 2 more minutes for yamamoto14:02
pprincipeza_ACK!14:02
slaweqok, lets start14:04
slaweqeven without yamamoto we have quorum so we should be good to go14:04
slaweq#topic RFEs14:04
*** openstack changes topic to "RFEs (Meeting topic: neutron_drivers)"14:04
slaweqwe have 2 RFEs today14:05
slaweqfirst one:14:05
slaweq#link https://bugs.launchpad.net/neutron/+bug/189133414:05
openstackLaunchpad bug 1891334 in neutron "[RFE] Enable change of CIDR on a subnet" [Wishlist,New]14:05
pprincipeza_I submitted that on behalf of a customer, who would like to have the ability to expand the subnet currently in use.  He has implemented the alternative alread (new subnets), his wish would be to avoid creating these distinct subnets, and keep the servers under a single subnet (even though this is completely virtual and internal to OpenStack).14:07
*** rafaelweingartne has joined #openstack-meeting14:07
pprincipeza_I understand the limitations that this would imply, as in having to repopulate existing Instances with new IP/Mask/GW information, and this would definitely need downtime. :/14:08
pprincipeza_I'd imagine this would be less "painful" on subnets with DHCP allocation, as this info *should* come with the lease renewal?14:10
dosaboyi assume this would only be expected to work as increase and not decrease of size14:10
pprincipeza_dosaboy, yes.14:10
*** rafaelweingartne has quit IRC14:11
dosaboypprincipeza_: is there a particular use-case? would just adding an extra subnet to the network now solve the issue?14:11
dosaboys/now/not14:12
haleybtechnically, it should be able to scale-down a subnet if number of ports is small enough, just don't know why you'd want to do that14:12
slaweqbut how You want to force changes of e.g. mask in the existing instances?14:12
*** rafaelweingartne has joined #openstack-meeting14:12
pprincipeza_dosaboy, the use-case is more on a "systems management" side than in functionality.  He has implemented other subnets, and everything is working fine.14:13
pprincipeza_slaweq, my only thought there would be on doing the change with instances down, as I imagine the new information from subnet would come in upon the lease renewal?14:14
pprincipeza_(And I expect that to happen at boot time?)14:14
haleybslaweq: scaling-up by just changing the mask might not cause a big disruption, but i can't see being able to do that if pools are being used, would need to change to a new subnet, bleck14:15
*** lpetrut has quit IRC14:15
mlavalleso the system manager wants to save himself / herself manag ement work and instead have the users reconfigure thier vms?14:15
dosaboyhaleyb: i guess either way i worry about the number of places that update would have to be applied to14:15
pprincipeza_mlavalle, yes, it sounds not much reasonable when thinking of end-users of the Cloud. :/14:16
pprincipeza_And the change on lb-mgmt for Octavia would also be a use-case, I believe?14:17
haleybi can see how this change would help with certain deployers too, for example where the undercloud was made too small, but don't know how the cloud admin could do this successfully, for a tenant it seems more doable14:17
haleybpprincipeza_: so is the use case more the end-user/tenant?14:18
mlavalleI understood the opposite, but I migh be wrong14:18
slaweqon neutron's side it would be change in the dhcp agent and neutron db, right? other things are on user who needs to e.g. reboot vms or force renew of lease, is that correct or am I missing something here?14:19
dosaboyif its octavia lb-mgmt net then its the case where it runs out of addresses for amphora vms etc14:19
pprincipeza_haleyb, ^ thanks, slaweq.  that sums it up.14:19
haleybmlavalle: it's not clear to me14:20
mlavallepprincipeza_: you also mention Octavia, which is not mentioned in the RFE. Is there an aditional conversation going on that we haven't seen in this meeting?14:20
pprincipeza_mlavalle, this was a use-case not initially added to the RFE I submitted, but discussing this with dosaboy, that use-case came up as an addition.14:21
dosaboymlavalle: tbh we've seen the octavia issue with older deployments before we switched to using v6 networks for the lb-mgmt net14:21
pprincipeza_mlavalle, I can certainly add that mention to the LP Bug, if that's needed.14:21
dosaboybut i havent yet tested if adding an extra subnet could fix that, planning to try that14:22
johnsomOctavia also has an rfe to add multiple subnets for the lb-mgmt-net. It just hasn’t come up that anyone needed it, so is low priority.14:22
dosaboyi don't know if that's pprincipeza_ original use-case though14:23
dosaboyjohnsom: oh interesting i was not aware of that14:23
*** hongbin has joined #openstack-meeting14:23
mlavallebut pprincipeza_'s aim is to avoid adding subnets, isn't it?14:24
slaweqI'm still not really convinced for that rfe and if we should implement something what may be in fact painful for users later14:24
amotokiI had a trouble in internet connection and am just following the discussion. As you already discussed, expanding a subnet CIDR leads to a subnet mask change. It sometimes leads to a problem between an existing vm and a new booted vm if the exsting vm does not update the mask. If all communications happen between gateway and VMs, we will hit less problems.14:25
pprincipeza_mlavalle, yes, that's my initial aim.14:25
mlavallein that case, the Octavia RFE mentioned above is not related, if I understand correctly14:26
haleybamotoki: and it might be you can't just change the mask, but need a new cidr due to overlap, right?14:27
pprincipeza_Yes.14:27
amotokihaleyb: yes14:28
johnsomIn fact, using the AZ code in Ussuri Octavia allows for multiple lb-mgmt-nets today.14:28
haleybso then it's new subnet and live migration, etc14:28
amotokihaleyb: I think overlapping case can be covered by the API side. we can check overlapping of CIDR14:28
*** baojg has quit IRC14:28
*** baojg has joined #openstack-meeting14:29
haleybamotoki: right, i was just thinking the simple case of changing from /26 to /24, same cidr, which causes little disruption, otherwise it's reboot everything14:29
mlavalleright14:30
amotokihaleyb: thanks. I am in a same page.14:30
pprincipeza_And if rebooting is needed, it is needed, I don't see that feature being added without some "pain" for the Instances. :)14:30
*** baojg has quit IRC14:31
mlavallef and the RFE refers to "changing the CIDR of a subnet", so it's not just going from /26 to /2414:32
*** baojg has joined #openstack-meeting14:32
haleybpprincipeza_: if you need to reboot, is a new subnet with new instances easier?  no downtime if these instances are part of a pool?14:32
*** yamamoto has joined #openstack-meeting14:32
*** baojg has quit IRC14:32
slaweqmlavalle: exactly, how it would be if You would e.g. changed from 10.0.0.0/24 to 192.168.0.0/16 ?14:33
pprincipeza_haleyb, the new subnet with new instances is already in place as a functional way out of the "expansion" limitation.14:33
slaweqthat may be much harder :)14:33
*** baojg has joined #openstack-meeting14:34
haleybthis has a ripple effect through security groups as well14:34
pprincipeza_mlavalle, slaweq, my initial use-case beared a minor /26 to /24 scenario, but the bigger change (CIDR) was requested, utmostly.14:35
slaweqpersonally I can imaging that we are allowing extend of the cidr, so old cidr has to be inside new, bigger one14:36
amotokidoes it work if the RFE is rephrased from "changing" to "expanding"?14:36
slaweqbut other use cases I'm not sure14:36
mlavalleamotoki: so the /26 to /24 case?14:36
amotokimlavalle: yes14:36
amotoki* with limitations14:37
slaweqso should we vote on that rfe or do You want some more clarifications and discuss that again next week?14:40
haleybamotoki: it's more reasonable if just expanding, but i guess there will still be connectivity issues since the gateway will have changed?14:40
mlavallehaleyb: I think so14:40
amotokihaleyb: the gateway address is alreaedy assigned so I don't think we need to change the gateway address.14:40
slaweqhaleyb: if we will just expand, why gateway need to be changed?14:40
haleybslaweq: i just didn't know if the expansion changed the ".1" address to be different. i.e. 2.1 to 0.1 or something14:42
haleybor the gateway stays the same...14:42
amotokiI thought the gateway stasy the same. In my understanding, the current logic is applied only when a gateway is not specified.14:43
slaweqamotoki: I think the same14:43
haleybamotoki: yes, i was just thinking out loud, shouldn't be an issue after thinking about it14:44
amotokihaleyb: thanks. we are careful enough :)14:45
slaweqso are we ok to approve this rfe as "expansion of subnet's cidr" and discuss details in the review of the spec?14:45
amotoki+1 for expanding a subnet CIDR. This operation may require additional workaround including instance reboot as we discussed. it is worth documenting in the API ref or some.14:46
rafaelweingartneIf it is just about expanding CIDRS, +114:46
slaweqpprincipeza_: will that work for You?14:47
pprincipeza_slaweq, it works for me.14:47
pprincipeza_Thank you very much for considering it!14:47
mlavalle+1 from me, then14:47
slaweqhaleyb ?14:47
haleyb+1 from me14:48
*** yamamoto has quit IRC14:48
slaweqthx, so I will mark this rfe as approved14:48
slaweqwith note about "expanding cidr" only14:49
slaweqok, lets quickly look into second rfe14:49
slaweq#link https://bugs.launchpad.net/neutron/+bug/189220014:49
openstackLaunchpad bug 1892200 in neutron "Make keepalived healthcheck more configurable" [Wishlist,New]14:49
pprincipeza_Awesome, thank you very much slaweq haleyb mlavalle!14:49
dosaboyok so,14:49
dosaboy1892200 is related to an issue that we have recently observed in an env using l3ha14:49
dosaboythe conditions to hit the issue are somewhat protracted and described in the LP but14:49
dosaboylong story short is that while the check was failing for a valid reason, the result of it failing ended up causing more problems14:49
dosaboyand since the original cause of the test failure was transient, there was no real need to failover14:49
dosaboytherefore a slightly more intelligent test than simply doing a single ping would be preferable14:49
dosaboyin terms of solutions I know that protocols like BFD are much better at dealing with this kind of thing and are available in OVN14:50
dosaboybut this is really for those users that will be stuck with L3HA for the forseeable14:50
dosaboyso adapting what we e.g. just trying more pings before we declare a failure, would be better than what we have imho14:50
dosaboyon top of that, the suggestion to move the current code to use a template seems like a good idea14:50
dosaboyright now the healthcheck script is entirely built from code14:50
dosaboyif we used a template it would also provide the opportunity to make the path to the template configurable14:50
dosaboythus allowing for it to be modified without changing neutron code14:50
dosaboyI've not looked to deeply into this yet but was thinkig something along the lines of a jinja template14:50
dosaboythoughts?14:50
slaweqdosaboy: I was thinking about jinja2 too :)14:52
rafaelweingartneThe idea of a customizable template looks great, as long as there is a default one already in place.14:52
slaweqrafaelweingartne: yes, my idea here was that we should basically provide default template which will be the same as what we have now14:53
dosaboyrafaelweingartne: yeah absolutely, default that can be overriden via config path14:53
mlavalleI think that is the idea, rafaelweingartne14:53
dosaboyslaweq: yep14:53
*** dklyle has joined #openstack-meeting14:54
amotokigenerally templating it sounds great. it potentially makes our bug triage complex. my question is whether we will keep current configurations (though I haven't checked if we have them).14:54
dosaboyso i guess there's two way to look at the request, either we "improve" the existing default test and/or make it templatised to allow user-override14:54
dosaboyamotoki: the only config currently iirc is the interval i.e. how often to run the check14:55
slaweqamotoki: are You asking about configuration for specific process which is spawned for router?14:55
dosaboythat can remain14:55
dosaboyslaweq: no process here fwiw, the check is run directly by keepalived14:56
*** rafaelweingartne has quit IRC14:56
amotokislaweq: what i mention is keepalived config14:56
dosaboyneutron generates the keepalived conf with the test enabled and a path to the test14:56
haleybslaweq: i like your thought on keepalived options for a router, maybe an extension?  instead of adding more config options?  or were you thinking something else?14:56
haleybthat was in the bug comments14:57
dosaboyhaleyb: this isnt really about how keepalived drives the test though, not in my experience anyway14:57
dosaboyour problem was really the test itself14:57
slaweqcurrently when neutron-l3-agent is configuring new router, it generates keepalived config file through https://github.com/openstack/neutron/blob/master/neutron/agent/linux/keepalived.py14:57
*** masahito has quit IRC14:58
slaweqand this config file is storred somewhere in /var/lib/neutrin/ha_confs/<router_id> (IIRC)14:58
*** baojg has quit IRC14:58
dosaboy... that fails when a single icmp reply is missed within 1s14:58
*** baojg has joined #openstack-meeting14:58
slaweqand my idea here was that we can somehow change clases in this module that it will generate keepalived config file based on some template14:58
dosaboyslaweq: correct14:58
dosaboyright14:59
slaweqso it will still set correct interface names, ip addresses and other variables14:59
slaweqbut user will be able to prepare in template other things like some timeouts, etc.14:59
dosaboyim totally +1 on that and make the path to the template configurable so that users can modify it and put it somewhere else14:59
slaweqI hope that it is clear and I hope it is correct with what dosaboy wants :)14:59
haleybslaweq: per-router or per-cloud?14:59
haleybi.e. admin-controlled template15:00
slaweqhaleyb: template would be "per l3 agent" in fact15:00
dosaboyslaweq: yeah i think thats it15:00
slaweqbut in practice it should be per cloud15:00
dosaboyyep per l3agent15:00
dosaboythats enough for us anyways15:00
slaweqas You shouldn't have different configs on different network nodes15:00
amotokiI am +1 for introducing template (and also we can keep better default configs)15:01
slaweqok, we are out of time today15:01
dosaboyslaweq: yeah sorry im confusing things, it would be the same everythere but thats just cause we would configure all l3-agents the same15:01
dosaboyok thanks for reviewing15:01
slaweqI think we need to get back to this next week15:01
haleybit now makes sense to me15:01
slaweqor is it clear for You and You want to vote now on that quickly ?15:02
haleybwhat about others?15:02
haleybi don't think there's a meeting right after us...15:02
mlavalleit makes sense to me15:02
mlavallei'm comfortable casting a +115:03
slaweqok, so it seems that mlavalle amotoki haleyb and I are ok to approve it now15:03
slaweqright?15:03
amotokiI think so15:03
slaweqhaleyb: you ok with that proposal, right?15:04
haleybyes, i'd +1, seems useful for cloud admins15:04
slaweqok, thx a lot15:04
slaweqso I will mark this one as approved too15:04
slaweqthx for proposing it dosaboy15:04
dosaboythanks guys, much appreciated15:05
slaweqand sorry that I keept You here longer than usually :)15:05
slaweqhave a great weekend and see You all next week15:05
slaweqo/15:05
slaweq#endmeeting15:05
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings/"15:05
openstackMeeting ended Fri Aug 21 15:05:23 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:05
openstackMinutes:        http://eavesdrop.openstack.org/meetings/neutron_drivers/2020/neutron_drivers.2020-08-21-14.00.html15:05
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/neutron_drivers/2020/neutron_drivers.2020-08-21-14.00.txt15:05
amotokio/15:05
openstackLog:            http://eavesdrop.openstack.org/meetings/neutron_drivers/2020/neutron_drivers.2020-08-21-14.00.log.html15:05
pprincipeza_slaweq, I saw you updated the bug with the SPEC request.  Is that something I shall work on, or else (newbie on RFEs for O7K here!)?15:06
slaweqpprincipeza_: I think You now should propose spec to the neutron-spec repository15:06
slaweqand we can review details of Your proposal there15:07
slaweqand then You can move on to the implementation part15:07
pprincipeza_slaweq, alright, I'll work on that!  Thanks!15:07
slaweqpprincipeza_++ thx a lot15:07
slaweqif You will have any question, please just ping me on #openstack-neutron channel15:07
slaweqor anyone else from the neutron team :)15:08
pprincipeza_slaweq, sweet, will do!  Awesome, thanks!15:08
*** slaweq has quit IRC15:17
*** e0ne_ has quit IRC15:22
*** pprincipeza_ has quit IRC15:26
*** slaweq has joined #openstack-meeting15:28
*** apetrich has joined #openstack-meeting15:32
*** gyee has joined #openstack-meeting15:34
*** ociuhandu_ has joined #openstack-meeting15:53
*** ociuhandu has quit IRC15:56
*** ociuhandu_ has quit IRC15:57
*** mlavalle has quit IRC15:59
*** tosky has quit IRC16:00
*** baojg has quit IRC16:01
*** mlavalle has joined #openstack-meeting16:02
*** baojg has joined #openstack-meeting16:02
*** yamamoto has joined #openstack-meeting16:06
*** baojg has quit IRC16:10
*** baojg has joined #openstack-meeting16:12
*** ociuhandu has joined #openstack-meeting16:15
*** ociuhandu has quit IRC16:19
*** yamamoto has quit IRC16:21
*** ijw has joined #openstack-meeting17:01
*** priteau has quit IRC17:07
*** psachin has quit IRC17:15
*** dustinc has quit IRC17:45
*** ijw has quit IRC17:47
*** ijw has joined #openstack-meeting17:48
*** hongbin has quit IRC18:17
*** yamamoto has joined #openstack-meeting18:21
*** vishalmanchanda has quit IRC18:27
*** yamamoto has quit IRC18:40
*** ijw has quit IRC18:41
*** armax has quit IRC18:44
*** ijw has joined #openstack-meeting18:48
*** bnemec has quit IRC18:53
*** armax has joined #openstack-meeting18:53
*** bnemec has joined #openstack-meeting19:01
*** armax has quit IRC19:05
*** bnemec has quit IRC19:08
*** hongbin has joined #openstack-meeting19:10
*** armax has joined #openstack-meeting19:22
*** rfolco has quit IRC19:29
*** rfolco has joined #openstack-meeting19:29
*** yoctozepto1 has joined #openstack-meeting19:30
*** raildo_ has joined #openstack-meeting19:30
*** raildo has quit IRC19:31
*** arne_wiebalck_ has joined #openstack-meeting19:31
*** arne_wiebalck has quit IRC19:32
*** jgriffith has quit IRC19:32
*** yoctozepto has quit IRC19:32
*** arne_wiebalck_ is now known as arne_wiebalck19:32
*** yoctozepto1 is now known as yoctozepto19:32
*** gyee has quit IRC19:32
*** rh-jlabarre has joined #openstack-meeting19:33
*** tdasilva has quit IRC19:34
*** tdasilva has joined #openstack-meeting19:35
*** gyee has joined #openstack-meeting19:36
*** csatari_ has joined #openstack-meeting19:37
*** jhesketh_ has joined #openstack-meeting19:38
*** moguimar_ has joined #openstack-meeting19:40
*** slaweq has quit IRC19:42
*** number80 has quit IRC19:42
*** csatari has quit IRC19:42
*** jhesketh has quit IRC19:42
*** rh-jelabarre has quit IRC19:42
*** moguimar has quit IRC19:42
*** csatari_ is now known as csatari19:42
*** armax has quit IRC19:42
*** mlavalle has quit IRC19:42
*** number80 has joined #openstack-meeting19:45
*** armax has joined #openstack-meeting19:48
*** mlavalle has joined #openstack-meeting19:48
*** slaweq has joined #openstack-meeting19:52
*** slaweq has quit IRC19:57
*** slaweq has joined #openstack-meeting20:02
*** slaweq has quit IRC20:07
*** ijw has quit IRC20:16
*** Lucas_Gray has joined #openstack-meeting20:24
*** tosky has joined #openstack-meeting20:30
*** moguimar_ has quit IRC20:37
*** yamamoto has joined #openstack-meeting20:39
*** rfolco has quit IRC20:49
*** TrevorV has quit IRC20:54
*** yamamoto has quit IRC20:59
*** andrebeltrami has joined #openstack-meeting21:03
*** bbowen__ has quit IRC21:29
*** yamamoto has joined #openstack-meeting21:32
*** bbowen has joined #openstack-meeting21:34
*** jgriffith has joined #openstack-meeting21:36
*** yamamoto has quit IRC21:45
*** ociuhandu has joined #openstack-meeting22:16
*** ociuhandu has quit IRC22:21
*** armax has quit IRC22:26
*** jamesdenton has joined #openstack-meeting22:31
*** Lucas_Gray has quit IRC22:36
*** _erlon_ has quit IRC22:46
*** armax has joined #openstack-meeting22:47
*** apetrich has quit IRC22:50
*** mlavalle has quit IRC23:02
*** yamamoto has joined #openstack-meeting23:44
*** tosky has quit IRC23:48

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!