| *** jamesmcarthur has joined #storyboard | 00:21 | |
| *** jamesmcarthur has quit IRC | 00:31 | |
| *** jamesmcarthur has joined #storyboard | 00:40 | |
| *** jamesmcarthur has quit IRC | 01:03 | |
| *** jamesmcarthur has joined #storyboard | 01:11 | |
| *** jamesmcarthur has quit IRC | 01:33 | |
| *** jamesmcarthur has joined #storyboard | 01:39 | |
| *** jamesmcarthur has quit IRC | 01:55 | |
| *** jamesmcarthur has joined #storyboard | 02:04 | |
| *** jamesmcarthur has quit IRC | 02:05 | |
| *** mrmartin has joined #storyboard | 02:12 | |
| *** mrmartin has quit IRC | 02:14 | |
| *** mrmartin has joined #storyboard | 07:13 | |
| *** mrmartin has quit IRC | 07:35 | |
| *** mrmartin has joined #storyboard | 10:50 | |
| *** mrmartin has quit IRC | 11:00 | |
| Zara | moooorning | 11:05 |
|---|---|---|
| Zara | SotK is running errands, I am half asleep (but getting up at last!) | 11:06 |
| Zara | in case anyone was wondering about the quiet | 11:06 |
| *** mrmartin has joined #storyboard | 11:26 | |
| *** mrmartin has quit IRC | 11:32 | |
| *** jamesmcarthur has joined #storyboard | 13:07 | |
| Zara | looking at the gerrit bot again now | 13:09 |
| Zara | I'll try to update the wip today, so the comments are in gerrit so people can see where it's going | 13:09 |
| Zara | plan is to use the sandbox to test commit message syntax... once I've fixed the control flow | 13:09 |
| *** jamesmcarthur has quit IRC | 13:11 | |
| *** jtomasek_ has joined #storyboard | 13:35 | |
| *** jamesmcarthur has joined #storyboard | 14:00 | |
| Zara | and the other thing is load-testing, using the dev server | 14:06 |
| Zara | so we should find out how other projects are doing that | 14:06 |
| pedroalvarez | wow! storyboard-dev is a thing! | 14:06 |
| SotK | yeah :D | 14:07 |
| Zara | https://storyboard-dev.openstack.org/ | 14:08 |
| Zara | a beautiful blank canvas, no stories yet! | 14:08 |
| Zara | who will make the first story? | 14:08 |
| persia | Should it not start with an import? | 14:09 |
| persia | Maybe a scheduled job that wipes and reimports once a week or so? | 14:09 |
| *** jamesmcarthur has quit IRC | 14:09 | |
| SotK | sounds sensible to me | 14:10 |
| persia | My thought is that real data contains more unexpected corner cases. | 14:10 |
| persia | Maybe private stories do not get imported, for security reasons. | 14:11 |
| persia | The docs-draft CI job should probably also point there. | 14:11 |
| * SotK wonders if we have the requisite db access for such a thing | 14:11 | |
| SotK | yeah, we should fix that | 14:11 |
| Zara | agreed on weird corner cases. we need to make it clear when it'll wipe if we wipe and reimport, or could be annoying for someone trying to debug a weird case | 14:12 |
| * persia finds http://docs-draft.openstack.org/66/312666/6/check/gate-storyboard-webclient-js-draft/b769b60//dist/#!/story/2000535 useful as a visual aid, by way of example. | 14:12 | |
| persia | Zara: yes, but I think weekly + decent python support should make that less painful. | 14:12 |
| *** jamesmcarthur has joined #storyboard | 14:13 | |
| Zara | persia: yeah, as long as it's obvious to users when things will be deleted, and we have a way to prevent the wipe if someone asks for longer, I think we can have whatever frequency we want | 14:14 |
| Zara | another danger with seeding it with production data is that people may mistake it for storyboard.openstack.org | 14:15 |
| Zara | 'this is the storyboard instance, for developers, I'm a developer; guess I log my bug here' | 14:15 |
| Zara | + they're both red, so tabbing around will lead to mistakes | 14:16 |
| persia | Good point. Maybe it needs a persistent branding patch. | 14:16 |
| persia | Or maybe it should only allow docs-draft access. | 14:16 |
| Zara | I'd like people to be able to use it as a sandbox, so I'd prefer some sort of branding | 14:17 |
| Zara | 'DEV SERVER DO NOT STORE YOUR MEMOIRS' | 14:17 |
| persia | Makes sense. | 14:18 |
| openstackgerrit | Adam Coldrick proposed openstack-infra/storyboard-webclient: Make the docs-draft build point to storyboard-dev https://review.openstack.org/318702 | 14:20 |
| Zara | (how we do that... I'm still hazy on. (both what it should look like and how to patch the config appropriately) but one thing at a time!) | 14:20 |
| Zara | ace, thanks | 14:20 |
| *** alexismonville has joined #storyboard | 14:20 | |
| alexismonville | Zara: hello, I would like to know if there was a discussion around this proposed changed https://review.openstack.org/#/c/314185/ | 14:21 |
| Zara | hi, alexismonville! :) yeah, we're happy with it so far, we're waiting for the spec to be finished as the parts remaining aren't things we can add (that's up to fungi, ttx or jeblair, I believe). | 14:23 |
| alexismonville | thanks Zara | 14:24 |
| Zara | I'm also hoping the proposed approach leads to more contributors :) | 14:24 |
| alexismonville | that's why I ask | 14:24 |
| alexismonville | potential contributors are pinging me everyday to know... | 14:24 |
| Zara | oooh, great! :D this channel is probably the best place for people to ask where they can help out. | 14:26 |
| ttx | Yeah, I feel like I can't bring that spec to the next stage. Too many battles to fight. I'll likely need someone to pick it up | 14:26 |
| alexismonville | ttx: I thinks this particular one needs your attention :) | 14:27 |
| fungi | and i'm happy to help finish drafting it, but balancing with ptl duties and other commitments i've already made would be tough | 14:27 |
| fungi | ideally someone on the tc would be a driver | 14:28 |
| fungi | if not the tc chair | 14:28 |
| persia | From my reading, the main blocker is identifying the set of features that SB lacks and would need to be resolved before any migtration. | 14:28 |
| Zara | I think the bits we definitely can't add ourselves are the things referred to in line 171 | 14:28 |
| ttx | alexismonville: agree it's important. But it's also one where I bring less value than others (I'm not the main user anymore, not even representative). So I'm working within my team at the foundation to find someone to pick it up. | 14:28 |
| Zara | snap | 14:28 |
| persia | Making that pretty or adding language is something many of us could do, but the list requires someone confident of OpenStack needs at a high level. | 14:29 |
| Zara | + SotK and I are thoroughly biased. | 14:29 |
| fungi | btw, need any more help with the storyboard-dev server? | 14:31 |
| fungi | i guess we should update the draft jobs for webclient changes to point there now | 14:31 |
| Zara | sotk has sent a patch for that! | 14:31 |
| fungi | ooh! link me | 14:31 |
| Zara | https://review.openstack.org/#/c/318702/ | 14:31 |
| Zara | he was so fast | 14:32 |
| fungi | wow, recent | 14:32 |
| fungi | i must be taking subliminal queues from him | 14:32 |
| fungi | er, cues too | 14:32 |
| * fungi always uses the wrong cue/queue | 14:32 | |
| Zara | :) the first thing we planned to use it for was load-testing, to see how storyboard scales, so now we need to work out *how* to do that. and the other thing we were just discussing was how to clearly distinguish it from storyboard.openstack.org, so people don't confuse the two and file their bugs in the dev server. | 14:33 |
| fungi | yeah, some minor theming/css ought to take care of that | 14:33 |
| Zara | yeah, and I think that one's on us. | 14:34 |
| SotK | making it survive a puppet apply will be interesting I suspect | 14:34 |
| Zara | =D | 14:34 |
| Zara | yes | 14:34 |
| fungi | as for 318702 i guess that will be self-testing so we can see it work correctly on the draft job once it runs | 14:34 |
| persia | How is pedroalvarez doing it for his deployment? Can the same mechanism be used? | 14:34 |
| Zara | pedroalvarez uses an ansible role | 14:34 |
| fungi | we probably need to roll back the cors provisions for docs-draft on production storyboard once this lands | 14:34 |
| fungi | for added safety | 14:35 |
| * SotK expects pedroalvarez builds the webclient from source with some custom css theming | 14:35 | |
| SotK | pedroalvarez? | 14:35 |
| persia | Zara: Yes, but aren't the issues with surviving puppet apply the same for ansible (in terms of branding)? | 14:35 |
| pedroalvarez | SotK: you are right | 14:35 |
| Zara | ah right, so the role is for the api | 14:36 |
| persia | fungi: The other topic of discussion for the dev server was data population: the suggestion was to wipe and copy production data on some schedule, possibly not copying private stories. Do you have an opinion on the safety of that? | 14:37 |
| SotK | I assume the role either also does the build, or deploys the result of it | 14:37 |
| pedroalvarez | the role does almos the same that the puppety thing does | 14:37 |
| pedroalvarez | except that bit, I found that branding was only possible when building the webclient from source | 14:37 |
| Zara | hehehe, the one thing... xD | 14:38 |
| pedroalvarez | and puppet scripts take a tarball from somewhere, I believe | 14:38 |
| SotK | yeah, they do | 14:38 |
| pedroalvarez | which is faster | 14:38 |
| fungi | persia: it sounds reasonable. we could add a cron job on the production server which sanitizes/filters a db dump, generate an ssh key for the storyboard user on the production server and authorize it for thr storyboard user on the dev server, allowing us to push that dump over and load it | 14:39 |
| SotK | fungi: that seems like a good approach to me | 14:40 |
| fungi | pedroalvarez: for branding, we could of course add a step which replaces the default theme with a custom one. include a generic theme in the storyboard repo/tarballs and then have separate repos for other themes | 14:40 |
| fungi | just stick that replacement call in the deployment routine after the base tarball is unpacked | 14:41 |
| * fungi is handwaving | 14:41 | |
| pedroalvarez | o/ | 14:41 |
| Zara | sounds hopeful, though! | 14:41 |
| Zara | I want a rainbow one | 14:41 |
| pedroalvarez | yeah, we could do that | 14:41 |
| pedroalvarez | making them look different is key | 14:41 |
| persia | Another option (which might make pedroalvarez's life easier) would be to not have any branding in the default client code, and then have a separate branding piece that is separately deployed to each server (also helps with dev differentiation), with local references. | 14:42 |
| persia | So non-OpenStack deployments would just populate that once, and could safely consume the OpenStack published tarball for CD. | 14:42 |
| Zara | that sounds more compliated, since aiui then either you end up with a client which can't run without the branding, but is split off from it-- or one with default branding, which is what we have atm (I think our default branding is just 'use red', there will always be some default colour) | 14:45 |
| Zara | *complicated | 14:46 |
| Zara | perhaps I misunderstood it, though | 14:46 |
| persia | Oh, right. In that case, maybe have the default branding be the dev-server branding, and use differentiated branding for production deployments. | 14:46 |
| persia | And have the code look for new branding, and only fall back to the default branding in the case it does not exist. | 14:47 |
| persia | (so, try to load a file for the CSS: if it doesn't exist, load the default, etc.) | 14:47 |
| persia | Unless I misunderstand the key branding assets are the core colours and the icons. | 14:47 |
| persia | Rather, just the big icon in the upper left. | 14:48 |
| SotK | isn't it easier to just overwrite the CSS when deploying with puppet/ansible? | 14:48 |
| SotK | (so deploy webclient with defaults, deploy server-specific branding on top) | 14:48 |
| persia | Ignoring race conditions, yes :) | 14:48 |
| Zara | this is how the theming currently works, for the curious: http://git.openstack.org/cgit/openstack-infra/storyboard-webclient/tree/src/theme | 14:48 |
| SotK | which race condition am I missing? | 14:48 |
| * persia often chooses correct over effective, so is not always a good source of ways of doing things | 14:48 | |
| persia | SotK: A request between unrolling the tarball and applying the branding change could potentially deliver the incorrect branding. | 14:49 |
| *** jamesmcarthur has quit IRC | 14:49 | |
| persia | Making that happen requires precise timing, and a refresh would probably fix it for anyone not aggressively caching. | 14:49 |
| SotK | hm, true | 14:50 |
| pedroalvarez | unpack on a temporary place, re-brand, move to producition place | 14:50 |
| persia | pedroalvarez: Excellent workaround. Much less can break than the complicated scheme I outlined before. | 14:51 |
| Zara | :) especially since aiui re-branding is putting 'brand-primary' in a file in the custom folder (and possibly something called favicon.ico to overwrite the default) which sounds automatable. | 14:56 |
| Zara | (http://git.openstack.org/cgit/openstack-infra/storyboard-webclient/tree/src/theme/custom ) | 14:56 |
| SotK | yeah, things in src/theme/custom/theme.less override things in src/theme/base/theme.less (I think those are the paths) | 14:58 |
| SotK | the build-from-source requirement is because we compile those .less files into one big css file to serve | 14:58 |
| Zara | yup, the default storyboard branding comes from here atm: http://git.openstack.org/cgit/openstack-infra/storyboard-webclient/tree/src/theme/storyboard (so really it's line 12 of the theme.less, and the favicon) | 15:03 |
| Zara | ^ that's for general reference, in case anyone's interested | 15:04 |
| Zara | (just wanted to make it clear that this isn't a case where the storyboard code itself has branding tied up in with the webclient functionality; it's already designed to be overwritten with custom things.) | 15:05 |
| persia | Yeah, the branding support went in a couple years ago: I think the only confusion comes from the compiled CSS importing the branding, such that if one isn't building from source, one has more difficulty overriding. | 15:07 |
| persia | The complicated suggestion came from that, the idea being that if custom branding assets exist on the server, those should be used, even after building the one-big-css file. | 15:08 |
| persia | But I think I like the rebrand-post-deployment-then-move-into-place model better, in terms of number of moving parts, etc. | 15:09 |
| * SotK too | 15:10 | |
| Zara | yup | 15:10 |
| persia | so, the tricky part there is how: does one insert custom branding and rebuild the CSS, or modify the generated CSS directly in the branding step? | 15:11 |
| Zara | insert, rebuild is probably easier | 15:11 |
| persia | And if the latter, does it make sense to have the custom branding override in the code? | 15:11 |
| persia | Does that change the requirements on the server? | 15:12 |
| *** mrmartin has joined #storyboard | 15:12 | |
| persia | I remember a discussion about the architecture being about trying to reduce server requirements, so one just delivered dumb files to be served by apache, and didn't need to have npm on the server. | 15:12 |
| persia | But if the less needs to be rebuilt, that changes things. | 15:12 |
| * persia notes that remembered discussions about branding are but poorly remembered and date from 2014, so may no longer be particularly relevant | 15:16 | |
| Zara | I feel like npm isn't a big requirement these days, could be wrong | 15:17 |
| * SotK would like to have a way to do it without npm on the server | 15:17 | |
| SotK | I don't yet know what that way is though | 15:17 |
| *** jamesmcarthur has joined #storyboard | 15:18 | |
| *** mrmartin has quit IRC | 15:18 | |
| Zara | aw, I think the drafts patch needs a recheck | 15:19 |
| *** jtomasek_ has quit IRC | 15:19 | |
| persia | For no-npm-on-server, I see two ways. A) have a build stage for each deployment that applies branding, B) have the branding overrides be exposed in the CSS so that magic extra files on a server cause brand overrides with no rebuild (requires separated repos) | 15:19 |
| SotK | Zara: looks to have worked though looking at the js-draft :D | 15:19 |
| SotK | I'd prefer the extra repos way, but I expect it to be messy | 15:20 |
| Zara | bear in mind at this point this is a 1 line change. | 15:21 |
| SotK | ? | 15:21 |
| Zara | for the way we'd change the branding, if we're currently just doing it to make sure dev looks different to prod, that's one variable that is changing value to a different hex. | 15:22 |
| SotK | hmm, maybe we can allow config.json to be set up via puppet, and pass extra css file paths with that | 15:22 |
| SotK | that's why I think extra repos would be messy | 15:22 |
| *** jamesmcarthur has quit IRC | 15:23 | |
| persia | I think extra repos would also mean pulling out the existing theme support (because it doesn't work so well in production), and refactoring the theme-relevant attributes out into the smallest file possible, so that most of the CSS would just work. | 15:24 |
| SotK | yep | 15:24 |
| Zara | grr, more recheck | 16:06 |
| *** xenthree3 has joined #storyboard | 16:07 | |
| *** xenthree3 has left #storyboard | 16:07 | |
| openstackgerrit | Pedro Alvarez Piedehierro proposed openstack-infra/storyboard-webclient: Close card-details modal when clicking on the Story link https://review.openstack.org/318779 | 16:54 |
| Zara | :0 a wild pedro appears! | 16:55 |
| pedroalvarez | not sure if you would consider this a bug, but here it is | 16:55 |
| pedroalvarez | So, you go to a board, open a card modal, click on the Story link, and the card modal remains open | 16:56 |
| Zara | haha, no, I do consider that a bug. never caught it because I always open the link in a new tab | 16:56 |
| Zara | I can see how someone might prefer the modal to stay up, but that's not behaviour I'd intend | 16:56 |
| Zara | I'll test that patch now, thanks | 16:57 |
| pedroalvarez | no worries :) | 16:57 |
| pedroalvarez | I found the behavior annoying, that's why I patched it | 16:57 |
| pedroalvarez | but as always, open to discussion | 16:57 |
| Zara | yeah, I like the change, anyway. :) all the information contained in the card, except due date, is available on the detail page anyway, so there's not really a good reason to keep both open by default (and users can still just open the story in a new tab if they want the card details visible) | 17:01 |
| pedroalvarez | I/me nods | 17:07 |
| * pedroalvarez too | 17:07 | |
| openstackgerrit | Pedro Alvarez Piedehierro proposed openstack-infra/storyboard-webclient: Close card-details modal when clicking on the Story link https://review.openstack.org/318779 | 17:20 |
| pedroalvarez | thanks for the review | 17:21 |
| pedroalvarez | checks seem to be failing for that patch, though | 17:22 |
| openstackgerrit | Zara proposed openstack-infra/python-storyboardclient: WIP Proof of Concept Storyboard Updating from Gerrit https://review.openstack.org/302912 | 17:23 |
| openstackgerrit | Pedro Alvarez Piedehierro proposed openstack-infra/storyboard-webclient: Close card-details modal when clicking on the Story link https://review.openstack.org/318779 | 17:23 |
| Zara | yeah the js-draft patch from earlier needed a recheck, so it might just be that | 17:24 |
| Zara | I just updated the gerrit patch with my comments on where it was going, it's still a total mess | 17:24 |
| Zara | I thiiiink the control flow is working, now (famous last words) | 17:25 |
| Zara | though hard to test since it has no sensible error-handling, so errors out before I can check if it's updating every time it should :P | 17:28 |
| *** mrmartin has joined #storyboard | 17:32 | |
| Zara | yeah, it looks like the control-flow works. had the events stream open in one tab, had my api in another, refreshed page each time events stream updated, task notes changed to match commit message | 17:33 |
| *** mrmartin has quit IRC | 17:36 | |
| Zara | so it doesn't yet seem able to handle things of this type: {"project":"openstack/keystone","ref":"refs/changes/07/317007/6","targetNode":"git07.openstack.org","status":"succeeded","type":"ref-replicated","eventCreatedOn":1463679432} | 17:38 |
| Zara | to use a sample event | 17:38 |
| Zara | probably because there is no 'change' field | 17:39 |
| Zara | so that script needs something to the effect of 'if change is none, don't freak out' | 17:39 |
| Zara | well that's enough idiosyncratic pseudocode for one day, night! | 17:40 |
| pedroalvarez | does it drop an error like "ValueError: too many values to unpack" | 17:40 |
| pedroalvarez | ? | 17:40 |
| Zara | no, I get TypeError: 'NoneType' object is not iterable | 17:41 |
| pedroalvarez | ahh, yes | 17:41 |
| pedroalvarez | we can solve that problem too :) | 17:41 |
| Zara | so yeah, atm it goes 'if the key is 'change', do stuff-- and there's no 'else' :D | 17:41 |
| Zara | so it just goes 'oh, okay, guess I'll stop then' | 17:42 |
| Zara | haha, I just saw your comments in the stream events! that's fun | 17:50 |
| Zara | I'll look more at it tomorrow, anyway, thanks for taking time to have a look at it | 17:50 |
| pedroalvarez | hahah | 17:50 |
| pedroalvarez | :) | 17:50 |
| pedroalvarez | night | 17:50 |
| Zara | night :) | 17:50 |
| *** lifeless has quit IRC | 18:26 | |
| *** lifeless has joined #storyboard | 18:26 | |
| *** sparkycollier has quit IRC | 18:31 | |
| *** sparkycollier has joined #storyboard | 18:33 | |
| *** jamesmcarthur has joined #storyboard | 20:41 | |
| *** jamesmcarthur has quit IRC | 20:50 | |
| *** jamesmcarthur has joined #storyboard | 20:52 | |
| *** jamesmcarthur has quit IRC | 21:02 | |
| *** jamesmcarthur has joined #storyboard | 21:08 | |
| *** jamesmcarthur has quit IRC | 21:13 | |
| *** jamesmcarthur has joined #storyboard | 22:09 | |
| *** jamesmcarthur has quit IRC | 22:14 | |
| *** jamesmcarthur has joined #storyboard | 22:17 | |
| *** jamesmcarthur has quit IRC | 22:18 | |
| *** jamesmcarthur has joined #storyboard | 22:28 | |
| *** jamesmcarthur has quit IRC | 22:49 | |
| *** jamesmcarthur has joined #storyboard | 23:12 | |
| *** jamesmcarthur has quit IRC | 23:17 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!