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