| *** zaneb has quit IRC | 00:55 | |
| *** zaneb has joined #openstack-tc | 01:01 | |
| *** ianychoi has quit IRC | 01:20 | |
| *** ricolin has joined #openstack-tc | 03:12 | |
| *** ricolin has quit IRC | 04:03 | |
| *** zaneb has quit IRC | 04:11 | |
| *** zaneb has joined #openstack-tc | 04:11 | |
| *** mriedem_away has quit IRC | 04:15 | |
| *** jamesmcarthur has joined #openstack-tc | 04:31 | |
| *** jamesmcarthur has quit IRC | 05:18 | |
| *** jamesmcarthur has joined #openstack-tc | 05:18 | |
| *** jamesmcarthur has quit IRC | 05:23 | |
| *** jamesmcarthur has joined #openstack-tc | 05:50 | |
| *** Luzi has joined #openstack-tc | 06:49 | |
| *** jamesmcarthur has quit IRC | 06:50 | |
| *** e0ne has joined #openstack-tc | 07:10 | |
| *** e0ne has quit IRC | 07:12 | |
| *** e0ne has joined #openstack-tc | 07:13 | |
| *** e0ne has quit IRC | 07:14 | |
| *** e0ne has joined #openstack-tc | 07:15 | |
| *** e0ne has quit IRC | 07:17 | |
| *** tosky has joined #openstack-tc | 07:58 | |
| evrardjp | o/ | 07:58 |
|---|---|---|
| gmann | TC Office hour started.. | 09:00 |
| evrardjp | Let's see how many ppl will show up | 09:03 |
| evrardjp | Do you think we should drop the office hours between 25th december and 1 January? | 09:04 |
| evrardjp | (Including those dates) | 09:04 |
| lbragstad | o/ | 09:05 |
| gmann | humm, not sure. I will be on vacation i think but if we have other TC members available (you in this TZ :)) then we can continue | 09:05 |
| *** eumel8 has joined #openstack-tc | 09:05 | |
| *** jpich has joined #openstack-tc | 09:09 | |
| ttx | I'm around | 09:10 |
| eumel8 | good morning | 09:11 |
| ttx | Yes I think it's safe to assume nobody will attend those hours then | 09:11 |
| ttx | eumel8: Hi! | 09:11 |
| * ttx briefly goes to caffeinate himself | 09:11 | |
| eumel8 | ttx: question regarding Extra-ATC deadline. I couldn't found any timespan in the release plan. Is this still coming? I would expect the deadline in January 2019 | 09:13 |
| ttx | yes, let me see | 09:16 |
| eumel8 | k | 09:16 |
| gmann | yeah, it seems January 2019 | 09:17 |
| ttx | It's not a release thing, it's set ahead of PTL elections | 09:18 |
| ttx | So in Rocky it was set two seeks before self-nomination deadline | 09:18 |
| ttx | So I would not expect that to happen before... March? | 09:19 |
| eumel8 | ok. last info for me was after TC election which is still over | 09:19 |
| ttx | We'd have to ask election officials for the schedule | 09:19 |
| ttx | Extra-ATCs can be provided any time. We just freeze them before PTL elections so that we know how to generate election rolls | 09:20 |
| eumel8 | mhm, I missed the deadline in last cycle so I would like to take a markup in my calendar ;) | 09:21 |
| gmann | many of them listed to expire in Jan - https://github.com/openstack/governance/blob/79772433e12dd8cd8db3005f08442350005c3aac/reference/projects.yaml#L705 | 09:22 |
| eumel8 | yeah, exactly, then I would propose the new one in January | 09:23 |
| ttx | eumel8: let me try to guesstimate | 09:23 |
| ttx | PTl elections should happen on or before R-3 week, which is March 18 | 09:23 |
| ttx | which means nomination is likely to be closed by March 11, and Extra-ATC need to be refreshed before Feb 28 | 09:24 |
| ttx | (assuming election officials propose the same style of election calendar as last time) | 09:25 |
| ttx | So my guesstimate would be that extra ATCs need to be refreshed before Feb 28 | 09:26 |
| ttx | One issue is that this cycle being longer, there might be a gap between January when a bunch of entries expire and february when you need to refresh them at the latest | 09:26 |
| ttx | so it might be a good idea to to an interim refresh | 09:27 |
| ttx | (nowish) | 09:27 |
| eumel8 | ok, that sounds good | 09:27 |
| ttx | We'll ask the election officials to propose a schedule ASAP | 09:27 |
| eumel8 | ttx: ok, thx | 09:28 |
| ttx | but it should roughly be around the dates I guesstimated | 09:28 |
| eumel8 | ok | 09:28 |
| ttx | persia, tonyb, fungi: see ^ | 09:29 |
| tonyb[m] | no problem | 09:31 |
| ttx | Also with release being close to summit again starting with Stein, TC/PTL elections will happen around the same time instead of being staggered | 09:31 |
| ttx | so this might trigger interesting discussions :) | 09:31 |
| tonyb[m] | I'll send something to the officials tomorrow and get it to the TC soon after that | 09:31 |
| ttx | It's not hyper-urgent, but it would be good to have the dates on the schedule, so that eumel8 and others know when things hit | 09:32 |
| ttx | eumel8: thanks for raising that question ! | 09:32 |
| eumel8 | ttx: thanks for catching up :) | 09:33 |
| * lbragstad was under the assumption PTL elections would be a little earlier than the summit | 09:36 | |
| ttx | lbragstad: the charter ties PTL elections to releases, so that the new PTL hits at the start of the next cycle | 09:37 |
| lbragstad | yeah - thinking about it that way makes sense | 09:37 |
| ttx | (while the TC elections are tied to summits, which was a way to stagger them a bit when summits happened mid-cycle) | 09:37 |
| gmann | but we need to consider PTG also with summit which i think make sense to have new PTL | 09:38 |
| ttx | yes, PTGs were also tied to start-of-cycle | 09:38 |
| lbragstad | gmann yeah - exactly | 09:38 |
| ttx | (which is why Summits+PTG are back to being tied to start-of-cycle) | 09:39 |
| *** ifat_afek has joined #openstack-tc | 09:46 | |
| Luzi | hi, i would like to ask, if there is a possibility to develop a workflow for cross-project-contributions? | 09:46 |
| Luzi | I think this belongs here, because it can affect all projects and there is definitly a need for it. | 09:47 |
| lbragstad | hi Luzi - is there a specific example you're thinking of? | 09:47 |
| Luzi | I am part of the tem trying to contribute image encryption | 09:48 |
| lbragstad | got it - there is the community goal process, but that's usually suited for things spanning across nearly all OpenStack projects | 09:49 |
| Luzi | i know | 09:50 |
| lbragstad | i assume image encryption isn't that broad? | 09:50 |
| Luzi | and i don't want help for contributing image encryption | 09:50 |
| Luzi | my problem is a more general one | 09:50 |
| lbragstad | more so - how to get things done effectively between multiple OpenStack components, then? | 09:51 |
| ttx | Luzi: we used to have cross-project specs, but that added a bit of boilerplate process that ended up hurting more than it helped | 09:51 |
| gmann | is it when 2-3 or few projects involved ? | 09:51 |
| Luzi | eyactly | 09:51 |
| Luzi | ttx, i don't want them to come back :) | 09:51 |
| ttx | In the past we've seen pop-up teams or temporary SIGs set up to coordinate the effort and publicize its existence | 09:52 |
| lbragstad | ^ | 09:52 |
| lbragstad | we've used that with keystone + horizon a few times to close the gap on several things | 09:52 |
| ttx | Like the nova-cinder pop-up team to get multiattach | 09:52 |
| gmann | yeah | 09:52 |
| lbragstad | yeah - that's another good example | 09:52 |
| ttx | or the nova-neutron one to get get-me-a-network in | 09:52 |
| Luzi | yeah and that's quite temporary and nothing people could rely on in the future | 09:52 |
| lbragstad | we used it for rehashing the direction for RBAC and policy, too | 09:52 |
| cmurphy | this was discussed in berlin https://etherpad.openstack.org/p/expose-sigs-and-wgs | 09:53 |
| gmann | and there are always required cross projects discussion during PTG/summit for such interaction | 09:53 |
| ttx | Luzi: my understanding is that it would be for a temporary effort, not a permanent team? | 09:53 |
| gmann | cmurphy: thanks. yeah that was i was searching for | 09:53 |
| gmann | ttx: same for me | 09:54 |
| Luzi | well image encryption as an example would involve mainly nova and cinder, glance for storing, maybe oslo for a library, osc, and in the future maybe ironic | 09:54 |
| ttx | Personally I like the idea of keeping it lightweight and organic, and just support pop-up teams that spring up naturally | 09:54 |
| ttx | rather than add extra process layers of registering efforts and asking the TC to bless them | 09:54 |
| ttx | but I understand some are interested in getting some kind of validation | 09:55 |
| Luzi | cmurphy, i was there in berlin | 09:55 |
| Luzi | the biggest issue is the communication | 09:55 |
| Luzi | the missing one | 09:55 |
| cmurphy | ttx: i think it's not about validation but help with coordination | 09:55 |
| cmurphy | Luzi: exactly | 09:56 |
| ttx | cmurphy: a bit of both maybe | 09:56 |
| ttx | In the past people asked us to bless things as being in the right direction | 09:56 |
| gmann | spec in self-healing are good example for involved project coordination and listed documentation for communication etc | 09:57 |
| Luzi | i don't want to bother the tc - or ask anyone in here for help for this specific contribution | 09:57 |
| ttx | Luzi: Do you need a framework to fit in, some form of validation, or coordination help? | 09:57 |
| lbragstad | or do we need to find ways to communicate initiatives better? | 09:58 |
| ttx | I feel like it's the missing link between goals (fits in cycle) and SIGs (more permanent) | 09:58 |
| Luzi | a way to let people from involved project teams discuss a thing together would help i think | 09:58 |
| ttx | Luzi: you can definitely give the effort a name, use the ML, create IRC channels, book IRC meeting slots, get PTG space, etc. | 09:59 |
| Luzi | ttx, it was to late for the latter one, but i did all of the above | 10:00 |
| ttx | If it does not fit in goals nor SIGs, I would call that a "pop-up team" since it has the implication that it will be disbanded once its goals are achieved | 10:00 |
| Luzi | ttx, now we do not only have the plan to contribute image encryption | 10:01 |
| ttx | Luzi: do you ned anything more to create that space for discussion? | 10:01 |
| ttx | need* | 10:01 |
| gmann | Luzi: and what is issue you faced? not hear from involved project teams or disagreement from teams etc ? | 10:01 |
| Luzi | but also user centric key-managment, which would also be cross-project | 10:01 |
| ttx | In the end you'll always need involvement of people in project teams, if only to land the changes locally | 10:02 |
| *** ifat_afek has quit IRC | 10:03 | |
| ttx | so engaging there (advertising the effort in regular project team meetings) is also useful | 10:03 |
| Luzi | people from different teams naturally have different priorities, which might be the opposite of each other - but i cannot solve this problem between different teams, they can only find a compromise when they are talking with each other, and thats not happening | 10:03 |
| lbragstad | Luzi you said you booked irc meeting slots? | 10:04 |
| Luzi | i talked in every project meeting of the involved projects | 10:05 |
| ttx | right, the difficulty is to get them to talk /together/ | 10:06 |
| lbragstad | were you able to generate cross-project discussion? | 10:07 |
| ttx | i.e. join the popup team meeting | 10:07 |
| lbragstad | (e.g., finding someone from one project who was willing to go to another project meeting to talk about things with you) | 10:08 |
| Luzi | lbragstad, not really... | 10:08 |
| evrardjp | Luzi: it seems you have a few things you want to achieve: image encryption , key-management. They all fit into a problem space of yours,right? Are you alone in that problem space? | 10:09 |
| gmann | yeah or PTL at least can volunteer or assign someone to take part in that discussion. But again it will depends on technical agreement about idea in respective project | 10:09 |
| ttx | Thinking out loud... Maybe if pop-up teams like this had a TC sponsor to grease the wheels of cross-project engagement, we'd see better results ? Depends on who the TC sponsor is I guess | 10:09 |
| evrardjp | ttx: i guess too | 10:10 |
| Luzi | evrardjp, i am part of a team called secustack, we implemented this and other things, but we have to handle IP and NDAs, so we cannot dump our whole code-diff somewhere to be tested | 10:12 |
| *** e0ne has joined #openstack-tc | 10:12 | |
| cmurphy | mriedem said it a while back, having an ildiko-like-person who knows all the teams and people involved and can keep track of the state of things and make sure the right people are in meetings moving things forward seems to be what's needed | 10:12 |
| evrardjp | indeed | 10:13 |
| lbragstad | sounds like Luzi is already doing some of that | 10:13 |
| cmurphy | it sounds like Luzi needs help with that :) | 10:13 |
| evrardjp | that's what ttx just proposed? | 10:14 |
| cmurphy | yeah basically | 10:14 |
| ttx | yeah, execpt cmurphy says you don't HAVE TO be on the TC to do it | 10:14 |
| cmurphy | exactly | 10:15 |
| lbragstad | ++ | 10:15 |
| ttx | even if TC members are natural good candidates for this | 10:15 |
| Luzi | well that sounds like a plan at least :) | 10:15 |
| ttx | So what are the teams involved ? keystone, glance... | 10:15 |
| evrardjp | yeah that's fine, but let's help Luzi with something practicallt right here, shall we? | 10:15 |
| evrardjp | :D | 10:15 |
| ttx | cinder, nova, oslo? | 10:16 |
| lbragstad | "well image encryption as an example would involve mainly nova and cinder, glance for storing, maybe oslo for a library, osc, and in the future maybe ironic" | 10:16 |
| evrardjp | Luzi: was there some other projects for your first item of your bucklist? | 10:16 |
| Luzi | no, thats it | 10:16 |
| gmann | Luzi: any ML ref ? which can be helpful to carry forward the coordination | 10:17 |
| evrardjp | I guess you could start with a ML email with those projects in the topic? | 10:17 |
| evrardjp | gmann: :) | 10:18 |
| Luzi | and because of the glance spec freeze, we would like to focuse on this in the next cycle. So maybe it's better to wait until start of the next cycle | 10:18 |
| ttx | yeah, that would help narrow it down. Ideally the sponsor/champion/coordination helper would be personally interested in pushing that feature forward, so having a more complete description posted would help | 10:18 |
| gmann | Luzi: but it is always good to start the discussion well in advance and prepare the hjme work for PTG discussion room with all projects | 10:19 |
| ttx | I'd say the pop-up effort needs a clear name and a reference ML post | 10:19 |
| gmann | ttx: indeed | 10:20 |
| Luzi | http://lists.openstack.org/pipermail/openstack-dev/2018-September/135167.html | 10:20 |
| ttx | multi-attach, get-me-a-network all started with a clear code name that people can learn to recognize | 10:20 |
| Luzi | well we already came a little bit further, i can also link you the specs | 10:20 |
| Luzi | Glance spec for example: https://review.openstack.org/#/c/609667/ | 10:21 |
| ttx | encrypt-my-images | 10:22 |
| * ttx reads | 10:22 | |
| lbragstad | yeah - we don't really have a way to track the cross-project stuff, that usually up to the preference of the people coordinating the work | 10:23 |
| lbragstad | the public cloud WG for example uses launchpad to track items they care about, and how they affect multiple projects | 10:24 |
| evrardjp | lbragstad: storyboard? | 10:24 |
| lbragstad | (reading fungi's reply from that thread) | 10:24 |
| ttx | In-person contributor events like Forum and PTGs are also good places to gather critical mass of participants | 10:25 |
| gmann | true, i will say f2f discussion in forum/ptg are more productive at least for such integrated features. | 10:26 |
| Luzi | ttx, that's right, we just didn't know that at the point, for the berlin summit. but we actually tried to find a way for the needed library and so proposed a new oslo-library as well, after talking to many people | 10:27 |
| lbragstad | evrardjp they are on lp - https://bugs.launchpad.net/openstack-publiccloud-wg but just using that as an example that i don't think there is really a standard for what tool to use for tracking stuff in multiple projects | 10:27 |
| ttx | Luzi: thanks for that post, I had missed it. | 10:27 |
| ttx | I still think an update, referencing the pop-up team name posted to openstack-discuss would have value. Cross-project work, like any nascent team, needs some work advertising, and establishing the name helps | 10:28 |
| evrardjp | lbragstad: sorry. I meant that storyboard would be a good way to track this cross-project initiative | 10:29 |
| evrardjp | probably | 10:29 |
| ttx | maybe explictly ask for help coordinating, so that people can volunteer cycles to help you herd the cats | 10:29 |
| lbragstad | evrardjp ++ | 10:29 |
| Luzi | okay, so i will ask ildiko for a little help with setting up a pop-up team and write to the ML afterwards. | 10:31 |
| ttx | would be good to get her advice on how to trigger interest yes. i'm pretty sure she won't have free cycles to directly help on that effort though :) | 10:32 |
| ttx | ildikov: see discussion ^ | 10:33 |
| Luzi | ttx, i mainly need another workflow, which is more effective. :) | 10:34 |
| Luzi | thank you all for listening :) | 10:34 |
| gmann | i will say to catch the PTL of involved projects and ask for response/contact person etc and coordination can be from anyone involved in broader level of ideas like Luzi in this case | 10:34 |
| lbragstad | Luzi thanks for swinging by and asking questions | 10:35 |
| ttx | Luzi: it's hard anyway -- Conway's law is not helping us here. And even getting well-known community members to help coordinating is not resulting in people suddenly deciding to shift their review priorities and the list of meetings they decide to attend | 10:35 |
| ttx | Which is why we should do everything we can to facilitate that sort of work | 10:36 |
| *** cdent has joined #openstack-tc | 10:43 | |
| *** dtantsur|afk is now known as dtantsur | 11:18 | |
| *** ifat_afek has joined #openstack-tc | 11:29 | |
| *** jamesmcarthur has joined #openstack-tc | 12:42 | |
| fungi | wow, successful office hour? | 12:42 |
| *** jamesmcarthur has quit IRC | 12:46 | |
| *** e0ne has quit IRC | 12:47 | |
| fungi | Luzi: i'm caught up on scrollback now... you're saying you also need a user-facing mechanism for key management. does barbican not provide that? if not, what is it missing? | 12:51 |
| Luzi | fungi, our work is focused for users, who want to handle their kes by themself. | 12:59 |
| Luzi | that would mean, either controlling which secret in barbican should be used to encrypt resources or leave out Barbican at all | 12:59 |
| Luzi | fungi, that ML-post might explain it a little bit better: http://lists.openstack.org/pipermail/openstack-dev/2018-November/136270.html | 13:00 |
| fungi | thanks, i'll re-read that part | 13:01 |
| fungi | though based on the short description, i don't see why part of the mechanism there shouldn't be to specify the name of a barbican-managed secret | 13:02 |
| fungi | i do recall part of the concern though was users may want to provide a key at decryption (boot/mount) time which isn't persisted in memory once the volume is unlocked | 13:03 |
| fungi | at least not beyond the hypervisor host anyway | 13:04 |
| fungi | i suppose that exposes a general problem of fitness for services like barbican and key management backends in general: users not wanting to expose a key to anything beyond the piece of the infrastructure which will end up using it | 13:05 |
| fungi | though that presumes deep user knowledge of openstack implementation details | 13:06 |
| Luzi | we also heard from ops and users in one forum at summit, that they would like to know explicitly when a secret is used to encrypt a volume for example | 13:06 |
| fungi | right, basically the corollary to what i just said for decryption as well | 13:07 |
| Luzi | we implemented a PoC for this anyway for our project | 13:07 |
| fungi | i think this comes down to fundamental disagreements over whether openstack is one platform or a toolkit of random services | 13:07 |
| Luzi | and we are allowed to contribute this part, if you want it | 13:07 |
| fungi | Luzi: well, that's not how free software collaboration works. designing in private cuts the majority of the community out of the design discussions | 13:08 |
| fungi | "open source is not a verb" as the popular saying goes | 13:08 |
| fungi | that's often the biggest part of the friction i see when contributors come along and say "we've built this for our business/customers and now we want to add it to openstack" | 13:10 |
| fungi | though i get that in this case you would likely be fine with some solution which met the same needs for those use cases, even if the implementation/code is not the one you originally wrote | 13:12 |
| fungi | anyway, back to barbican, if the concern is control over which pieces of openstack have access to the key (and specifically there is a desire to only provide it to the parts that need the key) then i'm not convinced providing it through the barbican api to wind up at the hypervisor host is necessarily any different from providing it to the nova api or the glance api. they're all openstack apis from the | 13:15 |
| fungi | user's perspective, and we can solve the access and reporting requirements on the backend in whatever ways are needed to meet their requirements | 13:15 |
| *** jamesmcarthur has joined #openstack-tc | 13:15 | |
| fungi | also, the entire idea with barbican is that when there's one api to provide such secrets through, there's fewer services you need to secure and audit with regard to handling of those secrets | 13:15 |
| Luzi | your last point is important: it is still possible to handle that while giving users a way to point at keys (in barbican) which they want to use for encryption. | 13:28 |
| fungi | i have a feeling what may be missing is the ability to provide keys through the barbican api which don't persist in barbican's secret store, but if so that sounds more like a feature request for barbican than a reason to discount it as a solution | 13:29 |
| fungi | (and it may even already support that use case, i'm simply not familiar enough with it to know for sure) | 13:30 |
| Luzi | we will write a mail to the new ML for that in the next year, i think, and we would really like to hear other opinions on the whole way to handle keys - maybe with the new ML also users and ops answer | 13:31 |
| fungi | yes, that's our hope with combining the old mailing lists is to get these to be broader discussions across our community | 13:32 |
| Luzi | i realy hope for a wide range of opinions and ideas, what to do... as we are just proposing our idea here too | 13:32 |
| * Luzi having another meeting right now | 13:33 | |
| *** jamesmcarthur has quit IRC | 13:47 | |
| *** jamesmcarthur has joined #openstack-tc | 13:48 | |
| *** jamesmcarthur has quit IRC | 14:02 | |
| *** jamesmcarthur has joined #openstack-tc | 14:03 | |
| *** mriedem has joined #openstack-tc | 14:06 | |
| ildikov | Luzi: hi | 14:07 |
| *** jamesmcarthur has quit IRC | 14:07 | |
| ildikov | Luzi: sorry for showing up late, I'm in US Pacific time zone right now | 14:08 |
| Luzi | ildikov, hi - no problem, i wanted to write you a mail :) | 14:08 |
| ildikov | Luzi: I'm happy to chat about the topic, share experience and see where I can help | 14:08 |
| ildikov | Luzi: if you can give a summary in mail so I get the full context that would be a good start and then we can see how to proceed from there | 14:09 |
| Luzi | ildikov, that's fine thank you :) | 14:10 |
| ildikov | Luzi: I'm happy to chat over IRC or jump on a call if we can find a good slot | 14:10 |
| ildikov | Luzi: I know that cross-project work is hard | 14:10 |
| *** ifat_afek has quit IRC | 14:25 | |
| smcginnis | Luzi: Seems like semi-regular posts to the ML on progress and highighting needs would really help that effort. | 14:43 |
| smcginnis | And soliciting involvement from others to help in each project team. | 14:43 |
| smcginnis | There was a lot of great discussion when you came to each team's weekly meeting to let them know about it, but I haven't heard much since then so it hasn't been something I've been watching out for. | 14:44 |
| Luzi | smcginnis, i wrote a mail to ildikov to discuss the creation of a popup team and what | 14:44 |
| smcginnis | So communicating progress and needs should go a long step towards getting things moving I think. | 14:45 |
| *** e0ne has joined #openstack-tc | 14:45 | |
| smcginnis | Yeah, this is basically what you do to get a "pop-up team". | 14:45 |
| ildikov | We could also call it team of unicorns :) | 14:46 |
| ildikov | But to be serious people from every team interested in pushing the topic forward is crucial to success | 14:47 |
| ildikov | And it can be tricky to keep them in sync still | 14:47 |
| smcginnis | Totally agree. After good communication and getting interested folks involved, then good to schedule some regular meetings to help keep some momentum going. | 14:49 |
| ildikov | Yeah, that was very helpful for the multi-attach activity for instance | 14:50 |
| ildikov | People will hate having yet another meeting, but it doesn't have to be long but rather consistent | 14:50 |
| smcginnis | ++ | 14:50 |
| smcginnis | Just a checkpoint to motivate people to get some things done. | 14:51 |
| Luzi | well, it seems that is basically, what i was looking for | 14:51 |
| ildikov | +1 | 14:51 |
| evrardjp | woulnd't it be good to distill experience and success stories somewhere (like the wiki for now), so that people can re-use/re-share the experience? | 14:51 |
| ildikov | I can check whether I did a SuperUser blog | 14:51 |
| Luzi | evrardjp, that would be nice, because i haven'T heard of popup teams before today | 14:51 |
| smcginnis | Do we have a general "how to get things done in open source" document anywhere? | 14:52 |
| ildikov | Or could write up a new one as a reminder | 14:52 |
| smcginnis | Popup teams aren't really an actual entity, more of a way to think about structuring what you're trying to accomplish. | 14:52 |
| fungi | yeah, it's a description of an emergent phenomenon | 14:53 |
| ildikov | smcginnis: There are best practices in the Contributor Guide not necessarily for cross-project work though | 14:53 |
| evrardjp | smcginnis: I think GTD in a random open source project x, in a openstack project y, and in multiple openstack projects z are 3 different things, but that's maybe me. | 14:53 |
| ildikov | evrardjp: everyone does it differently, it's a good observation | 14:53 |
| smcginnis | True. But there's not really a concrete process for any of those things to make things happen. | 14:54 |
| ildikov | So we can talk about principles that are supposed to be applicable everywhere | 14:54 |
| smcginnis | Things happen by figuring out how to make the given thing come about. | 14:54 |
| ildikov | And then about practices that differ | 14:54 |
| * dhellmann signs smcginnis up for writing t-shirt slogans | 14:54 | |
| smcginnis | :) | 14:55 |
| * cdent sits at smcginnis' feet | 14:55 | |
| smcginnis | :P | 14:56 |
| cdent | except, like a good teenager, I disagree, in principle | 14:56 |
| evrardjp | cdent: :) | 14:57 |
| cdent | things happen in two ways: | 14:58 |
| *** openstackgerrit has joined #openstack-tc | 14:58 | |
| openstackgerrit | Thierry Carrez proposed openstack/governance master: Document the role of the TC https://review.openstack.org/622400 | 14:58 |
| cdent | some_one_ just does it, without regard for others, including telling others they control to do it | 14:58 |
| cdent | or, several establish a shared goal by establishing shared language and understanding | 14:58 |
| dhellmann | that second approach is what has worked best for us, and is how I'm interpreting the advice everyone has been giving Luzi | 14:59 |
| smcginnis | I agree. That second one is actually what I'm thinking with consistent ML communication and trying to enlist others that are also interested in the functionality. | 14:59 |
| cdent | yeah. And I think where, in general, we can do a better job is spending more time/attention/energy on working on the shared language/understanding processing | 15:00 |
| cdent | (which is aligned with "consistent ml comm..." | 15:01 |
| *** Luzi has quit IRC | 15:12 | |
| cdent | tc-members see mriedem's comment on https://review.openstack.org/#/c/624055/ | 15:35 |
| mriedem | the troll hath spoken | 15:35 |
| cdent | it applies to the python3 stack that's been going through governance of late | 15:35 |
| smcginnis | Totally agree with those commments. | 15:35 |
| cdent | is that speech? all I heard was grunts | 15:35 |
| smcginnis | Hah | 15:36 |
| fungi | if i'm matching this up to zaneb's proposal, py27 is there because we've said we aren't dropping it until after train. py35 is there because some projects don't yet work with py36 and we want them to be able to have some expectation their interdependencies will remain stable until then. py36 is there because it's the target tested python 3.x for stein, and py37 is being added by that change because it's | 15:43 |
| fungi | the most recent python version we can reasonably test against for now | 15:43 |
| cdent | right, which is why, though rational, zane's proposal may cause "too many jobs" | 15:45 |
| cdent | however, clarkb (I think it was him) said that was less of a problem than we may think, but mriedem demurs, somewhat | 15:45 |
| ttx | yeah, it's one case of the right thing not necessarily being the best | 15:45 |
| fungi | i really only care about py27 (for a little longer) and py36 (because it's the recommended version for eventually running released stein in production) | 15:45 |
| ttx | I feel like we could have a provision to do "most recent available" only once we got rid of py2. Test a max of 3 | 15:46 |
| fungi | having a non-voting py37, or a canary in experimental or periodic seems like a reasonable trade-off | 15:46 |
| ttx | at least until we no longer have py2 to care for | 15:46 |
| fungi | and dropping py35 immediately doesn't bother me if it encourages other projects to drop whatever else they're doing and fix their py36 jobs asap | 15:46 |
| fungi | we're getting dangerously close to the end of the cycle already to still be arguing about what should get tested | 15:47 |
| fungi | while the past model of "the infra team decides this and gives everyone a heads up" at least we got to skip the design-by-committee risk that we don't reach some consensus on what should be done until it's too late to act on that decision | 15:48 |
| fungi | er, while the past model was painful in other ways, it at least got to skip the design-by-committee risk | 15:49 |
| fungi | wrapping the "but what about projects that are too busy to work on py36 testing yet" and "but what about making sure we have some idea of what's coming in even newer python" up into this discussion delays our ability to tell everyone to get moving on the py36 transition *now* | 15:51 |
| fungi | which is what i originally hoped to accomplish by just ripping out the py35 mention in our pti so teams would stop pushing back against the move from xenial to bionic for the testing platform as early as possible | 15:53 |
| cdent | so the sense here seems to be that we're in the midst of approving some plans that we don't actually want? | 15:54 |
| cdent | (for some definition of "we") | 15:54 |
| clarkb | ya I sent a response to an earlier thred with the exact numbers but running unittests for a python3 was only current a few percent of total resource usage | 15:54 |
| fungi | documenting our expectations is fine, but making the ironing out of that documentation a roadblock to getting the actual work done is a problem | 15:55 |
| clarkb | so a handful of projects opting into py37 would be a relatively minor invenstment | 15:55 |
| cdent | clarkb: the concern is more with resets rather than overall job count | 15:56 |
| fungi | clarkb: i think mriedem's concern is less about resource consumption and more about nondeterminism increasing unexpected failures the more jobs we run | 15:56 |
| mriedem | yes | 15:56 |
| clarkb | no one was saying gate on py37 right? | 15:56 |
| clarkb | the whole point with 37 at least was to start testing it somewhere and see what breaks and improve it from there. Once its stable we should be able to gate on it if projects want | 15:57 |
| fungi | of course, that drives back to your point about our slipping qa focus and the "run fewer jobs, test less stuff" approach | 15:57 |
| clarkb | right there are two ways you can approach this. One is use the tools to figure out what is broken and actively fix it | 15:57 |
| clarkb | the other is put up blinders and ignore the possibility of broken | 15:57 |
| clarkb | they both address the inefficient use of test resources, but one has a higher human cost | 15:58 |
| cdent | this is why I think we should be gating on py37, the pain is higher... | 15:58 |
| fungi | i also know mriedem in particular is especially not a fan of shrugging off nondeterministic bugs so that was not a critique of his argument ;) | 15:58 |
| clarkb | cdent: unfortunately we don't seem to care much about that pain recently | 15:58 |
| clarkb | debugging of the gate for openstack integrated and tripleo queues has largely fallen on mriedem and myself it feels like | 15:59 |
| * cdent has just fixed 4 python 3.7 bugs in nova | 15:59 | |
| cdent | Is there a canonical process for fixing code when the problem is effectively: this code doesn't deal with being on a way underpowered vm as well as it should? | 16:01 |
| clarkb | cdent: many of the bugs haven't been that though | 16:01 |
| clarkb | these are actual bugs in the software or test framework | 16:01 |
| cdent | I'm not saying they all are, but the ones I've seen recently have been and I've not had a strategy for addressing them | 16:01 |
| cdent | so was hoping there was one | 16:02 |
| clarkb | not waiting for volume to be ready before operating on it is an error in cinder. Test framework must wait then | 16:02 |
| cdent | because I do try to investigate things as they cross my path | 16:02 |
| clarkb | tripleo tests crashing because nested virt is buggy is another | 16:02 |
| clarkb | a race in apache using poll connections due to misconfigure another | 16:02 |
| clarkb | nova startup polling an invalid cell for compute hosts | 16:02 |
| clarkb | tripleo misconfiguring ntp so it fails | 16:02 |
| clarkb | cdent: usually the underpowered fix is to rethinki what or how we are testing something | 16:04 |
| clarkb | for example if qemu is too slow to test nested workload can we isolate that and avoid nesting it? | 16:04 |
| *** jamesmcarthur has joined #openstack-tc | 16:10 | |
| *** e0ne has quit IRC | 16:36 | |
| mugsie | yeah, I know the octavia team has had problems figuring that out | 16:41 |
| johnsom | We have seen libvirt crash on some nodepool image instances. It is a bug in the kernel running in the nodepool instance (guest). It has been fixed and then broken again. We just check the host at test start and enabled/disable KVM depending on what we find. | 16:43 |
| clarkb | johnsom: it may also be bugs in the host kernel too. Updating the host kernel fixes it sometimes (like with the most recent situation) | 16:44 |
| clarkb | the point is mroe that this is a limitation (unreliable nested virt) and there are ways to deal with that if necessary | 16:44 |
| johnsom | We tested a bunch of combinations at OVH and found it was the nodepool kernel coming from Ubuntu/upstream | 16:44 |
| johnsom | The hypervisor host and kernel didn't seem to make any difference | 16:45 |
| clarkb | johnsom: logan- recently found that centos 7.6 kernel update led to crashing and updating the hypervisor kernel fixed it in that case | 16:46 |
| clarkb | I think it happens both ways and we shouldn't assume it is only one or the other | 16:46 |
| johnsom | Ha, well, more interesting behavior then. We have found a number of strange things in centos 7.6. We just moved that gate to non-voting again. | 16:47 |
| fungi | the take-away so far on nested virt is that everyone who insists it's reliable is running a private cloud or similar situation where they have control over both the host _and_ guest kernel builds | 16:59 |
| johnsom | We ran it reliably for over a year in the gates. | 17:00 |
| fungi | in selective locations | 17:00 |
| fungi | some of our providers disable support, some lack support... | 17:00 |
| johnsom | Yeah, only hosts that exposed the capability | 17:00 |
| *** jamesmcarthur has quit IRC | 17:13 | |
| clarkb | in general though I think as resource constraints pop up we should try to rethink how we test things. Due to the heavy reliance on tempest (and devstack) for our testing we've ended up in a spot where that is often our hammer | 17:16 |
| clarkb | this works well for proper integration testing, but isn't necessary to test all of the software. cdent has actually proven this out a bit with placement's functional tests I think? | 17:17 |
| cdent | it works well for placement, but in part because placement is just one thing | 17:18 |
| cdent | so one might argue (I probably would) that we should put some energy into being just one thing | 17:19 |
| cdent | I was sad to add tempest and grenade to the extracted placement tests, but it has been defined as the right thing | 17:19 |
| clarkb | I don't think its wrong to have tempest and grenade and evstack to double check nova uses placement properly across upgrades and all that. But we can do that relatively cheaply from an integration standpoint until we try using that entire platform to test specific placement functionality | 17:21 |
| clarkb | it is the difference between does nova boot an instance and live migrate it properly when placement is used and does placement return the correct answer in all of these scenarios | 17:22 |
| *** jpich has quit IRC | 17:24 | |
| *** dtantsur is now known as dtantsur|afk | 18:07 | |
| *** e0ne has joined #openstack-tc | 18:10 | |
| *** cdent has quit IRC | 19:04 | |
| *** jamesmcarthur has joined #openstack-tc | 19:09 | |
| *** jamesmcarthur has quit IRC | 19:14 | |
| *** lbragstad has quit IRC | 19:30 | |
| *** lbragstad has joined #openstack-tc | 19:32 | |
| *** jamesmcarthur has joined #openstack-tc | 19:43 | |
| *** jamesmcarthur has quit IRC | 19:47 | |
| dhellmann | tc-members: there is a board meeting in ~1 hr at which they will be talking about confirmation guidelines for the strategic focus areas: https://wiki.openstack.org/wiki/Governance/Foundation/11Dec2018BoardMeeting | 20:03 |
| mnaser | I don’t think I got an invite for that one :/ | 20:04 |
| mnaser | Did it not make it by any chance ? | 20:04 |
| dhellmann | I don't know; those go to the foundation mailing list I think? I watch the wiki page with the list of meetings so I don't always pay attention to the meeting invitations | 20:05 |
| dhellmann | there's a zoom link in the wiki page, which is different from what they have usually used in the past | 20:05 |
| zaneb | I don't see anything that looks like a meeting announcement on the foundation or foundation-board mailing lists | 20:06 |
| clarkb | dhellmann: mnaser the old reminders/invites came from webex | 20:06 |
| clarkb | chances are reminding people now that zoom is used was missed | 20:06 |
| dhellmann | seems likely | 20:07 |
| clarkb | jbryce: ^ fyi | 20:07 |
| zaneb | I wonder if I'll be able to figure out how to join this one since I don't have my VOIP phone with me here... | 20:07 |
| mnaser | They have an app | 20:07 |
| mnaser | For zoom | 20:07 |
| mnaser | I’ll likely use it because I’m at kubecon.. | 20:07 |
| scas | zoom has consistently worked for me across windows, macos and linux. can't say the same for other options | 20:08 |
| clarkb | zaneb: ya there is an app for the various mobile platforms and you can dial in directly via pots (though I'm guessing POTS is the issue for you) | 20:08 |
| fungi | zoom has consistently worked for me via plain old telephone service, yes. i haven't tried their voip stuff since it seems to require proprietary software | 20:12 |
| zaneb | fungi: I meant at home I have a VOIP phone that allows me to dial in to POTS (I mean not really, because it's 2018, but you know), but I don't have it with me so I'll have to try from a browser. which may well work, but the previous thing never did for me | 20:14 |
| fungi | ahh, yeah | 20:14 |
| *** mriedem has quit IRC | 20:22 | |
| *** mriedem has joined #openstack-tc | 20:24 | |
| jbryce | Thanks for the ping. I'll check with Alan but I bet you're right that it's a side effect of the zoom switch | 20:26 |
| *** jamesmcarthur has joined #openstack-tc | 21:44 | |
| *** e0ne has quit IRC | 21:47 | |
| *** jamesmcarthur_ has joined #openstack-tc | 21:48 | |
| *** jamesmcarthur has quit IRC | 21:50 | |
| *** EmilienM has quit IRC | 22:07 | |
| *** EmilienM has joined #openstack-tc | 22:08 | |
| zaneb | wow, so much scrollback | 22:29 |
| zaneb | I spoke to Luzi in Berlin about the issue she raised above, as did a number of other TC members I believe | 22:30 |
| zaneb | I'd summarise the immediate issue as being that despite the fact they were doing an outstanding job of talking to all the groups they needed to, there was no way to get all those groups to talk to each other at the same time | 22:31 |
| zaneb | so e.g. in trying to find somewhere to host the encryption code, they talked to like 5 teams who each said something along the lines of 'this is great, but I think it should be hosted over there' for 5 different values of 'over there' | 22:32 |
| *** jamesmcarthur_ has quit IRC | 22:33 | |
| zaneb | eventually the olso team stepped up, but there was a ton of legwork and playing telephone involved to get to that point | 22:34 |
| *** jamesmcarthur has joined #openstack-tc | 22:35 | |
| zaneb | a slightly less motivated & organised team would never have made it | 22:35 |
| *** jamesmcarthur has quit IRC | 22:35 | |
| *** jamesmcarthur has joined #openstack-tc | 22:35 | |
| zaneb | we do have a mechanism to get groups of people from different teams together: cross-project PTG and/or Forum sessions | 22:36 |
| *** jamesmcarthur has quit IRC | 22:36 | |
| zaneb | but those only happen every 6 months (from now on) | 22:36 |
| *** jamesmcarthur has joined #openstack-tc | 22:37 | |
| zaneb | and they have to be registered in advance, so if you time it wrong there is a lead time of up to 7+ months to get a session | 22:37 |
| zaneb | I'm sure Luzi will contradict me when she comes back online, but that seems like the first problem we need to solve | 22:38 |
| zaneb | I like ildikov's suggestion of organising a regular meeting, and evrardjp's suggestion of documenting how teams have done this successfully in the past | 22:39 |
| *** jamesmcarthur has quit IRC | 22:40 | |
| *** jamesmcarthur has joined #openstack-tc | 22:42 | |
| *** jamesmcarthur has quit IRC | 22:46 | |
| *** jamesmcarthur has joined #openstack-tc | 23:22 | |
| *** jamesmcarthur has quit IRC | 23:26 | |
| *** dklyle has joined #openstack-tc | 23:51 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!