| *** Dobroslaw has joined #storyboard | 04:18 | |
| SotK | persia: thats probably a sensible idea, I'll send a new version later | 05:44 |
|---|---|---|
| *** jtomasek has joined #storyboard | 05:56 | |
| Zara | thanks for those | 12:36 |
| *** Dobroslaw has quit IRC | 13:49 | |
| SotK | yw, I'm a little concerned it doesn't entirely solve the issues given it timed out in zuul, but it makes things much tidier at least | 14:53 |
| Zara | yeah, at this point I think the only reason to use the ancient versions would be for debugging purposes | 14:55 |
| *** jtomasek has quit IRC | 17:30 | |
| *** jtomasek has joined #storyboard | 17:31 | |
| * SotK wonders where a good place in the docs for this is | 18:08 | |
| SotK | I guess I'll put it in the migration README | 18:08 |
| SotK | and maybe write some docs for upgrading an instance in a different commit | 18:08 |
| openstackgerrit | Adam Coldrick proposed openstack-infra/storyboard master: Consolidate old database migrations https://review.openstack.org/510370 | 18:58 |
| Zara | thanks again | 19:01 |
| Zara | it may be worth including a note in the 'installing and running...' docs since they're rendered online and more likely to be seen, though I'm wondering if most folk really need to see it | 19:03 |
| Zara | maybe the only people it'll apply to would be delving deeper into the repo anyway | 19:04 |
| SotK | my logic was that if someone was upgrading they're probably not going to look in the installation guide | 19:06 |
| SotK | then I realised we should probably have an upgrade guide on docs.o.o | 19:06 |
| Zara | yep | 19:07 |
| Zara | I agree with all that | 19:07 |
| SotK | \o/ | 19:10 |
| *** jtomasek has quit IRC | 19:13 | |
| *** diablo_rojo has joined #storyboard | 19:21 | |
| openstackgerrit | Adam Coldrick proposed openstack-infra/storyboard master: Add documentation on manually upgrading a StoryBoard instance https://review.openstack.org/510669 | 19:43 |
| SotK | I based that on https://review.openstack.org/510370 since I wanted to include a warning about the consolidated migrations | 19:44 |
| Zara | *nod* | 19:58 |
| openstackgerrit | Adam Coldrick proposed openstack-infra/storyboard master: Properly populate Worklist.items in automatic worklists https://review.openstack.org/307712 | 20:01 |
| SotK | whilst people are vaguely around, I was thinking about https://storyboard.openstack.org/#!/story/2000132 yesterday when consolidating those migrations | 20:07 |
| SotK | and I was wondering how folk feel about the idea of reintroducing an optional username field, which isn't populated by launchpad | 20:08 |
| SotK | kind of like how Gerrit works | 20:09 |
| SotK | s/launchpad/the openid provider/ | 20:10 |
| persia | login.ubuntu.com these days, no? | 20:10 |
| persia | But, yes, I think it makes sense to allow users to add a nickname. | 20:11 |
| persia | Enough people don't know my actual name that having "Emmet Hikory (persia)" would be valuable, despite my having a globally unique given name. | 20:11 |
| persia | For folk named "John Smith", this is more important. | 20:11 |
| * persia once worked for a consultancy under a man named "John Smith", and was dispatched for onsite work under another man named "John Smith": it wasn't hard to figure out the thing they had in common to smooth the sale | 20:12 | |
| persia | Do we reliably know the user's IRC nick? Perhaps from their foundation member profile? | 20:13 |
| SotK | the member profiles have a field for IRC nick, but its optional | 20:18 |
| * SotK wonders how easy it is to map openstackid accounts to login.ubuntu.com accounts | 20:19 | |
| persia_ | Some will map by email address. | 20:24 |
| persia_ | I believe it is a requirement to have the login.ubuntu.com email address as one of the gerrit addresses, and email addresses are supposed to be unique. | 20:25 |
| persia_ | We have been imposing a rule that folk cannot vote in PTL elections unless their have a matching email address between gerrit and their foundation email address, and the code that detects when things go wrong has had a few updates in the past few months, which helps with automatic mapping. | 20:26 |
| persia | http://git.openstack.org/cgit/openstack-infra/system-config/tree/tools/owners.py has some code that might be relevant | 20:27 |
| persia | Some folk may be missed, especially folk who don't have gerrit accounts. I'm not sure what to do about that, precisely. | 20:28 |
| persia | Maybe just do the lookup of email addresses in the member directory directly? | 20:28 |
| persia | And if it doesn't return anything, notify the user somehow? | 20:29 |
| SotK | thanks for the link, it does indeed look useful | 20:30 |
| persia | Note that the code in question is scheduled for refactoring and may move away from that location, so be careful about how you depend upon it. | 20:30 |
| persia | That said, all the folk who have expressed a desire to do anything with it are likely fairly busy through at least mid-November, so it won't change right away. | 20:31 |
| SotK | I wonder how best to implement this, since ideally the nickname field wouldn't be tied to foundation membership except for storyboard.o.o, and yet it'd also be best to have the lookup happen when a user logs in for the first time | 20:32 |
| SotK | it'd be nice if we had a gerrit-like events stream... | 20:32 |
| persia | Wasn't there some code to do that at some point? | 20:34 |
| persia | I'm not sure it needs the connect-over-ssh-... model | 20:34 |
| persia | But perhaps some port to which one can attach that steams things some other way? | 20:34 |
| * persia doesn't actually know that much about secure and sensible architectures for event streams | 20:35 | |
| * SotK remembers that the rabbitmq notification system exists | 20:39 | |
| SotK | somehow in my head that only supported a subset of things | 20:40 |
| persia | Or, more generally, AMQP :) | 20:40 |
| persia | And that's precisely the sort of pub/sub model I was thinking would make sense | 20:40 |
| persia | But I'm not sure how that relates to name display | 20:41 |
| persia | (yes, it did take me that long to realise the topic had changed) | 20:41 |
| SotK | well, I wouldn't want to hardcode a dependency on some kind of API which provides IRC nicks when queried by email address in storyboard itself, and so was contemplating a way to trigger the lookup only when a user was created | 20:44 |
| SotK | and apparently I forgot we already have stuff in place for things like that | 20:44 |
| persia | Ah, that makes sense. | 20:45 |
| persia | Something that queries the foundation API on user creation, and then sits idle and ignores everything. | 20:45 |
| persia | It might make sense to have a one-time migration to populate the DB. I'm not sure what other deployers might do though. | 20:45 |
| persia | (all the more reason not to hardcode a dependency or add this code directly to Storyboard) | 20:46 |
| SotK | replace one-time-migration with "a script to run manually once" and there will be no effect on other deployers | 20:47 |
| persia | Hrm? What about the on-new-account-do-something-to-populate-the-field? Where would that live? | 20:48 |
| SotK | it could be an openstack-specific plugin similar to those for subscription events and emails, I'm not settled on where exactly the code should live though | 20:50 |
| persia | That makes sense. | 20:54 |
| * SotK adds some tasks to https://storyboard.openstack.org/#!/story/2000132 based on the above | 21:05 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!