Tuesday, 2012-06-12

*** jgriffith has quit IRC00:00
*** jgriffith has joined #openstack-meeting00:01
*** dprince has quit IRC00:01
*** rkukura has joined #openstack-meeting00:03
*** jgriffith has quit IRC00:06
*** rkukura has left #openstack-meeting00:09
*** ncode has quit IRC00:12
*** edygarcia has quit IRC00:13
*** sdake has joined #openstack-meeting00:16
*** gongys has quit IRC00:27
*** rnirmal has quit IRC00:28
*** jaypipes-afk is now known as jaypipes00:38
*** zul has quit IRC00:42
*** s0mik has quit IRC00:42
*** matwood has quit IRC00:45
*** nati_ueno has quit IRC00:45
*** jaypipes has quit IRC00:46
*** johnpostlethwait has quit IRC00:47
*** ryanpetr_ has joined #openstack-meeting00:51
*** Mandell has quit IRC00:52
*** ryanpetrello has quit IRC00:53
*** ayoung has joined #openstack-meeting01:04
*** lloydde has joined #openstack-meeting01:07
*** lloydde has quit IRC01:11
*** jog0 has quit IRC01:11
*** nati_ueno has joined #openstack-meeting01:15
*** nati_ueno has quit IRC01:19
*** nati_ueno has joined #openstack-meeting01:20
*** jdurgin has quit IRC01:22
*** jakedahn is now known as jakedahn_zz01:28
*** mdomsch has joined #openstack-meeting01:29
*** zul has joined #openstack-meeting01:31
*** jakedahn_zz is now known as jakedahn01:37
*** jakedahn is now known as jakedahn_zz01:37
*** gyee has quit IRC01:38
*** mattray has joined #openstack-meeting01:40
*** notmyname has quit IRC01:42
*** glenc has quit IRC01:44
*** ayoung has quit IRC01:53
*** adjohn has quit IRC01:54
*** krtaylor has quit IRC01:58
*** PotHix has quit IRC02:16
*** danwent has quit IRC02:17
*** ryanpetr_ has quit IRC02:26
*** mdomsch has quit IRC02:29
*** mdomsch has joined #openstack-meeting02:29
*** mdomsch_ has joined #openstack-meeting02:31
*** bencherian has quit IRC02:32
*** dtroyer is now known as dtroyer_zzz02:33
*** nati_uen_ has joined #openstack-meeting02:36
*** nati_ueno has quit IRC02:39
*** Mandell has joined #openstack-meeting02:49
*** novas0x2a|lapto1 has quit IRC02:55
*** vish1 is now known as vishy03:04
*** s0mik has joined #openstack-meeting03:05
*** zul has quit IRC03:07
*** mattray has quit IRC03:09
*** s0mik has quit IRC03:37
*** s0mik has joined #openstack-meeting03:47
*** dendro-afk is now known as dendrobates04:01
*** dendrobates has joined #openstack-meeting04:01
*** nati_uen_ has quit IRC04:04
*** s0mik has quit IRC04:05
*** Mandell_ has joined #openstack-meeting04:11
*** Mandell has quit IRC04:11
*** jgriffith has joined #openstack-meeting04:19
*** adjohn has joined #openstack-meeting04:20
*** blamar has quit IRC04:21
*** garyk has quit IRC04:28
*** dolphm has joined #openstack-meeting04:30
*** notmyname has joined #openstack-meeting04:36
*** mdomsch_ has quit IRC04:41
*** bencherian has joined #openstack-meeting04:44
*** adjohn has quit IRC04:46
*** dolphm has quit IRC04:56
*** danwent has joined #openstack-meeting04:56
*** mnewby has quit IRC05:03
*** jakedahn_zz is now known as jakedahn05:04
*** mnewby has joined #openstack-meeting05:04
*** cburgess has quit IRC05:05
*** cburgess has joined #openstack-meeting05:05
*** dabo has quit IRC05:05
*** dabo has joined #openstack-meeting05:05
*** littleidea has quit IRC05:08
*** mnewby has quit IRC05:08
*** littleidea has joined #openstack-meeting05:08
*** jakedahn is now known as jakedahn_zz05:10
*** adjohn has joined #openstack-meeting05:12
*** adjohn has quit IRC05:15
*** dayou has joined #openstack-meeting05:36
*** novas0x2a|laptop has joined #openstack-meeting05:43
*** garyk has joined #openstack-meeting05:48
*** jgriffith has quit IRC05:54
*** joearnold has joined #openstack-meeting06:05
*** dolphm has joined #openstack-meeting06:06
*** dolphm has quit IRC06:10
*** littleidea has quit IRC06:20
*** joearnold has quit IRC06:38
*** danwent has quit IRC06:51
*** ttrifonov_zZzz is now known as ttrifonov07:03
*** Razique has joined #openstack-meeting07:15
*** chrisfer1 has joined #openstack-meeting07:17
*** chrisfer has quit IRC07:18
*** openstack has joined #openstack-meeting07:28
*** ChanServ sets mode: +o openstack07:28
*** _0x44 has joined #openstack-meeting07:28
*** Mandell_ has quit IRC07:29
*** ghe has joined #openstack-meeting08:16
*** ghe is now known as Guest5577408:17
*** Guest55774 is now known as GheRivero08:33
*** sandywalsh has quit IRC08:38
*** darraghb has joined #openstack-meeting08:46
*** Razique has quit IRC08:47
*** Razique has joined #openstack-meeting08:50
*** GheRivero has quit IRC08:55
*** GheRivero has joined #openstack-meeting09:08
*** myz has joined #openstack-meeting09:28
*** bencherian has quit IRC10:09
*** myz is now known as mynewnick10:55
*** mynewnick is now known as myz10:56
*** myz is now known as mynewnick10:56
*** mynewnick is now known as myz10:56
*** myz has quit IRC10:57
*** dendrobates is now known as dendro-afk11:11
*** markvoelker has joined #openstack-meeting11:20
*** zul has joined #openstack-meeting11:20
*** milner has joined #openstack-meeting11:32
*** krtaylor has joined #openstack-meeting11:54
*** myz has joined #openstack-meeting12:11
myzhelp12:11
sorenmyz: Wrong channel.12:11
myzsoren: sorry meant to send '/help' to the client :)12:12
*** myz has quit IRC12:18
*** myz has joined #openstack-meeting12:19
myzI'd a couple of successful Nova installations before, but I came to a point where I want understand Nova configuration file          │ apetrescu12:28
myz                 | 'nova.conf'; It has too many options and for multinode installtion you can't understand which option goes to which component         │ Apolonio12:28
myzso, you will copy 'nova.conf' to all your nodes, but I think this is not the proper way for deployment12:29
sorenmyz: Wrong channel :)12:30
*** dolphm has joined #openstack-meeting12:30
*** dhellmann_ has joined #openstack-meeting12:32
*** dhellmann_ has quit IRC12:32
myzsoren: sorry again it is just my new client :)12:34
*** martianixor has joined #openstack-meeting12:34
*** dhellmann has quit IRC12:36
*** martianixor has quit IRC12:39
*** martianixor has joined #openstack-meeting12:40
*** ryanpetrello has joined #openstack-meeting12:41
*** myz has quit IRC12:42
*** ryanpetrello has quit IRC12:42
*** dprince has joined #openstack-meeting12:44
*** myz has joined #openstack-meeting12:45
*** martianixor has quit IRC12:45
*** martianixor has joined #openstack-meeting12:45
myzanyone with experience in installing multinode openstack Nova?12:50
zulstill wrong channel12:51
myzzul: why?? still wrong channel??12:52
zulmyz: this isnt a support channel you want #openstack12:53
myzsorry guys I know i made headache for you12:53
*** dendro-afk is now known as dendrobates13:04
*** dwcramer has quit IRC13:11
*** glenc has joined #openstack-meeting13:14
*** dolphm has quit IRC13:26
*** ayoung has joined #openstack-meeting13:32
*** oubiwann has quit IRC13:34
*** primeministerp has quit IRC13:37
*** mattray has joined #openstack-meeting13:39
*** primeministerp has joined #openstack-meeting13:42
*** ryanpetrello has joined #openstack-meeting13:42
*** littleidea has joined #openstack-meeting13:47
*** primeministerp has quit IRC13:50
*** primeministerp has joined #openstack-meeting13:51
*** nikhil has joined #openstack-meeting13:52
*** joesavak has joined #openstack-meeting13:54
*** dayou has quit IRC13:55
*** dolphm has joined #openstack-meeting14:05
*** dolphm_ has joined #openstack-meeting14:05
*** nikhil has quit IRC14:08
*** dolphm has quit IRC14:09
*** edygarcia has joined #openstack-meeting14:09
*** morellon has left #openstack-meeting14:13
*** blamar has joined #openstack-meeting14:19
*** dwcramer has joined #openstack-meeting14:20
*** Gordonz has joined #openstack-meeting14:21
*** dhellmann has joined #openstack-meeting14:21
*** sandywalsh has joined #openstack-meeting14:22
*** Gordonz has quit IRC14:22
*** Gordonz has joined #openstack-meeting14:22
*** sandywalsh_ has joined #openstack-meeting14:26
*** sandywalsh has quit IRC14:26
*** Gordonz has quit IRC14:27
*** Gordonz has joined #openstack-meeting14:28
*** dendrobates is now known as dendro-afk14:30
*** dhellmann has quit IRC14:43
*** krtaylor has quit IRC14:44
*** edygarcia has quit IRC14:45
*** jgriffith has joined #openstack-meeting14:48
*** sandywalsh_ has quit IRC14:53
*** dhellmann has joined #openstack-meeting14:55
*** bencherian has joined #openstack-meeting15:04
*** sandywalsh has joined #openstack-meeting15:08
*** rnirmal has joined #openstack-meeting15:14
*** lzyeval has joined #openstack-meeting15:19
*** krtaylor has joined #openstack-meeting15:24
*** edygarcia has joined #openstack-meeting15:25
*** joearnold has joined #openstack-meeting15:29
*** danwent has joined #openstack-meeting15:30
*** joearnold has quit IRC15:30
*** joearnold has joined #openstack-meeting15:32
*** martianixor has quit IRC15:36
*** DuncanT has quit IRC15:37
*** DuncanT has joined #openstack-meeting15:38
*** DuncanT has quit IRC15:40
*** ravi has joined #openstack-meeting15:43
*** DuncanT has joined #openstack-meeting15:43
*** DuncanT has joined #openstack-meeting15:44
*** ravi has quit IRC15:46
*** ravi has joined #openstack-meeting15:46
*** ravi_ has joined #openstack-meeting15:52
*** lzyeval has quit IRC15:52
*** adjohn has joined #openstack-meeting15:53
*** heckj has joined #openstack-meeting15:54
*** ravi has quit IRC15:54
*** krtaylor has quit IRC15:55
*** mnewby_ has joined #openstack-meeting15:59
*** blamar_ has joined #openstack-meeting16:01
*** mnewby_ has quit IRC16:01
*** myz has quit IRC16:02
*** blamar has quit IRC16:05
*** blamar_ is now known as blamar16:05
*** oubiwann has joined #openstack-meeting16:06
*** mnewby has joined #openstack-meeting16:09
*** s0mik has joined #openstack-meeting16:13
*** dtroyer_zzz is now known as dtroyer16:14
*** adjohn has quit IRC16:16
*** sleepsonzzz is now known as sleepsonthefloor16:16
*** lzyeval has joined #openstack-meeting16:16
*** GheRivero has quit IRC16:17
*** lzyeval has quit IRC16:32
*** lloydde has joined #openstack-meeting16:35
*** Razique has quit IRC16:43
*** dhellmann has quit IRC16:46
*** oubiwann has quit IRC16:48
*** sandywalsh has quit IRC16:48
*** ryanpetrello has quit IRC16:49
*** Mandell has joined #openstack-meeting16:55
*** jakedahn_zz is now known as jakedahn16:59
*** nati_ueno has joined #openstack-meeting17:01
*** PotHix has joined #openstack-meeting17:09
*** rafaduran has joined #openstack-meeting17:14
*** ncode has joined #openstack-meeting17:15
*** garyk has quit IRC17:28
*** adjohn has joined #openstack-meeting17:29
*** bencherian has quit IRC17:30
*** bencherian_ has joined #openstack-meeting17:30
*** darraghb has quit IRC17:31
*** krtaylor has joined #openstack-meeting17:41
*** johnpostlethwait has joined #openstack-meeting17:43
*** krtaylor has quit IRC17:53
*** marek_ has joined #openstack-meeting17:55
* heckj pokes his head in the meeting room17:55
*** kevin-lewis-9 has joined #openstack-meeting17:56
*** bencherian_ has quit IRC17:59
chmouelheckj: it's ok since http://icanhascheezburger.files.wordpress.com/2007/08/this-meeting-is-over.jpg18:01
heckjheh18:01
*** gyee has joined #openstack-meeting18:01
*** arunkant has joined #openstack-meeting18:01
heckjwho's here for keystone?18:01
heckjo/18:01
chmouelo/18:01
rafadurano/18:01
*** liemmn has joined #openstack-meeting18:01
heckj#startmeeting18:02
openstackMeeting started Tue Jun 12 18:02:13 2012 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.18:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:02
heckjHowdy all!18:02
liemmno/18:02
heckjSorry for missing the last meeting - thank you Dolph for coordinating it!18:02
heckjI've got some specific pieces to go over for the API review, but first I figured I'd hit any hot topics18:03
heckj#topic New Issues?18:03
*** openstack changes topic to "New Issues?"18:03
heckjAny production issues?18:04
*** gyee has quit IRC18:04
liemmnNot really new issue; but, I asked on the list if we can include an RBAC example for how to isolate users that are created in one domain from being modifiable by a domain admin in another domain... I think it is doable.18:05
*** gyee has joined #openstack-meeting18:05
heckjliemmn: agreed. I think I'm going to create a blueprint to do some of this, because we're not tracking it otherwise18:06
*** lcheng has joined #openstack-meeting18:06
liemmnheckj, sounds good...  If you want, you can assign it to me, and I will take a stab at it...18:06
heckjliemmn: thanks, will do18:07
liemmngracias18:07
heckj#action heckj to create blueprint to track doc updates on how to deploy - policy.json, suggested role names, etc18:08
dolphm_o/18:08
heckjanything else in new topics?18:08
heckjtermie: you around?18:09
*** novas0x2a|laptop has quit IRC18:09
heckjheading to V3 API feedback & questions18:09
heckj#topic V3 API feedback18:09
*** openstack changes topic to "V3 API feedback"18:09
heckj#link https://docs.google.com/document/d/1s9C4EMxIZ55kZr62CKEC9ip7He_Q4_g1KRfSk9hY-Sg/edit#18:10
liemmnIs there going to be a draft#2, or is that it?18:10
heckjI sent an email out sunday with open questions and general notes from the feedback.18:11
dolphm_yeah the date wasn't updated either :P18:11
liemmnahh... gotcha ;)18:11
heckjliemmn: I aimed at creating another draft, but focused on small questions this past weekend from the coffee shop18:11
heckjI have a list of questions I thought I'd bring up here - most related to Andy's feedback, but some others as well.18:12
heckjgyee: you around?18:12
gyeeo/18:12
heckjgyee: you asked about adding a status field into the token attributes - could you illuminate a bit more what's going on there? I made a suggestion in feedback, but I'm not clear on what multifactor auth needs18:13
gyeeI am connecting from a coffee shop this time too :)18:13
gyeeMFA18:13
*** lcheng has quit IRC18:13
gyeelike half-token18:13
dolphm_heckj: i think a token just needs to be able to say "I exist, but I'm not valid, yet"18:13
gyeestatus = 'incomplete' or something18:13
heckjgyee: I got that bit. I guess here's the question - right now a token is expected to be fully there if it's there18:15
*** lcheng has joined #openstack-meeting18:15
heckjso if we add a partial field, do we want to specify some specific values there so we can update auth_token to know how to validate a partial token correctly?18:15
gyeeyes, hopefully the auth modules will update token status accordingly18:16
dolphm_could we accomplish this with status codes? (http 206 partial content)18:16
heckjgyee: since you know a touch more about multifactor, could you suggest possible values there? (and lets limit in in the spec)18:16
gyeeright now, its going to be 'enabled' or 'incomplete'18:17
dolphm_(i think 206 is totally wrong, btw)18:17
gyeecase-insensitive :)18:18
heckjdolphm_: switching topics - the /versions thing. I'm afraid I never quite groked the original setup, so I wasn't clear on how to assert what capabilities the backends provide. How can we do that reasonably with the /versions API setup?18:19
dolphm_heckj: not sure what you're asking for? a use case for /versions?18:19
heckjdolphm_: sorry - what more definition should we add to a V3 draft 2 to be explicit about backends? resource attributes, etc? I don't have a sense of what gets returned when you do a GET /versions now...18:20
termiei am here now, ping pong game was won18:21
heckjyeah!!!18:21
heckjtermie, dolphm_, et al - I'm intentionally flattening the endpoints (or suggesting it). Bad idea?18:22
dolphm_well, i actually don't know what /versions is ... i assume you mean / (the multiple choice response, containing links to available api versions) or /v#/extensions ?18:22
heckjit related to some of termie's comments about mapping policy to endpoints as well...18:23
heckjdolphm_: yeah - that's driven by the VersionController in keystone today18:23
*** nati_ueno has quit IRC18:23
dolphm_heckj: and you're proposing to move it to /v3/versions?18:23
termielulz18:24
dolphm_(if so, that seems to defeat the point?)18:24
termienobody uses it to begin with18:24
*** nati_ueno has joined #openstack-meeting18:24
dolphm_termie: that's because we only have 1 version in openstack18:24
termienope, it is because people only write code that talks to one version18:24
heckjdolphm_: I don't know what to do with / that whole version, extension thing - I never understood it, so I'm looking for what we *should* do with it in V3 API18:24
termiermeove18:24
gyeeor run two instances of keystone! :)18:25
termiegyee: not a solution18:25
termiegyee: but i like the joke18:25
*** marek_ has quit IRC18:25
termiethe point is, if you are using v1 api or whatever, you give htem the endpoint that starts with /v1 and they do what they expect to be in v118:26
dolphm_ideally you wouldn't have to specify versions in the catalog, it'd just be http://identity:5000/18:27
dolphm_and the client would take that, discover what versions are supported by the endpoint, compromise on compatiblity/stability, and talk to that api endpoint18:27
*** jog0 has joined #openstack-meeting18:27
termieno chance that any developer would ever write code to discover versions and do compat18:27
gyeeI do if I am writing a 3rd client18:28
liemmndolphm: +118:28
termiegyee: no you don't18:28
termiegyee: a website gives  you an endpoint for the version you want to use18:28
termiegyee: not an api18:28
dolphm_termie: certainly not if the server doesn't provide the necessary info to write an intelligent client18:28
termiedolphm_: there are no intelligent clients18:28
dolphm_termie: i'm not saying there are18:29
liemmnThere are no intelligent clients out there because in general, APIs suck....  but, with better adoption of concepts like HATEOAS, it will make it easier to write one.18:30
termiedolphm_: i'm saying there never will be because it isn't worth the effort, y'all act as if the rest of the world is somehow better at this than we are, they aren't they are just as lazy18:30
termieliemmn: pipe dream18:30
heckjOkay - I think we're at a dead end on that point. Won't hurt to add, but there's little confidence (from Andy) that it would ever be actually useful.18:31
heckjtermie - switching back to feedback on service & endpoints: what do you think about modeling endpoints as a single layer instead of modelling service and endpoint separately and linking them?18:31
dolphm_leave it in the api but don't implement it?18:31
*** jog0 has quit IRC18:31
*** jog0 has joined #openstack-meeting18:32
termieheckj: i think the service as a first class citizen allows us to do things that reference services18:32
dolphm_termie: what's the value of referencing a service without an endpoint?18:32
*** lzyeval has joined #openstack-meeting18:32
termieheckj: as in,right now we create users for a service and make them an admin for operations under that service18:32
termies/user for a service/the service itself (actual service not in keystone) uses a user to do its operations18:33
heckjtermie: so you'd prefer to stay with service and endpoint as separate REST resources?18:33
termieso if we want to allow that user to have control only over things for a service, it is helpful to keep it as a first-class citizen18:33
dolphm_termie: so you want to preserve services + endpoints on the management api, which i think we're all fine with ... what about the public api (catalog)?18:34
termieheckj: yes, i'm not happy with how they are exactly used right now (it wasn't previously clear their connection with generating the catalog)18:34
termieheckj: but i think the concepts are now ingrained in the system18:34
heckjtermie: gotcha. In the next draft I'll revert back to separate service+endpoint.18:34
termiedolphm_: what about what part of the public api / catalog ?18:35
termieyou mean how they are represented in teh catalog?18:35
heckjtermie: I'll also link suggest a link on policy to service instead of endpoint18:35
dolphm_termie: right18:35
dolphm_termie: what do you want the catalog to look like18:35
termiedolphm_: i already wrote the catalog how i wanted it to look and then wrote a translation to the format defined tby the api18:36
termiedolphm_: off hand i think it was service -> region -> endpoint or something of that nature18:36
termiei don't think flattening helps us too much18:36
*** lzyeval has quit IRC18:36
termiei am being dragged away from the computer at this point18:37
heckjtermie: do you want to change the V3 API to present it in your prefered format? I don't recall what you wanted there, but happy to18:37
heckjdamn18:37
dolphm_region -> service_type -> {adminUrl, internalUrl, name, publicUrl}18:37
heckjI'll follow up with termie in email18:37
heckj(and on mailing list)18:37
dolphm_heckj: see get_catalog() in keystone.catalog.core18:37
heckj#action heckj follow up on service catalog and CRUD API for service and endpoints18:37
heckjliemmn, dolphm_: for credentials - should those be linked to tenant, or is there a use case to have them be specific to just a user?18:38
dolphm_no preference from me18:38
heckjI was thinking of EC2 credentials, which I thought was linked to tenant - but I think one of you two brough up that it should be optional.18:39
gyeeuser access key auth?18:39
dolphm_not me18:39
liemmnI think optional18:39
liemmnallows for other credential type that do not need to be scoped to tenant18:39
heckjI could see that for general credentials, but wasn't sure how to deal with the EC2 case (create EC2 creds) if the tenant wasn't provided. Today EC2 creds infer a tenant automatically18:39
heckjliemmn: So for the impl of EC2 creds, throw a failure when creating when not linking to a tenant?18:40
liemmnwe can infer with the default tenant id thingy from the user, if a tenant is not specified.18:40
gyeewait, didn't someone suggested user passwords management using credential APIs18:40
dolphm_gyee: o/18:41
heckjliemmn: we're definitely heading towards a "default tenant" concept on the user based on the feedback I've been seeing.18:41
gyeedolphm_ so in that case, cred is linked to user not tenant right?18:41
dolphm_gyee: for that case, yes18:42
heckjgyee: creds have always been linked to use - the question is do we also link them explicitly to tenant.18:42
gyeeheckj, i c18:42
heckjI'm wanting to be as explicit about links as possible through the APIs to avoid some of the pain we hit with the earlier v1 and v2 api impls.18:42
heckjtheoretically, we could have the keystone service also store/serve SSH keys for use in images when they're created as well (i.e. look towards moving keypairs into keystone from currently in nova)18:43
heckjthat's a use case for something that wouldn't be linked to tenant, but would be for user18:44
gyeemake sense18:44
*** devananda has joined #openstack-meeting18:45
heckjOk - I'll go with optional in the next draft.18:45
dolphm_heckj: a tenant reference IS required for ec2 credentials, correct?18:45
*** novas0x2a|laptop has joined #openstack-meeting18:45
heckjI'm aiming to make a new draft (#2) this weekend and get it published.18:46
heckjdolphm_: yes18:46
heckj#topic open discussion18:46
*** openstack changes topic to "open discussion"18:46
heckjWhat do you all think about the feedback mechanism (google docs) for the API? I think it's been reasonably good - not sure of anything better out there, but would love to have alternate suggestions for the future18:47
dolphm_i like it18:47
gyeeetherpad?18:47
liemmn+118:47
dolphm_-1 for etherpad in this case :(18:47
liemmn+1 (for googledocs)18:47
heckjgyee: I specifically didn't want etherpad because it was too easy for everything to change the content we're discussing18:47
dolphm_i like the limited control over the doc, and discussion notifications18:47
heckjI love etherpad for immediate collaboration, but Q&A over time has (to be) been immensely painful18:48
dolphm_and etherpad might complement google docs fairly well18:48
dolphm_or wiki18:48
gyeehard to follow google doc sometime, I had to go back to emails18:48
gyeeespecially if there are so many comments18:48
gyeebut no big deal18:49
*** Shrews has joined #openstack-meeting18:49
heckjgyee: I found the same, which is why I got aggressive about resolving some of the comments.18:49
dolphm_i do think we need to resolve comments more frequently18:49
gyee+118:49
heckjdolphm_: my bad on some of that - was very distracted last week and didn't get a chance to read much until this past weekend18:49
dolphm_heckj: speaking of which, i think i just accidentally resolved a discussion lol18:49
heckjheh18:50
heckjtime check: 10 minutes left - any other topics?18:50
gyeeis the keystone RBAC impl be similar to Nova18:50
heckjgyee: yes, identical in fact. It's not that way now, but that would be my choice. Same policy engine code that it's nova, glance, (soon quantum), etc.18:51
gyeegotcha18:51
heckjgyee: right now there's a binary "is_admin" check getting used. Needs to get updated18:51
dolphm_CRUD on /policy vs /actions ... we're leaning on /policy blobs, correct?18:51
gyeeI was mocking with that code for the domain stuff18:51
gyeehad to fix a few bugs18:52
gyeefor example, is_admin:1 doesn't work18:52
heckjdolphm_: I'm not leaning on anything there as yet, I just don't have a good sense of what will make the most sense near and longer term. Looking for a way to make a reasonable decision.18:52
gyeebackend is returning is_admin:True18:52
*** vincentricci has joined #openstack-meeting18:53
heckjgyee: the policy engine bits and decorators are in several places in nova & glance - though we might consolidate that into openstack-common and then use it in keystone as well.18:53
dolphm_heckj: i still don't have a solution/understanding for matching the current feature set of rules18:53
heckj(or put it in keystone and then use in nova, glance, etc)18:53
gyeeheckj, agreed18:53
*** joearnold has quit IRC18:53
*** vincentricci has left #openstack-meeting18:53
gyeedolphm_, it would be nice if RBAC and do object matching18:54
heckjdolphm_: I'm being dense, didn't grok your last sentence. What don't you have a solution for?18:54
gyeelike serialize the object, then string comparison18:54
heckjdolphm_: nm, just got it18:54
*** ecarlin has joined #openstack-meeting18:54
*** ecarlin has quit IRC18:55
*** ecarlin has joined #openstack-meeting18:56
*** nati_uen_ has joined #openstack-meeting18:56
heckjanything else?18:57
dolphm_gyee: not sure if i follow your last two comments18:57
heckj#action heckj to publish draft2 of V3 API this weekend18:57
gyeeis_admin:1 != is_admin:True18:57
dolphm_YAY18:57
gyeeif we serialize it and compare apple to apple18:57
dolphm_if ... then what?18:58
gyeethen is_admin:1 == is_admin:True18:58
dolphm_what's is_admin?18:58
*** nati_ueno has quit IRC18:58
gyeea string18:58
gyeein RBAC18:59
dolphm_what kind of string18:59
dolphm_a role name?18:59
dolphm_admin?18:59
gyeekeystone middleware sets it I think18:59
gyeewhen it sees that ADMIN token18:59
dolphm_we don't have rbac today18:59
dolphm_oh that's in the wsgi env?19:00
gyeeI know, I was mocking with that code19:00
heckjI'm wrappin' this up - continue until Monty kicks you :-)19:00
dolphm_heckj: /salute19:00
gyeeI think so19:00
heckj#endmeeting19:00
*** openstack changes topic to "OpenStack meeting channel. See http://wiki.openstack.org/Meetings for schedule and http://eavesdrop.openstack.org/meetings/openstack-meeting/ for meeting logs"19:00
openstackMeeting ended Tue Jun 12 19:00:34 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-12-18.02.html19:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-12-18.02.txt19:00
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-12-18.02.log.html19:00
liemmnlunch time!19:00
gyee+119:00
liemmnsee y'all19:00
*** gyee has quit IRC19:01
heckjthanks y'all19:01
dolphm_is_admin shouldn't exist with proper rbac, as there's no granularity in that statement19:01
dolphm_or rather, in the claim being made19:01
LinuxJedimtaylor: CI time?19:01
mtayloryup19:02
mtaylor#startmeeting19:02
openstackMeeting started Tue Jun 12 19:02:17 2012 UTC.  The chair is mtaylor. Information about MeetBot at http://wiki.debian.org/MeetBot.19:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.19:02
mtayloranybody want to talk about CI?19:02
clarkbmaybe19:02
LinuxJediyou mean that TV show about DNA that plays The Who in the intro?19:03
mtayloryup19:04
jeblairTonight on CI: OpenStack -- the brutal killing of an incubated project.19:04
mtaylorhahaha19:04
LinuxJedilol! :)19:04
mtaylorfirst up - I'm deleting all of the melange jobs19:04
mtayloranybody have any problems with that?19:05
mtaylorgood.19:05
mtaylornext?19:05
mtaylorclarkb: anything fun to talk about?19:05
clarkbsure19:05
clarkbI think I am happy with the etherpad lite puppet module now. I need to make it puppet masterable then use the host LinuxJedi gave me19:05
mtaylorsweet19:06
clarkbso the testing of migrated the DBs should happen RSN19:06
* LinuxJedi upgraded that to 12.04 for clarkb19:06
mtaylorexcellent19:06
mtaylorI'm excited about our new etherpad lite overlords19:06
LinuxJediclarkb: you have SSH access to that now?19:06
clarkbLinuxJedi: in theory I do, I haven't tested it yet19:06
clarkbjeblair merged a puppet change that added my public key to the host19:06
LinuxJediclarkb: ok, theory is good19:06
*** nati_uen_ has quit IRC19:07
mtaylorclarkb: so we might have migrated data to test next week some time?19:07
mtayloror this week even (it's tuesday)19:07
clarkbmtaylor: hopefully by the end of this week19:07
mtaylorballer19:07
clarkbI will need to borrow LinuxJedi at some point as he has access to the old stuff19:07
mtaylorI betcha that can be arranged19:08
LinuxJediclarkb: in theory... I tried to SSH into it the other day and failed, need to make sure I really do have access...19:08
mtaylorLinuxJedi: speaking of machines and access ... it looks like there are still some things using the default tenant in my mordred@inaugust.com and/or my monty.taylor@hp.com accounts on hpcloud19:09
LinuxJediclarkb: worst case I should have shell type access19:09
mtaylorjeblair: ^^ devstack is using one of them I think19:09
clarkbLinuxJedi: that should work19:09
jeblairmtaylor: don't think so.19:09
LinuxJedimtaylor: should only be your servers left there now19:09
LinuxJedimtaylor: I removed all of Stackforge.19:09
clarkbI have also spent some time fixing bugs in the important changes and "status:reviewable" patch to gerrit now that it is live19:10
clarkball UI related so nothing horribly broken, but trying to make it useful19:10
clarkbShrews: were you still planning to update review-dev sometime soon?19:11
mtaylorall those and Shrews changes have been merged in now I think19:11
Shrewsclarkb: just submitted the change  :)19:11
clarkbwoot19:11
Shrewshttps://review.openstack.org/#/c/8450/19:11
*** ecarlin has quit IRC19:11
*** dendro-afk is now known as dendrobates19:11
clarkbthe other major time suck over the last week has been standardizing project in tree documentation19:11
clarkbthe idea is that we can use a templated jenkins job to build in tree sphinx documentation then copy it to docs.openstack.org19:12
mtayloryeah. that's all going to be great19:12
clarkbcurrently many projects build documentation in their own special ways so I have 8 changes in gerrit right now to make them the same (though similar is probably a better description)19:13
jeblairthat makes me happy19:13
mtayloryeah. _same_ is ...19:13
mtaylor++19:13
mtaylorI also like uploading them to docs.openstack.org - makes more sense than $project.openstack.org19:13
mtayloralso - I think that means that the wiki server will be down to only being a wiki server19:13
clarkbI have also updated jenkins jobs to do that, but haven't been able to test it much beyond spitting out XML and glancing at it19:14
clarkbso I may need to fire up a jenkins instance to test that19:14
annegentleYay same.19:14
mtaylorI _was_ thinking we should wait until the docs changes land...19:14
clarkbmtaylor: yes we should19:14
*** matwood has joined #openstack-meeting19:14
mtaylorbut then I realied, screw it - they're not related19:14
annegentledid we need to shop the idea with PTLs at all?19:14
annegentleor did you already?19:14
mtaylorit's not going to break any more than it already is19:14
mtaylorannegentle: nope19:15
annegentlemtaylor: good point, that19:15
mtaylorannegentle: we just submitted the changes19:15
clarkbI have seen any screaming. I think I got one "ok..."19:15
mtaylornobody has complained yet - I don't think it's going to bug anyone19:15
annegentlemtaylor: ok, normal review process should be sufficient19:15
mtayloryeah19:15
mtaylorheckj seemed bemued19:15
mtaylorbemused19:15
clarkbs/have/haven't19:15
LinuxJediclarkb: ok, my todo this week.  Find out who owns the etherpad server because it isn't on any of our cloud accounts either...19:15
LinuxJedimtaylor: who owned the old eavesdrop?19:16
*** arunkant has quit IRC19:16
mtaylornobody19:16
LinuxJedimtaylor: o..k.. how did we get access to it?19:16
clarkbso in addition to finishing those things up I will also be attempting to fix the github pull request closing script19:16
mtaylorLinuxJedi: ant or rick clark are the usual people to ping19:17
LinuxJedimtaylor: cool, SSH is on the same port so I'm assuming same ownership19:17
mtaylorLinuxJedi: antonym19:17
mtayloris the irc nick19:17
LinuxJedimtaylor: thanks19:17
mtaylorawesome. that's a bunch of good stuff19:17
mtaylorShrews: updates on gerrit-y things?19:18
Shrewsmtaylor: a bit19:18
Shrewsfixed a WIP issue where it was possible to WIP a draft19:19
Shrewsthus causing "real bad stuff"19:19
Shrewsand...19:19
Shrewsi have the python version of gerrit running19:19
Shrewswell, "running"  (with quotes)19:19
mtaylorhehe19:20
* LinuxJedi assigns Shrews the task of re-writing it in Ruby19:20
*** ecarlin has joined #openstack-meeting19:20
clarkbLinuxJedi: I think that propoganda got to you19:20
* Shrews assigns a big knife to LinuxJedi's neck19:20
* jeblair assigns Shrews the task of re-writing it in go19:20
mtaylorfor the record - pygerrit uses protocol buffers and protobuf rpc19:20
LinuxJedilol :)19:20
LinuxJediwoot!19:20
LinuxJedimtaylor: even more WTF? about ditching it then19:21
mtaylorright?19:21
mtaylorwell- they do seem to have used that partially to talk back and forth between the portions written in java and the portions written in python19:21
mtaylorso "pygerrit" might be a bit of a misnomer19:21
jeblairugh19:21
mtaylorit's a django app with the git repo stuff done in jgit19:22
Shrewsit's pyjagerrit19:22
mtaylorhahaha19:22
LinuxJediShrews: bless you19:22
mtaylorok. moving on ...19:22
mtaylorLinuxJedi: did you do anything this last week?19:22
LinuxJedimtaylor: I got the puppet master up and running19:23
mtaylor++19:23
LinuxJediwe have eavesdrop, planet and paste running from it19:23
LinuxJediand found an issue with file serving which I think we are ready for me to implement a solution for19:23
*** matwood_ has joined #openstack-meeting19:23
*** mnewby has quit IRC19:23
LinuxJediand I did some minor things that I forgot about19:24
*** matwood has quit IRC19:24
*** matwood_ is now known as matwood19:24
mtaylorsweet19:24
mtaylorI'm excited about our new puppetmaster overlords19:25
LinuxJediwhen complete we can call CI the muppet show19:25
Shrewshow many overlords do we have now?19:25
mtaylormany many many19:25
*** matwood has quit IRC19:25
LinuxJediShrews: we are slaves to the machines19:25
mtaylorjeblair: fun in the land of zuul and backups?19:26
jeblairwell, that's the future.  :)19:26
*** donaldngo has joined #openstack-meeting19:26
jeblairi've identified a couple of bugs in zuul, but by and large, it has mostly worked.19:26
jeblairwhat has failed should be easy to fix.19:27
jeblairi wrote gobs of docs for it19:27
jeblairhttp://ci.openstack.org/zuul/19:27
mtaylorI actually just sent someone a link to that, actually19:27
jeblairbased on clarkb's settings, so we should be able to switch that to use the new job template like the rest of the projects19:27
mtayloroh - speaking of - I got a feedback on one of the lines in the docs:19:27
LinuxJedijeblair: we should totally find a way to make CI docs home link to that19:28
mtaylorjeblair: "Zuul queues those changes in the order they were approved, and notes that each subsequent change depends on the one ahead of it merging"19:28
mtaylorjeblair: confused the reader and caused him to think it was talking about actual git-level dependent changes19:28
mtaylorjeblair: rather than the dependencies created by queue position19:29
jeblairi've been looking into server based and swift-based backups.  i'm leaning toward server-based due to the complexity around key and account (ie, cloud account) credentials.19:29
mtaylor++ server-based19:29
jeblairmtaylor: okay.  i will take a look at that.  i vomited out the docs in one long session and have hardly even read them.  :)19:29
jeblairLinuxJedi: good idea19:29
mtaylorjeblair: :)19:30
mtaylorjeblair: I'm impressed that they exist19:30
*** ncode has quit IRC19:30
jeblairas far as the past -- i switched like all the jenkins slaves to precise19:30
jeblair(except we need to keep some oneiric around to run py26)19:30
mtaylorexcited about that19:30
LinuxJediah, I was going to write a todo for me to do that in Stackforge19:31
mtaylorstill haven't observed jclouds bursting yet19:31
jeblairand i've been working on figuring out why tempest isn't happy; it turns out at least one problem is that one of our devstack node providers is giving us corrupted images.  no points for guessing which.19:31
*** nina has joined #openstack-meeting19:31
mtaylorec2?19:31
jeblairmtaylor: maybe take some precise slaves offline?  i did make 8 of them.19:31
jeblairmtaylor: close.19:32
LinuxJediAzure?19:32
*** nina has left #openstack-meeting19:32
jeblairthat's it in broad strokes.19:32
* jeblair hands the speaking stone back to mtaylor19:33
mtaylorjeblair: point. I'll do that19:33
mtaylorso- I've been poking at a bunch of random things19:33
mtaylortox.ini alignment, got coverage jobs pretty much all green19:33
* jeblair looks worried19:34
mtaylorttx and I are going to talk to the ppb next meeting about client lib release plan19:34
clarkbjeblair: cronspam? I wonder if it is related to pypi being slow19:34
mtaylorand I'm going to try to get an answer from them too on the global dep list versions that are in conflict19:35
mtaylorand I wrote a little code to do tag-based post-release versioning for client libs19:35
mtaylorand I tried not to break too many things19:35
mtayloroh - didn't I do the new pypi mirror last week?19:35
jeblairyep19:35
mtaylorso, wrote a new pypi mirror from scratch :)19:36
LinuxJediyay, fixing what the broken one did was fun :)19:36
clarkbdecided the existing wheels were too square?19:36
mtaylorit grabs all of our projects, pip install downloads all of their depends (and depends of depends) to populate the PIP_DOWNLOAD_CACHE19:36
mtaylorand then turns the files in the pip download cache into a pypi style index19:36
LinuxJediclarkb: the existing wheels broke all our jobs overnight ;)19:37
heckjo/ (mtaylor: bemused is a good word - fine by me, don't mind being consistent)19:37
mtayloryay!19:38
mtaylorwe'll consider that a binding opinion19:38
mtaylorI think that's about all I've got19:38
mtayloranything from anybody else?19:38
LinuxJedimtaylor: we will be able to do the meeting next week?19:39
LinuxJedi(we as in me and you)19:39
mtaylorLinuxJedi: good question19:39
mtaylorwe'll try - but LinuxJedi and I might be offline during meeting time19:40
*** sandywalsh has joined #openstack-meeting19:40
mtayloreven so - I'm sure that jeblair and clarkb and Shrews can soldier on without us :)19:40
clarkbbut who will Shrews stab if you guys aren't here19:40
Shrewsmtaylor: you're still here?  heh19:40
* Shrews eyes clarkb19:41
LinuxJedilol :)19:41
jeblairwe will get so much done... and violence free.19:41
jeblairVIOLENCE FREE, SHREWS!19:41
LinuxJedijeblair: nothing will break ;)19:41
Shrewspffft19:41
jeblairLinuxJedi: was that some kind of curse?   thanks.  :)19:41
LinuxJediclarkb: my availability will be real patchy next week so make sure you get what you need out of me this one :)19:42
clarkbjust access to the old etherpad db at some point this week19:42
LinuxJediwill aim for that at least19:42
mtaylork. well, I think that's about it19:45
*** jk0 has joined #openstack-meeting19:45
*** ecarlin has quit IRC19:45
mtaylorunless anybody else has anything...19:47
Shrewsmtaylor, jeblair: when can we upgrade gerrit?19:48
jeblairasap i think.  if the change looks good on gerrit-dev, propose it for prod, and we can approve it when things seem quietish.19:49
Shrewsk19:49
mtaylorwork. k. thanks everybody19:50
mtaylor#endmeeting19:50
*** openstack changes topic to "OpenStack meeting channel. See http://wiki.openstack.org/Meetings for schedule and http://eavesdrop.openstack.org/meetings/openstack-meeting/ for meeting logs"19:50
openstackMeeting ended Tue Jun 12 19:50:24 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:50
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-12-19.02.html19:50
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-12-19.02.txt19:50
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-12-19.02.log.html19:50
*** Shrews has left #openstack-meeting19:52
*** jbryce has joined #openstack-meeting19:52
*** bcwaldon has joined #openstack-meeting19:53
*** nati_ueno has joined #openstack-meeting19:56
*** nati_ueno has quit IRC19:56
*** nati_ueno has joined #openstack-meeting19:57
*** johnpur has joined #openstack-meeting19:58
*** dprince has quit IRC19:58
*** krtaylor has joined #openstack-meeting19:59
*** gyee has joined #openstack-meeting19:59
ttxo/20:00
bcwaldonhey hey20:00
johnpuro/20:00
mtaylor o/20:01
jbryce#startmeeting20:01
danwento/20:01
openstackMeeting started Tue Jun 12 20:01:18 2012 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.20:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.20:01
jbryce6 of us...one more around?20:01
chmouelnotmyname is not able to attend today so I will be giving the swift update for him20:01
bcwaldonchmouel: wrong meeting!20:01
jk0o/20:02
ttxchmouel: one more hour to wait :P20:02
jbrycedevcamcar, heckj, vishy: around at all?20:02
chmouelhey :)20:02
bcwaldonvishy and anotherjesse are out20:02
*** edconzel has joined #openstack-meeting20:02
jbrycewell jk0 makes 7 so we can get started20:02
mtaylordon't count me ...20:03
mtaylorI'm not a member any more - i'm merely a petitioner today20:03
jbryceoops...habit20:03
*** jaypipes has joined #openstack-meeting20:03
jbrycepvo: ?20:03
ttxjaypipes is your man20:03
jaypipeshello.20:03
jaypipessorry for being late.20:03
jbrycesweet20:03
jbryce#topic Library/Gating projects20:04
*** openstack changes topic to "Library/Gating projects"20:04
jbrycehttp://wiki.openstack.org/Governance/Proposed/LibraryProjectDefinition20:04
jbrycettx or mtaylor: want to intro this oen?20:04
jbryceone20:04
ttxI can intro and let mtaylor elaborate20:04
mtayloryeah20:04
mtayloror ttx can20:04
heckjo/20:04
ttxI'll do the historic intro20:04
ttxFor client library projects we've always been a bit in between states20:05
ttxwhen they got split out of their "parent" project we decided that they would retain core status...20:05
ttx... by being considered another deliverable of the same project20:06
ttxso same PTL, but also same release date20:06
ttxand same project in Launchpad, so same bugtracker20:06
ttxThis creates a number of problems, so now is probably the time to change20:06
*** sparkycollier has joined #openstack-meeting20:06
ttxmtaylor: go for it20:06
mtaylorso what we'd like to do, as I've written up above with a bunch of chatting with bcwaldon and ttx20:07
*** nati_ueno has quit IRC20:07
*** donaldngo has quit IRC20:07
mtayloris to divorce the release of the client libs from the normal release process a bit20:07
mtaylorand just release them whenever they need a release20:07
mtaylorin general, we seem to be in general agreement that any given version of a client lib should support both the current and the previous versions of the api20:08
jaypipes++20:08
danwentmtaylor: how far back?  do we have a strategy for EOL-ing API versions?20:08
*** nati_ueno has joined #openstack-meeting20:08
ttxtook us a while to come up with somethign that we would both agree with20:08
mtaylordanwent: well, at the moment as far back as essex, because diablo is problematic20:08
mtaylorbut, I'd argue indefinitely, tbh20:08
bcwaldonmtaylor: 'essex' is not an api version20:08
*** bencherian has joined #openstack-meeting20:09
mtayloryou can still use libmysqlclient to talk to v1.0 mysql if you can find a v1.0 mysql20:09
*** markmc has joined #openstack-meeting20:09
mtaylorbcwaldon: sorry. v2 and on, since v1 didn't have a fully impl, right?20:09
bcwaldonmtaylor: are you talking about compute api?20:09
danwentmtaylor: but there's definitely a maintenance burden to supporting all API versions.20:09
jaypipesmtaylor: compute 1.1 api was renamed to 220:09
mtaylordanwent: that there is - so I'm purely talking about theory - I think we probably do want to think about an EOL policy for practicality sake20:10
bcwaldonhold on meow, mtaylor, do you have anything else to say w.r.t. explanation, or can we move forward with feedback?20:10
danwentI'd like to remove support for Quantum v1.x APIs fairly agressively… maybe even in Folsom.20:10
mtaylorbut, the thing is - thinking about it from an end user's perspective, if they hear "my cloud provider is running openstack" -20:10
danwentbcwaldon: good point, i'll hold off :)20:10
mtaylorthen it really should be enough for them to just grab the openstack library and be assured that they can talk to that cloud20:11
ttxthe discussion on deprecation doesn't really affect the proposed plan anyway20:11
mtaylorwithout having to know whether or not the provider is running essex or garbanzo20:11
mtaylorit actually doesn't20:11
mtaylorwell, it does a LITTLE20:11
mtaylorso- amongst the points are:20:11
ttxthe question at hand is about the creation of new categories of projects to cover for a separate release scheme for client library projects20:12
ttxand additionally recognize gating projects as a category of openstack projects as well20:12
mtaylorindeed. sorry, I got caught up in technical details :)20:12
danwentttx: ok, let's talk about that first, then we can circle back to backward compat questions.20:12
ttxseparate from our strict definition of "core"20:12
heckjmtaylor, ttx: what are the problems this is triyng to solve? ttx referred to problems that have come up…20:12
mtaylora couple - one of them is the branching problem20:12
ttxheckj: on my side, I'd say pressure to release cleint libraries at other moments that openstack core releases20:13
ttxthan*20:13
mtaylorin that a stable/essex branch of python-*client doesn't make any sense from a release perspective for an end user20:13
mtaylorthe other being what ttx just said20:13
markmcmtaylor, why not a stable/essex branch? it's what essex distros would ship20:14
mtaylormarkmc: say you're a customer of rackspace or hp20:14
ttxadditionally, sharing bugtracker is actaully a bit of pain that we'd remove :)20:14
mtayloror ibm or at&t20:14
pvojbryce: here now.20:14
mtaylorand you'd like to talk to instances in your cloud account20:14
mtaylorwhat version of the library should you install?20:14
mtayloradditionally, what if you have an account on rackspace AND hp AND at&t20:15
heckjmtaylor: I'm not getting the "a stable/essex branch of python-*client doesn't make any sense from a release perspective for an end user"… why doesn't it make sense?20:15
ttxfor the late arrivals, we're discussing http://wiki.openstack.org/Governance/Proposed/LibraryProjectDefinition20:15
mtaylorand you would like to have a script which operates on all of those clouds20:15
mtaylor(such as the devstack gating scripts)20:15
mtaylordo you suggest that I should install two different versoins of python-*client to talk to the different clouds?20:15
markmcmtaylor, you might need to e.g. wait until Fedora 18 before being able to talk to a folsom based cloud provider20:15
jaypipesheckj: have you ever downloaded the "stable/whatever" version of libmysqlclient? :)20:16
mtaylormarkmc: I'm installing from pypi20:16
markmcmtaylor, I'm giving the distro perspective20:16
jaypipesheckj: or have you downloaded the libmysqlclient0.15?20:16
jbryceheckj: i think because the clients are talking to APIs not a specific version of the implementation20:16
mtaylormarkmc: I know20:16
mtaylormarkmc: I'm giving the "end user wants to talk to service" perspective20:16
mtaylorwhich I battle with every day as a very large customer of both hp and rackspace clouds :)20:16
markmcmtaylor, right, but both might be an option - stable/essex branch and more regular releases from master20:16
heckjjaypipes, mtaylor: then it's the same issue that Thierry is asserting - we'd like to have client library release versioned independently of the core projects, and not assert dependence on client library to core version20:17
mtaylorheckj: yes20:17
*** edconzel has quit IRC20:17
jaypipesheckj: exactly.20:17
jbrycemarkmc: but it's not essex from a client perspective, it's api v X20:17
jbrycewhich may or may not be different in essex from diablo or folsom20:18
jaypipesheckj: and the clients would be named not stable/essex, but python-glanceclient-2.x.x20:18
jaypipesheckj: with the number representing the last version of the API they speak to.20:18
ttxfwiw I was defending the same view as markmc until recently, but the idea of versioning client libraries by API support... and have pure <= backward compat makes the need for stable/* go away... and not having them simplifies versioning wrt PyPI publishing a lot20:18
jbrycethat's pretty appealing to me from a user perspective20:18
*** torgomatic has joined #openstack-meeting20:19
johnpurjbryce: agree20:19
bcwaldonI do want to bring up that it doesn't work 100% to version clients to match api versions directly20:19
mtaylorit means we'll need stronger back-compat testing than we have, but that's on our todo list20:19
mtaylorbcwaldon: why not?20:19
jaypipesbcwaldon: just the major API version..20:19
heckjI just updated http://wiki.openstack.org/Governance/Proposed/LibraryProjectDefinition to add the list of problems that we're solving with this proposal20:19
mtayloryeah- just major version20:19
bcwaldonjaypipesThe versioning needs to belong to the library -- what if we need to rewrite a client lib without changing supported versions?20:19
heckjbcwaldon: +++20:20
jaypipesbcwaldon: then the minor/revision numbers would change.20:20
mtaylorbcwaldon: so, I'd say that the Major of the client lib matches the major of the api20:20
bcwaldonand what does it mean to release glanceclient v2, then add a bugfix for v1 support20:20
bcwaldonjaypipes: that versioning is insane20:20
bcwaldonmtaylor: no20:20
markmcI guess I mean "stable releases of the v2 glance client"20:20
mtaylorbcwaldon: I would argue that the major of the client lib is the contract assertion "I support X and earlier"20:20
markmci.e. safe fixes to the v2 API support20:20
bcwaldonbut that version represents the librarary, not itscapabilities!20:20
jaypipesbcwaldon: you'd still increment the minor (or revision) number... it's a fix in the v1 area for the client that supports v220:21
bcwaldonwhat other projects do that?20:21
markmcadding v3 support does not qualify as a safe update to the v2 client20:21
mtaylorbcwaldon: every C library that versions itself sensibly20:21
jaypipesbcwaldon: every C library I know.20:21
heckjI'm 100% with bcwaldon here - the versioning of the library needs to be independent of it's capabilities. The whole point is to break this away from dependence on core project releases.20:21
mtaylorbcwaldon: standard libtool versioning20:21
bcwaldonI'm not a C developer, so I don't have that bias20:21
bcwaldonor experience, however you want to say it20:21
mtaylorno, the version of the library is only meaningful as an API contract assertation20:21
jbrycei think the version is actually very easy to understand and pretty consistent with most server/client libs that i've seen20:22
bcwaldonjbryce: example?20:22
ttxjbryce: ++20:22
jbrycewe've already talked about mysql20:22
bcwaldonI agree it's EXTREMELY obvious, but then we lose the versioning of the library itself20:22
jbrycepostgres20:22
jbrycebcwaldon: how?20:22
jbrycebcwaldon: did you read the proposal?20:22
bcwaldonjbryce: ...yes20:22
jbrycebcwaldon: there is versioning of the library itself20:22
jbrycebcwaldon: all the other numbers20:22
ttxfwiw mtaylor proposed pure numbers as versions (1...2..3...) but I really thought that linking them to supported APi versions would make it a lot more meaningful20:23
bcwaldonso let me post this case to you20:23
markmcmtaylor, libtool versioning is independent of project release versioning20:23
bcwaldonif I want to completely rewrite my library, I'll probably increment the major version to indicate that20:23
jaypipesmarkmc: not project release. API version.20:23
mtaylormarkmc: yes. that's what's great about it20:23
bcwaldonif I completely rewrite glanceclient, I can't tell anybody about it!20:23
jbrycebcwaldon: why? i don't have that bias...or experience20:23
devcamcaro/20:23
devcamcarmade it finally20:23
mtaylorbcwaldon: why would they care?20:24
jbrycemtaylor: ++20:24
bcwaldonmtaylor: as a developer, I care a LOT20:24
mtaylorbcwaldon: why would I, as a consumer of the library and its api, care if you rewrote it?20:24
mtaylorbcwaldon: you shouldn't20:24
jbryceversions are useful for the meaning we put in them20:24
mtayloreither it works when you call its api or it doesn't20:24
bcwaldonmtaylor: do you care if you hav epython 2.6 vs 2.7?20:24
mtaylorbcwaldon: I care if the api changed20:24
mtaylorbcwaldon: I do not care if guido rewrite string.strip()20:24
jaypipesright.20:24
mtayloras long as it behaves the same20:24
bcwaldonmtaylor: I think you should20:24
mtaylorbcwaldon: no20:24
mtayloractually20:25
mtaylorthat's why apis are awesome20:25
bcwaldonmtaylor: maybe not *you*, but you should be able to20:25
mtaylorI don't have to know20:25
ijwWhat if you changed the Python side of the calling interface but it still works with over-the-wire API v2?20:25
bcwaldongreat point20:25
mtaylorijw: I would argue that you can't do that20:25
bcwaldonmtaylor: and thats where you lose me20:25
markmcof course you care if an implementation is a compatible rewrite of the same API20:25
mtayloradd a new interface20:25
bcwaldonmtaylor: if you want to tie my hands, I guess you can20:25
bcwaldonmtaylor: but I will disown you20:25
markmcwe cared about ksl being a rewrite of the same API20:25
jbryceversioning schemes have whatever meaning we give to them20:25
mtaylorso, you might have 10000s of devs using your lib20:25
bcwaldonmarkmc: +1 million20:25
mtaylordo you want to make them rewrite all of their code just because you had a whim?20:26
mtaylorthat's crazy20:26
bcwaldonjbryce: and I want to assign the most sane versioning20:26
ttxbcwaldon: I see your point. API-based versioning doesn't let you "show" that you made a major rewrite of the lib if it supports the same APIs20:26
bcwaldonttx: yes20:26
ttxThe proposed plan supposes a bit of stability in the client libs20:26
bcwaldonttx: and major versions are supposed to indicate backwards incompatibile changes20:26
bcwaldonor at least allow it20:26
markmcminor versions indicate a large, potentially risky update20:27
heckjbcwaldon: I think the idea here (re-reading the proposal) is that the first number is intended to indicate the API compatibiity, the second, third, etc - are whatever the client wants to use for it's versioning20:27
markmcmicro versions indicate a safe update20:27
bcwaldonheckj: I know what the proposal is20:27
jbryceheckj: exactly20:27
ttxbcwaldon: would a era.api.revision numbering work better for you ?20:27
jbryceagain...the version means whatever we want it to mean20:27
ttxinstead of api.revision ?20:27
heckjbcwaldon: so for example 2.5 getting a core API rewrite could go to 2.6?20:28
heckj^^ that made no sense as a sentence20:28
uvirtbotheckj: Error: "^" is not a valid command.20:28
bcwaldonttx: I dont really want 'api version' in my versioning scheme20:28
mtaylorheckj: :)20:28
mtaylorok. can I propose something then?20:28
heckjdoing a rewrite of the client library but supporting the same API would do something like go from 2.5 to 2.620:28
ttxbcwaldon: I'd argue that's a bit developer-centric20:28
bcwaldonmtaylor: shoot20:28
ijwThe significance of the code version number isn't so much a significance of the number of lines of code changed.  It's more an indicator of what reported bugs apply to the version you're looking at.20:28
mtaylorcan we table the exact versioning scheme discussion for later20:28
mtaylorand get through the "we should release these in this general manner" bit for now20:29
ttxyes, it's actually not the core of the proposal either ;)20:29
jbrycettx: ++ personally i hope we have far more users than developers...otherwise we're all going to be in a tough place20:29
mtaylorand then we can circle back on what the major number should mean or not mean20:29
jbrycemtaylor: good idea20:29
mtaylorbecause I TOTALLY hear your point20:29
bcwaldonokie dokie20:29
mtaylorand I've got a slightly different one that I think we can sit down and work through so that we're both happy :)20:29
ttxthe cenrtal part of the proposal is:20:29
ttx* Agree on a category of "openstack" project that is separate from core (which is the servers that get released every 6 months)20:30
ttx* Agree that those could be released separately20:30
johnpurI think that any developer will need to read the "doc" README etc. prior to using a particular library to see if his app will be compatible with the target system. To some extent the actual versioning numbers have little meaning to me as a dev, except as a starting point perhaps20:31
ttxThen the secodn part is the abandon of stable/* branches and pure backwards compat20:31
ttxThen versioning20:31
ttxThen deprecation of API20:31
jbryceok20:31
johnpurttx: agree20:31
ttxI think the versioning discussion is actually not that important once you agree on the "second part"20:31
jbryceis the vote bot running?20:31
jaypipesjbryce: should be.20:32
ttxit's more what is obvious by the version number and what is documented20:32
Daviey /win 28620:32
ttxDoes anyone have objections on the central part of the proposal20:32
bcwaldonnegative20:32
ttxThe idea that there are openstack projects that are not core projects.20:32
jaypipesno objections.20:32
jbrycenot here20:32
*** joesavak has quit IRC20:32
ttxLibraries and Gating projects20:32
jaypipesnotmyname: thoughts?20:33
jbrycejaypipes: he's out today20:33
ttxthat we stronglmy depend on to build core projects anyway20:33
jaypipesah, k20:33
ttxjaypipes: I picked my day to present that ;)20:33
jaypipesheh20:33
heckjno objection20:33
ttxOK... second part then, the absence of need for stable/* branches  and the idea that you should always be running the latest version of the client anyway20:34
ttxsince that's what supports every non-completely-deprecated old version20:34
bcwaldonttx: how reasonable is that for distros?20:34
bcwaldonalways running the latest client, that is20:35
ttxbcwaldon: you have to take into account that there aren't so many fixes to client libs20:35
heckjfor a distribution, you need a cut somewhere, and I want to be able to patch those specific pieces. Are you asserting all distributions should choose their own markers for that?20:35
danwentttx:  i mentioned this in an email to you all a while back.  If in folsom I make big changes to the client, but someone discovers an important but small fix in what we release for essex, where do I commit that minor fix such that distros pick it up?20:35
bcwaldondanwent: you won't be releasing clients as 'folsom' or 'essex'20:35
danwentttx: assumption is that current state of client lib is in churn.20:35
ttxbcwaldon: otherwise it's quite unacceptable, and they would be doing their stable/essex branches anyway... but if you consider that there aren't that many updates anyway...20:35
bcwaldondanwent: you'll bump the bugfix number and release again20:35
annegentledo we have any limiters on complaints about documentation for non-core projects? :)20:35
heckjdanwent: ^ exactly. I think we need this. I don't care if we call it stable/*, but we should have a branch or at least tag when we make a release. Doing otherwise is irresponsible20:36
danwentbcwaldon: fair, substitute "previous release" for essex, and "next release" for folsom.20:36
danwentbcwaldon: so we as developers we essentially keep an internal notion of a stable branch?20:36
bcwaldondanwent: I would assume you could maintain the previous major release if you really wanted to and tag it20:36
bcwaldondanwent: with glanceclient, I would only tag master when I want to release20:37
ttxheckj: the trick is that there are going to be a flow of releases (uploads to Pypi)20:37
ttxheckj: no strong marker like "essex"20:37
danwentbcwaldon: that makes sense.  I guess my point is that we'll effectively be having a "stable" branch.  So I guess i'm missing why we said we're getting rid of stable branches.20:38
heckjttx: I'm fine with a tag on each release then, and not a branch - but there needs to be a marker in our code control that indicates where that match is. I don't relish using git commitish20:38
bcwaldondanwent: how would we have 'stable' branches?20:38
ttxheckj: client libs are actually released by tagging, that's mtaylor's plan20:38
bcwaldondanwent: there would be a single branch: master20:39
danwentbcwaldon: if i have one branch where I make major changes targeted for the next "big" release of the client, and I also have the ability to keep patching the last big release with minor fixes, to me that seems like having a master branch and a stable branch.20:39
*** kevin-lewis-9 has quit IRC20:39
ttxwe basically only maintain the master..; that doesn't prevent people from having branches... or caollaborating in backporting20:39
danwentb/c those "minor bug fixes" would accumulate20:39
bcwaldondanwent: I'm advocating for not keeping a 'previous relase' branch around20:39
ttxbut the CI only tests a simple square matrix of combinations on every commit... not a cubic one20:40
ttxhmm, I mean, a set instead of a matrix :)20:40
jaypipeswe're still talking about the client library projects ONLY here, right?20:41
danwentttx: ok, i don't want to throw this discussion off track.  my only point was that we may well be developing on train sequence of commits, while doing bugfix releases on another.20:41
bcwaldonI think we're wandering off into arbitrary-land here20:41
ttxjaypipes: yes20:41
*** mnewby has joined #openstack-meeting20:41
bcwaldonttx: get us back on track! :)20:41
ttxstruggling20:41
ttxmtaylor just shot himself20:41
*** dolphm_ has quit IRC20:41
bcwaldonwe're obviously all in support of the overarching goal here20:41
mtaylorhehe20:41
*** mnewby_ has joined #openstack-meeting20:41
ttxmtaylor: stil here ? Defend the absence of need for stable branches, that's your idea :)20:42
mtaylorttx: yup20:42
* markmc wonders whatever happened to the idea of proposals for the PPB being discussed on the mailing list first20:42
*** mnewby__ has joined #openstack-meeting20:43
mtaylorit comes back down to user experience thing ... in what way do you release the old bugfixed client lib so that it's useful to the end user20:43
danwentsorry, is that a question to me? :)20:44
danwentmtaylor: i agree that's the question I'm getting at.20:44
*** mnewby___ has joined #openstack-meeting20:44
ttxmarkmc: actually I don't think we'll close the proposal this week, it's more RFC at this stage20:45
*** mnewby has quit IRC20:45
*** mnewby___ is now known as mnewby20:45
ttxwhen we know how to write the final proposal, we'll push to list20:45
markmcttx, cool, just think the various strands could be teased out more thoughtfully on list20:45
ttxmarkmc: in particular, got to know if the "cental part" is acceptable to a majority of PPB members or not20:46
*** mnewby_ has quit IRC20:46
*** yaguang has joined #openstack-meeting20:46
ttxcentral*20:46
danwentttx: none of my concerns are around the central part.20:47
*** mnewby__ has quit IRC20:47
ttxSo if I summarize...20:47
jaypipesyes please :)20:47
ttxWe can elaborate a plan based on the central part, with the following remaining pain points:20:47
ttx- need for "official" stable branches20:48
ttx- API or major-rewrite-driven versioning scheme20:48
ttx- room for deprecating old APIs20:48
ttxany other pain point ?20:48
danwentttx: captures my comments20:49
johnpurjust a comment, as this is a "policy" decision... this needs to be globally applicable, not choose or not on a per project basis20:49
heckjttx: matches to me20:50
ttxjohnpur: that would apply to the new "Library" category of openstack projects.20:50
ttxbut yes, for all of them.20:50
johnpurright20:50
*** joearnold has joined #openstack-meeting20:50
ttxIn particular, it should probably include openstack-common once it is released as a separate lib20:51
ttxmtaylor: so that sums up the pain points you need to discuss on and off the ML this week20:52
*** dendrobates is now known as dendro-afk20:52
ttxmtaylor: ideally we'll have a final proposal based on that feedback for next week ?20:53
ttxCorollary: devstack becomes a gating project, so it is no longer "not an official OpenStack project" as the website claims20:54
jbryceall right...anything else for this week on this one?20:55
*** nati_uen_ has joined #openstack-meeting20:57
mtaylorttx: yes. by next week we will have that20:57
ttxjbryce: looks like we're done for this week20:57
jbrycethanks guys20:57
jbryce#endmeeting20:58
*** openstack changes topic to "OpenStack meeting channel. See http://wiki.openstack.org/Meetings for schedule and http://eavesdrop.openstack.org/meetings/openstack-meeting/ for meeting logs"20:58
openstackMeeting ended Tue Jun 12 20:58:00 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)20:58
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-12-20.01.html20:58
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-12-20.01.txt20:58
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-12-20.01.log.html20:58
*** jk0 has left #openstack-meeting20:58
*** sandywalsh has quit IRC20:58
*** rnirmal has quit IRC20:59
*** Ravikumar_hp has joined #openstack-meeting20:59
*** nati_ueno has quit IRC20:59
*** lzyeval has joined #openstack-meeting21:01
ttxo/21:02
danwento/21:02
ttxheckj, bcwaldon, vishy, devcamcar, danwent: still around ?21:02
devcamcaro/21:02
bcwaldonttx: yes21:02
bcwaldonttx: no vishy21:02
bcwaldonttx: and no, I am not his replacement21:02
*** reed has joined #openstack-meeting21:03
heckjo/21:03
chmouelttx: i'll be replacing for notmyname today21:03
jgriffitho/21:03
ttxchmouel: awesome21:03
ttxarh21:03
ttx(about vishy)21:03
ttx#startmeeting21:03
openstackMeeting started Tue Jun 12 21:03:43 2012 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.21:03
bcwaldonttx: fire him!21:03
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.21:03
ttxbcwaldon: can't, he is my boss.21:03
*** ttrifonov is now known as ttrifonov_zZzz21:03
ttxAgenda @ http://wiki.openstack.org/Meetings/ProjectMeeting21:04
ttx#info 3 weeks left until the milestone-proposed cut for Folsom-2 (July 3)21:04
ttx#topic Actions from previous meeting21:04
*** openstack changes topic to "Actions from previous meeting"21:04
ttx* ttx to point Swift distro packagers to required config changes in Swift 1.5.0: DONE21:04
ttxFor completeness: see https://lists.launchpad.net/openstack/msg12754.html21:04
ttx* bcwaldon to set assignees for glance-client-parity and streaming-server specs: DONE21:04
ttx* jog0 to update status for general-host-aggregates bp: DONE21:05
ttx* ttx to fix jgriffith access to bp updating: DONE21:05
ttx* lzyeval to update status of ec2-id-compatibilty bp: DONE21:05
ttx* vishy to contact assignees for config-drive-v2, delete-in-any-state and user-configurable-rbac and confirm F3 targeting21:05
ttxlooks DONE now21:05
ttx#topic Keystone statu21:05
*** openstack changes topic to "Keystone statu"21:05
ttxs21:05
ttx:)21:05
ttxheckj: o/21:05
* heckj waves21:05
ttxwelcome back :)21:06
ttx#link https://launchpad.net/keystone/+milestone/folsom-221:06
ttxGot a few questions for you21:06
heckjshoot21:06
ttx* https://blueprints.launchpad.net/keystone/+spec/stop-ids-in-uris (Guang Yee)21:06
ttxHow is that going ? termie said last week he didn't understand why that was needed, or "essential"...21:06
termiettx: the best description i have run into was that people are worried about token ids leaking in logs21:07
heckjThat blueprint will be dealt with in the V3 API, shouldn't be listed as essential. Certainly won't be done by this milestone at the rate we're going.21:07
heckjtermie: correct21:07
ttxheckj: downgrade to "High" ?21:07
heckjttx: done21:07
ttxcool21:07
termiewhile i feel like that is probably nice to think about, i also don't think our tokens are long-lived enough for that to matter much21:07
ttx* https://blueprints.launchpad.net/keystone/+spec/implement-v3-core-api (heckj)21:08
ttxhow is it going so far ?21:08
ttx...and how likely is it to be completed within the next 3 weeks ?21:08
heckj^ still working through draft updates, so no initial work has started here. Given the timing, I suspect it's not going to be done this milestone, and we'll need to delay it21:08
uvirtbotheckj: Error: "still" is not a valid command.21:08
heckjwill retarget the BP21:08
bcwaldonuvirtbot: thanks for the update21:08
uvirtbotbcwaldon: Error: "thanks" is not a valid command.21:08
heckjone of these days I'm going to have figure out what that thing does21:09
*** nati_uen_ has quit IRC21:09
bcwaldonheckj: it's a bender21:09
markwashinsert girder?21:09
*** nati_ueno has joined #openstack-meeting21:09
bcwaldon31 degrees, 32 degrees21:09
ttx* https://blueprints.launchpad.net/keystone/+spec/keystone-ipv6-support (ayoung)21:10
ttxNot started either ? Any chance /that one/ will be in F2 ?21:10
ayoungttx, my vote is no21:10
heckjttx: no progress as yet, expected as documentation on a deployment option in documentation. Quite possibly.21:10
heckjOr not, if ayoung says...21:10
ttxheh21:10
ayoungttx, IPv6 support is not there yet in upstream Eventlet.  I suggest that if someone wants it, they use HTTPD for the near term21:11
heckjwill retarget that too21:11
ttxnote that you're preparing yourself a large F3 plate, which is not really the best idea in the world :)21:11
heckjdidn't say I'd retarget that to F321:11
ttxayoung: if the implementation of that bp depends on ipv6 support in eventlet... sounds a bit far away to me21:11
*** jbryce has quit IRC21:11
ttxheckj: ack21:11
heckjremoved from any milestones or series for now21:12
ttx* https://blueprints.launchpad.net/keystone/+spec/rbac-keystone (dolphm)21:12
ttxSlow progress, does that mean it might miss F2 too ?21:12
ttx..or that there are still 3 weeks left after all ?21:13
heckjThat will likely split per this mornings keystone meeting21:13
ttxcool. Split is good, couldn't actually figure what work was involved in this one21:13
ttxheckj: anything else ?21:13
heckjThe implementation of an API supporting RBAC will be tied to V3 API, but we'll also be documenting and setting some defaults, suggested values for policy.json and implementing a policy engine in keystone itself21:13
ttxso APIv3 is the big blocker IIUC21:14
heckjQuite a bit of the desired feature work is dependent on it21:14
ttxheckj: any other comment ?21:14
heckjnope21:15
ttxAnyone else, questions about Keystone ?21:15
ayoungttx, BTW,  that blueprint should really be for IPv6 support across all Openstack projects that are based on Eventlet21:15
ttxayoung: should probably be filed as separate blueprints... since there is no need to roll it all out at the exact same moment21:16
ttx#topic Swift status21:16
*** openstack changes topic to "Swift status"21:16
* chmouel waves21:16
ttxchmouel: yo21:16
ttxI just had a question about the python-swiftclient split, how far is it from completion ?21:16
chmouelit's done since bcwaldon merged the review on glance21:17
*** devananda has left #openstack-meeting21:17
*** ttrifonov_zZzz is now known as ttrifonov21:17
chmouelthere seem to be some problem with the functional tests21:17
chmouelwhich I am going to work on21:17
ttxchmouel: was the client lib removed from swift proper ?21:17
chmouelyes21:17
ttxdevcamcar: does that affect horizon ?21:18
chmouelI have logged a bug on horizon to have a look at it so they can switch from cloudfiles21:18
ttxor did you anticipate it ?21:18
ttxok.21:18
chmouelthey are not using swift.common.client21:18
chmouelbut python-cloudfiles21:18
devcamcarttx: no, we've been using python-cloudfiles21:18
ttxoh, so that's actually good news for you :)21:18
devcamcarwe do plan to move to python-swiftclient when this all settles21:18
chmouelwell python-cloudfiles is somewhat slower than swiftclient  :)21:18
ttxchmouel: could you post to the ML when the final bits land ? This will affect distros21:19
chmouelttx: yes I was planning to do that just after this meeting21:19
ttxthey should anticipate the work, before 1.5.1 is released21:19
ttxawesome21:19
chmouelso another thing21:19
chmouelThere has been some discussion to have devstack gating on swift commits21:20
ttx#action chmouel to post about python-swiftclient separation to the ML21:20
chmoueland we still need to look over how's that going to work21:20
chmouelso I am going to get in touch with the CI to understand how's that going to work with the swift specifics21:20
Ravikumar_hpquestion: any documentation on python-swiftclient21:21
chmouelRavikumar_hp: there is none21:21
Ravikumar_hplist of APIs and how to call21:21
chmouelis there any documentation for other *clients library btw: ?21:21
bcwaldonchmouel: isn't it the same as the old swift.client docs?21:21
bcwaldonchmouel: yes, current glance client21:21
ttx#action chmouel to discuss with CI on enabling swift in devstack-gate21:22
chmouelRavikumar_hp: oh yeah actually they should get auto generated soon we have just merged a commit but I am not sure where this is going to be exposed21:22
ttxchmouel: Anything else ?21:22
chmouelnoip21:22
ttxOther questions on Swift ?21:23
*** lloydde has quit IRC21:23
ttx#topic Glance status21:23
*** openstack changes topic to "Glance status"21:23
ttxbcwaldon: o/21:23
ttx#link https://launchpad.net/glance/+milestone/folsom-221:23
ttxLooking at the road to api-v2, looks like continuous progress...21:24
bcwaldonindeed21:24
bcwaldonwe've come up with some more bps in the past week or two21:24
ttxapi-v2-links depends on api-v2-refactor-schemas, which in unassigned / unknown status ?21:24
bcwaldonbut we are making steady progress21:24
bcwaldonttx: you should really stop caching that info before the meetings21:24
bcwaldonttx: I've gotten efficient at updating it just as the meeting starts :)21:24
ttxsigh21:24
bcwaldonle sigh indeed21:25
ttxActually it's http://wiki.openstack.org/releasestatus/ that is not refreshed at the right time :)21:25
bcwaldonaha21:25
*** yaguang has quit IRC21:25
bcwaldonI don't have anything to report21:25
*** yaguang has joined #openstack-meeting21:26
ttxbcwaldon: you still have an essential depending on a medium :P21:26
bcwaldonwhy yes I do21:26
bcwaldonI've created a paradox!21:26
ttxwell, that makes it essential as well :)21:26
bcwaldonfixing it right now21:26
ttxor the other just pretends to be essential.21:26
ttxDid you hear from dprince about swift-tenant-specific-storage ?21:27
bcwaldonnegative21:27
bcwaldonor I forgot21:27
ttxHow essential is this ?21:27
bcwaldonnot as essential as I thought21:27
bcwaldoncould be Med or High21:27
ttxmake it high :)21:27
bcwaldonk21:28
ttxAlso had a question about essential stuff being targeted to folsom-3...21:28
chmouelI can help if dprince want21:28
ttxI understand why you absolutely need separate-client and glance-client-parity...21:28
bcwaldonchmouel: I'll keep that in mind, thanks :)21:28
ttxBut shouldn't https://blueprints.launchpad.net/glance/+spec/streaming-server be "High" priority instead ?21:28
ttxSounds like something you'd really like to have, rather than something we can't release without.21:28
bcwaldonttx: true21:28
bcwaldondone21:28
ttxthx21:28
ttxbcwaldon: Anything else you wanted to mention ?21:28
bcwaldonno sir21:29
ttxCool. Questions on Glance ?21:29
Ravikumar_hpPython-glanceclient   - Folsom-3?21:29
bcwaldonRavikumar_hp: yes21:29
ttx#topic Quantum status21:30
*** openstack changes topic to "Quantum status"21:30
ttxdanwent: hey21:30
ttx#link https://launchpad.net/quantum/+milestone/folsom-221:31
danwentttx: hello21:31
danwentyou'll noticed i flagged a couple things with slow progress to highlight them :)21:31
*** ttrifonov is now known as ttrifonov_zZzz21:31
danwentthe good news is that we got the bulk of the API stuff merged21:31
ttxooh.21:31
ttxGood thing I refreshed21:31
ttxSo now that's done, should we consider that Melange as a separate project is dead ?21:32
danwentfrom a folsom release perspective, yes.  there may still be people that use the essex version21:32
ttxsure.21:32
danwentok, so the two big issues are DHCP and the Quantum/Nova integration21:33
danwentDHCP: the folks working on this say they are still confident with the F-2 date21:33
*** sparkycollier has quit IRC21:33
danwentbut I haven't seen much yet.  Will be trying to kick this work into high gear this week.  Otherwise, we potentially need to revisit what we think we'll be able to do with the F-2 deliverable (my goals was that basic uses cases would be functionally complete by F-2)21:34
ttxthat's how I understand the "Slow progress" you have there21:34
*** salv-orlando has joined #openstack-meeting21:34
ttxIn other news, can authorization-support-for-quantum be considered 'Implemented' ?21:34
ttxI saw the change landed21:34
*** ttrifonov_zZzz is now known as ttrifonov21:34
danwentttx: one patch landed, but there's one more coming21:34
ttxoh, ok21:34
danwentkevin's making good progress on that though, so i'm not worried about it.21:35
danwenti am worried about the nova/quantum integration, as it looks like tr3buchet may no longer be able to work on that in F-221:35
ttxCould you look into and set the priority and series goal for https://blueprints.launchpad.net/quantum/+spec/cisco-plugin-v2-api-support (proposed for F3) ?21:35
danwentttx: ah, i think that's a new one.  hadn't seen it yet.21:35
danwentwill do.21:35
danwentdone21:36
ttxdanwent: could you explain what that nova/quantum integration blueprint will cover exactly ?21:36
ttxNova QuantumManager for quantum v2 ?21:36
danwentttx: nova will use the v2 quantum apis when VMs are created and destroyed21:36
danwentmeaning that quantum will take care of IPAM as well.21:36
danwentand that you can now create networks directly using the quantum API, rather than using nova-manage21:37
ttxok, yes, would have been good to have that in F221:37
danwentttx: indeed, its quite central.21:37
ttxso that it sees some mileage21:37
danwentso if I can't get someone to work on it, i'll probably drop my other F-2 stuff and do it myself :(21:37
ttx#help volunteer needed to help with improved-nova-quantum-integration21:38
danwentother than that, things are going wel though.  lot of good code being written an reviewed.  a few new core devs.21:38
ttxdanwent: I think it might be worth it21:38
danwentttx: agreed.21:38
ttx(drop the other things to get that into F2)21:38
ttxdanwent: Anything else ?21:38
danwentdon't think so.21:38
ttxQuestions on Quantum ?21:39
ttx#topic Nova status21:39
*** openstack changes topic to "Nova status"21:39
ttxSo we don't have vishy, i'll just ask a few questions just in case the assignees can answer21:39
ttx#link https://launchpad.net/nova/+milestone/folsom-221:39
ttxPlan & progress looks good to me21:40
ttxQuick review of the status on the essential stuff:21:40
ttx* https://blueprints.launchpad.net/nova/+spec/general-host-aggregates (jog0)21:40
ttx* https://blueprints.launchpad.net/nova/+spec/finish-uuid-conversion (mikal)21:40
ttxjog0, mikal: if you're around, a quick update on status for those BPs ^21:41
ttxjgriffith: around ?21:41
jgriffithYep21:41
jog0ttx: making good progress.  Working with Citrix guys to keep xen hv_pools working.21:41
jgriffithttx: Things are looking good on cinder21:41
ttxjgriffith: do you know how volume-decoupling goes ?21:41
ttxjog0: thx, still on track for F2, then ?21:42
*** littleidea has quit IRC21:42
jgriffithttx: Yeah, alot of what I'm doing this morning is part of that:21:42
jgriffithBetween sleepsonthefloor and myself we've about got it done21:42
ttxcool21:42
jgriffithI'm just finishing some ec2 compat issues21:42
ttxjgriffith: What's left to do before Cinder becomes a first-class citizen ?21:42
jgriffithttx: It already is in my book :)21:43
jog0ttx:  yes.  Not sure if every part will be in by F2 (such as reming duplicate metadata concepts).  but most will be ready21:43
jgriffithttx: Fix the ec2 stuff21:43
jgriffithttx: add some tests to devstack21:43
ttxjgriffith: Is there anything that will get broken in F2 by the completion of this ?21:43
jgriffithWe're just about fully functional...21:43
ttxLike horizon, which has switch-to-cinder-client targeted to F3 now ?21:43
jgriffithThat's up to everybody else (ie vish)21:43
*** nati_ueno has quit IRC21:44
jgriffithWe have it now so everything is turned on/off by flags21:44
jgriffithSo you can go nova-volume or cinder21:44
jgriffiththis includes devstack as well as "nova"21:44
ttxjgriffith: we'll probably make the decision post-F2 to do the full switch or not21:44
jgriffithI have a couple of challenges to get this to work correctly in nova api's but I should get there21:44
ttxtogether with the core confirmation21:44
*** littleidea has joined #openstack-meeting21:44
jgriffithttx: The only other concern is TESTS21:44
ttxjgriffith: TESTS are good21:45
jgriffithttx: the majority of the existing tests aren't so good though21:45
jgriffithttx: Most are all using fakes for everything!!21:45
ttxheh21:45
ttxnothing like a test that can't fail.21:45
jgriffith:)21:45
ttxjgriffith: anything else ?21:45
jgriffithttx: Not unless anybody is interested, or better yet wants to help out :)21:46
jgriffithIt's been me and sleepsonthefloor and that's about it21:46
annegentlejgriffith: what updates to the Compute docs do you expect you'll need?21:46
ttx#help Cinder needs more useful test coverage21:46
ttxQuestions on Nova/Cinder ?21:46
jgriffithttx: bahhh21:46
jgriffithdocs21:46
annegentle#help Cinder needs documentation21:46
jgriffithI'll have to tackle that in force after this week21:47
jgriffithannegentle: I'll make a note to link up with you21:47
ttxok, great21:47
ttx#topic Horizon status21:47
annegentlejgriffith: maybe you and sleepsonthefloor can tell me more about it21:47
*** openstack changes topic to "Horizon status"21:47
devcamcaro/21:47
annegentlejgriffith: sounds good21:47
ttxdevcamcar: hey21:47
devcamcarttx: howdy21:47
ttxdevcamcar: we'll talk about a stable/essex point release after the quick folsom-2 status21:47
jgriffithperhaps I'll send a note out to the ML just to update folks???21:47
devcamcarok21:47
ttx#link https://launchpad.net/horizon/+milestone/folsom-221:47
ttxjgriffith: good idea21:48
jgriffithttx: KO21:48
devcamcarF2 blueprints are generally progressing well21:48
ttx#action jgriffith to update the ML with Cinder progress21:48
devcamcarhttps://blueprints.launchpad.net/horizon/+spec/nova-volume-optional may get bumped to F321:48
devcamcarwhen we make the rest of the cinder client changes21:48
devcamcarin fact, i'm going to do that now, been meaning to move it21:48
ttxdevcamcar: Two blueprints were added to F2 without having their series goal confirmed, would be good to look into those and set Priority and Series goal accordingly:21:48
ttx* https://blueprints.launchpad.net/horizon/+spec/use-common-jsonutils21:48
ttx* https://blueprints.launchpad.net/horizon/+spec/automatic-secure-key-generation21:48
devcamcarttx: will fix the series goal now21:49
ttxLast question, about the "Essential" blueprints in Folsom-3 (I don't really like to have essential stuff left on the last milestone):21:49
ttx* https://blueprints.launchpad.net/horizon/+spec/switch-to-cinder-client21:49
ttxI understand why this one is essential, and work is started, so we should be alright there...21:49
ttx* https://blueprints.launchpad.net/horizon/+spec/quantum-workflow-integration21:49
ttxThis one has no assignee, should it just be assigned to "Nebula" team ?21:50
*** nati_ueno has joined #openstack-meeting21:50
ttxThis sounds like a risky thing to consider "Essential"... Could you explain why we can't release Folsom without that feature ?21:50
devcamcarttx: we can probably downgrade that to "high"21:51
ttxsounds like a plan.21:51
devcamcarit will be a poor user experience without it though21:51
ttxwell, "High" should still definitely get done :)21:51
devcamcarttx: true enough ;)21:52
ttxSo, second subject, Horizon 2012.1.121:52
ttxThe process is usually as simple as designating a commit ID as your candidate21:52
ttxBut the tarballs are currently not generated for stable/essex and we need to clean that up first21:52
devcamcarttx: yes, we've gotten a number of back ports into stable/essex that are helpful, so as soon as one more lands, we can tag it21:52
devcamcarttx: ok21:52
ttxI'll discuss with markmc and see how we'll proceed here exactly21:53
ttx(markmc is the release team member that handles stable release updates)21:53
devcamcarfor the record, a few stable/essex reviews here would help: https://review.openstack.org/#/c/7730/21:53
ttxfwiw, here is how he handled the 2011.3.1 releases: http://wiki.openstack.org/StableBranchRelease21:53
devcamcar#help need reviews on https://review.openstack.org/#/c/7730/21:54
ttxdevcamcar: so, i'l discuss with him, fix CI and come back to you21:54
devcamcarttx: sounds good21:54
ttx#action ttx to clarify Horizon 2012.1.1 release process and fix CI to match21:54
ttxdevcamcar: Anything else ?21:54
devcamcarttx: nope21:54
ttxQuestions for Horizon ?21:54
ttx#topic Other Team reports21:55
*** openstack changes topic to "Other Team reports"21:55
ttxannegentle, jaypipes, mtaylor: ?21:55
annegentledoc team met yesterday - here are notes:21:56
annegentle#link http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-11-20.03.html21:57
*** mdomsch has quit IRC21:57
annegentleI didn't hire an intern for the summer, sorry folks. 4 final candidates took other positions.21:57
annegentleNeed to start in March not April next year.21:57
*** dwcramer has quit IRC21:57
ttxintern drought in Texas21:57
ttxAny other team lead with a status report ?21:57
annegentleI'm testing chinese language output through the maven plugin21:57
annegentleWill report back on progress.21:58
annegentleLooking for writers for http://etherpad.openstack.org/EssexOperationsGuide21:58
annegentleAnd reviewers for the high availability document draft https://review.openstack.org/#/c/8139/21:58
ttx#help <annegentle> Looking for writers for http://etherpad.openstack.org/EssexOperationsGuide21:59
annegentleAlso, the CI team is working on a doc-related consistency project21:59
ttx#help <annegentle> And reviewers for the high availability document draft https://review.openstack.org/#/c/8139/21:59
annegentlemaybe mtaylor or jeblair or clarkb can explain better21:59
ttx#topic Open discussion21:59
*** openstack changes topic to "Open discussion"21:59
ttxAnything else, anyone ?21:59
ttxQuick glance at the effect of the BugTriage day on Nova: http://webnumbr.com/untouched-nova-bugs22:00
ttxNow we need to discuss how to make that more permanent :)22:01
ttx#endmeeting22:01
*** openstack changes topic to "OpenStack meeting channel. See http://wiki.openstack.org/Meetings for schedule and http://eavesdrop.openstack.org/meetings/openstack-meeting/ for meeting logs"22:01
openstackMeeting ended Tue Jun 12 22:01:09 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)22:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-12-21.03.html22:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-12-21.03.txt22:01
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-12-21.03.log.html22:01
ttxThanks everyone !22:01
*** lzyeval has quit IRC22:01
*** heckj has quit IRC22:01
*** yaguang has left #openstack-meeting22:01
*** ayoung has quit IRC22:02
*** ttrifonov is now known as ttrifonov_zZzz22:02
*** rnirmal has joined #openstack-meeting22:07
*** littleidea has quit IRC22:09
*** Gordonz has quit IRC22:10
*** littleidea has joined #openstack-meeting22:10
*** nati_ueno has quit IRC22:13
*** jaypipes has quit IRC22:13
*** dhellmann has joined #openstack-meeting22:19
*** dendro-afk is now known as dendrobates22:21
*** ryanpetrello has joined #openstack-meeting22:21
*** markmc has quit IRC22:29
*** ryanpetrello has quit IRC22:29
*** ryanpetrello has joined #openstack-meeting22:30
*** dtroyer is now known as dtroyer_zzz22:34
*** nati_ueno has joined #openstack-meeting22:34
*** mattray has quit IRC22:40
*** nati_ueno has quit IRC22:47
*** nati_ueno has joined #openstack-meeting22:47
*** gyee has quit IRC22:49
*** dwcramer has joined #openstack-meeting22:51
*** dendrobates is now known as dendro-afk22:57
*** rafaduran has quit IRC23:03
*** ryanpetrello has quit IRC23:10
*** nati_ueno has quit IRC23:16
*** torgomatic has left #openstack-meeting23:26
*** sleepsonthefloor is now known as sleepsonzzz23:26
*** joearnold has quit IRC23:26
*** mnewby has quit IRC23:31
*** edygarcia has quit IRC23:35
*** rnirmal has quit IRC23:38
*** dtroyer_zzz is now known as dtroyer23:40
*** dtroyer is now known as dtroyer_zzz23:45
*** salv-orlando has quit IRC23:45
*** ryanpetrello has joined #openstack-meeting23:51
*** Ravikumar_hp has quit IRC23:54
*** jgriffith has quit IRC23:58

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!