| *** zaneb has quit IRC | 00:06 | |
| *** zaneb has joined #openstack-tc | 00:18 | |
| *** kumarmn has joined #openstack-tc | 00:59 | |
| *** kumarmn has quit IRC | 01:04 | |
| *** zaneb has quit IRC | 01:10 | |
| *** zaneb has joined #openstack-tc | 01:20 | |
| *** kumarmn has joined #openstack-tc | 01:29 | |
| *** kumarmn has quit IRC | 01:35 | |
| *** zaneb has quit IRC | 01:36 | |
| *** zaneb has joined #openstack-tc | 01:41 | |
| *** edmondsw has quit IRC | 01:47 | |
| *** kumarmn has joined #openstack-tc | 02:19 | |
| *** kumarmn has quit IRC | 02:24 | |
| *** kumarmn has joined #openstack-tc | 02:39 | |
| *** kumarmn has quit IRC | 02:45 | |
| *** edmondsw has joined #openstack-tc | 02:54 | |
| *** edmondsw has quit IRC | 02:59 | |
| *** kumarmn has joined #openstack-tc | 03:16 | |
| *** kumarmn has quit IRC | 03:20 | |
| *** kumarmn has joined #openstack-tc | 03:22 | |
| *** kumarmn_ has joined #openstack-tc | 03:26 | |
| *** kumarmn has quit IRC | 03:29 | |
| *** kumarmn_ has quit IRC | 04:21 | |
| *** gagehugo has quit IRC | 04:24 | |
| *** dklyle has joined #openstack-tc | 04:25 | |
| *** dklyle has quit IRC | 04:31 | |
| *** gagehugo has joined #openstack-tc | 04:37 | |
| *** kumarmn has joined #openstack-tc | 04:51 | |
| *** kumarmn has quit IRC | 04:55 | |
| *** kumarmn has joined #openstack-tc | 05:31 | |
| *** kumarmn has quit IRC | 05:36 | |
| *** kumarmn has joined #openstack-tc | 06:04 | |
| *** kumarmn has quit IRC | 06:09 | |
| *** jaosorior has joined #openstack-tc | 07:10 | |
| *** kumarmn has joined #openstack-tc | 07:15 | |
| *** kumarmn has quit IRC | 07:20 | |
| *** bauzas has joined #openstack-tc | 07:39 | |
| *** jpich has joined #openstack-tc | 08:00 | |
| *** dtantsur|afk is now known as dtantsur | 08:40 | |
| *** dtantsur is now known as dtantsur|bbl | 09:49 | |
| *** kumarmn has joined #openstack-tc | 10:38 | |
| *** kumarmn has quit IRC | 10:42 | |
| *** jrollen is now known as jroll | 10:44 | |
| *** cdent has joined #openstack-tc | 11:00 | |
| *** kumarmn has joined #openstack-tc | 11:16 | |
| *** jroll has quit IRC | 11:18 | |
| *** jroll has joined #openstack-tc | 11:18 | |
| *** kumarmn has quit IRC | 11:21 | |
| *** kumarmn has joined #openstack-tc | 11:54 | |
| *** kumarmn has quit IRC | 11:59 | |
| *** kumarmn has joined #openstack-tc | 12:03 | |
| *** kumarmn has quit IRC | 12:08 | |
| *** edmondsw has joined #openstack-tc | 12:12 | |
| openstackgerrit | Merged openstack/governance master: Add openstackclient to Chef OpenStack https://review.openstack.org/571504 | 13:19 |
|---|---|---|
| *** dtantsur|bbl is now known as dtantsur | 13:25 | |
| smcginnis | Apparently it's "pad your stats day" today - https://review.openstack.org/#/q/status:open+owner:inspur.com | 13:25 |
| cdent | ah, that | 13:26 |
| cdent | while I'm sure this is padding by people, the changes themselves are not negative are they? | 13:28 |
| smcginnis | cdent: I hate to see all the gate resources consumed for a patch that changes one character in a comment that is understandable without the change. Especially when it's a whole series of patches doing the same one character change in multiple files instead of just one patch. | 13:29 |
| smcginnis | But yeah, they aren't necessarily "negative". | 13:29 |
| cdent | true, good point. Half of me wishes that we just had _way_ more gate resources and then we wouldn't need to worry | 13:30 |
| fungi | could be trying to get their "one required change" landed to get discount summit passes before feature freeze (assuming we even do those for berlin) | 13:30 |
| smcginnis | Hah | 13:31 |
| smcginnis | I've seen the same behavior happening in other communities, so I do think it is all about the metrics. | 13:31 |
| *** kumarmn has joined #openstack-tc | 13:32 | |
| *** mriedem has joined #openstack-tc | 13:44 | |
| mnaser | i think it would be nice if we figure out a way to make jobs run more efficiently | 13:58 |
| mnaser | as in, only run on the things that need to be covered | 13:58 |
| openstackgerrit | Merged openstack/governance master: fix tox python3 overrides https://review.openstack.org/573792 | 13:58 |
| mugsie | I think a lot of the irrevant files execptions have been good for that | 13:58 |
| smcginnis | We've gotten a little better with irrelevant-files, but hard to tell with these that do change relevant files but only code comments. | 13:59 |
| dtroyer | I don't think it is even smart stats-padding, its mechanical, I've gotten a couple of those on two starlingx repos already :) | 14:01 |
| zaneb | mnaser: zuul allows that (on a per-file basis though, so you can't e.g. avoid running jobs on changes to comments) | 14:01 |
| *** ianychoi has quit IRC | 14:02 | |
| mugsie | I got one on the openstack letsencrypt plugin as well :) | 14:03 |
| zaneb | to some extent reviewers are encouraging this stuff by approving pointless changes like "Replace Chinese punctuation with English punctuation" - which has nothing to do with Chinese, and consists of replacing curly quotes in the docs with straight quotes, both of which are rendered identically as curly quotes in the HTML output | 14:04 |
| mugsie | zaneb: ++ | 14:05 |
| mugsie | I don't review them | 14:06 |
| *** zaneb has quit IRC | 14:09 | |
| *** zaneb has joined #openstack-tc | 14:13 | |
| fungi | the trick with trying to avoid running jobs against certain changes is that it's non-trivial to guess what file changes can impact what functionality. inevitably as soon as you try to get fancy about it, breaking bugs start slipping through and wedging the jobs you didn't run | 14:14 |
| *** annabelleB has joined #openstack-tc | 14:15 | |
| *** needssleep is now known as TheJulia | 14:15 | |
| fungi | also, rerunning jobs which you don't expect to be impacted by a given change isn't a total waste, as (especially in the gate pipeline) it still gives us useful telemetry on nondeterministic bugs already present in the software | 14:15 |
| *** ricolin__ has joined #openstack-tc | 14:21 | |
| *** dklyle has joined #openstack-tc | 14:40 | |
| *** hongbin has joined #openstack-tc | 14:46 | |
| *** dklyle has quit IRC | 14:47 | |
| fungi | smcginnis: on the barbican topic, what i'm talking about there is things like if a feature requires the user to upload key material, then don't create a key upload method in the calling service's api just expect them to upload the key through barbican's api and tell you which key to use | 14:59 |
| smcginnis | fungi: OK, I thought castellan was meant to help keep us from relying on a specific backend implementation in case we wanted to swap out barbican for $OTHER at some point. | 15:00 |
| fungi | barbican already supports multiple backends itself | 15:00 |
| smcginnis | So why do we use castellan? Why not just go right to barbican then. | 15:00 |
| jroll | this is what doug was asking a few weeks ago when this came back up :) | 15:01 |
| cdent | as I recall because castellan allowed avoid barbican, so it all sounds a bit tautological? | 15:01 |
| fungi | because if there are features which don't require user interaction but do need a key store, then deployments can make use of those features without necessarily having to install barbican | 15:01 |
| fungi | this all goes back to the initial conversations around making barbican a base service and the compromise decided on back then (over a year ago now) was to create a library interface | 15:02 |
| smcginnis | That seems a little odd to me. They still need to deploy something. And then the user experience is it's fine to use whatever is supported, but oh, you want to use that feature? Then you must deploy this other thing. | 15:03 |
| fungi | but i still think the flip-side of that is, if you need a user-facing api to do things barbican provides, then use barbican for that | 15:03 |
| smcginnis | I goes it is rehashing past conversations, but if barbican supports configuring different backends, and we may require barbican for certain functionality, I guess I would rather just drop castellan and go just with barbican. | 15:04 |
| fungi | if your service only needs access to a key store, then use castellan along with a supported key store (which could be barbican, or could be something else) | 15:05 |
| fungi | the argument was "our deployments need a key store for non-user-facing feature x, and we already have vault installed for other reasons, so we'd rather not have to run an additional service with a user-facing api just for that" | 15:07 |
| cdent | the complexity of managing/turning off/tuning/etc "user-facing api" is the crux, yes? | 15:08 |
| fungi | in those situations, they have the option of also installing barbican and configuring it to use vault as a backend, when the time comes that they have some new security feature they want to make use of which does have a user-facing component handled by the barbican api | 15:08 |
| fungi | and i think in those situations we do want them deploying barbican rather than adding yet still more duplicate apis in random services and passing around sensitive data unnecessarily | 15:09 |
| fungi | cdent: yeah, basically it's the fear of openstack's never-ending service/api sprawl | 15:11 |
| fungi | i personally think it would be great if we could just get everybody to deploy barbican and be done with it, but there was significant pushback when that got proposed, and i still think that having a key store available for non-user-facing security features is still a net win so i'd rather not unnecessarily delay that with broader-reaching hopes | 15:13 |
| dtantsur | folks, do we have SB stories for Pike-era project-wide goals? | 15:32 |
| fungi | dtantsur: nope, those were tracked in git, why do you ask? | 15:33 |
| dtantsur | fungi: we have a few fallouts since then. wondering where to track them. | 15:33 |
| dtantsur | using SB would be handy | 15:33 |
| fungi | dtantsur: there's an argument underway currently as to whether it makes sense to expect goal completion past the end of the cycle for that goal, or for some other arbitrary duration, or until the end of time | 15:34 |
| dtantsur | well, sometimes it's not quite easy. e.g. for WSGI goal: one of our two services did not (and still does not) have a separate API service AT ALL | 15:35 |
| fungi | on one hand, saying you completed a pike goal when the code you shipped for pike doesn't have it seems a little misleading | 15:35 |
| dtantsur | mm, fair | 15:36 |
| fungi | but also, at what point do we want people to be able to free up the tracking overhead/busywork for goals completed long after the effort was timeboxed | 15:37 |
| dtantsur | maybe we should not call it "a Pike goal" on SB? | 15:38 |
| dtantsur | like, on https://governance.openstack.org/tc/goals/ it's associated with Pike, but on SB it's just "Deploy your API with WSGI" | 15:38 |
| fungi | we previously accepted tracking updates after a goal's cycle, but never decided how long that should be expected to continue, and as we accumulate more historical goals cycle after cycle expecting projects to keep tracking them all seems burdensome | 15:39 |
| smcginnis | Well, if they all complete them, then that historical burden is gone, right? ;) | 15:40 |
| fungi | yeah, it also came up whether we should put in the effort to "import" tracking for all the historical <=pike goals into sb | 15:40 |
| fungi | which goes hand-in-hand with whether there's benefit to having teams continue to update year+ old goals | 15:41 |
| fungi | also do we bother to retroactively note whether retired deliverables met those goals? what about recording that deliverables added after the goal's cycle? | 15:55 |
| fungi | the argument in favor of continuing to update them is that you can look at the goal document/story to determine what deliverables meet that goal, but in practice that doesn't hold up unless we indefinitely add all future deliverables to it too | 15:57 |
| *** dtruong_ has quit IRC | 16:05 | |
| *** ricolin__ has quit IRC | 16:27 | |
| *** jpich has quit IRC | 16:41 | |
| *** annabelleB has quit IRC | 17:02 | |
| *** annabelleB has joined #openstack-tc | 17:14 | |
| *** dklyle has joined #openstack-tc | 17:32 | |
| *** dtantsur is now known as dtantsur|afk | 17:37 | |
| *** kumarmn has quit IRC | 18:00 | |
| *** kumarmn has joined #openstack-tc | 18:01 | |
| *** kumarmn has quit IRC | 18:10 | |
| *** kumarmn has joined #openstack-tc | 18:11 | |
| *** kumarmn has quit IRC | 18:15 | |
| *** dklyle has quit IRC | 18:17 | |
| *** kumarmn has joined #openstack-tc | 18:24 | |
| *** kumarmn has quit IRC | 18:29 | |
| *** kumarmn has joined #openstack-tc | 18:30 | |
| *** dtruong has joined #openstack-tc | 18:31 | |
| *** kumarmn has quit IRC | 18:35 | |
| *** kumarmn has joined #openstack-tc | 18:36 | |
| *** annabelleB has quit IRC | 18:41 | |
| *** kumarmn has quit IRC | 18:47 | |
| *** kumarmn has joined #openstack-tc | 18:48 | |
| *** dklyle has joined #openstack-tc | 18:48 | |
| *** kumarmn has quit IRC | 18:52 | |
| *** kumarmn has joined #openstack-tc | 18:54 | |
| *** kumarmn has quit IRC | 18:56 | |
| *** kumarmn has joined #openstack-tc | 18:56 | |
| *** annabelleB has joined #openstack-tc | 19:02 | |
| *** annabelleB has quit IRC | 19:20 | |
| *** mriedem1 has joined #openstack-tc | 19:26 | |
| *** mriedem has quit IRC | 19:28 | |
| *** mriedem1 is now known as mriedem | 19:37 | |
| *** annabelleB has joined #openstack-tc | 19:41 | |
| -openstackstatus- NOTICE: Zuul was restarted for a software upgrade; changes uploaded or approved between 19:30 and 19:50 will need to be rechecked | 19:57 | |
| *** annabelleB has quit IRC | 20:11 | |
| *** annabelleB has joined #openstack-tc | 21:17 | |
| *** kumarmn has quit IRC | 21:55 | |
| *** annabelleB has quit IRC | 22:02 | |
| *** cdent has quit IRC | 22:19 | |
| *** mriedem has quit IRC | 22:21 | |
| *** kumarmn has joined #openstack-tc | 22:23 | |
| *** kumarmn has quit IRC | 22:28 | |
| *** EmilienM|PTO is now known as EmilienM | 22:41 | |
| *** edmondsw has quit IRC | 22:47 | |
| *** annabelleB has joined #openstack-tc | 22:49 | |
| *** hongbin has quit IRC | 23:26 | |
| *** mriedem has joined #openstack-tc | 23:31 | |
| *** annabelleB has quit IRC | 23:42 | |
| *** mriedem has quit IRC | 23:51 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!