Thursday, 2018-04-05

*** rosmaita has quit IRC00:35
*** diablo_rojo has quit IRC00:37
*** notmyname_ has joined #openstack-tc00:49
*** notmyname has quit IRC00:51
*** notmyname_ is now known as notmyname00:51
*** mriedem_away has quit IRC01:34
*** harlowja has quit IRC01:42
*** harlowja has joined #openstack-tc03:37
*** lbragstad has joined #openstack-tc03:42
*** lbragstad has quit IRC04:58
*** lbragstad has joined #openstack-tc05:01
*** lbragstad has quit IRC05:10
*** harlowja has quit IRC05:22
*** jpich has joined #openstack-tc07:40
*** cmurphy has quit IRC08:11
*** zaneb has quit IRC08:12
*** cmurphy has joined #openstack-tc08:13
*** zaneb has joined #openstack-tc08:14
*** melwitt has quit IRC08:26
*** cdent has joined #openstack-tc08:26
*** persia has quit IRC08:26
*** persia has joined #openstack-tc08:28
*** melwitt has joined #openstack-tc08:33
mugsiezaneb: you had more restraint than I did :)08:33
mugsieor do08:33
cdentmornin' mugsie08:38
mugsiecdent: morning08:38
*** dtantsur|afk is now known as dtantsur10:23
*** lbragstad has joined #openstack-tc11:53
*** rosmaita has joined #openstack-tc12:05
ttxfungi: fwiw fighting Conway's law by aligning structures with our technical goals is definitely  a business I think the TC needs to stick their nose in12:49
ttxhence my (personal) interest in that kolla/kolla-ansible/kolla-k8s/OSH discussion12:50
*** mriedem has joined #openstack-tc12:57
persiaOne of the issues with the application of Conway's law is that it assumes strong tribes.  While I agree it is the TC's proper business to create social organisation that supports technical goals, one of the strengths of the OpenStack community is that may participants are able to work in a cross-project fashion: building strong organisation for clean communiication between "teams" may limit that, as the nature of the constructed organisation13:09
persiareinforces the idea that a team is a valid social identity.13:09
mugsiepersia: I would argue that a project team (in the OpenStack context) *is* a valid social identity for a lot of people, just like the people who do cross project work are another social group. If you look at who socialises with who at summits / PTGs a lot of it is either company based or team based. If you spend time working with a group on something, it is pretty standard to have social group form from that.13:22
mugsieit is like smokers form pseudo social groups within companies and conferences :) - it all about who you spend time with and talking to13:23
persiaI share your observations.  I am not sure that taking that as a base assumption will best forward TC goals.  I believe there are a sufficient number of people who work on two or more projects (not necessarily in a way that is visible to those you describe as "people who do cross project work") that strengthening the project group identity may be harmful, or make some participants feel pressured to "choose".13:26
cdentI reckon the association of identity/socialness with project team is a large part of why we continue to talk about what openstack is13:27
cdentit is, however, inevitable because of the way we organized work and other activities13:29
*** david-lyle has quit IRC13:30
openstackgerritMerged openstack/project-team-guide master: Update Stable policy for Extended Maintenance
*** annabelleB has joined #openstack-tc13:53
*** hongbin has joined #openstack-tc13:54
*** annabelleB has quit IRC14:07
*** annabelleB has joined #openstack-tc14:22
*** annabelleB has quit IRC14:22
*** david-lyle has joined #openstack-tc14:40
* dhellmann looks around and checks the clock14:59
fungiit's about that time14:59
dhellmanntc-members: office hours14:59
fungitc-members: (and anyone else) an hour of office awaits us all...14:59
*** gagehugo has joined #openstack-tc15:00
* mugsie lurks15:01
cdentCan anyone summarize the kolla discussions?15:01
* dhellmann is missing some scrollback15:01
ttxkolla discussion -- still collecting a rather wide feedback15:02
fungiit seems there's yet another new turn of events in kolla-land today too, with a plan to more thoroughly separate kolla-ansible from kolla images so that loci images can also be used there15:02
dhellmannit seems like this organizational question has always been there with kolla. Didn't we have a similar discussion when they asked to become official?15:02
ttxyes, moving target at that point15:02
ttxdhellmann: we did, but sdake was pretty adamant back then that was the only way to do it and it would not cause issues down the line15:03
dhellmannyes, well15:03
fungi On moving start scripts out of Kolla images15:03
fungiis the new thread15:03
dhellmannwas the original change about kolla-kubernetes abandoned?15:04
ttxI still think it builds a superstructure not adapted to the technical need for reasons that are ultimately branding reasons15:04
dhellmannthe governance patch, that is15:04
fungino, it's still getting new messages15:04
fungiat least as recently as yesterday15:04
dhellmannoh, found it15:04
fungioh, original change. i thought you said original thread15:04
dhellmannit wasn't clear to me if that was a request from kolla-kubernetes contributors to have their own team, or from someone else asking for kolla to be split up15:04
dhellmanndoes anyone have insight into that?15:05
fungiwell, change 552531 was proposed by the current kolla ptl15:05
ttxSo yes, several ideas have been pitched, split k-k8s off, merging k-k8s with OSH, keeping things as-is, splitting Kolla from k-ansible and k-k8s, and the discussion is still going on15:05
ttxdhellmann: originally it was more a recognition that the kolla and k-ansible team have nothing to do with k-k8s15:05
mugsiedhellmann: I *think* it was kolla wanting to divest itself of kolla-kubernetes15:05
dhellmannfungi : ah, yes, I should have looked at that, thsnks15:06
ttxand therefore split them out and let it live or die in a different corner15:06
dhellmannaha, ok15:06
ttxbut sice then k-k8s people have chimed in15:06
dhellmannin favor, or opposed?15:06
dhellmannsorry, I should probably just go read all of this more closely. personal distractions have prevented that this week.15:07
ttxwell, some suggesting an OSH merge, and some pointing to the root cause15:07
ttxit's fine we can't all read everything15:07
fungithe k-k8s contributors who have replied seemed not to be in favor of being forcibly separated from the kolla team at this point, plead for an opportunity to revive activity there, and didn't seem interested in getting absorbed into osh, based on my reading (perhaps others read it differently?)15:08
*** kumarmn has quit IRC15:08
ttxactually I think for omplex issues like this having someone dedicvated to following up and summarizing is a good thing [tm]15:08
dhellmannttx: yes, I think that's a good approach for us to take in general15:08
dhellmanneven the not complex things can use someone to stay on top of them15:08
ttxfungi: I think there were variants, but I may have read affiliations incorrectly15:09
fungioh, perhaps15:09
ttxanyway, I think it's still too early to make a call15:09
dhellmannit appears there is already a separate kolla-kubernetes team in gerrit, though I haven't looked at the membership cross-over with kolla-core15:09
cdentttx: in your mind what is it that a call is being made on?15:09
ttxI pitched my original position, which is that the team should align with its common constituency. If there are parts of the team that are completely disjoint and handle separate deliverables, they should have their own PTL making the calls15:10
dhellmannright, that's what we've tried to have all of the other teams do15:10
dhellmannand what we wanted kolla to do from the start15:10
ttxIt's the only way to have sane governance15:10
fungiin particular i was recalling the reply from rich wellum:
ttx1/ aligned with constituency  and 2/ only at levels where decisions are actually needed15:11
dhellmannI don't think there is a situation like we had in neutron, where the team being split off can't qualify to be an official team on their own15:11
mugsiefrom my reading the issue seems to be with > 2. Agreement within Kolla core team to learn kolla-kubernetes and start to put a percentage of time into this sub-project.15:11
ttxyes, the neutron situation is more a trade-off. it's not perfect but the best so far15:11
dhellmannand I have sympathy for a PTL who is left "managing" a deliverable that isn't actually actively developed/maintained15:11
mugsieI do think a lot of the tensions could be solved by splitting the team, and then having CI gates on image builds from kolla-k8s and other people who use the images15:12
ttxdhellmann: some argue that k-k8s would not be in he position it's in if it had flown under its own wings, but I don't know enough of the details to confirm that15:12
mugsiebut that seems to be incompatible with some members of kolla's long term visions of what they want to produce15:13
ttxcdent: approving one of the team restructuration option15:13
dhellmannttx: sure. we might be talking about whether the *tc* wanted to drop an inactive team15:13
dhellmannmugsie : yes, that's disappointing. it leaves room for some of the container-consuming projects to work with another image-building team that is more interested in just managing the images.15:14
mugsiettx: is this a TC issue at all? - this could all still run under kolla with different groups in gerrit, and a "k8s lieutent" (like neutron did / does?) who can work with the kolla PTL. If that works out, then split it out, if it doesn't, retire the project15:15
ttxmugsie: i think it's our role to ensure sane governance yes15:16
dhellmannmugsie : it could run that way. the question is whether the team actually wants to do that. it sounds like we're still mediating that discussion15:16
mugsiemlavelle doesn't have a day to day PTL role on things like LBaaS / FWaaS - that is ran by someone else15:16
fungii don't think any members of the tc were pushing for them to retire kolla-k8s, at least not that i saw15:16
ttxLike one might argue that kolla-k8s contributors are not in control of their deliverable, with a PTL elected by a completely disjoint  and larger group15:16
mugsiefungi: no, I think that was just people from within kolla15:17
ttxhence breaking one of the 4 opens15:17
fungiit was more a point that if the k-k8s team feels like their needs were being edged out due to a too-tight association between kolla images and k-ansible then perhaps alternatives should be considered to loosen up that coupling15:17
fungias in the kolla team could take a critical eye to their current approach15:18
dhellmannif the team building the images is not prepared to make support promises for other teams about the images being reusable, then it sounds like those are not good images for other teams to be trying to use15:19
fungiright, i completely agree on that point15:19
*** kumarmn has joined #openstack-tc15:19
mugsiedhellmann: ++15:19
fungibut in that case they need to not claim that their images are implementnig a stable api for others to build their own orchestration systems on top of15:19
dhellmannand other teams need to take a hard long look at whether the claim is accurate or not15:20
fungimy point in is that it's hard for one group to serve two masters15:21
fungieither they're producing a deployment solution with images as a byproduct, or they're producing images with an example deployment system as a byproduct15:21
dhellmannor they're producing images that are independent of the deployment tool15:22
dhellmannthough, not having done it myself, I wonder how practical that really is15:22
fungiwhich it sounds like others in the thread have been claiming is not the case15:22
ttxdhellmann: did you want to discuss the lower-bounds-testing tag ?15:23
dhellmannis loci the image team for osh? or are the loci images more reusable?15:23
fungi(claiming that the deployment system and images are effectively not independent entities)15:23
* ttx has to leave in 25 min15:23
fungiloci is a separate project/team from osh as far as i know15:23
jrolldhellmann: it's very practical, dockerhub operates around this assumption imo (people use their tool of choice to deploy these public images)15:23
dhellmannttx: we can. I think I see your point. I don't know if anyone other than distributors really care about the lower-bounds tests so maybe a tag is not the right approach. It seemed like a reasonable soft approach to encouraging teams to sign up for the tests, though.15:23
ttxYes LOCI is more of an alternate approach to Kolla-the-base-stuff15:23
fungianyway, i like pbourke's proposal to have k-ansible support loci images in addition to kolla images15:24
dhellmannjroll : that was my assumption. I wonder what all the fuss over the kolla images is, then.15:24
dhellmannI'm not sure I understand the point of that, fungi. what makes that attractive?15:24
ttxdhellmann: my main question is whether we should not just consider it a madatory part of suing requirements15:24
ttxerr using15:24
jrolldhellmann: the new thread highlights the problems that make it impractical for others to use kolla images with a different deployment system
ttxdhellmann: do you expect only some projects to adopt lower-bounds-testing?15:25
smcginnisttx: That would be my preference - once we get everyone to that point.15:25
dhellmannok, I'll put that on my queue for next week15:25
dhellmannttx: it has been more popular than I expected, but I wasn't prepared to say it was a requirement.15:25
jrolltl;dr kolla does image configuration very differently than everyone else does image configuration15:25
ttxIt feels like goal material to me, if it's not too complex15:25
dhellmannfwiw, I personally don't care about the lower-bounds stuff except that the requirements team made it a prerequisite for the thing I *do* care about which is that we stop syncing g-r into projects15:25
jroll(the config.json "stable api" thing, instead of environment variables or bind-mounting a config volume)15:26
dhellmannttx: it takes 1 patch and is quite easy to set up. I've submitted patches to all of the projects that were syncing requirements already15:26
dhellmannso the goal is really "make patch X work and approve it"15:26
dhellmannthey don't even have to write the patches15:26
fungidhellmann: the steps they need to take to be able to implement support for multiple image backends in k-ansible seems like it would help solidify a stronger decoupling between k-ansible and kolla images as deliverables15:26
dhellmannfungi : very good point, I had not looked at it that way15:27
fungibased on that e-mail from pbourke and some of the discussion in their meeting yesterday, it seems like right now the "stable api" for kolla images is actually a set of files in the kolla-ansible repo15:27
dhellmannhmm, that's unfortunate15:28
cdentI think it is slightly more complex than that fungi, but close enough15:28
fungithough that also seems to be hotly debated in the meeting as to what constitutes an "api" for images15:28
clarkbdhellmann: I'm not sure if you saw it but re requirements syncing I think the current system makes it more important that we install all of openstack into a single env to ensure coinstallability? since we no longer use a single constraints file everywhere?15:29
*** kumarmn has quit IRC15:29
cdentI think the underlying fault(?) here is that kolla has it's own api rather than using one that is common to the container world15:29
dhellmannclarkb : we *do* still use upper-constraints.txt. That's the co-installability list. And we test against that list, both when changes are made to g-r and in project trees.15:29
jrollcdent: that also appears to be the wedge, to me15:29
ttxdhellmann: ok then I'd rather implement it where we can in R and make it a community goal for stragglers in S15:30
dhellmannclarkb : the "insight" I had was that we didn't have to have our requirement ranges match exactly as long as they were all compatible with the u-c list15:30
fungiclarkb: it's the lower-constraints.txt which is not global15:30
clarkbdhellmann: ah ok so maybe separate venvs is potentially viable (though not also working today)15:30
dhellmannttx: I'm OK with that approach.15:30
ttxand then consider it part of the requirements policy and be done with it15:30
dhellmannclarkb : separate venvs should work, but one is probably easier15:30
clarkbdhellmann: ya to start one definitely seems easier at least to hack into devstack15:30
clarkbsome thought separate venvs may be easier because devstack almost has support for it15:31
dhellmannoh, that could be15:31
clarkbbut adding support for the things it doesn't yet support likely to be more work than global venv to start15:31
clarkb(especially with plugins)15:31
dhellmannalthough using 1 should just need to be a change to where we call pip to point to the right path15:31
clarkbdhellmann: yup thats basically what my current hack is doing15:31
clarkbchange 558930 if you are curious15:31
clarkb(needs a lot of cleanup, but its getting there)15:32
clarkbalso yay pip1015:32
* dhellmann stars 55893015:32
ttxOn the Adjutant front, been trying to summarize the concerns and brainstorm potential next steps/questions to answer -- please check that my two points cover the main concerns (and add to those if you have others)15:32
dhellmannttx: your points summarize my concerns nicely15:33
*** openstackgerrit has quit IRC15:34
dhellmannthough for point 1 I would also mention that it's an issue of the team's scope15:34
* TheJulia has been mentally derailed by an in-person meeting :(15:34
ttxOh, I had an important question15:40
ttxIn the release cycles discussion at the PTG we pointed to the need for better data about consumption models15:40
ttxand said we could try to add a question for that in the user survey15:41
ttxHere is what I came up with:15:41
ttxa question around upgrade pattern, something like:15:41
ttxHow do you upgrade your version of OpenStack:15:41
ttx- Tracking HEAD of master15:41
ttx- Tracking intermediary releases15:41
ttx- Upgrade all coordinated releases (once every 6 month)15:41
ttx- Skipping/fast-forwarding releases15:41
ttx- Not upgrading15:41
ttxAnd another about stable consumption patterns, like:15:41
ttxOnce on a given release, do you use stable branches for bugfix upgrades:15:41
ttx- Yes, upgrading at various points in time depending on fixes15:41
ttx- Yes, backporting specific fixes15:41
ttx- Yes, using only official point releases15:41
dhellmannI am also interested in knowing which tools people are using and if they are customizing community tools15:42
ttx- I do not do bugfix upgrades15:42
ttxI feel like that would give us better data than just asking what release version people are using15:42
dhellmannit would be good to ask the version question, too, but I agree that this extra detail will help15:42
dhellmannknowing that someone is tracking official releases of newton, for example15:42
cdentyes, to having version and ttx's questions15:42
ttxdhellmann: The version question is a classic user survey questionm so we'll have that15:42
jrollttx: for the second, maybe add "Yes, tracking HEAD of the stable/branch" (IOW, deploying every commit)15:42
dhellmannok, good15:43
ttxThe 2 questions above would be added in the same way the customized project-centric questions are added15:43
dhellmanndo we have a question asking which tool they use? I still have this theory that a lot of the upgrade pain is caused by using home-grown tools and I would like to either verify or dispense it15:44
dhellmannhome-grown or heavily customized15:44
ttxdhellmann: there is a question about which project people use to deploy/ maintain lifecycle yes... but it's generally giving confusing results15:44
fungiwe've had questions about choice of deployment and lifecycle management tooling in the past15:44
ttxsince there are lots of overlap15:44
ttxLike people would check "Ansible" and "Kolla-Ansible"15:45
smcginnisDeployment tool questions have been brought up at the last few ops meetups.15:45
ttxor "Puppet" And "Debian"15:45
smcginnisThat would be a good one to collect from a wider group.15:45
dhellmannok so they're choosing the tool and the source of packages15:45
ttxso the question is hard to formulate simply15:45
mugsieyeah - and the questions in previous years were missing projects, or had projects twice15:45
ttxmugsie: right15:45
dhellmannis that something we can help with? rewording the question/answers?15:45
smcginnisBut +1 for the currently proposed questions. That would be great to get that data.15:45
ttxI can ask about potential changes to that question yes15:46
mugsieI think the OSA PTL was going to reach out to the foundation to help word the querstion15:46
jrollthere's also companies using multiple tools - rackspace public cloud used (uses?) ansible to orchestrate puppet-masterless (but neither were upstream openstack ansible/chef tooling)15:46
ttxone issue being that they prefer not changing "common " questions so that they can compare results over time15:46
dhellmannI realize it will make it harder to do historical comparisons, but if the answers we have aren't useful I don't think comparing new answers to them will be either15:46
mugsiedhellmann: ++15:46
ttxThanks for the quick feedback15:46
dhellmannjroll : I think we should have a question that asks which community project people are using (not listing "ansible" as a separate thing) and then include the project and "a customized version of $project" as answers15:47
dhellmannand anything that isn't a community project is "other"15:47
dhellmannbecause what I want to learn about is whether people are finding the need to heavily customize their deployment tools and then making upgrades harder15:47
dhellmannor if they're building their own some other way15:47
jrolldhellmann: I agree that would answer the question of custom vs not15:48
dhellmannso we shouldn't say "puppet" we should say "openstack puppet"15:48
jrollif that's the only question we want to answer, +100015:48
dhellmannI don't really care if they're using saltstack to write their own thing, I just care they're writing their own thing.15:48
jrollI guess it still answers the popularity question too15:48
dhellmannif we *do* care what they're writing it in, we can list the answer as "I wrote my own using X" for lots of values of X15:49
persiadhellmann: Separating can be tricky in cases like Debian, where the team used to be an OpenStack team, and then decided they wanted to be under Debian governance, so left, but are mostly the same folk, and do many of the same things.15:49
dhellmannor just have "I wrote my own" with a fill-in-the-blank15:49
dhellmannpersia : Debian isn't a deployment tool, it's a source of packages.15:49
dhellmannand that's a different question15:50
mugsiewell, they do use debconf, to try and wire things together, right?15:50
jrollyes, AIUI15:50
persiadhellmann: Except when I set up automatic preseeded install based on DHCP, which triggers metapackages (in Debian) to install, configure, and bring up all the components.15:50
dhellmannok, well, then that needs an answer that clearly differentiates from using the packages and deploying configured systems with debian tools15:50
* persia believes the "custom" part of that is about 3 lines of DHCP configuration15:51
persiaAnd that *is* using the packages and deploying configured systems with Debian tools :)15:51
dhellmannbasically we need to think more carefully about what we're trying to learn and ensure that the questions are phrased to help us get answers that teach us what we use15:52
dhellmann*what we want15:52
persiaYes :)15:52
dhellmannttx: do we need volunteers to work on that?15:53
ttxdhellmann: let me circle back with user survey team -- it might be too late to modify it for this round. I'll ask again if we can work to improve it15:55
*** dklyle has joined #openstack-tc15:55
fungidhellmann: yeah, in the case of the debian openstack packages, the intent is that they can be used as a means of configuration management too15:55
dhellmannyeah, I didn't realize that, and it does make the question more complicated15:56
ttxok, need to run15:56
* dhellmann needs to wander off, too15:56
fungisince at nistallation time the package management can prompt the operator for their configuration choices, or the operator can preseed answers to those questions to avoid being prompted interactively15:56
*** david-lyle has quit IRC15:57
fungithis is a big chunk of where the debian and ubuntu packaged services diverge, since ubuntu expects operators to bring their own configuration basically15:58
fungi(talking about the packaged openstack services on those two distros specifically, not indicating anything about each distro's general stance on service deployment)15:58
mugsiefungi: and in your personal capacity as well?16:00
fungiyes, these are my personal opinions and do not reflect the opinion of my employer, the openstack technical committee, nor the royal planetary government of neptune16:02
*** kumarmn has joined #openstack-tc16:20
*** jpich has quit IRC16:38
*** hongbin has quit IRC17:07
*** dklyle has quit IRC17:13
*** hongbin has joined #openstack-tc17:18
*** david-lyle has joined #openstack-tc17:18
*** harlowja has joined #openstack-tc17:21
*** diablo_rojo has joined #openstack-tc17:24
*** harlowja has quit IRC17:25
*** dtantsur is now known as dtantsur|afk18:06
*** david-lyle has quit IRC18:11
*** hongbin has quit IRC18:16
*** hongbin has joined #openstack-tc18:24
*** diablo_rojo has quit IRC18:24
*** harlowja has joined #openstack-tc18:29
*** david-lyle has joined #openstack-tc18:40
*** mriedem has quit IRC19:07
*** mriedem has joined #openstack-tc19:07
dmsimardI feel like I remember there was a discussion here about potentially colocating ops tracks or ops meetups with OpenStack days events. Maybe when we were discussing all the PTG vs Summit vs Ops summit things ?19:29
dmsimardIf my memory is correct, does anyone know who I should reach out to learn more about that ? I'm part of the committee for the next OpenStack days Canada event.19:29
smcginnisdmsimard: There was a ML thread about it. One sec, I can pull that up.19:38
dmsimardsmcginnis: thanks! I really just can't remember where I've seen that mentioned.19:39
smcginnisdmsimard: Took me a bit, it was actually in openstack-operators:
dmsimardsmcginnis: oh! That might be the one -- is Jimmy on IRC ?19:41
smcginnisI'm not seeing him right now, but he is around from time to time.19:42
smcginnisdmsimard: Any questions I can try to answer? I've been involved in that a bit from both sides.19:43
dmsimardsmcginnis: oh, mostly curious if we really wanted to make that a thing -- because we can19:44
dmsimardbut it has an impact on the venue, layout, tracks, etc19:44
dmsimardso we just need to know19:44
smcginnisdmsimard: Wait, are you asking for the idea of combining ops meetup with the PTG, or are you talking about trying to do something along with OpenStack Days events?19:46
dmsimardsmcginnis: specifically openstack days19:47
dmsimardsmcginnis: this part of the email:19:47
dmsimard* OpenStack Days - Having an Ops track at OpenStack Days in an effort to solicit feedback and open discussion from operators, especially those who might normally not attend other events. The goal here is to generate common operator issues and features, and also share best practices. The Public Cloud WG has been successfully pioneering this approach at several OpenStack Days last year.19:47
smcginnisdmsimard: I don't believe there is a plan for that at the moment, just combining with the PTG. But if this is the last PTG, I know that was another attractive option for some.19:47
smcginnisdmsimard: There is an ops meetup team meeting Tuesday's at 10am EST in #openstack-operators. If you want to start a discussion about a contingency plan if the PTG falls through, I am sure they would love to talk to you about it.19:49
smcginnisCanada would be a great place to hold one.19:49
smcginnisWell - let me qualify that - there are a lot of places in Canada that would be great to hold one.19:50
dmsimardsmcginnis: well -- is it really a plan B or contingency ? Or did we want to make that a regular occurrence despite the PTG/Summit/Ops meetup conclusion19:50
smcginnisdmsimard: It might be worth bringing up with them.19:50
dmsimardok so the openstack-operators meeting is the right place to bring that up then ?19:51
smcginnisI think the hope right now is that the combined event will work out well and it will continue to happen every 6 months.19:51
smcginnisdmsimard: Yeah, I think that would be best.19:51
smcginnisdmsimard: You could drop in and just mention it in the channel if that time doesn't work for you.19:51
smcginnisdmsimard: I think a lot of the same people are there most of the time.19:51
dmsimardyeah I already idle there.. alright, thanks for your help :)19:52
smcginnisdmsimard: Where/when is the next OSD Canada?19:52
* smcginnis switches windows19:52
*** eandersson has joined #openstack-tc19:53
dmsimardNot everything is written in stone yet but I can already tell you it'll be in Montreal and after both the summit and the PTG :)19:53
* cdent considers OSD Cornwall19:56
cdent(on the beach of course)19:56
smcginnisI second that motion.19:58
*** cdent has quit IRC20:09
persiaI have attended some OSDs with WG meeting space, which seemed to work well.  I would expect the same for SIG meeting space.  I think it would be bad for the Ops Meetups to have the Meetup colocated with an OSD event: the foci are too different.  Merging Ops Meetup and PTG would improve my life.20:49
smcginnisI could see them being follow-on events, with a day or two for OSD, and a couple days for the Ops Meetup.20:53
smcginnisBut that's more days to pay for space, coffee, etc.20:53
smcginnisIt does help attendees with travel, but not as much for event logistics.20:54
smcginnisI agree, trying to both simultaneously would probably be too distracting since most attendees of one would be interested in the activities of the other.20:54
*** diablo_rojo has joined #openstack-tc21:13
fungidmsimard: jimmy hangs out in some channels as jamesmacarthur but isn't always around21:15
smcginnisThanks fungi. He was in -dev so I pinged him there, but doesn't appear to be around.21:16
dmsimardIt's alright, no emergency -- thanks everyone for helping :)21:16
*** diablo_rojo has quit IRC21:24
*** kumarmn has quit IRC21:25
*** diablo_rojo has joined #openstack-tc21:35
*** annabelleB has joined #openstack-tc21:52
*** annabelleB has quit IRC22:18
*** diablo_rojo has quit IRC22:23
*** annabelleB has joined #openstack-tc22:37
*** lbragstad has quit IRC22:41
*** diablo_rojo has joined #openstack-tc22:53
*** hongbin has quit IRC23:05

Generated by 2.15.3 by Marius Gedminas - find it at!