| *** gouthamr has quit IRC | 01:23 | |
| *** gouthamr has joined #storyboard | 02:36 | |
| *** jamesmcarthur has joined #storyboard | 03:08 | |
| *** jamesmcarthur has quit IRC | 03:13 | |
| *** diablo_rojo has quit IRC | 03:34 | |
| *** diablo_rojo has joined #storyboard | 06:33 | |
| *** tosky has joined #storyboard | 07:13 | |
| *** jpich has joined #storyboard | 07:20 | |
| *** dtantsur|afk is now known as dtantsur | 07:22 | |
| *** jtomasek has joined #storyboard | 07:42 | |
| *** tosky has quit IRC | 07:43 | |
| *** tosky has joined #storyboard | 07:43 | |
| *** diablo_rojo has quit IRC | 08:48 | |
| *** tosky has quit IRC | 08:59 | |
| *** tosky has joined #storyboard | 09:00 | |
| *** jamesmcarthur has joined #storyboard | 09:09 | |
| *** jamesmcarthur has quit IRC | 09:13 | |
| *** ttx has joined #storyboard | 09:17 | |
| *** jaosorior_ has quit IRC | 10:05 | |
| *** jaosorior has joined #storyboard | 11:15 | |
| *** ssbarnea|ruck has quit IRC | 12:13 | |
| *** fatema_ has joined #storyboard | 12:42 | |
| *** jamesmcarthur has joined #storyboard | 12:50 | |
| *** fatema_ has quit IRC | 13:01 | |
| dhellmann | I'm seeing some interesting performance issues with https://storyboard.openstack.org/#!/story/2002586 that are probably related to the large number of comments on that story | 13:02 |
|---|---|---|
| dhellmann | the browser seems to hang for a good while trying to render the page | 13:03 |
| dhellmann | safari, at least, I haven't tried others | 13:03 |
| tosky | dhellmann: is it the python3 goal? I've seen it with Firefox | 13:04 |
| tosky | I was going to ask about it | 13:04 |
| dhellmann | yeah, that's the one tracking the zuul migration | 13:04 |
| dhellmann | chrome offers to kill the page since it's unresponsive | 13:05 |
| tosky | firefox too after a while | 13:05 |
| SotK | oh that's pretty painful | 13:08 |
| SotK | I guess our old hope that no stories would have so many comments as to cause big issues was too hopeful | 13:08 |
| dhellmann | how hard would it be to do something like show the N most recent comments by default and have a user-triggered action to show the rest? | 13:11 |
| dhellmann | I don't know what value N might have, 50? | 13:12 |
| SotK | shouldn't be too hard since the API already supports doing something like that | 13:13 |
| dhellmann | I can't tell if the delay is in fetching the comments or just turning the results into html | 13:14 |
| dhellmann | it feels like the latter? but I would have to look at the page load times more closely | 13:14 |
| tosky | SotK: but what exactly lead to that overload? | 13:16 |
| tosky | a simple list of items should not kill the browser, even with a bit of graphic around | 13:16 |
| dhellmann | https://storyboard.openstack.org/#!/story/2003525 for tracking | 13:17 |
| SotK | its the latter, the large number of tasks won't be helping since the code to organise them by project and branch is pretty inefficient too | 13:19 |
| SotK | the fetching takes a few seconds for me, but the rendering takes ages | 13:19 |
| SotK | tosky: I think passing them all through the markdown renderer isn't helping, but I haven't looked in enough depth to know properly | 13:20 |
| *** gouthamr has quit IRC | 14:00 | |
| *** dabukalam has quit IRC | 14:25 | |
| *** jamesmcarthur has quit IRC | 14:51 | |
| *** jamesmcarthur has joined #storyboard | 14:56 | |
| *** jamesmcarthur has quit IRC | 15:06 | |
| *** jamesmcarthur has joined #storyboard | 15:10 | |
| *** jamesmcarthur has quit IRC | 15:15 | |
| *** openstackgerrit has quit IRC | 15:31 | |
| *** jamesmcarthur has joined #storyboard | 15:33 | |
| *** diablo_rojo has joined #storyboard | 16:02 | |
| fungi | the webclient had pagination of comments once upon a time, didn't it? and we dropped it because people had a hard time figuring out that they weren't seeing them all and had to click something to load the rest | 16:10 |
| fungi | i expect if we ever get to that angularjs upgrade mordred was talking about, the server-side prerendering would solve a lot of this too since it could be cached and served back up quickly while the browser slowly worked to replace it with the dynamically-rendered equivalent | 16:11 |
| *** fatema_ has joined #storyboard | 16:17 | |
| *** jpich has quit IRC | 16:40 | |
| *** jamesmcarthur has quit IRC | 16:52 | |
| dhellmann | that story is now up to 1166 comments and counting | 17:07 |
| SotK | yeah we used to paginate them starting at the oldest, and there was lots of confusion about why some comments were "missing" | 17:13 |
| *** EmilienM has quit IRC | 17:25 | |
| *** corvus has quit IRC | 17:25 | |
| *** jeblair has joined #storyboard | 17:30 | |
| *** EmilienM has joined #storyboard | 17:30 | |
| *** jeblair is now known as corvus | 17:41 | |
| *** jamesmcarthur has joined #storyboard | 18:07 | |
| *** ChanServ has quit IRC | 18:16 | |
| *** ChanServ has joined #storyboard | 18:22 | |
| *** barjavel.freenode.net sets mode: +o ChanServ | 18:22 | |
| *** dtantsur is now known as dtantsur|afk | 18:43 | |
| *** tosky has quit IRC | 18:47 | |
| *** jamesmcarthur has quit IRC | 18:50 | |
| diablo_rojo | We having a meeting today? | 19:02 |
| SotK | sure | 19:02 |
| mordred | SotK, fungi: I thni know that the scss transition is complete, the next step in the crap I was working on should be possible | 19:12 |
| mordred | also - I'm not really here right now | 19:12 |
| SotK | mordred: yeah I figured getting that done would help your patch | 19:13 |
| mordred | SotK: yah - the less stuff in grunt == unhappy in webpack | 19:19 |
| mordred | SotK: once I can get that webpack patch done, there's actually a good pattern for wrapping an angular v1 app in an angular v2 app so that components and whatnot can be updated one piece at a time | 19:20 |
| fatema_ | I can do it as a separate patch | 20:00 |
| fatema_ | for simplejson and I guess this would make using arrow function in JS possible | 20:01 |
| persia | fatema_: Procedurally, my understanding is that if someone -1's something, anyone who uploads a new revision to the same change resets the -1 back to "needs review". | 20:01 |
| persia | So either a separate patch for simplejson (with rationale in the commit message), or new revision of the rejected change (only for simplejson) should work. I'd recommend a new one, as the purpose is different, so the old abandoned one can remain as documentation of the consensus not to add launchpadlib. | 20:02 |
| fatema_ | aha persia I am fine with new patch as well | 20:03 |
| persia | Err, a new change (rather than a new revision of the old change). Apologies that I can't write clearly today. | 20:03 |
| fatema_ | a new change** -> still getting use to the names | 20:03 |
| SotK | adding simplejson to the api dependencies won't make arrow functions possible, I think you'd need to at least set http://git.openstack.org/cgit/openstack-infra/storyboard-webclient/tree/.eslintrc#n5 to true | 20:03 |
| SotK | there may also be some other things that need updating for the build not to error, but I'm not certain what at a glance | 20:04 |
| persia | Maybe the ideal new change adds the dependency, sets the configuration, and adds some code to make it work. | 20:04 |
| fatema_ | I can try both, but how to test it | 20:05 |
| fatema_ | ? | 20:05 |
| fatema_ | is it done locally : | 20:06 |
| diablo_rojo | Other thing to note that I forgot to mention before the end of the meeting- there will be a storyboard demo at the PTG during lunch so we might get a lot of interest after the PTG | 20:06 |
| persia | That's why I was suggesting adding everything in a single change (dependency, config, code). That should let you render some new javascript that can be pointed at storyboard-dev for testing (either directly or by making zuul build it) | 20:06 |
| fatema_ | like I'd edit write a function and run "npm run lint" | 20:06 |
| fatema_ | persia, but this would complicate the change, I just prefer small changes | 20:07 |
| fatema_ | but you make sense | 20:08 |
| persia | I share your preference for small changes. If you think it becomes too large in one change, maybe a set of changes that depend on each other, that get reviewed all together. | 20:09 |
| persia | Mostly because I dislike small changes where it isn't clear *why* the change is made, or where it isn't possible to test whether the small change helps achieve the large goal. | 20:09 |
| persia | (but I can't +2 or -2, so it's very safe to disagree with me about these things) | 20:10 |
| fatema_ | I guess I'd try testing locally, my guess it'd work then as the change I'm trying to write and needs arrow function is already dependent | 20:11 |
| SotK | i don't think you'll need the dependency at all, it should just be a case of enabling the use of modern syntax in our build process and then trying to use it | 20:12 |
| fatema_ | SotK, I guess I'll give it a try then | 20:15 |
| fatema_ | well, as the tasks statuses are verified by the API now, It would make sense to drop the enum constraints for that column | 20:18 |
| fatema_ | in the DB\ | 20:18 |
| persia | My general experience suggests a "belt & braces" approach to constraints. | 20:19 |
| persia | Unless there is evidence that doing so is causing delays of some sort due to excessive overhead. | 20:20 |
| fatema_ | my point isn't the delay, I'd like more flexibility for the statuses | 20:21 |
| fatema_ | as to be more maintainable | 20:22 |
| fatema_ | e.g. for further expansion | 20:22 |
| *** jamesmcarthur has joined #storyboard | 20:27 | |
| *** jamesmcarthur has quit IRC | 20:33 | |
| *** jamesmcarthur has joined #storyboard | 20:34 | |
| persia | I'm very strongly against expansion of task status. Having very few is, to me, one of the strengths of storyboard. When Malone (which became LP Bugs) grew new statuses, it would exponentially grow documentation about statuses, meetings to set statuses, and arguments about the semantics of status. | 20:34 |
| persia | I'm fine with the idea of having rich Story Status, derived from simple task status, but to me, having rich task status is a recipe for people substituting fiddling with task status for doing things or understanding the wider scope. | 20:34 |
| persia | Further, I think some popular statuses are actively bad. Things like "needinfo", "opinion", and even "wontfix" tend to constrain development and cause frustration for contributors. | 20:36 |
| persia | "confirmed" is fine, when used to mean "happens in more than one place". It is more painful when used to mean "actually an issue", and even moreso when ACL limited so that only blessed folk can confirm (because this creates a group of people who are actively disenfranchised while experiencing problems with a project). | 20:37 |
| persia | Limiting ourselves to a set that means "available to start", "someone is working on it", "solution available", "done", and "Adding this was a mistake" is ideal to me. I'm open to discussion about why we need more, but there should be a clear and obvious wide benefit to the entire project to have it, rather than it being useful for something that could be expressed with a tag. | 20:39 |
| persia | (for extra points, when considering adding a status, consider how it might affect a storyboard installation other than openstack's) | 20:42 |
| *** openstackgerrit has joined #storyboard | 20:53 | |
| openstackgerrit | Merged openstack-infra/storyboard master: Make email public field https://review.openstack.org/589663 | 20:53 |
| *** jamesmcarthur has quit IRC | 20:57 | |
| *** jtomasek has quit IRC | 20:57 | |
| *** jamesmcarthur has joined #storyboard | 21:03 | |
| *** jamesmcarthur has quit IRC | 21:08 | |
| *** gouthamr has joined #storyboard | 21:12 | |
| fungi | i agree with persia's minimalist approach to task statuses | 21:37 |
| fungi | i always want that plural to be stati but it's 4th declinsion nominative, not 2nd | 21:37 |
| fungi | statūs for the nominative plural in latin i suppose | 21:38 |
| * fungi drags his brain back out of highschool latin class | 21:39 | |
| SotK | I also agree | 21:39 |
| fungi | but yes, from what i've seen any proliferation of statuses leads users to attempt to find a meaning for each and use them all whether they're needed or not | 21:39 |
| fungi | you get very pointlessly nuanced rules to differentiate between certain ones, where ultimately the practical result of using any of them is roughly the same | 21:40 |
| fungi | unnecessary cognitive overhead | 21:41 |
| fatema_ | well, what I wanted is flexibility to change statuses for more meaningful as said for "Merged" to be "Resolved" to be more relevant issues that are resolved but not patches in code https://storyboard.openstack.org/#!/story/2001432 | 22:33 |
| *** ChanServ has quit IRC | 22:49 | |
| *** ChanServ has joined #storyboard | 23:03 | |
| *** barjavel.freenode.net sets mode: +o ChanServ | 23:03 | |
| dhellmann | fatema_ : I want you to know that i have not forgotten you, but I've been buried under other work and haven't been able to get back to answering your email. :-/ | 23:12 |
| *** jamesmcarthur has joined #storyboard | 23:13 | |
| dhellmann | fungi , persia, SotK : part of the point of the discussion about dropping the database constraint around task statuses is that having that constraint makes it harder to change the terms used, and as fatema_ points out "Merged" currently means "Resolved" but sometimes there was no patch to merge for a task. So we don't necessarily want to add a bunch more statuses, but as things stand today *changing* any of them is really | 23:14 |
| dhellmann | tough. | 23:14 |
| persia | dhellmann: Can we do a name change with just two patches, Depends-On, and some IRC traffic? If not, you've convinced me. If so, then I'm less certain. | 23:16 |
| persia | I'm delighted with the idea of clearing up semantics to change "Merged" to "Resolved": it's a clearer word for the concept in the minimal semantics I prefer. | 23:16 |
| dhellmann | using sqlite for dev testing makes some of this harder, because it doesn't support most of the DDL to change table definitions after the fact | 23:17 |
| dhellmann | so we probably need to do something about that | 23:17 |
| dhellmann | after we fix that, somehow, then we can change the names stored in mysql | 23:17 |
| persia | Sadly, really, because the sqlite-for-local-testing stuff made development setup a lot easier. | 23:17 |
| dhellmann | but I personally don't consider database constraints necessary for a service that is only accessed through an API, because that layer can do the constraining -- we even have a layer just for that, in WSME | 23:18 |
| dhellmann | yes, that's why I did it | 23:18 |
| dhellmann | well, that and I got tired of the tests thrashing my disk | 23:18 |
| persia | I agree they aren't necessary. I've just been bitten before by having out-of-band imports cause systems to fail because constraints were skipped through the out-of-band nature of import, which makes me extra cautious. | 23:19 |
| dhellmann | do we have that here? I thought the import tool used the api | 23:19 |
| persia | There exists raw DB access, limited to infra-root. So far, I think all the raw SQL has been safe. | 23:20 |
| dhellmann | if we have to resort to that, it sounds like we need more tools, but I do understand the concern if we're doing that on any sort of frequent basis | 23:20 |
| persia | I believe we've done it three times over the entire lifetime of storyboard.openstack.org. | 23:20 |
| dhellmann | ok, so that seems low risk :-) | 23:21 |
| persia | Yep. I'm just hyper-conservative :) | 23:21 |
| fungi | we occasionally go in and edit fields in tables manually | 23:21 |
| dhellmann | anyway, I just wanted to give some of the background on that conversation | 23:21 |
| fungi | mostly for renaming things | 23:21 |
| persia | fungi: Ah, so maybe it is more often. I was only counting the times I remember it being requested in this channel because of an outage or issue. | 23:22 |
| fungi | stuff that could happen through an api but gets done so infrequently that there was no drive to add the update methods (or we don't know they exist" | 23:22 |
| fungi | we very occasionally rename a project or project-group. it's an update to one field of one row of one table | 23:23 |
| fungi | as i say, if there are/were api methods to achieve those, we'd just do that instead | 23:24 |
| fungi | the less occasional things which you're likely remembering had to do with updating to nondefault utf8mb4 text encoding, or mass alterations of openid url hostnames | 23:25 |
| fungi | that sort of one-time maintenance | 23:25 |
| persia | fungi: does the code that does things like renames undergo review? | 23:25 |
| persia | Yes, those were two of them. The third was when we discovered we didn't have any admins defined. | 23:25 |
| fungi | ahh, right, that needed a bool flipped in a row i think | 23:26 |
| persia | I think it was two or three rows, but yeah. | 23:26 |
| fungi | yes and no on the review. the project rename code is in an ansible role in the system-config repo and that gets code-reviewed. the project-group rename has only ever been done once to my knowledge but looks basically the same except the table name is different | 23:27 |
| persia | Then let's call that "four manual actions" and everything else in is code review. | 23:28 |
| fungi | yeah | 23:28 |
| persia | Given that we implicity trust code review (and implicitly trust our infra team with being careful), that seems like maybe enough to not need belt & braces. | 23:28 |
| fungi | and i meant ansible playbook, not role. it's here: https://git.openstack.org/cgit/openstack-infra/system-config/tree/playbooks/rename_repos.yaml#n37 | 23:28 |
| persia | Mind you, we'll need to be extra-careful with manual SQL changes if we don't have DB constraints (but it makes DB portability much easier anyway) | 23:29 |
| * persia really wishes to have never been a DBA, which would make it much easier to make a positive statement at this point | 23:30 | |
| fungi | the infra sysadmins already tend to be ultra-paranoid when directly manipulating relational database content, and also have two former mysql upstream devs on the team | 23:31 |
| fungi | those two assertions might also be related ;) | 23:31 |
| persia | heh | 23:32 |
| fungi | and we have redundant copies of database backups taken automatically too, just in case | 23:32 |
| persia | fatema_: You might want to check with SotK again, but I suspect there's a chance of consensus to move forward with your multi-step plan for 2001432 | 23:33 |
| fungi | one copy on the server itself, another copied to a server in a different cloud region, performed daily with substantial retention on the remote copy too | 23:33 |
| persia | By "substantial retention", you mean to say that we have N snapshots of the database over some time period, in case of mass damage? | 23:34 |
| fungi | more like in case of subtle damage which goes undetected for weeks/months | 23:35 |
| *** jamesmcarthur has quit IRC | 23:35 | |
| fungi | immediately obvious catastrophic damage is far easier to deal with | 23:35 |
| persia | Fair enough :) | 23:36 |
| fungi | i say "substantial retention" because i don't think we've deleted any of those | 23:37 |
| fungi | granted, we likely should at some point | 23:37 |
| persia | That is a more generous definition of "substantial" than I would have expected. | 23:37 |
| fungi | on the sb server we only keep a month of nightly snapshots | 23:38 |
| fungi | those just get rotated with logrotate | 23:38 |
| fungi | on the bup server i don't actually know if it's possible to truncate history other than to redirect future updates to a new repository and eventually age out and delete the previous one | 23:39 |
| persia | bup is clearly not a technology designed to be used for sequentia millenia :) | 23:40 |
| persia | +l | 23:40 |
| fungi | heh | 23:41 |
| fungi | yeah, it basically just writes and commits to a git lfs repo | 23:41 |
| fungi | i suppose it would be possible to rewrite history onto a squash of earlier commits | 23:42 |
| fungi | but the temporary storage and cpu cost make rotating to fresh repos about as effective | 23:43 |
| fungi | we really only backup data. everything else can be rebuilt via configuration management, so by being selective in what we back up we've been able to put off actually dealing with running out of space for backup retention | 23:45 |
| *** gouthamr has quit IRC | 23:48 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!