19:02:40 <fungi> #startmeeting infra
19:02:41 <openstack> Meeting started Tue Jun 10 19:02:40 2014 UTC and is due to finish in 60 minutes.  The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:45 <openstack> The meeting name has been set to 'infra'
19:02:47 <jesusaurus> o/
19:02:49 <SergeyLukjanov> fungi, ++
19:03:07 <SergeyLukjanov> and I think I have a big latency ;)
19:03:11 <fungi> #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting
19:03:23 <fungi> #topic Actions from last meeting
19:03:41 <anteaya> I like the quick topics
19:03:51 <fungi> #link http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-06-03-19.02.html
19:03:54 <fungi> there were none
19:03:59 <fungi> (that was quick)
19:04:02 <anteaya> :D
19:04:18 <fungi> #topic Manage-projects status (fungi, mordred)
19:04:35 <fungi> mordred fixed a new bug today
19:04:35 <mordred> fungi: I pushed a patch to fix the current issue
19:04:39 <fungi> #link https://review.openstack.org/99136
19:04:39 <mordred> it was a fun one
19:04:53 <mordred> everyone should marvel at its wonder
19:04:57 <fungi> i haven't gone back to see if the recently added projects are updated yet
19:05:06 <clarkb> huh how did that sneak in
19:05:21 <mordred> clarkb: it came in during the exception error cleanup
19:05:24 <clarkb> ah
19:05:33 <mordred> and it's one of those places where the backwards logic makes your head spin
19:05:39 * anteaya marvels
19:05:49 <clarkb> mordred: go bourne?
19:06:01 <mordred> clarkb: :)
19:06:23 <fungi> also there's still an open review to add some extra race safety around acl creation... no idea if it's actually needed any longer
19:06:26 <fungi> #link https://review.openstack.org/94684
19:06:49 <fungi> anything else to cover on this before i move to the next topic?
19:07:18 <clarkb> fungi: I think we can be defensive and mrege that change
19:07:18 <fungi> #topic Review proposal to move Activity Board fully under openstack-infra (reed)
19:07:20 <clarkb> I will rereview
19:07:24 <fungi> thx
19:07:33 <fungi> #link http://lists.openstack.org/pipermail/openstack-infra/2014-June/001292.html
19:08:09 <fungi> reed: apologies for not following up yet. it's been a crazy week. i think mordred replied a couple times on that thread though
19:08:24 <mordred> I have. I think we're making progress in the thread
19:08:26 <reed> #info the gist of it is that we're going to need assistance in order to achieve that. Bitergia is not self-sufficient and being an external provider it may become quite expensive.
19:08:43 <mordred> I think we can make the puppet without problems, I read through their docs
19:08:53 <mordred> but I think we may need slightly more detailed install instructions from them
19:09:05 <rdopieralski> hi
19:09:14 <reed> mordred: i think so too, the basic install shouldn't be too complicated
19:09:22 <mordred> the stackalytics install instructions I referenced are a great example of about the level of detail we need
19:09:33 <reed> I'll have them provide those
19:09:36 <fungi> rdopieralski: welcome... you haven't missed your topic yet, so just hang in there
19:09:55 <mordred> reed: it took me about an hour to puppet stackalytics, so I dont' think it'll take long to do activity board
19:10:06 <rdopieralski> fungi: thank you
19:10:16 <reed> there are other 'puppetification' jobs we need to do, too, askbot for example
19:10:17 <clarkb> mordred: cool
19:10:24 <clarkb> reed: ugh
19:10:36 <clarkb> reed: as long as I don't have to do it <_<
19:10:39 <mordred> clarkb: askbot might not be as bad anymore since we've got postgres in puppet at this point
19:10:57 <mordred> although it woudl be eversonice if it would run on mysql so we could use rax cloud dbs
19:11:07 <reed> clarkb, and this time we have the head developer on board :)
19:11:13 <clarkb> I mean yes we could just postgres it
19:11:17 <mordred> ++
19:11:18 <reed> Evgeny agreed that it would be a good idea to do it
19:11:26 <mordred> let's get activity done first
19:11:28 <clarkb> ++
19:12:01 <reed> yes, I agree, activity first because it's 1) easier and 2) askbot requires a bit more thoughts on a more resilient architecture, too
19:12:05 <fungi> mordred: i'm still a little twitchy about rackspace's trove service since it's query socket is accessible from all tenants in the same region... we might want to hold off putting more stuff in it until we get a better comfort level for that
19:13:02 <mordred> fungi: we can get iccha1 to fix that now!
19:13:05 <reed> #task reed to ask Bitergia to provide detailed instructions to run the grimoire suite
19:13:11 <fungi> (though it sounds like neutron is needed to be able to address it)
19:13:25 <mordred> fungi: several things are needed I believe, but yeah
19:13:56 <reed> next topic?
19:14:07 <mordred> fungi: we could always move to just running our own galera cluster in which all of our dbs lay with ssl cert-based auth ...
19:14:12 * mordred shuts up
19:14:16 <fungi> #topic Review proposal towards a better integration of gerrit and openstack people db (reed)
19:14:24 <fungi> #link http://lists.openstack.org/pipermail/openstack-infra/2014-June/001297.html
19:14:43 <fungi> another awesome e-mail i'm sorry i haven't replied to yet. it's flagged for attention still :/
19:14:43 <reed> so, this one is detailed in a blog post by me, etherpad and blueprint
19:14:56 <reed> no problem
19:15:07 <reed> the TL;DR version:
19:15:31 <reed> we're going to build a directory of people involved in openstack
19:16:02 <reed> built on top of the current 'members' database, and exposing OpenID services
19:16:08 <morganfainberg> yeah.
19:16:11 <anteaya> please no pictures
19:16:11 <morganfainberg> that was a topic from the summit
19:16:14 <reed> the database will not be of Foundation members
19:16:26 <morganfainberg> this is the replacement for LP SSO right?
19:16:34 <reed> not only, at least, multiple roles are envisioned
19:16:39 <fungi> morganfainberg: right, and more
19:16:40 <morganfainberg> well one of the roles.
19:16:42 <reed> morganfainberg, yes, also
19:16:44 <morganfainberg> yep
19:17:01 <morganfainberg> as i said at the summit, count me on this front. ahppy to help
19:17:07 <mordred> woot
19:17:26 <clarkb> one concern on my end is we need to make sure doing something other than openid is feasible
19:17:27 <reed> Right now we have members==developers, speakers, voters to talks and a few other smaller roles
19:17:51 <anteaya> clarkb: ++
19:17:56 <morganfainberg> unfortunately ubuntu running freeipa (longer view) wont... really occur, though fedora if could [again if we wanted to move away from the peopledb info]
19:18:02 <reed> clarkb, why? until now I have insisted on openid because my understanding is that gerrit won't do anything but openid
19:18:03 <morganfainberg> s/if/it
19:18:06 <anteaya> since gerrit is changing its auth strategy
19:18:26 <morganfainberg> clarkb, what auth strategies do we need?
19:18:27 <clarkb> reed: gerrit is potentialyl removing openid
19:18:31 <mordred> reed: gerrit will also do ldap - and yes, upstream gerrit is starting to want to make openid go away
19:18:38 * reed yells at the cloud
19:18:45 <clarkb> mordred and zaro have pinged them and it looks like we may get an openid plugin
19:18:51 <mordred> morganfainberg: I thought freeipa on ubuntu was coming?
19:18:54 <clarkb> but I wasn't super convinced given spearce's stance
19:18:54 <mordred> clarkb: awesome
19:18:56 <morganfainberg> ok LDAP is easy
19:18:58 <morganfainberg> mordred, it's... slow
19:19:05 <reed> ldap is crap
19:19:07 <morganfainberg> mordred, i'm still trying to lean on people to get resources
19:19:18 <clarkb> I think starting with openid is great
19:19:19 <mordred> reed: well, let's not go to the "is crap" place just yet
19:19:23 <clarkb> we have openid today and will have it tomorrow
19:19:25 <mordred> clarkb: ++
19:19:26 <morganfainberg> mordred, but it's hard to get commitment on it.
19:19:31 <reed> anyway, this is largely independent from the crap we have to deal with :)
19:19:31 <clarkb> just keep in mind that openid may not be the only thing we need to do
19:19:35 <mordred> reed: yes
19:19:43 <fungi> gerrit will actually do other things besides openid now and has for a while (for example ldap)
19:19:55 <morganfainberg> mordred, it might be if we do FreeIPA we run fedora for those boxen until ubutnu is stable+happy
19:19:56 <reed> currently the OpenID service is just a php app built on top of a couple of database tables
19:20:01 <morganfainberg> it's coming, just might be longer than this dev cycle
19:20:06 <mordred> I think clarkb's point is excellent - in making the db, we should keep in mind we might want to put more than one access method on top of it
19:20:27 <mordred> morganfainberg: well ... our biggest problem is the fedora lifecycle - but we can come back to that
19:20:33 <fungi> but yes, i agree that openid is a good initial target and then we just need to make sure it's not designed to make it harder than necessary to hook in other protocols later as needed
19:20:35 <reed> now, the reason for this topic in the agenda is that I'd like to make sure that we design the tables and the database to keep into account all of the things that gerrit needs
19:20:39 <morganfainberg> reed, there was some desire to not use the people db info directly, some data that shouldn't be used?
19:20:45 <morganfainberg> i think i remember
19:21:05 <reed> morganfainberg, not sure I follow... do you remember something more?
19:21:20 <mordred> reed, morganfainberg: I believe they were talking about wanting to be able to split the db into people db and then also some of the info that the foundation might need that the project might not want access to
19:21:25 <morganfainberg> reed, there was extra data in the people db there was concern about exposing
19:21:30 <mordred> that ^^
19:21:35 <reed> right ...
19:21:56 <reed> the DB itself won't be publicly available, ever, there are personal data in there that we're not allowed to share
19:22:00 <mordred> because ultimately we want to be able to operate the people db in infra, but we don't want to have secrets in there that it would be inappropriate for infra to be privy to
19:22:09 <morganfainberg> mordred, ++
19:22:16 <fungi> yeah, separation of concerns... not just dumping it all together
19:22:19 <reed> right now running the people DB in infra is not an option
19:22:26 <fungi> agreed
19:22:31 <morganfainberg> it might make sense to separate concerns and sync the important infra-safe info to the new db somehow?
19:22:41 <morganfainberg> to begin with.
19:22:56 <morganfainberg> or is that biting off too much/boiling the ocean
19:23:04 <reed> morganfainberg, boiling :)
19:23:05 <fungi> from what i understand more refactoring of the current database is needed to separate out authentication and basic account info from foundation membership stuff
19:23:19 <reed> fungi, exactly
19:23:29 <morganfainberg> reed, fair enough. lets use what we have and then work on a split.
19:24:15 <fungi> the idea i think is that we get a toehold by running the openid service connecting to the current database with some constraints on the db server end and then try to get a new authentication/accounts db separate from it running in parallel
19:24:16 <reed> new database will need to have all the details for gerrit to authorize commits, and contain also status about each person: is that person a developer? a speaker? something else?
19:24:26 <fungi> the migration could be piecemeal if we do it carefully
19:24:27 <morganfainberg> fungi, ++
19:24:55 <morganfainberg> reed, i'd like to circle back on that and see about something like FreeIPA (if possible) when we split vs. just-another-SQL-back-end
19:24:59 <reed> this is also an attempt at simplyfing *a lot* the onboarding of new developers
19:25:01 <clarkb> is the intent to keep the existing HTTP request to db get back 200 for signed CLA?
19:25:07 <clarkb> er keep that process?
19:25:17 <clarkb> in that case gerrit doesn't need to know anything really
19:25:18 <fungi> clarkb: i think we should be able to replace that
19:25:24 <clarkb> fungi: how?
19:25:25 <reed> clarkb, not if we can make it better
19:25:36 <clarkb> I think I am missing that important piece
19:25:49 * mordred is too
19:25:52 <mordred> fungi: can you splain?
19:25:54 <clarkb> if we do have this magical pony
19:26:13 <clarkb> how do we interact with it? because that will help determine the size and shape of this thing
19:26:19 <mordred> ++
19:26:23 <fungi> clarkb: leave the cla signing in but drop the contactstore connection. instead the openid data should be sufficient to (hopefully) marry to group membership api calls now that those exist and now that all clas in current gerrit are group-based not tracked in separate tables
19:26:27 <reed> we want to get to a place where openstackid.org shows profile pages for each person involved in openstack
19:27:09 <mordred> fungi: you're suggesting that the openid thing simply doesn't auth if the person doesn't have the CLA?
19:27:10 <reed> person creates an account, goes to groups.openstack.org, checks things there...
19:27:30 <fungi> mordred: no, not at all suggesting that
19:27:33 <reed> maybe later signs the CLA, commits code, maybe later becomes a member of the foundation, a speaker... etc
19:27:46 <reed> all with one identity managed by us
19:28:03 <clarkb> fungi: so we would be going back to syncing against an openid service?
19:28:07 <morganfainberg> reed, so o.o properties would be SSO to this system
19:28:12 <mordred> ok. I get all that. I have two questions that I would like asnwered
19:28:13 <fungi> mordred: suggesting that the reason we did the contactstore thing was twofold... to make sure the contributor was a foundation member first and to track the correlation to their gerrit account (the latter of which was never done entirely properly anyway)
19:28:13 <clarkb> fungi: just with API calls isntead of direct DB manipulation?
19:28:38 <fungi> but for anyone to sign the cla in gerrit, they have to log into gerrit, which now means they have an openid account in our openid provider
19:28:49 <reed> morganfainberg, SSO would be cool but until now, all the design choices depend on what gerrit provides... openid I was told and openid I had implemented
19:28:58 <morganfainberg> reed, sure.
19:28:59 <mordred> fungi: ah. ok
19:29:14 <fungi> clarkb: syncing? not needed this way as far as i know
19:29:25 <clarkb> fungi: I see so we would purely rely on the data provided by openid
19:29:30 <mordred> fungi: so how does the foundation get information that a user has signed the CLA?
19:29:47 <reed> mordred: right nkow the foundation doesn't know that
19:29:49 <fungi> gerrit handles cla signing and enforcement. it auto-adds users to per-cla gerrit groups now. there is also an api call to enumerate group members in gerrit
19:29:59 <mordred> ok
19:30:09 <clarkb> so we would sync the other direction and that is where the APIs come into play
19:30:16 <fungi> yep
19:30:24 <reed> mordred: in fact, the foundation needs to query gerrit directly to find the list of ATCs
19:30:33 <mordred> seems fine to me
19:30:35 <fungi> the foundation can, when and as often as it wants, query gerrit to find out who's signed the cla
19:30:37 <mordred> I like it
19:30:44 <clarkb> ya I think that should work fine
19:30:47 <fungi> via a rest api now even
19:31:32 <fungi> so between having openid authentication info and the cla lookups, the foundation can correlate whatever they need
19:31:41 <mordred> ++
19:31:41 <fungi> where gerrit is concerned
19:32:00 <clarkb> so the data would be whatever gerrit thinks it should know about at https://review.openstack.org/#/settings/ and https://review.openstack.org/#/settings/contact
19:32:04 <anteaya> much better relationship
19:32:50 <reed> indeed, instead of counting on email lookups that sometimes fail with obscure error messages
19:33:02 <fungi> clarkb: so the outstanding question which someone hopefully finds time to look into soon is how much gerrit will import from openid. i know it does e-mail address and username...
19:33:23 <fungi> i suspect it does not do group membership updates from openid, but hopefully we don't need that
19:33:27 <reed> the process to onboard a new developer will be extremely linear, no back and forth between 3 accounts
19:33:51 <mordred> group memberships is an openid extension
19:34:09 <reed> fungi, gerrit may not need to know about that...
19:34:10 <mordred> gerrit does not consume it - launchpad provided it but we had to do that db sync script hell to get group info
19:34:11 <fungi> yeah, and one i'm assuming gerrit doesn't make use of
19:34:28 <clarkb> which should be fine
19:34:30 <morganfainberg> sounds like a question for zaro
19:34:30 <fungi> right, that 'splains why we didn't make use of it for gerrit
19:34:40 <reed> are you talking about groups as in 'programs'?
19:34:41 <fungi> reed: agreed
19:34:42 <morganfainberg> but, i don't think gerrit does consume that
19:34:43 <clarkb> it keeps gerrit group membership in gerrit rather than cores needing to use $thingoverthere to manage the groups
19:34:52 <mordred> yup
19:35:13 <fungi> reed: no, meaning if we wanted to control things like acls via group membership managed from the openid end rather than directly in gerrit, but probably not necessary or even desirable anyway
19:35:23 <reed> let's be clear: when I talk about 'groups' in the openid (let's call it this way at the moment) is more similar to 'affiliation'
19:35:33 <mordred> like, "Monty works for HP"
19:35:34 <clarkb> ya I don't think it is desireable
19:35:38 <mordred> not "Monty is Infra Cre"
19:35:45 <fungi> right, so not a concern
19:35:46 <mordred> s/re/ore/
19:35:48 <mordred> ++
19:36:03 <zaro> morganfainberg: sorry i don't know, would need to dig.
19:36:07 <mordred> it will be data that things like stackalytics and activity board could mine
19:36:16 <reed> mordred: right, we want to have the manager of a team specify who works for him/her on the 'People Directory'
19:36:24 * reed notes that this thing needs a name
19:36:26 <morganfainberg> zaro, no worries. sounds like it's a non-issue
19:36:32 <anteaya> really?
19:36:42 <anteaya> we want work organization trees?
19:36:50 <anteaya> or openstack organization trees?
19:36:51 <fungi> anteaya: for tracking the corporate cla
19:36:56 <anteaya> oh
19:36:56 <reed> anteaya, yes, for a couple of reasons
19:37:02 <mordred> reed: biggest thing I think we need there so that the reporting thigns can do the right thing...
19:37:11 <reed> CCLA is one, reporting is another
19:37:14 <fungi> but also for member company contribution metrics in aggregate
19:37:22 <mordred> reed: is making sure we're keeping data-warehouse style data ranges for affiliations
19:37:37 <reed> mordred: next step will be to have an API service on top of this database
19:37:38 <anteaya> k
19:38:01 <reed> an API that stackalytics, git-dm, bitergia and the world can query
19:38:21 <reed> we'll have to sit down and design that
19:38:25 <morganfainberg> reed, so, the READ part of CRUD
19:38:32 <anteaya> I like that someone can change call signs and it makes no nevermind to the rest of us
19:39:04 <reed> morganfainberg, indeed
19:39:10 <reed> so, how do we proceed?
19:39:28 <fungi> anteaya: yes, but large companies donating funds and people to the effort want to be able to show the "money people" what they're accomplishing with that
19:39:33 <reed> the blueprint and spec need feedback
19:39:41 <anteaya> fungi: true, they do
19:39:54 <anteaya> did the inital spec commit merge yet?
19:39:57 <morganfainberg> reed, have links for those handy? (i can look up if not)
19:40:10 <fungi> anteaya: i should have put that on the agenda. inserting it as a quick topic now
19:40:15 <anteaya> thanks
19:40:24 <reed> morganfainberg, from the email: http://lists.openstack.org/pipermail/openstack-infra/2014-June/001297.html
19:40:29 <morganfainberg> reed, tyvm
19:42:18 <fungi> okay, so anything else on that? we've got about 15 minutes left
19:42:44 <fungi> was definitely good to get an update and call to action there
19:42:44 <reed> fungi, I'm good, as long as I get comments on the blueprint :)
19:43:19 <fungi> yes, i will make a note to provide some feedback, please everyone with interest do the same
19:43:28 <fungi> #topic Infra specs (fungi)
19:43:36 <fungi> #link https://review.openstack.org/94440
19:43:50 <fungi> please let's get this put to bed. there are now numerous specs changes waiting on it
19:43:54 <anteaya> yes
19:43:57 <anteaya> do merge
19:44:15 <anteaya> then we can look at other specs
19:44:15 <fungi> mordred: clarkb: jhesketh: please weigh in on that
19:44:35 <clarkb> fungi: I mean I weighed in, it won't work :P
19:44:48 <clarkb> fungi: should we just go ahead and address comments and shove it through?
19:44:48 <SergeyLukjanov> ++ for merging
19:44:49 <SergeyLukjanov> :)
19:44:56 <morganfainberg> as somethng keystone just went through, have you decided what the spec approval process is? standard +2/+2/+A?
19:45:06 <morganfainberg> just so there isn't a question when it comes time to approve specs.
19:45:08 <fungi> clarkb: i think so, if the comments are blockers
19:45:31 <clarkb> fungi: not being able to build the resulting document seems like a blocker to me but I didn't -1 because you can still review specs without it
19:45:47 <mordred> clarkb: the doc doesn't build?
19:45:56 <fungi> yeah, we're not yet publishing them other than as drafts anyway, so i wasn't too worried about it, but it's trivial to fix
19:46:02 <clarkb> mordred: see my comment, it won't find docs under subdirs like implemented/
19:46:06 <anteaya> +1 address comments and shove it though
19:46:19 <fungi> #link https://review.openstack.org/#/c/94440/3/doc/source/index.rst
19:46:24 <fungi> for clark's concern
19:46:33 <mordred> clarkb: lemme pull it then - I hacked on the heat one to fix its doc build
19:46:46 <mordred> oh - or your thing
19:46:47 <fungi> anyway, didn't want to take up too much time with this topic, just wanted to make sure to get it on everyone's radar
19:46:54 <mordred> yeah. I'll go look at it.
19:47:01 <clarkb> mordred: are you volunteering to fix the issues real quick?
19:47:05 <anteaya> fix and merge is my stance
19:47:14 <clarkb> I don't think there is anything contentious just details needed to make it work properly
19:47:17 <mordred> clarkb: I'm volunteering to think about it
19:47:20 <mordred> :)
19:47:21 <clarkb> :) ok
19:47:29 <fungi> #topic Request for comments on the horizon split plan (rdopiera)
19:47:39 <fungi> #link https://etherpad.openstack.org/p/horizon-split-plan
19:47:55 <mordred> I, for one, welcome our new split horizon overlords
19:48:01 <morganfainberg> mordred, ++
19:48:03 <fungi> this seems to have been fleshed out a lot more now
19:48:18 <anteaya> rdopieralski: my comment is the same one I made on https://review.openstack.org/#/c/95716/
19:48:19 <fungi> i tried to keep up with the related threads on the -dev ml but probably missed some of the issues
19:48:35 <rdopieralski> anteaya: yes, I will make a new group for that
19:48:42 <mordred> "    in horizon, add django_horizon to requirements.txt, as -e path-to-the-repo"
19:48:43 <rdopieralski> anteaya: thank you
19:48:43 <anteaya> rdopieralski: I agree with markmc that expecting core to admin 16 repos in stackforge is odd
19:48:44 <mordred> please no
19:48:49 <anteaya> rdopieralski: k, thanks
19:49:05 <mordred> that needs to be as a refernce to the master tarball on tarballs.o.o
19:49:16 <rdopieralski> mordred: great, thank you
19:49:28 <mordred> (updated etherpad)
19:49:33 <rdopieralski> awesome
19:49:50 <fungi> what needs to be discussed here, other than making sure we're all aware this is coming? (i know the new name for the split-out half hasn't been settled yet at least)
19:50:06 <mordred> seems straightforward to me
19:50:13 <anteaya> poll is open: http://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_ea99af9511f3f255&akey=e4c064fca36f8d26
19:50:30 <clarkb> anteaya: were those names vetted first?
19:50:36 <clarkb> we seem to have a really hard time doing that
19:50:46 <mordred> yeah. that was my question
19:50:50 <anteaya> rdopieralski's email has the process
19:50:52 <rdopieralski> fungi: I mostly wanted you to look at it and catch any obvious blunders, like you just did
19:50:53 <fungi> clarkb: i asked, sounds like the top several will get sent to the foundation for vetting
19:50:55 <pleia2> one landed on the -infra list, but it was moderated so I was able to reject it
19:51:11 <pleia2> (one == a ballot)
19:51:18 <fungi> clarkb: mordred: vetting 18 would be a bit of a waste of time
19:51:23 <clarkb> fungi: right but a human can use the googles before hand
19:51:24 <rdopieralski> I would also want, if possible, to ask someone of you to volunteer in helping with it
19:51:30 <clarkb> fungi: which would have caught every other rename we have had to do
19:51:30 <mordred> please let schwartzchild win
19:51:31 <rdopieralski> during the freeze itself
19:51:38 <anteaya> http://lists.openstack.org/pipermail/openstack-dev/2014-June/037185.html
19:51:44 <fungi> clarkb: true. the degree to which anyone has is unknown
19:51:48 <fungi> to me anyway
19:51:53 <rdopieralski> but we don't have a date for that yet, so it may be too early
19:52:16 <fungi> rdopieralski: yeah, once we know when you'll be ready, it'll be easier to rally the troops on it
19:52:25 <anteaya> rdopieralski: helping with what? with the vetting of names?
19:52:30 <morganfainberg> mordred, there is a t missing in the poll option compared to what you typed. "schwarzchild" vs "schwartzchild"
19:52:41 <clarkb> https://www.paloaltonetworks.com/products/technologies/panorama.html
19:52:42 <rdopieralski> anteaya: nah, with the actual split
19:52:52 <anteaya> rdopieralski: oh the split
19:52:59 <morganfainberg> is that supposed to be schwartzchild instead?
19:53:14 <rdopieralski> morganfainberg: possibly
19:53:24 <clarkb> a quick googling should be able to exclude blatant problems...
19:53:27 <rdopieralski> I just copied it from the etherpad :P
19:53:39 <morganfainberg> rdopieralski, probably a typo ... it looks... off
19:53:56 * morganfainberg shrugs
19:54:02 <fungi> morganfainberg: no, http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB8QFjAA&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FSchwarzschild_radius&ei=SWKXU-bYMrCisATqtoGwDQ&usg=AFQjCNFL3m870AJgoy-enNcbYecDseUeew&sig2=VLmoF4rk51OcChUoTZUynw
19:54:05 <fungi> er
19:54:13 <fungi> http://en.wikipedia.org/wiki/Schwarzschild_radius
19:54:26 <morganfainberg> fungi, oh ok.
19:54:27 <morganfainberg> works for me
19:54:29 <fungi> (a nod to the event _horizon_)
19:54:34 <morganfainberg> yep yep
19:54:37 <anteaya> can I get a few minutes, I just need folks to agree I am doing the right thing with templates
19:54:38 <fungi> at least that's my assumption
19:54:48 <fungi> anteaya: yep
19:54:51 <fungi> rdopieralski: anything else?
19:55:16 <rdopieralski> fungi: that's all, thank you
19:55:19 <fungi> #topic Review Third Party wiki templates - seed pages (anteaya)
19:55:28 <anteaya> thanks
19:55:35 <fungi> you have the floor ;)
19:55:37 <mordred> morganfainberg: :)
19:55:40 <anteaya> so we have been progressing through third party templates
19:55:45 <anteaya> and i have some to look at
19:55:49 <anteaya> #link https://wiki.openstack.org/wiki/ThirdPartySystems/IBMPowerKVMCI
19:56:00 <anteaya> #link https://wiki.openstack.org/wiki/ThirdPartySystems/OpenStack-Neutron
19:56:07 <anteaya> please share your feedback
19:56:22 <anteaya> are we happy yet? do we want them all to use this format?
19:56:26 <anteaya> anything missing?
19:56:43 <fungi> anteaya: well, the example demonstrates that intent and focus may be redundant concepts
19:56:57 <fungi> but beyond that, fine with me
19:57:12 <anteaya> okay, which should we keep, intent?
19:57:17 <anteaya> and thanks
19:57:32 <anteaya> or do we like focus better?
19:57:35 <clarkb> it might be more readable as a more normal wiki page but then you will probably have drift
19:57:36 <reed> anteaya, how hard is it to make the line "3rd party system: IBM PowerKVM CI" more prominent?
19:57:55 <fungi> i'm also marginally unsure how we want to translate openstack programs to the per-project acls we talked about setting up (all projects in the listed program, or only some projects in a program allow any third-party voting?)
19:58:06 <anteaya> reed: I can work for that, what do you want, larger font? more space around it?
19:58:12 <ianw> "current status" seems like something that will get out of date and not always reflect reality
19:58:20 <reed> where are these templates going to be shown? on individual pages or as a 'sidebox' embedded in other pages?
19:58:45 <anteaya> fungi: yes, that does present an issue needing discussion
19:58:48 <reed> not clear to me the scope of this effort to be able to comment... but since I love templates :)
19:58:48 <clarkb> fungi: I think we go with all projects
19:58:53 <clarkb> fungi: its too complicated otherwise
19:59:01 <fungi> ianw: i think the hope is that it gets updated by the owners of that account when it breaks, as an indicator to everyone that they know it's broken
19:59:20 <fungi> clarkb: yeah, agreed. all projects in a given program get an acl stanza allowing that vote
19:59:23 <clarkb> so you have compute-ci network-ci et al as groups owned by nova-ptl neutron-ptl
19:59:35 <fungi> anteaya: did you need to hit your other topic too? 30 seconds
19:59:53 <anteaya> line 11 #link https://etherpad.openstack.org/p/automated-gerrit-account-naming-format
20:00:00 <fungi> #topic Formatting Automated Gerrit Account Names (anteaya)
20:00:07 <reed> anteaya, that first line with a larger font, like an h3 level or something similar would be better... right now the pages as they are displayed now are not very clear to me (but I may be the wrong audience)
20:00:08 <anteaya> can we live with that as an automated gerrit naming format?
20:00:12 <fungi> #link https://etherpad.openstack.org/p/automated-gerrit-account-naming-format
20:00:25 <anteaya> reed: you are the right audience, will look at that
20:00:43 <anteaya> lines 11-16 is the proposed format
20:00:51 <fungi> anteaya: seems fine to me
20:00:54 <fungi> also we're running over
20:00:57 <anteaya> do we need more discussion or can i publish?
20:01:01 <anteaya> kk
20:01:02 <anteaya> done
20:01:05 <clarkb> I don't want to change usernames
20:01:20 <clarkb> but we can talk over there ->
20:01:21 <anteaya> clarkb: just asking about format guidelines atm
20:01:22 <fungi> clarkb: i think we had decided we only change new usernames, not existing ones
20:01:30 <fungi> and we change existing and new display names
20:01:37 <markmc> "time now, folks. time now"
20:01:39 <fungi> anyway, ttx is going to get mad at me
20:01:44 <fungi> #endmeeting