19:01:32 #startmeeting infra 19:01:33 Meeting started Tue Jun 4 19:01:32 2013 UTC. The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:34 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:36 The meeting name has been set to 'infra' 19:01:40 o/ 19:01:42 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting 19:01:47 #link http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-05-28-19.02.html 19:01:55 #topic actions from last meeting 19:02:04 clarkb: did you get up to speed on recent testr'ing? 19:02:10 o/ 19:02:27 * mordred failed at his action from last week - but has had several emails indicating people are coming 19:02:52 hola 19:03:08 mordred: okay. are the dates confirmed? 19:03:08 mordred: do you have a venue? or is this taking place in your living room? 19:03:26 hi o/ 19:03:28 fungi: I do not yet have a venue, but it will be near my living room 19:03:41 jeblair: yes. june 27/28 19:04:08 we will either be in a swanky meeting place in soho if I can figure out how HP pays for such things - or a room at NYU :) 19:04:22 #action mordred make a signup thingy for bootcamp 19:04:29 oooooh nyu 19:05:01 reed: do we need to talk about the mailing list? 19:06:00 i think we lost clarkb 19:06:20 yeah, that was another massive netsplit 19:06:37 or server drop 19:06:52 #topic TryStack user management 19:06:54 clarkb1 is here 19:07:06 hey nati_ueno ! 19:07:09 bunch of people just flooded back in 19:07:29 annegentle: ping (you added this topic) 19:07:40 jeblair: heya 19:07:44 reed: ping (you mentioned this topic) 19:07:45 nachi__: around? 19:07:57 nati_ueno: is here 19:08:02 nati_ueno: woo! 19:08:16 I'll just bring up the topics for your team's input if that's ok 19:08:23 does anyone need trystack background info? 19:08:46 fungi: I am sort of here 19:09:02 it finally dropped my other connection 19:09:12 The goal for TryStack is to use donated hardware and admin resources to give people a chance to try OpenStack as cloud consumers/devs. 19:09:31 nati_ueno and jaypipes started it a while back 19:09:32 jeblair, I have nothing to report unfortunately 19:09:50 originally Facebook was the starting point for user access, with the intention to move it 19:10:58 a kerfluffle came up last week where Facebook wanted a privacy policy in place for what happens with user info for a group. Sorry I don't have many details there. 19:10:58 now it seems that Facebook has kicked the app for lack of a privacy policy 19:11:04 Ideally we'd have a user identity layer that enables access to Trystack without the use of Facebook 19:11:21 ...launchpad? 19:11:23 I know of people in this channel who would like that 19:11:28 fungi, anything 19:11:29 The short list of requirements would be: 19:11:46 1. Group member management (CRUD, remove) 19:11:54 2. ensure real identities, not bots 19:12:00 2.a not spammers 19:12:11 3. Enable group communication with users 19:12:25 Facebook does meet these except well you know, walled garden and all 19:12:27 ahh, okay, so just general unvetted openid providers are off the table 19:12:42 really just want to get ideas for managing 8000+ users and how to migrate 19:12:47 regarding 3, I think we should re-use what we have 19:12:53 that is: mailing lists and ask 19:13:05 (...and irc!) 19:13:08 and IRC (it is linked to directly on trystack.org) 19:13:16 * fungi laughs 19:13:18 well, is it apprporiate to use openstack-announce for Trystack announcements? (seems like it) 19:13:31 clarkb, I don't see the 8k facebook users use irc... but I may be wrong :) 19:13:32 however, there is a fair amount of churn on #openstack about trystack and none of the people with answers seem to hang out there... 19:14:00 ask is IMHO the best place to ask trystack things 19:14:24 reed: I think clark is saying that tons of people _do_ show up to IRC and ask questions about trystack 19:14:28 clarkb: the churn happens when there's a problem with the cluster. I think #openstack is okay for asking questions about trystack, I can update the page to not use a separate channel. 19:14:33 annegentle, for the migration, if we enable simply authentication via facebook (no group management) it should be ok 19:14:37 reed: and they do so in a channel that doesn't have trystack coverage 19:14:42 I think launchpad is as good as any other authn/authz system as the things you mention, and of course we use it for everything else openstack. 19:14:48 jeblair: ++ 19:14:55 mordred: I haven't seen a trystack question in #openstack for a while 19:15:00 annegentle: ossum 19:15:20 I think it if wants to 'feel' like an openstack project thing, launchpad is the way to go 19:15:26 mordred: but might be a timing thing too 19:15:47 mordred: correct 19:15:48 I think #openstack is fine but if trystack is going to continue advertising it on their website it should have more trystack people in that channel 19:16:06 mordred: so originally I was thinking it's a different audience than the Launchpad crowd, that we should enable multiple identities to try to get coverage in more than just the dev crowd 19:16:16 mordred: or go right to github since more activity there. 19:16:21 eh 19:16:22 how many trystack support people are there currently and what times do they hang out in #openstack? 19:16:24 does anybody know what it takes to remove that facebook app auth from trystack and enable facebook oauth (and LP, maybe)? 19:16:32 fungi: probably 3 19:16:45 annegentle: what's the goal we're trying to get with using a different auth system? 19:17:00 mordred: trying to expand the "community" beyond LP 19:17:04 annegentle: why 19:17:15 mordred, because LP user experience sucks 19:17:20 we're not expecting that we're going to draw our community _from_ LP 19:17:30 it's a login mechanism 19:17:37 and we don't want to force *users* to create yet another login in a system we don't control 19:17:38 and it's the one we use for SSO for OpenStack things 19:17:42 reed: i don't think any of us disagree about lp being suboptimal. i'd love to see us have something better available to the project 19:17:44 our wiki is tied to it 19:17:45 reed: https://blueprints.launchpad.net/trystack/+spec/openid-registration 19:17:57 mordred: is doing the five whys with me. 19:18:10 fungi, in the long run I think we will be using the openstack foundation db... 19:18:16 annegentle: I don' tknow what those are :) 19:18:26 reed: if that is ever open sourced. :( 19:18:46 reed: yeah, but lp between now and the openstack official identity provider means one fewer places we need to migrate from when that happens 19:18:49 reed: i would not recommend trystack wait on the foundation db at the moment due to very slow progress. 19:18:50 I don't like facebook as a source, because it's not open source, and because there are community members who refuse to use it 19:18:53 mordred: walled gardens abound :) 19:18:55 fungi: +1 19:18:59 jeblair, talked to todd, it's not as simple... he can give you the details 19:19:14 fungi +1 19:19:17 I don't like github as a source, because it's not open source, and it would be more more step of confusion of people thinking that openstack uses github 19:19:19 reed: i would love for him to do that. it seemed simple when we last talked about it at the summit. 19:19:24 it doesn't have to be launchpad 19:19:36 mordred, facebook is like any other oauth system, you don't have to use it 19:19:42 but I would like to see whatever the source is be somethign that's open source, and something that doesn't present a confusing experience 19:19:49 mordred: +1 19:20:04 reed: what? for trystack, currently, you have to have a facebook account 19:20:22 and if it happens to be launchpad, it can just piggyback on the later migration we're going to have to do for everything else anyway 19:20:24 mordred, what's wrong with the approach that Ask takes? authenticate using any system you want or create a new id 19:20:31 mordred: I think the ideal experience is enabling people to identify using what ever auth they like 19:20:46 reed: +1 19:20:54 annegentle: then openid with allowing any providers is a good way to do that 19:20:57 reed, annegentle: so, that's a potential thing - but it completely misses out on points 2 and 3 you listed above 19:21:08 I don't mean "what ever auth" that's silly, but I do mean that people represent themselves differently and may have reasons for which auth they want to id as 19:21:10 it doesn't provide for a group management system 19:21:10 annegentle: if you allow any openid provider, it is a little easier for spammers 19:21:14 annegentle: sure but one of your other requirements was tying those identities back to some sort of group management and communication platform 19:21:30 mailing list can help with 3 19:21:36 mordred, right! that's why using oauth via FB is a good thing 19:21:41 reed: no 19:21:51 reed: it is one of the reasons i have never seen trystack 19:21:54 point 3 is IMHO not a priority of this project 19:22:04 reed: oauth via fb prevents jeblair from using trystack 19:22:16 he is not the target audience :) 19:22:21 reed: who is? 19:22:22 oath via more providers seems like the right direction? 19:22:28 we might need to go back to that question 19:22:29 oauth 19:22:30 consumers of API are 19:22:38 jeblair is a consumer of the API 19:22:40 in 19:22:40 annegentle: i think openid with more providers is the right direction 19:22:42 in fact 19:22:51 mordred, but he has tens of other and better places to test openstack 19:22:51 he might be one of the most active consumers of the OpenStack API 19:22:53 * annegentle studies oauth v openid 19:23:06 mordred: and earliest 19:23:14 let me recap 19:23:20 reed: he's also indicitive of a type of alpha developer 19:23:22 we are getting sidetracked 19:23:25 we're not 19:23:31 this is what the conversatoin started on 19:23:38 and it's an important point that you're trying to blow off 19:23:46 I would like to re-frame the conversation 19:23:55 hi sorry i'm back now 19:24:04 yay! it's nati_ueno 19:24:20 we have now a very poweful tool that is not getting used at its best, we have limited resources to manage it, too 19:24:24 nati_ueno: hurrah 19:24:26 mordred: yay 19:24:35 one of the issues that trystack faces is spammers and abuse 19:24:39 i think the question of whether we're targeting lowest-common-denominator users with near-zero technical skills, a la the facebook crowd, is a very valid question 19:24:46 those things take *lots* of time 19:24:48 fungi: ++ 19:25:00 reed: right. launchpad, it turns out, is a pretty good spammer filter :) 19:25:08 as we've seen with the previous wiki, launchpad does a bad job at preventing spammers 19:25:14 people who are interested in testing cloud servers also are not likely afraid of launchpad, irc, mailing lists, and so on 19:25:15 it does? 19:25:21 oh. ok. my bad 19:25:27 wait 19:25:35 what did launchpad have to do with spam on the previous wiki? 19:25:36 mordred, I remember the contrary... spam was an issue on the previous wiki 19:25:42 annegentle: i thought when we turned on openid on the wiki the spam was redured? 19:25:47 reed: how is that related to launchpad? 19:25:50 We also need to figure out whether the useage/experience of the current 8000 users is more worth maintaining than disrupting. That might help shape priorities. 19:25:50 are we going to get 8000 more? 19:25:57 If we got 8000 on FB that's something to consider is what I mean. 19:26:00 reed: the previous wiki started off not using launchpad auth 19:26:07 which is when we had spam issues 19:26:21 jeblair: yes the openid on the wiki helped immensely with the spam problem 19:26:41 the current wiki uses - launchpad 19:26:58 I thought there was a bot that via lp kept adding bad edits 19:27:03 I'm still saying, what about 8K FB users? Is that meaningful to y'all? We have over 9000 Launchpad users? We have no way of seeing an intersection there but I bet it's less than 1k 19:27:06 the later moin spam issues had mostly to do with someone leveraging a compromised lp account, i believe 19:27:27 so openid is a good tech choice because it gives us a lot of options for providers now and in the future. 19:27:28 same sort of thing is possible with just about any auth provider 19:27:29 fungi, ok, at least I didn't dream of that :) 19:27:34 yeah, I'm scaring spam users 19:27:43 We are giving free VM with root 19:27:45 we could do openid with any provider and make it very easy for people and spammers 19:27:58 or we could do openid with launchpad as the provider, and use that for the following side effects: 19:28:04 Yes but we need manegement ui for that 19:28:13 Just one click and ban the spammer 19:28:33 I can't find such providers which can provide user management UI otherwise facebook 19:28:33 openID is one choice, oauth via facebook IMHO needs to be part of the range of possibilities 19:28:34 - spammers are less likely to go through the lp signup process repeatedly 19:28:54 - lp provides group management, meaning it can be used for authz as well as authn 19:28:55 So there are some way to spam 19:28:59 just spam comment 19:29:06 or use the VM for VM 19:29:10 i really think that it's hard to scare spammers away from free services anyway. in my service provider life we had customers who offered free trials for their mail marketing services and were plagued by spammers signing up for free trials with stolen credit card numbers 19:29:11 sorry typo 19:29:14 using VM for spamming 19:29:29 For attacher, it is worth login to the lp for spamming 19:29:40 also we can create any number of lp id 19:29:45 without Name 19:30:03 so IMO, lp id is not sufficient for trystack 19:30:07 so yes, any barrier to entry lower than or equal to requiring a credit card is little barrier at all to criminal spammers 19:30:10 nati_ueno: but if you're using a lp group, then you can only add people with names (and maybe email addresses) 19:30:11 ok. I'd like to make a suggestion. we've now been on this topic for 22 minutes and we have several more to go 19:30:21 nati_ueno: and if they are abusive, you can remove them from the group 19:30:25 there seem to be as many opinions here as people 19:30:40 jeblair: But what's if the spanner creates new lp id after we banned him? 19:30:45 how about we have someone go away and write up a list of proposals/possibilities 19:30:57 mordred: secondeed 19:30:57 mordred: +1 19:30:59 I'll do it 19:31:01 that we can read offline and discuss and we can come back to the meeting next week 19:31:03 thanks reed 19:31:07 thanks reed 19:31:09 nati_ueno: i don't think an authentication system can prevent spammers. 19:31:21 jeblair: Yes. We need some ID. 19:31:33 #action reed to summarize the discussion so far and send recap to mailing list 19:31:34 jeblair: credit card is best 19:31:40 however it costs 19:31:56 Facebook ID is easier way to get some kind of IDs 19:32:01 #link https://blueprints.launchpad.net/trystack/+spec/openid-registration 19:32:08 stolen credit card numbers abound and can be had for cheap 19:32:09 regardless, additional work will be required. i don't think any system suceptible to spam has solved the problem just with authentication. 19:32:09 It is easy to check spammer because he has no friends 19:32:30 nati_ueno: i have no friends and i am not a spammer. you can get false positives that way too. 19:32:53 jeblair: I can be your friend :). 19:33:01 that's a great way to end this topic. :) 19:33:06 :) 19:33:08 nati_ueno: thank you 19:33:17 #topic TripleO Testing (TOCI) 19:33:17 jeblair: We are accepting new users without check for now 19:33:35 so, last week I was testing TOCI and learned we can't use kvm, so I tried using qemu 19:33:52 that was unuseably slow on hpcloud 19:34:02 action mordred get hpcloud to support nested kvm 19:34:22 I then started looking into lifeless' takeover node to see if we could launch multiple vms instead of doing nested 19:34:36 jeblair: haha 19:34:52 but that 1) causes lots more problems (local lan between them?) 2) ends up not testing all of what we want to test anyway (it's not really tripleo anymore) 19:35:11 so lifeless suggested trying with lxc instead 19:35:25 that's where I'm at now 19:35:50 this would be lxc on (essentially) a devstack throwaway test slave? 19:35:55 fungi: right 19:36:27 i think lxc for testing things like that will probably work great. it has some security challenges still, but shouldn't be an issue in that situation 19:36:35 ++ 19:37:18 so I'm working through some lxc configs and doing some tests on hpcloud 19:37:29 pleia2: sounds good! 19:38:03 end of topic? 19:38:07 yeah 19:38:15 #topic Py3K support, testing and potential platforms 19:38:22 pleia2: SpamapS_ suggested it; I misunderstood then got it :) 19:38:26 woo this has been fun :) 19:38:30 clarkb: ++ 19:38:33 lifeless: oh right, thanks SpamapS_! :) 19:38:58 so I got into running things with py3k because my log pusher script is a py3k script and I want to use gear 19:39:16 * zul ears perked up 19:39:18 I basically learned that you start scratching at the surface of this problem and very quickly find yourself deep underground 19:39:20 also, zul wants to start running tests 19:39:41 yes, I think tests are super important so that we stop ending up in giant pits 19:39:57 I don't like giant pits 19:40:05 so the question here is test with what version(s) on what platform(s) 19:40:15 and how to get there 19:40:15 now /me gives it over to zul so he can talk about why testing is hard ;) 19:40:40 at the design summits, it was generally agreed to target 3.3 because supporting <3.3 and 2.x is hard 19:40:55 thats what i rember as well 19:40:59 that matches my recollection 19:41:02 and precise only have 3.2 19:41:25 which is why we should ditch ubuntu for debian on our test slaves 19:41:28 * mordred ducks 19:41:51 honestly - I think the open question is do we revisit our recent decision to just run precise for our test slaves 19:41:52 mordred: to be fair you get 3.3 on debian stable right now by installing it from testing, at least until it starts getting into the backports repo 19:42:10 because we could test 3.3 on quantal or raring 19:42:11 quantal also has 3.3 19:42:32 quantal also has not a lot of life left in it already, right? 19:42:32 but quantal only has a 9 month release window 19:42:35 I really don't think we can do raring 19:42:36 or do we add new slaves to do 3.x testing? 19:42:48 oh - sorry , that's what I was suggesting 19:42:49 and perhaps treat it more opportunistically? 19:42:57 not moving our precise slaves back to quantal 19:42:59 jeblair: yes 19:43:19 if we do Debian we could have python3.alltheversions on the same box and use those slaves to test python3 19:43:24 we'll try to run python3.x tests on branches as long as we can, but we're not going to do crazy things when they go eol 19:43:26 quantal slaves for 3.3 testing and then move them to raring when we have raring slaves availble? 19:43:31 jeblair: ++ 19:43:49 mordred: +1, and if raring works on stable/havana, sure, and if it doesn't, drop the tests? 19:43:49 raring should already be avialable on hp cloud btw 19:43:55 jeblair: yah 19:44:14 if we decide to go the debian route, i spun a test slave up in rackspace and threw together a quick gap list... 19:44:17 #link https://etherpad.openstack.org/debian-wheezy-slave-todo 19:44:42 zul: nope 19:44:46 zul: I see no raring 19:44:53 fungi: oh yeah, quantal puppet issue. :( 19:45:01 mordred: ugh ill bug them again 19:45:12 jeblair: oh. wait. which one was that? 19:45:20 jeblair: right several of the items on that debian/wheezy list also apply to quantal and raring 19:45:28 mordred: what fungi said 19:45:37 yum 19:45:55 mordred: specifically, the puppetlabs thing was the shebang problem, iirc 19:46:01 ah. yes 19:46:04 that 19:46:06 wow 19:46:13 everything about this is making me have memories of hating people 19:46:24 * lifeless whispers 19:46:25 heat 19:46:27 oac 19:46:29 orc 19:46:30 doit 19:46:34 * mordred kickbans lifeless 19:47:06 so yeah python3 get it done ;) 19:47:19 thanks zul ;) 19:47:46 my sense is that we're generally in favor of launching quantal slaves for python3.3 testing... that sound about right? 19:47:49 zul: add python3.3 to precise-backports might be easier? 19:47:54 jeblair: yes 19:48:01 jeblair: pending the work to make the puppet happy 19:48:12 mordred: easier to stick it a ppa 19:48:16 (and some of us are ready to hop on over to debian at the first sign of trouble) 19:48:19 oh - well... 19:48:34 jeblair: one thought zul brought up was - what if he put python3.3 in a ppa? 19:49:05 i can't immediately come up with a reason to to do that 19:49:06 mordred: then you arent going to get other crap in the backport-archive 19:49:13 it's really just a question of whether someone is taking care of continually backporting new 3.3 releases to cover security issues 19:49:23 i can do that 19:49:24 sorry, 'a reason not to do that' 19:49:34 assuming zul is minding that ship. :) 19:49:44 it might actually be less work than spinning up quantal slaves and porting puppet nonsense 19:49:45 i hear he knows about packaging 19:49:48 what? 19:49:50 zul? 19:49:52 crazy! 19:49:59 i think it sounds great if zul's taking care of the package updates quickly 19:50:05 I would be onboard wit ha py3k PPA 19:50:08 whats more work for me to do 19:50:27 zul: so yeah python3 get it done ;) 19:50:40 fungi: okie dokie...done...just kidding 19:50:52 #action zul make py3k ppa 19:51:13 actually, let's think that through a little more... 19:51:28 if we used quantal/raring, we would have slaves dedicated to py3.3 testing 19:51:35 right 19:51:37 I have another suggestion. Why not use Fedora 18 (which has python 3.3 natively) 19:51:43 that's also backporting things like python3-pip and whatever other libs we need, right? 19:51:44 * dprince will do the puppet work to make it work. 19:52:05 which means we could make that be the only python env, which makes the puppet pip problem simple... 19:52:25 if we used a backport ppa on precise, we would either still need to make dedicatde slaves for python3 testing 19:52:28 It would be nice to support 3.2 too if possible 19:52:29 or solve the puppet pip problem 19:52:36 jeblair: good point 19:52:44 while more difficult it is not impossible to do 2.x and 3.2 and some projects may want to do that 19:52:47 isn't that correct? (because we do have puppet pip installing things needed for tox testing; like tox?) 19:53:04 mordred: quantal is 18 month release window btw. 19:53:16 and raring is 9? 19:53:19 yes 19:53:19 fungi: right 19:53:23 k 19:53:30 jeblair: not to derail us further... but should we re-think about deb packaging the things we install via puppet from pip? 19:53:47 * zul sniggers 19:54:24 I think I like the dedicated python3.3 slave idea 19:54:31 dprince: ack; (quantal|f18) might be an option, but the puppet pip thing is an issue regardless 19:54:39 dprince: what's the support period on f18? 19:54:56 jeblair: is it on f18 if python3.3 is just the python on f18? 19:55:05 fungi: 13 months. 19:55:10 k 19:55:24 dprince: when is f19 due out? 19:55:26 how much effort does it take to bring new slave OS's online? 19:55:28 mordred: i'm cool with deb packaging; several of our contributors deb package things we're using, so we can collab more there 19:55:41 mordred: i phrased that poorly, i meant to say that f18 and quantal are in the same boat.... 19:55:42 SpamapS_: not a whole lot anymore. mostly just making puppet handle corner cases 19:55:48 ah. gotcha 19:55:49 fungi: july 19:56:00 fungi: 2nd 19:56:00 SpamapS_: it is a nonzero effort, but no more than a week or two once the providers have images available to us generally 19:56:00 mordred: so i think the decision tree is like "precise or (quantal or f18)" 19:56:17 jeblair: just one thing the packages are called python3-all, etc 19:57:17 Ok so if you do quantal, you are talking about having to do one more flip to saucy before you can bridge to 14.04... 19:57:51 SpamapS_: pretty much, yes, there's a gap there between either quantal or raring and the next lts 19:58:14 you could technically even just go right from quantal -> 12.04 if you start with the betas and don't mind the potential for being EOL'd whilst fixing issues 19:58:34 fungi: there's no gap. 12.10 (quantal) is supported until April 2014. 19:58:54 Its just that.. there's no overlap 19:59:18 ahh, right, and no guarantee our providers will have glance or images available immediately 19:59:33 we're about out of time; let's take this back to #openstack-infra and see if we can get a consensus real quick... 19:59:46 * fungi agrees 19:59:51 #endmeeting