| *** rosmaita has quit IRC | 00:35 | |
| *** diablo_rojo has quit IRC | 00:37 | |
| *** notmyname_ has joined #openstack-tc | 00:49 | |
| *** notmyname has quit IRC | 00:51 | |
| *** notmyname_ is now known as notmyname | 00:51 | |
| *** mriedem_away has quit IRC | 01:34 | |
| *** harlowja has quit IRC | 01:42 | |
| *** harlowja has joined #openstack-tc | 03:37 | |
| *** lbragstad has joined #openstack-tc | 03:42 | |
| *** lbragstad has quit IRC | 04:58 | |
| *** lbragstad has joined #openstack-tc | 05:01 | |
| *** lbragstad has quit IRC | 05:10 | |
| *** harlowja has quit IRC | 05:22 | |
| *** jpich has joined #openstack-tc | 07:40 | |
| *** cmurphy has quit IRC | 08:11 | |
| *** zaneb has quit IRC | 08:12 | |
| *** cmurphy has joined #openstack-tc | 08:13 | |
| *** zaneb has joined #openstack-tc | 08:14 | |
| *** melwitt has quit IRC | 08:26 | |
| *** cdent has joined #openstack-tc | 08:26 | |
| *** persia has quit IRC | 08:26 | |
| *** persia has joined #openstack-tc | 08:28 | |
| *** melwitt has joined #openstack-tc | 08:33 | |
| mugsie | zaneb: you had more restraint than I did :) | 08:33 |
|---|---|---|
| mugsie | or do | 08:33 |
| cdent | mornin' mugsie | 08:38 |
| mugsie | cdent: morning | 08:38 |
| *** dtantsur|afk is now known as dtantsur | 10:23 | |
| *** lbragstad has joined #openstack-tc | 11:53 | |
| *** rosmaita has joined #openstack-tc | 12:05 | |
| ttx | fungi: 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 in | 12:49 |
| ttx | hence my (personal) interest in that kolla/kolla-ansible/kolla-k8s/OSH discussion | 12:50 |
| *** mriedem has joined #openstack-tc | 12:57 | |
| persia | One 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 organisation | 13:09 |
| persia | reinforces the idea that a team is a valid social identity. | 13:09 |
| mugsie | persia: 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 |
| mugsie | it is like smokers form pseudo social groups within companies and conferences :) - it all about who you spend time with and talking to | 13:23 |
| persia | I 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 |
| cdent | I reckon the association of identity/socialness with project team is a large part of why we continue to talk about what openstack is | 13:27 |
| cdent | it is, however, inevitable because of the way we organized work and other activities | 13:29 |
| *** david-lyle has quit IRC | 13:30 | |
| openstackgerrit | Merged openstack/project-team-guide master: Update Stable policy for Extended Maintenance https://review.openstack.org/552733 | 13:31 |
| *** annabelleB has joined #openstack-tc | 13:53 | |
| *** hongbin has joined #openstack-tc | 13:54 | |
| *** annabelleB has quit IRC | 14:07 | |
| *** annabelleB has joined #openstack-tc | 14:22 | |
| *** annabelleB has quit IRC | 14:22 | |
| *** david-lyle has joined #openstack-tc | 14:40 | |
| * dhellmann looks around and checks the clock | 14:59 | |
| fungi | it's about that time | 14:59 |
| cdent | almost | 14:59 |
| dhellmann | tc-members: office hours | 14:59 |
| fungi | tc-members: (and anyone else) an hour of office awaits us all... | 14:59 |
| EmilienM | o/ | 15:00 |
| TheJulia | o/ | 15:00 |
| smcginnis | o/ | 15:00 |
| cmurphy | hiya | 15:00 |
| *** gagehugo has joined #openstack-tc | 15:00 | |
| * mugsie lurks | 15:01 | |
| cdent | Can anyone summarize the kolla discussions? | 15:01 |
| dtroyer_zz | o/ | 15:01 |
| * dhellmann is missing some scrollback | 15:01 | |
| ttx | ohai | 15:01 |
| ttx | kolla discussion -- still collecting a rather wide feedback | 15:02 |
| fungi | it 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 there | 15:02 |
| dhellmann | it 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 |
| ttx | yes, moving target at that point | 15:02 |
| ttx | dhellmann: 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 line | 15:03 |
| dhellmann | yes, well | 15:03 |
| ttx | right | 15:03 |
| fungi | http://lists.openstack.org/pipermail/openstack-dev/2018-April/129088.html On moving start scripts out of Kolla images | 15:03 |
| fungi | is the new thread | 15:03 |
| dhellmann | was the original change about kolla-kubernetes abandoned? | 15:04 |
| ttx | I still think it builds a superstructure not adapted to the technical need for reasons that are ultimately branding reasons | 15:04 |
| dhellmann | the governance patch, that is | 15:04 |
| fungi | no, it's still getting new messages | 15:04 |
| fungi | at least as recently as yesterday | 15:04 |
| dhellmann | oh, found it | 15:04 |
| dhellmann | https://review.openstack.org/#/c/552531/ | 15:04 |
| fungi | oh, original change. i thought you said original thread | 15:04 |
| dhellmann | it 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 up | 15:04 |
| dhellmann | does anyone have insight into that? | 15:05 |
| fungi | well, change 552531 was proposed by the current kolla ptl | 15:05 |
| ttx | So 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 on | 15:05 |
| ttx | dhellmann: originally it was more a recognition that the kolla and k-ansible team have nothing to do with k-k8s | 15:05 |
| mugsie | dhellmann: I *think* it was kolla wanting to divest itself of kolla-kubernetes | 15:05 |
| dhellmann | fungi : ah, yes, I should have looked at that, thsnks | 15:06 |
| ttx | and therefore split them out and let it live or die in a different corner | 15:06 |
| dhellmann | aha, ok | 15:06 |
| ttx | but sice then k-k8s people have chimed in | 15:06 |
| dhellmann | in favor, or opposed? | 15:06 |
| dhellmann | sorry, I should probably just go read all of this more closely. personal distractions have prevented that this week. | 15:07 |
| ttx | well, some suggesting an OSH merge, and some pointing to the root cause | 15:07 |
| ttx | it's fine we can't all read everything | 15:07 |
| fungi | the 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 IRC | 15:08 | |
| ttx | actually I think for omplex issues like this having someone dedicvated to following up and summarizing is a good thing [tm] | 15:08 |
| dhellmann | ttx: yes, I think that's a good approach for us to take in general | 15:08 |
| dhellmann | even the not complex things can use someone to stay on top of them | 15:08 |
| ttx | fungi: I think there were variants, but I may have read affiliations incorrectly | 15:09 |
| fungi | oh, perhaps | 15:09 |
| ttx | anyway, I think it's still too early to make a call | 15:09 |
| dhellmann | it appears there is already a separate kolla-kubernetes team in gerrit, though I haven't looked at the membership cross-over with kolla-core | 15:09 |
| cdent | ttx: in your mind what is it that a call is being made on? | 15:09 |
| dhellmann | https://review.openstack.org/#/admin/groups/1380,members | 15:10 |
| ttx | I 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 calls | 15:10 |
| dhellmann | right, that's what we've tried to have all of the other teams do | 15:10 |
| dhellmann | and what we wanted kolla to do from the start | 15:10 |
| ttx | It's the only way to have sane governance | 15:10 |
| fungi | in particular i was recalling the reply from rich wellum: http://lists.openstack.org/pipermail/openstack-dev/2018-March/128892.html | 15:10 |
| ttx | 1/ aligned with constituency and 2/ only at levels where decisions are actually needed | 15:11 |
| dhellmann | I 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 own | 15:11 |
| mugsie | from 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 |
| ttx | yes, the neutron situation is more a trade-off. it's not perfect but the best so far | 15:11 |
| dhellmann | and I have sympathy for a PTL who is left "managing" a deliverable that isn't actually actively developed/maintained | 15:11 |
| mugsie | I 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 images | 15:12 |
| ttx | dhellmann: 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 that | 15:12 |
| mugsie | but that seems to be incompatible with some members of kolla's long term visions of what they want to produce | 15:13 |
| ttx | cdent: approving one of the team restructuration option | 15:13 |
| dhellmann | ttx: sure. we might be talking about whether the *tc* wanted to drop an inactive team | 15:13 |
| dhellmann | mugsie : 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 |
| mugsie | ttx: 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 project | 15:15 |
| ttx | mugsie: i think it's our role to ensure sane governance yes | 15:16 |
| dhellmann | mugsie : it could run that way. the question is whether the team actually wants to do that. it sounds like we're still mediating that discussion | 15:16 |
| mugsie | mlavelle doesn't have a day to day PTL role on things like LBaaS / FWaaS - that is ran by someone else | 15:16 |
| fungi | i don't think any members of the tc were pushing for them to retire kolla-k8s, at least not that i saw | 15:16 |
| ttx | Like one might argue that kolla-k8s contributors are not in control of their deliverable, with a PTL elected by a completely disjoint and larger group | 15:16 |
| mugsie | fungi: no, I think that was just people from within kolla | 15:17 |
| ttx | hence breaking one of the 4 opens | 15:17 |
| fungi | it 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 coupling | 15:17 |
| dhellmann | alternatives? | 15:17 |
| fungi | as in the kolla team could take a critical eye to their current approach | 15:18 |
| dhellmann | if 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 use | 15:19 |
| fungi | right, i completely agree on that point | 15:19 |
| *** kumarmn has joined #openstack-tc | 15:19 | |
| mugsie | dhellmann: ++ | 15:19 |
| fungi | but 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 of | 15:19 |
| dhellmann | and other teams need to take a hard long look at whether the claim is accurate or not | 15:20 |
| fungi | my point in http://lists.openstack.org/pipermail/openstack-dev/2018-March/128943.html is that it's hard for one group to serve two masters | 15:21 |
| fungi | either they're producing a deployment solution with images as a byproduct, or they're producing images with an example deployment system as a byproduct | 15:21 |
| dhellmann | or they're producing images that are independent of the deployment tool | 15:22 |
| dhellmann | though, not having done it myself, I wonder how practical that really is | 15:22 |
| fungi | which it sounds like others in the thread have been claiming is not the case | 15:22 |
| ttx | dhellmann: did you want to discuss the lower-bounds-testing tag ? | 15:23 |
| dhellmann | is 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 min | 15:23 | |
| fungi | loci is a separate project/team from osh as far as i know | 15:23 |
| jroll | dhellmann: it's very practical, dockerhub operates around this assumption imo (people use their tool of choice to deploy these public images) | 15:23 |
| dhellmann | ttx: 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 |
| ttx | Yes LOCI is more of an alternate approach to Kolla-the-base-stuff | 15:23 |
| fungi | anyway, i like pbourke's proposal to have k-ansible support loci images in addition to kolla images | 15:24 |
| dhellmann | jroll : that was my assumption. I wonder what all the fuss over the kolla images is, then. | 15:24 |
| dhellmann | I'm not sure I understand the point of that, fungi. what makes that attractive? | 15:24 |
| ttx | dhellmann: my main question is whether we should not just consider it a madatory part of suing requirements | 15:24 |
| ttx | err using | 15:24 |
| jroll | dhellmann: the new thread highlights the problems that make it impractical for others to use kolla images with a different deployment system http://lists.openstack.org/pipermail/openstack-dev/2018-April/129088.html | 15:24 |
| ttx | dhellmann: do you expect only some projects to adopt lower-bounds-testing? | 15:25 |
| smcginnis | ttx: That would be my preference - once we get everyone to that point. | 15:25 |
| dhellmann | ok, I'll put that on my queue for next week | 15:25 |
| dhellmann | ttx: it has been more popular than I expected, but I wasn't prepared to say it was a requirement. | 15:25 |
| jroll | tl;dr kolla does image configuration very differently than everyone else does image configuration | 15:25 |
| ttx | It feels like goal material to me, if it's not too complex | 15:25 |
| dhellmann | fwiw, 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 projects | 15:25 |
| jroll | (the config.json "stable api" thing, instead of environment variables or bind-mounting a config volume) | 15:26 |
| dhellmann | ttx: it takes 1 patch and is quite easy to set up. I've submitted patches to all of the projects that were syncing requirements already | 15:26 |
| dhellmann | so the goal is really "make patch X work and approve it" | 15:26 |
| dhellmann | they don't even have to write the patches | 15:26 |
| fungi | dhellmann: 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 deliverables | 15:26 |
| dhellmann | fungi : very good point, I had not looked at it that way | 15:27 |
| fungi | based 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 repo | 15:27 |
| dhellmann | hmm, that's unfortunate | 15:28 |
| cdent | I think it is slightly more complex than that fungi, but close enough | 15:28 |
| fungi | though that also seems to be hotly debated in the meeting as to what constitutes an "api" for images | 15:28 |
| clarkb | dhellmann: 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 IRC | 15:29 | |
| cdent | I think the underlying fault(?) here is that kolla has it's own api rather than using one that is common to the container world | 15:29 |
| cdent | its | 15:29 |
| dhellmann | clarkb : 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 |
| jroll | cdent: that also appears to be the wedge, to me | 15:29 |
| ttx | dhellmann: ok then I'd rather implement it where we can in R and make it a community goal for stragglers in S | 15:30 |
| dhellmann | clarkb : 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 list | 15:30 |
| fungi | clarkb: it's the lower-constraints.txt which is not global | 15:30 |
| clarkb | dhellmann: ah ok so maybe separate venvs is potentially viable (though not also working today) | 15:30 |
| dhellmann | ttx: I'm OK with that approach. | 15:30 |
| ttx | and then consider it part of the requirements policy and be done with it | 15:30 |
| dhellmann | clarkb : separate venvs should work, but one is probably easier | 15:30 |
| clarkb | dhellmann: ya to start one definitely seems easier at least to hack into devstack | 15:30 |
| clarkb | some thought separate venvs may be easier because devstack almost has support for it | 15:31 |
| dhellmann | oh, that could be | 15:31 |
| clarkb | but adding support for the things it doesn't yet support likely to be more work than global venv to start | 15:31 |
| clarkb | (especially with plugins) | 15:31 |
| dhellmann | although using 1 should just need to be a change to where we call pip to point to the right path | 15:31 |
| clarkb | dhellmann: yup thats basically what my current hack is doing | 15:31 |
| dhellmann | cool | 15:31 |
| clarkb | change 558930 if you are curious | 15:31 |
| clarkb | (needs a lot of cleanup, but its getting there) | 15:32 |
| clarkb | also yay pip10 | 15:32 |
| * dhellmann stars 558930 | 15:32 | |
| ttx | On 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 |
| dhellmann | ttx: your points summarize my concerns nicely | 15:33 |
| *** openstackgerrit has quit IRC | 15:34 | |
| dhellmann | though for point 1 I would also mention that it's an issue of the team's scope | 15:34 |
| * TheJulia has been mentally derailed by an in-person meeting :( | 15:34 | |
| ttx | Oh, I had an important question | 15:40 |
| ttx | In the release cycles discussion at the PTG we pointed to the need for better data about consumption models | 15:40 |
| ttx | and said we could try to add a question for that in the user survey | 15:41 |
| ttx | Here is what I came up with: | 15:41 |
| ttx | a question around upgrade pattern, something like: | 15:41 |
| ttx | How do you upgrade your version of OpenStack: | 15:41 |
| ttx | - Tracking HEAD of master | 15:41 |
| ttx | - Tracking intermediary releases | 15:41 |
| ttx | - Upgrade all coordinated releases (once every 6 month) | 15:41 |
| ttx | - Skipping/fast-forwarding releases | 15:41 |
| ttx | - Not upgrading | 15:41 |
| ttx | And another about stable consumption patterns, like: | 15:41 |
| ttx | Once on a given release, do you use stable branches for bugfix upgrades: | 15:41 |
| ttx | - Yes, upgrading at various points in time depending on fixes | 15:41 |
| ttx | - Yes, backporting specific fixes | 15:41 |
| ttx | - Yes, using only official point releases | 15:41 |
| dhellmann | I am also interested in knowing which tools people are using and if they are customizing community tools | 15:42 |
| ttx | - I do not do bugfix upgrades | 15:42 |
| ttx | I feel like that would give us better data than just asking what release version people are using | 15:42 |
| dhellmann | it would be good to ask the version question, too, but I agree that this extra detail will help | 15:42 |
| dhellmann | knowing that someone is tracking official releases of newton, for example | 15:42 |
| cdent | yes, to having version and ttx's questions | 15:42 |
| ttx | dhellmann: The version question is a classic user survey questionm so we'll have that | 15:42 |
| jroll | ttx: for the second, maybe add "Yes, tracking HEAD of the stable/branch" (IOW, deploying every commit) | 15:42 |
| dhellmann | ok, good | 15:43 |
| ttx | The 2 questions above would be added in the same way the customized project-centric questions are added | 15:43 |
| dhellmann | do 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 it | 15:44 |
| dhellmann | home-grown or heavily customized | 15:44 |
| ttx | dhellmann: there is a question about which project people use to deploy/ maintain lifecycle yes... but it's generally giving confusing results | 15:44 |
| fungi | we've had questions about choice of deployment and lifecycle management tooling in the past | 15:44 |
| ttx | since there are lots of overlap | 15:44 |
| ttx | Like people would check "Ansible" and "Kolla-Ansible" | 15:45 |
| smcginnis | Deployment tool questions have been brought up at the last few ops meetups. | 15:45 |
| ttx | or "Puppet" And "Debian" | 15:45 |
| smcginnis | That would be a good one to collect from a wider group. | 15:45 |
| dhellmann | ok so they're choosing the tool and the source of packages | 15:45 |
| ttx | so the question is hard to formulate simply | 15:45 |
| mugsie | yeah - and the questions in previous years were missing projects, or had projects twice | 15:45 |
| ttx | mugsie: right | 15:45 |
| dhellmann | is that something we can help with? rewording the question/answers? | 15:45 |
| smcginnis | But +1 for the currently proposed questions. That would be great to get that data. | 15:45 |
| ttx | I can ask about potential changes to that question yes | 15:46 |
| mugsie | I think the OSA PTL was going to reach out to the foundation to help word the querstion | 15:46 |
| jroll | there'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 |
| ttx | one issue being that they prefer not changing "common " questions so that they can compare results over time | 15:46 |
| dhellmann | I 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 either | 15:46 |
| mugsie | dhellmann: ++ | 15:46 |
| ttx | Thanks for the quick feedback | 15:46 |
| dhellmann | jroll : 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 answers | 15:47 |
| dhellmann | and anything that isn't a community project is "other" | 15:47 |
| dhellmann | because what I want to learn about is whether people are finding the need to heavily customize their deployment tools and then making upgrades harder | 15:47 |
| dhellmann | or if they're building their own some other way | 15:47 |
| jroll | dhellmann: I agree that would answer the question of custom vs not | 15:48 |
| dhellmann | so we shouldn't say "puppet" we should say "openstack puppet" | 15:48 |
| dhellmann | etc. | 15:48 |
| jroll | if that's the only question we want to answer, +1000 | 15:48 |
| dhellmann | I 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 |
| jroll | I guess it still answers the popularity question too | 15:48 |
| jroll | yep | 15:48 |
| dhellmann | if 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 X | 15:49 |
| persia | dhellmann: 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 |
| dhellmann | or just have "I wrote my own" with a fill-in-the-blank | 15:49 |
| dhellmann | persia : Debian isn't a deployment tool, it's a source of packages. | 15:49 |
| dhellmann | and that's a different question | 15:50 |
| mugsie | well, they do use debconf, to try and wire things together, right? | 15:50 |
| jroll | yes, AIUI | 15:50 |
| persia | dhellmann: 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 |
| dhellmann | ok, well, then that needs an answer that clearly differentiates from using the packages and deploying configured systems with debian tools | 15:50 |
| * persia believes the "custom" part of that is about 3 lines of DHCP configuration | 15:51 | |
| persia | And that *is* using the packages and deploying configured systems with Debian tools :) | 15:51 |
| dhellmann | basically 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 use | 15:52 |
| dhellmann | *what we want | 15:52 |
| persia | Yes :) | 15:52 |
| dhellmann | ttx: do we need volunteers to work on that? | 15:53 |
| ttx | dhellmann: 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 it | 15:55 |
| *** dklyle has joined #openstack-tc | 15:55 | |
| dhellmann | ok | 15:55 |
| fungi | dhellmann: yeah, in the case of the debian openstack packages, the intent is that they can be used as a means of configuration management too | 15:55 |
| dhellmann | yeah, I didn't realize that, and it does make the question more complicated | 15:56 |
| ttx | ok, need to run | 15:56 |
| ttx | cheers! | 15:56 |
| * dhellmann needs to wander off, too | 15:56 | |
| fungi | since 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 interactively | 15:56 |
| *** david-lyle has quit IRC | 15:57 | |
| fungi | this is a big chunk of where the debian and ubuntu packaged services diverge, since ubuntu expects operators to bring their own configuration basically | 15: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 |
| mugsie | fungi: and in your personal capacity as well? | 16:00 |
| fungi | yes, these are my personal opinions and do not reflect the opinion of my employer, the openstack technical committee, nor the royal planetary government of neptune | 16:02 |
| mugsie | :) | 16:02 |
| *** kumarmn has joined #openstack-tc | 16:20 | |
| *** jpich has quit IRC | 16:38 | |
| *** hongbin has quit IRC | 17:07 | |
| *** dklyle has quit IRC | 17:13 | |
| *** hongbin has joined #openstack-tc | 17:18 | |
| *** david-lyle has joined #openstack-tc | 17:18 | |
| *** harlowja has joined #openstack-tc | 17:21 | |
| *** diablo_rojo has joined #openstack-tc | 17:24 | |
| *** harlowja has quit IRC | 17:25 | |
| *** dtantsur is now known as dtantsur|afk | 18:06 | |
| *** david-lyle has quit IRC | 18:11 | |
| *** hongbin has quit IRC | 18:16 | |
| *** hongbin has joined #openstack-tc | 18:24 | |
| *** diablo_rojo has quit IRC | 18:24 | |
| *** harlowja has joined #openstack-tc | 18:29 | |
| *** david-lyle has joined #openstack-tc | 18:40 | |
| *** mriedem has quit IRC | 19:07 | |
| *** mriedem has joined #openstack-tc | 19:07 | |
| dmsimard | I 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 |
| dmsimard | If 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 |
| smcginnis | dmsimard: There was a ML thread about it. One sec, I can pull that up. | 19:38 |
| dmsimard | smcginnis: thanks! I really just can't remember where I've seen that mentioned. | 19:39 |
| smcginnis | dmsimard: Took me a bit, it was actually in openstack-operators: http://lists.openstack.org/pipermail/openstack-operators/2018-March/014994.html | 19:40 |
| dmsimard | smcginnis: oh! That might be the one -- is Jimmy on IRC ? | 19:41 |
| smcginnis | I'm not seeing him right now, but he is around from time to time. | 19:42 |
| smcginnis | dmsimard: Any questions I can try to answer? I've been involved in that a bit from both sides. | 19:43 |
| dmsimard | smcginnis: oh, mostly curious if we really wanted to make that a thing -- because we can | 19:44 |
| dmsimard | but it has an impact on the venue, layout, tracks, etc | 19:44 |
| dmsimard | so we just need to know | 19:44 |
| smcginnis | dmsimard: 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 |
| dmsimard | smcginnis: specifically openstack days | 19:47 |
| dmsimard | smcginnis: 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 |
| smcginnis | dmsimard: 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 |
| smcginnis | dmsimard: 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 |
| smcginnis | Canada would be a great place to hold one. | 19:49 |
| smcginnis | Well - let me qualify that - there are a lot of places in Canada that would be great to hold one. | 19:50 |
| smcginnis | :) | 19:50 |
| dmsimard | smcginnis: 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 conclusion | 19:50 |
| smcginnis | dmsimard: It might be worth bringing up with them. | 19:50 |
| dmsimard | ok so the openstack-operators meeting is the right place to bring that up then ? | 19:51 |
| smcginnis | I 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 |
| smcginnis | dmsimard: Yeah, I think that would be best. | 19:51 |
| smcginnis | dmsimard: You could drop in and just mention it in the channel if that time doesn't work for you. | 19:51 |
| smcginnis | dmsimard: I think a lot of the same people are there most of the time. | 19:51 |
| dmsimard | yeah I already idle there.. alright, thanks for your help :) | 19:52 |
| smcginnis | dmsimard: Where/when is the next OSD Canada? | 19:52 |
| * smcginnis switches windows | 19:52 | |
| *** eandersson has joined #openstack-tc | 19:53 | |
| dmsimard | Not 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 Cornwall | 19:56 | |
| cdent | (on the beach of course) | 19:56 |
| smcginnis | I second that motion. | 19:58 |
| *** cdent has quit IRC | 20:09 | |
| persia | I 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 |
| smcginnis | I could see them being follow-on events, with a day or two for OSD, and a couple days for the Ops Meetup. | 20:53 |
| smcginnis | But that's more days to pay for space, coffee, etc. | 20:53 |
| smcginnis | It does help attendees with travel, but not as much for event logistics. | 20:54 |
| smcginnis | I 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-tc | 21:13 | |
| fungi | dmsimard: jimmy hangs out in some channels as jamesmacarthur but isn't always around | 21:15 |
| smcginnis | Thanks fungi. He was in -dev so I pinged him there, but doesn't appear to be around. | 21:16 |
| dmsimard | It's alright, no emergency -- thanks everyone for helping :) | 21:16 |
| *** diablo_rojo has quit IRC | 21:24 | |
| *** kumarmn has quit IRC | 21:25 | |
| *** diablo_rojo has joined #openstack-tc | 21:35 | |
| *** annabelleB has joined #openstack-tc | 21:52 | |
| *** annabelleB has quit IRC | 22:18 | |
| *** diablo_rojo has quit IRC | 22:23 | |
| *** annabelleB has joined #openstack-tc | 22:37 | |
| *** lbragstad has quit IRC | 22:41 | |
| *** diablo_rojo has joined #openstack-tc | 22:53 | |
| *** hongbin has quit IRC | 23:05 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!