21:05:12 #startmeeting 21:05:13 Meeting started Tue Sep 7 21:05:12 2010 UTC. The chair is dendrobates. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:05:14 Useful Commands: #action #agreed #help #info #idea #link #topic. 21:05:21 Thank you for coming everyone. 21:05:35 We had a meeting only a few days ago, ut I wanted to have this one, since we extended the blueprint deadline. The agenda is on the wiki, I encourage other to add items if there are things they want to discuss. 21:05:45 #link http://wiki.openstack.org/Meetings 21:05:56 #topic blueprints 21:06:04 The current list of Blueprints targeted for Austin are here: 21:06:13 #link https://blueprints.edge.launchpad.net/nova/austin 21:06:34 This does not include swift, but they only have a couple. 21:06:59 If your blueprint is not listed but you think it should be, please contact me ASAP 21:07:19 There is one blueprint that is suggesting some major networking changes: Extend the network control API 21:07:29 #link https://blueprints.edge.launchpad.net/nova/+spec/austin-extend-network-model 21:07:46 That is from over here and @romain_lenglet 21:07:52 I've asked for feedback from the openstack-core team. 21:08:07 adjohn: do you guys have any code yet? 21:08:14 dendrobates: I added this one https://blueprints.edge.launchpad.net/nova/+spec/austin-stats-utilization 21:08:57 littleidea: must have just missed it. I'll look at it. 21:09:05 @dendrobates coming soon 21:09:32 I just added it. I was trying to make a spec, but instead I messed up the wiki. 21:09:45 adjohn: have you seen the other networking changes that vishy made? 21:10:04 adjohn: I want to be sure you are working with the newest code. 21:11:04 Does anyone have any questions about austin-extend-network-model, or should we move it to the mailing list? 21:11:06 dendrobates: ok, we'll start from this branch 21:11:31 adjohn: I recommend pushing code ASAP, even if is is just a skeleton 21:11:45 that will help others get an idea of your changes. 21:11:55 dendrobates: got it 21:12:30 soren: did you see the question abour your austin-xen blueprint? 21:12:48 dendrobates: I didn't, no. 21:12:59 you added ewanmellor's branches 21:13:11 I.... did? 21:13:16 so I was not sure if it was for xenserver or all xen 21:13:31 well they were there, unless I am crazy 21:13:33 I really don't think I did. 21:13:38 Ewan must have done that himself. 21:13:44 Nope! 21:13:48 I was confused too ;-) 21:13:49 O_o 21:14:10 Anyway, I made an austin-xenapi, just to avoid any further confusion. 21:14:20 so you meant that to be opensourc xen, right? 21:14:27 We can use austin-xen for non-XenServer Xen support, if that's what you intend. 21:14:31 dendrobates: Me? Yes. 21:14:54 ok, I'll remove the branches from it. 21:14:55 soren: Do you intend to support other Xen's through libvirt, or some other means? 21:15:22 ewanmellor: libvirt. 21:15:30 That's how I roll. 21:15:56 OK, so should we call this blueprint austin-xen-libvirt or something, to distinguish it from austin-xenapi? 21:16:19 I'll fix it up 21:16:22 soren: I deferred your puppet blueprint 21:16:48 I don't believe there is any way in hell you could finish every bp you submitted 21:16:50 dendrobates: I can tell. 21:16:55 dendrobates: I've got a plan :) 21:17:01 dendrobates: But no worries. 21:17:06 dendrobates: I'll do it while you're not looking. 21:17:08 soren: Is there anything even to do? Doesn't it "just work" if you use libvirt today? 21:17:09 :p 21:17:27 ewanmellor: It's really meant as a "make sure that it already works" sort of blueprint. 21:17:33 ok, if you have a plan fine, but the other things are more critical, and I know you and your "plans" pretty well. 21:17:35 :) 21:17:49 ewanmellor: I do think, though, that it needs a tiny, tiny bit of template tweaking. 21:18:06 dendrobates: Gotcha. 21:18:07 soren: OK, that makes sense. 21:18:38 ewanmellor: all the work may be in ubuntu's version of libvirt 21:18:52 Well... 21:18:59 Ubuntu doesn't even have a dom0. 21:19:08 (Clever as they are) 21:19:12 :) 21:19:23 soren: true, but that doesn;t stop rackspace from using it with xen 21:19:31 But yeah, there might be libvirt work involved. That's fine. 21:19:41 dendrobates: Good point. 21:19:46 soren: zul has agreed to hepl if you need it. 21:19:58 * soren hugs zul 21:20:23 any other blueprint questions or discussions people want to have? 21:20:36 3 21:20:36 What's the plan with Redis? 21:20:43 Will we still have Redis in Austin? 21:20:54 afaik, yes -- i rely on it to get the new API working 21:20:59 afaik, yes 21:21:01 ~vishvananda/nova/orm_deux should be live 21:21:05 vishy, care to chime in? 21:21:05 and don't plan on figuring anything else out by october :) 21:21:37 yeah, but for all practical purposes, Redis will still be required this release 21:21:57 right vishy? 21:21:58 Do we expect to remove it soon? 21:22:00 * soren didn't realise the orm_deux branch was a Redisectomy? 21:22:14 it is not, it is an abstraction 21:22:26 Ok, that's what I thought. 21:22:33 right, but no redis backend has been written yet, only sqlalchemy 21:23:12 gundlach will have to re-jigger all the stuff that used nova.compute.model to use nova.db, regardless 21:23:38 even if it hits, I don;t think everything can be reworked in time, Austin+1 i'd say. 21:23:57 what day is the freeze? 21:24:04 9/30/10 21:24:06 Sep 30. 21:24:23 * soren will never get used to middle-endian dates. 21:24:38 30/9/10 21:24:42 10/9/30 21:24:46 2010-09-30. 21:24:49 Deal. 21:24:52 What's the name of Austin + 1? 21:24:52 ha 21:25:08 ewanmellor: probably san antonio 21:25:16 Is Austin going to be OpenStack 1.0? 21:25:22 * soren was hoping for something beginning with 'b' 21:25:32 sorry guys was afk 21:25:33 xtoddx, vishy: don't you plan on having the orm branch land soon? if so, that means it's going to be austin 21:25:37 dendrobates: oh, come, we *surely* must do alphabetical :) 21:25:46 gundlach: sorry out of my hands 21:25:51 would be great if the orm branch landed soon 21:25:56 http://en.wikipedia.org/wiki/List_of_cities_in_Texas 21:26:02 ewanmellor: Probably Nova 1.0, but Swift already had a 1.0. 21:26:08 dudes name it after south park characters :) 21:26:14 and with that branch the only thing requiring redis is fake ldap 21:26:37 vishy: ok, so for most purposes, redis will be gone in austin 21:26:37 Bangs, TX 21:26:54 xtoddx: I bet she does! 21:26:54 vishy: but there are other branches out there that are using redis, like gundlach's 21:26:56 fyi i'm using the central redis store to map RS API image ids to Glance image URLs 21:27:05 eday: yes, if someone wants to rewrite fakelap using mysql then we could ditch it completely 21:27:19 if someone else can lend a hand turning that into a local store for the API cluster to use, i'm fine with that 21:27:32 dedrobates: I wasn't aware that gundlach was using redis 21:27:50 vishy: i kind of fell into it when i realized we'd need a persistent mapping for IDs and redis was lying around. 21:27:53 vishy: when do you plan on this being merged? 21:27:54 I think we need to land the ORM branch sooner than later, before merge conflicts become even more of a nightmare :) 21:28:26 vish, can we work on landing orm this week? 21:28:31 dendrobates: as soon as possible...there will be some inevitable cleanup, i think i may have broken xen a bit 21:28:56 dendrobates: I 21:29:11 ewanmellor: you 21:29:32 dendrobates: (Sorry about that) It make sense to line up version numbers, doesn't it? Nova and Swift 1.1? 21:29:45 ewanmellor: I thought about that, but.. 21:29:47 ewanmellor: #agree 21:30:24 ewanmellor: It's not unimaginable that other thigsn will come under the OpenSTack umbrella in the future, and they might already have a versioning scheme in place that conflicts. 21:30:35 naming scheme kinda forces not to have a development summit twice in the same town ? 21:30:41 ewanmellor: So we might be able to do it now, but at some point, it's going to fall apart (or so I hypethicise) 21:30:45 ewanmellor: possibly, but I don't want to put a 1.0 release on nova yet. 21:30:46 hypothecise. 21:30:56 Or whichever way it's meant to be spelled. 21:31:02 ttx: that is the goal 21:31:15 ttx: Sounds familiar? :) 21:31:18 gundlach: I can help you move stuff over to orm...it is pretty straightforward 21:31:19 ok, back on topic 21:31:30 dendrobates: You're not shooting for Nova 1.0? 21:31:34 soren: now you must just pick towns alphabetically :P 21:31:37 i thought it was just alph by town 21:31:39 any more blueprint questions? 21:31:47 boston release next? 21:31:51 vishy: ty, i'll talk w/ you offline 21:32:28 vishy: Bahamas City. 21:32:29 San Antonio is in Bexar county if you want to cheat a bit. 21:32:46 #topic Release 21:33:00 are there any questions about the Austin release? 21:33:05 Yes. 21:33:07 21:31 < soren> dendrobates: You're not shooting for Nova 1.0? 21:33:29 soren: no 21:33:35 Hm. 21:33:36 Ok. 21:34:27 What is the license on OpenStack documentation? 21:34:42 Will we (Citrix) be able to repurpose OpenStack docs, for example? 21:34:56 I will be working to get everything documented with our new community tech writer/leader annegentle 21:35:07 creative commons probably 21:35:12 will that work? 21:35:36 I was looking at the Swift Deployment Guide and thinking how good it was and how I'd just want to cut huge sections into a page with a Citrix logo at the top, and ship it ;-) 21:35:42 dendrobates: well, there are different CC versions, some allowing for commercial uses 21:35:43 I havent asked anyone in RS legal yet, but we've already used CC for other things. 21:35:52 Would that be morally acceptable to the community? 21:36:02 I would not want to restrict usage in anyway. 21:36:05 dendrobates: how does that fit with python docs generated from the code which is apache? 21:36:11 hmm 21:36:18 damn good question 21:36:35 I don't know ianal 21:37:09 #action find out what license to use for docs] 21:37:10 could just use apache lic for docs too, keep it simple (whether it's code-generated or not) 21:37:31 by-sa would maybe be acceptable? 21:37:32 #action find out how APL2 affects docs in code 21:38:01 that might be best, but I am not ready to commit without more knowledge 21:38:21 Anne isn't with us today or she might know 21:38:30 I will find out 21:38:44 are there any questions about the Austin release? 21:38:47 #link http://www.apache.org/dev/apply-license.html 21:38:58 ASF policy is to apply the Apache license to docs, too. 21:39:13 ewanmellor: thanks 21:39:29 (Not that we have to do the same, just that they've obviously decided that it's legally sensible.) 21:39:50 it does sound easy, I'll take it up with the lawyers 21:40:22 #topic OpenStack-Clients project group 21:40:41 The LP admins created a project group for the clients. I will be populating it with the client projects and teams asap 21:41:25 it let's them control their own group without our interference, the clients are pretty separate anyway. 21:41:44 questions? 21:41:52 these are things like the mobile apps and CP? 21:41:59 yep 21:42:19 mostly written by mike mayo 21:42:33 does clients mean libraries for other languages, or just end-user applications? 21:42:36 i any thing was server side we would still keep it in openstack 21:42:43 end user apps 21:42:57 although.... 21:43:00 is there a place for client libraries for ruby, java, etc to grow up at?\ 21:43:05 not sure if this is the time or place, but will there be any level of effort to include 3rd party devs (like CyberDuck or wordpress extensions [in the case of swift])? 21:43:08 what about projects to implement different lang bindings? 21:43:25 xtoddx: the javascript library already exists, as part of the GroundControl browser extension 21:44:07 We could put them all under clients, or keep them with openstack if they are tied to our release cycle. 21:44:25 its a sign of maturity to have many language bindings, so i think we need to give them a place to exist and be loved 21:44:30 or they could not have anything to do with us officially 21:44:37 tying them to our release cycle sounds smart 21:44:53 they may be tied to a release cycle (new features, etc), but they probably need a faster release cycle than the main projects 21:44:56 with tiny-number upgrades for any changes specific to their code 21:45:09 #agreed love <3 21:45:12 then let's do that until someone bitches and reconsider it then. 21:45:17 #agreed 21:45:22 do that == ?? 21:45:32 keep in openstack? 21:45:40 what xtoddx said: keep them with openstack\ 21:46:32 is that openstack/swift-python, openstack/swift-php or openstack/swift/ 21:46:52 or even openstack/bindings/ 21:46:53 under each project 21:47:07 so you only dl what you actually need 21:47:23 I would assume different devs 21:48:04 let's take this to the mailing list. 21:48:25 but we've resolved to keep them in openstack 21:48:36 #topic 21:48:43 #topic meeting time 21:49:05 I was thinking about rotating the times 21:49:37 one week we would be very lat for our friends in Japan, and the next early for Europe 21:50:09 I can see no way to please everyone all the time. 21:50:16 I think rotating times tends to dissipate energy. 21:50:35 I feel that way to, but have no better suggestions 21:50:56 how does this time work for those in Japan? 21:51:04 Europe? 21:51:04 it's ok 21:51:07 6am is a bit early for us I think, and the other guys like NTT may not be able to make it that early it seems? 21:51:20 it's not terrible, but i'm an early riser 21:51:28 maybe it's always in a certain time the 1st week, a different time 2nd... and when there are more than 4 in a month we double up on one 21:51:30 most of the Japanese are not 21:51:37 dendrobates: It's kinda late, but manageable. 21:51:46 but something that has a predictable cadence 21:52:06 meet every 170 hours? (168 hours in a week) 21:52:21 * soren slaps notmyname 21:52:21 littleidea: so tie the time to the week of the month 21:52:32 dendrobates: just an idea 21:52:54 looking for a compromise that keeps some regularity 21:53:26 We can ask the others we know in the Japan community about the meeting times, but I guess for the 3 of us from Japan here now the current time is ok 21:54:06 I'll send a suggestion to the ML for a perm rotation, but we need to schedule next weeks. 21:54:10 It's worth noting that if we find a time that is on the edge of being acceptable to someone, that will probably require us to move it every time /anyone/ goes to/from DST. 21:54:20 I think Tuesday is a good day 21:54:35 any disagreement 21:54:42 Nope. Tuesday is good. 21:54:45 or wednesday in Japan 21:54:49 fine here 21:55:21 same time next week or 1 hour later? 21:55:56 http://www.timeanddate.com/worldclock/meetingtime.html?day=7&month=9&year=2010&p1=195&p2=248&p3=64&p4=137 21:56:17 for some reason it is easier for me to ask to stay up till 1am than to expect people up at 6am 21:56:18 The Englishman here votes for no later than the current time! 21:56:40 That's one vote 21:56:46 anyone else. 21:56:55 I prefer this time as well 21:56:56 I prefer now over one hour later. 21:57:04 I prefer this time rather than one our later 21:57:06 That would put it at midnight for me. 21:57:19 adjohn: really! wow 21:57:21 +1 for keeping this time 21:57:22 ...and I have to get up early Wednesday. 21:57:27 ok done 21:57:42 same time next week 21:57:53 dendrobates: one our later means i have to commute to work before the meeting, or some of us will show up late as they have a long commute after the meeting 21:58:08 s/our/hour 21:58:12 send anything else to the ml or #openstack 21:58:27 adjohn: I forgot, some people go to work. 21:58:41 I just walk downstairs 21:58:47 #endmeeting