19:00:53 <mtaylor> #startmeeting
19:00:54 <openstack> Meeting started Tue Jul 31 19:00:53 2012 UTC.  The chair is mtaylor. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:06 <mtaylor> anybody interested in CI?
19:01:15 <mtaylor> #topic horizon
19:01:20 <Shrews> Cuddling Iquanas?
19:01:33 <mtaylor> what is an Iquana?
19:01:42 <Shrews> same as an Iguana, but more exotic
19:01:46 <mtaylor> neat
19:02:15 * mtaylor forward-proposes the openstack I relase to be named Iquana, invoking the bcwaldon rule
19:02:32 <mtaylor> ok. so - gabrielhurley did you get a chance to read the email I sent this morning?
19:02:41 <gabrielhurley> mtaylor: I did
19:02:53 <gabrielhurley> andI was thinking similarly about using selenium tests to ensure some of that stuff
19:02:54 <mtaylor> gabrielhurley: excellent. that means less typing now
19:03:00 <mtaylor> perfect!
19:03:43 <gabrielhurley> it is a bit of a catch-22 though, where we need to test against the future changes but also against the current pip-requires lists...
19:04:14 <mtaylor> it is. I think the key is to make sure that changes don't go in that _can't_ work with released libs
19:04:32 <mtaylor> if the client libs start ganking with existing apis too much it'll screw all the other projects too anyway
19:05:00 <gabrielhurley> yeah, it just happened to be that we (Horizon) hit it first
19:05:06 <gabrielhurley> it's definitely not a horizon-only problem
19:05:06 <mtaylor> and then, if someone is adding a new api call/feature to a client lib that you desperately need in horizon ...
19:05:09 <mtaylor> they need to cut a release
19:05:13 <gabrielhurley> yep
19:05:23 <gabrielhurley> Brian Waldon is pushing a new glanceclient release today
19:05:39 <mtaylor> do you think there would be any value in running selenium tests against the devstack install too?
19:05:39 <jeblair> gabrielhurley: he already did it, and it's on pypi!  0.2.0
19:05:49 <gabrielhurley> jeblair: nice
19:05:59 <gabrielhurley> mtaylor: definitely value in that
19:06:26 <mtaylor> gabrielhurley: k. I'll put that on the list of things for clarkb to think about
19:06:59 <jeblair> mtaylor: one further question for clarkb to think about -- can it be incorporated into tempest, or does that make no sense.
19:07:08 <mtaylor> +
19:07:10 <mtaylor> ++
19:07:12 <mtaylor> that is
19:07:31 <mtaylor> clarkb: this is what happens when you go to lunch instead of this meeting - you get assigned things
19:07:48 <mtaylor> gabrielhurley: cool. so I think we're set for now, until we think of something else
19:08:32 <gabrielhurley> sounds good. we'll give it a try and revise as needed
19:08:45 <mtaylor> awesome
19:09:01 <mtaylor> #topic PTL's + client lib releases
19:09:38 <mtaylor> jeblair: so - bcwaldon made a releaes because I explicitly added him to the acls for that project a few weeks ago, which is obviously the wrong way to do things
19:10:12 <mtaylor> I believe the ML decision was to add $project-drivers to python-${projet}client  with tagging acls, yeah?
19:10:52 <mtaylor> so I think we can get that done - BUT - it brings up a thought...
19:11:05 <jeblair> mtaylor: that makes sense to me
19:11:05 <mtaylor> should we manage the project ACL files int eh config branches with puppet?
19:11:35 <jeblair> mtaylor: neat idea.
19:11:49 <mtaylor> jeblair: I was thinking about it when I was making the "create a project" additions
19:11:56 <mtaylor> since the acls part is the most annoying part
19:12:18 * mtaylor assigns clarkb to think about that when he gets back
19:12:30 <mtaylor> #action clarkb manage project acls with puppet
19:12:55 <mtaylor> #actoin clarkb think about running selenium against devstack
19:12:57 <mtaylor> damn
19:13:03 <mtaylor> #action clarkb think about running selenium against devstack
19:13:28 <mtaylor> #action clarkb think about running selenium in tempest
19:13:30 <mtaylor> ok
19:13:33 <mtaylor> recorded those
19:13:45 <mtaylor> #topic renaming client libs
19:14:09 <mtaylor> notmyname: you aroud?
19:14:11 <mtaylor> around
19:14:12 <mtaylor> dammit
19:14:37 <mtaylor> zul: how about you?
19:14:58 <zul> around? not really
19:15:08 <zul> ill lurk continue without me
19:15:15 <jeblair> so the gist was that automated packaging scripts have problems with "python-fooclient" because they want to call the result "python-python-fooclient"
19:15:31 <notmyname> mtaylor: here
19:15:33 <jeblair> which isn't a problem for, say, ubuntu, who just pick the right name, but for individuals making their own .debs
19:16:02 <mtaylor> also, we do already have a pile of extra logic in stuff to deal with the fact that some of our projects are named differently than their main module
19:16:24 <jeblair> and i guess we should distinguish between the git repo name, and the setup.py name -- it's the setup.py name that the deb build scripts pick up, so that's what's being wanted to change.
19:17:10 <mtaylor> yes. it is not necessary that we change the git repo name - although I kinda think that if we change the one we should consider changing the other too
19:17:27 <notmyname> IMO, the git repo name makes sense
19:17:29 <mtaylor> however, this would affect the tarball name that we produce, which might affect ubuntu a little
19:18:04 <mtaylor> and we should consider whether or not it should affect the launchpad project name
19:18:10 <jeblair> right, so that brings up the question "why are they named python-fooclient?" is it because we might have an openstack/java-fooclient project someday?  if so, yeah, we might want to leave it as-is.
19:18:23 <mtaylor> yes. I believe that was the reason
19:18:42 <jeblair> so, if we consider just changing the setup.py name, what breaks?
19:18:48 <mtaylor> also, we'll need to make new pypi entries
19:18:51 <jeblair> (but leaving the git repo name alone)
19:18:58 <mtaylor> if all we change is the setup.py name
19:19:01 <gabrielhurley> if you change the setup.py name the names on PyPI will get screwed
19:19:11 <mtaylor> yeah - it'll be a whole new pypi thing
19:19:27 <gabrielhurley> you'll need to update all the pip-requires in all the projects with the new names as well
19:19:32 <mtaylor> ++
19:19:44 <mtaylor> although that could be done in a rolling fashion
19:19:50 <gabrielhurley> I don't object to that, btw. just sayin' it's the case
19:19:54 <mtaylor> yup
19:19:59 <jeblair> mtaylor: do tarball names come from that?
19:20:05 <mtaylor> yes
19:20:14 <jeblair> so that would affect distros
19:20:52 <mtaylor> yup - although we've pre f3, so I think it's maybe still ok?
19:20:54 <mtaylor> ttx: ?
19:21:12 <mtaylor> notmyname: any sense of whether the other python-*client people have interest in following suit?
19:21:36 <jeblair> mtaylor: i'm sure we'd have a whole bunch of puppet config files that would need changing, but that's probably not a huge deal.
19:21:40 <notmyname> no idea. I got the request from people building python-swiftclient packages
19:22:25 <soren> I'm apparently missing some context.
19:22:29 <mtaylor> k.
19:22:34 <soren> What are we renaming from and to?
19:23:05 <mtaylor> soren: the suggestion is to make setup(name='python-swiftclient' be setup(name='swiftclient'
19:23:22 <mtaylor> soren: and, of course, if we think about that, we'd like to think about doing that across the board
19:23:47 <soren> And what's the motivation? Did I miss a mailinglist discussion?
19:23:48 <mtaylor> but leaving the git repo named the same
19:24:19 <mtaylor> motivation is - apparently there are packaging tools for python which pull the python name from setup.py and pre-pend python- to it
19:24:30 <notmyname> package building tools take the internal name (python-fooclient) and turn it into python-python-fooclient
19:24:32 <mtaylor> so those are making python-python-swiftclient packages
19:24:53 <notmyname> which implies that clients of the module are a python-python-swiftclient-client
19:25:16 <jeblair> i'm sure those can change, but it does also seem weird that these are in pypi as "python-swiftclient" because it's obviously python.
19:25:23 <jeblair> so it's certainly worth considering
19:25:50 <soren> There are hundreds of projects named python-* on pypi.
19:25:55 <soren> How do they manage?
19:26:11 <jeblair> there are tens of thousands that aren't.  :)
19:26:16 <mtaylor> https://github.com/emonty/openstack-depends/blob/master/tools/pip-requires#L42
19:26:25 <mtaylor> there are 58 things openstack depends on
19:26:33 <soren> jeblair: That's got to be the worst argument ever fo.
19:26:40 <soren> jeblair: For anything :)
19:26:44 <mtaylor> 3 of them that are not our projects are prefixed with python-
19:27:05 <mtaylor> so I'd say that the general trend seems to be non-python prefixing for pypi modules
19:27:30 <mtaylor> with the one really odd-one out being MySQL-python which installs MySQLdb - but Andy is weird anyway
19:27:56 <jeblair> soren: i won't get into a meta-argument with you, i will just note that it was a rebuttal to your rebuttal to my _actual_ point that the name is redundant.
19:28:35 <soren> jeblair: It's not redundant. It's the python blahclient (as opposed to the java blahclient or haskell blahclient etc).
19:28:40 <soren> jeblair: How's it redundant?
19:28:47 * mtaylor abstractly wants to be a meta-observer
19:28:58 <mtaylor> soren: it's redundant on pypi
19:29:14 <mtaylor> soren: it makes sense for the ubuntu package to be named python-${pypi-package-name}
19:29:20 <soren> I don't think that should dictate naming.
19:29:27 <mtaylor> I'm not saying that it should
19:29:41 <soren> Ok.
19:29:42 <soren> Hm.
19:29:46 <soren> So what are you saying?
19:30:08 <mtaylor> purely that, for the name whose main purpose is tarball naming and pypi project, python- isn't essential
19:30:27 <soren> I think it is. For tarball naming.
19:31:10 <mtaylor> because we're likely, as a project, to produce ${foo}-novaclient where foo!=python ?
19:31:13 <soren> Having the t at the end for client also isn't essential. In fact, it's redundant, because "clien" isn't a real world, and the context should reveal its true purpose.
19:31:15 <jeblair> that is a good point; the tarball exists in a similar context to the git repo, so its name having python- makes sense.
19:31:26 <soren> mtaylor: Absolutely.
19:31:34 <soren> mtaylor: I'm surprised we don't already.
19:31:37 <mtaylor> I'mnot
19:31:41 <jeblair> to be clear, soren's point about tarball naming was a good point.  not "clein".  :)
19:31:48 <mtaylor> we make python libs becuase we're a python based projects
19:31:55 <mtaylor> java and ruby libs are silly
19:32:02 <mtaylor> because ruby people should be using fog
19:32:09 <mtaylor> and java people should be using jclouds
19:32:13 <mtaylor> and even when they aren't
19:32:23 <mtaylor> the java project is named after openstack
19:32:28 <mtaylor> and not after each project
19:32:30 <notmyname> mtaylor: actually because the API isn't a language, it's HTTP. we simply provide wrappers for a particular language
19:32:53 <mtaylor> notmyname: indeed. and we do that _purely_ because our projects need to be able to talk to each other
19:33:43 <mtaylor> and then we use those libraries as the basis for command line clients ... but it isn't part of a larger decision to try to make openstack-project generated client libraries for all languages
19:34:09 <notmyname> this seems to be way off track. current proposal is to internally drop the language prefix and externally (the repo and maybe the tarball) to have the prefix? and what issue does that cause
19:34:12 <mtaylor> but - that's just my opinion, of course
19:34:24 <soren> mtaylor: Even if *we* don't create them, there's a great big world out there whose namespace we're sharing.
19:34:25 <mtaylor> the tarball name is generated from the name
19:34:42 <soren> If someone wants to build php-glanceclient, more power to them.
19:34:50 <mtaylor> soren: no. I disagree. the only place it would matter is our tarballs ftp server
19:34:56 <mtaylor> I cannot be responsible for a theoretical global namespace of tarballs
19:35:11 <mtaylor> soren: sure. and they can call it python-glanceclient for all I care
19:35:17 <mtaylor> notmyname: so the reason we're ratholing
19:35:24 <mtaylor> notmyname: is python setup.py sdist
19:35:30 <soren> mtaylor: Well, that's just silly. We pick the names fo things to avoid collisions with others.
19:35:41 <soren> Heck, half this discussion has been about other people's namespace!
19:35:49 <soren> PyPi and Ubuntu, to be exact.
19:35:57 <mtaylor> notmyname: which bases its tarball name on what's in setup.py(name=
19:36:33 <notmyname> ya. like stdeb makes it python-<name from setup.py>
19:36:43 <soren> mtaylor: So don't give me the "we don't care about other people's namespace".
19:36:45 <mtaylor> yup
19:37:03 <mtaylor> soren: "we don't care about it for tarballs" - because there is no shared tarball namespace we need to care about
19:37:19 <mtaylor> we upload to a shared thing called pypi, and we kinda talk to the ubuntu people
19:37:23 <mtaylor> but I belive we are wandering
19:37:29 <mtaylor> into a meta argument again
19:37:49 <mtaylor> more to the point - tarball name, setup(name= and pypi name are tied together
19:38:09 <mtaylor> so, unless we want to get weird, changing one changes all three
19:39:31 <mtaylor> notmyname: can we touch base with bcwaldon and jk0? I know I'm arguing against soren here, but that's probably just because it's fun - there is potentially a valid concern in there
19:39:58 <jeblair> mtaylor: perhaps we should take this to the ML?
19:40:03 <mtaylor> and I doubt we're going to come to conclusion here right now
19:40:05 <mtaylor> yeah
19:40:15 <mtaylor> I think we know which things would change and where the issues might be
19:40:23 <notmyname> mtaylor: ya, sure. like I said earlier, this certainly isn't an issue that's important enough to be different about. it's mostly an "awkwardness in naming" issue
19:40:36 <notmyname> mtaylor: jeblair: thanks for talking through it
19:41:20 <jeblair> indeed, this has been useful to explore the issue, and i think it's worth finding out what others think
19:41:35 <mtaylor> ++
19:42:40 <mtaylor> ok. so those were talky
19:42:42 <ttx> mtaylor: what's the question ?
19:42:46 <mtaylor> #topic statuses of stuff
19:42:58 <mtaylor> ttx: we'll bring it back on ML or over in normal chanel
19:43:10 <mtaylor> a few quick status things:
19:43:51 <ttx> python-python-python
19:43:54 <mtaylor> I got a bunch of puppet module re-org done (yay) and we have some code in from Ryan_Lane to get our new wiki up and going
19:44:06 <mtaylor> clarkb got selenium tests going against horizon
19:44:25 <mtaylor> jeblair: did you accomplish anything worthwhile last week?
19:44:27 <mtaylor> ;)
19:44:44 <jeblair> zuul should be testing/merging changes in an optimal order now
19:44:58 <jeblair> if that looks like it's working...
19:45:18 <jeblair> i'll switch the CI repos to cherry-pick so we can dogfood that idea before proposing we change the rest of the projects
19:45:53 <jeblair> and i finally have tests for zuul, so we can make changes to it without the _extremely_ laborious process of clicking around in jenkins and gerrit
19:46:10 <jeblair> eol
19:46:57 <mtaylor> YAY!
19:47:47 <mtaylor> anybody got anything else?
19:47:53 <devananda> yep
19:48:07 <devananda> patches for devstack and devtack-gate to support testing openvz have been proposed
19:48:12 <devananda> just waiting for reviews/etc now
19:48:21 <mtaylor> w00t!
19:48:40 <mtaylor> if anybody around here has devstack review status, checking those out would be god
19:48:42 <mtaylor> good
19:49:08 <Shrews> devananda: is RS ready to push once those changes are in? i know daniel has already merged in my patches
19:49:11 <devananda> oh, and i did a pretty big re-org from something jaypipes pointed out (the openvz glance image gets handled just like the other images now)
19:49:30 <devananda> Shrews: whether or not they think they are, no, they're not
19:49:43 <jaypipes> w00t.
19:49:43 <devananda> it fails several tests right now, most notably volume and snapshots
19:49:57 <Shrews> devananda: ah, right
19:50:04 <devananda> but it's testing them, heh ;)
19:50:53 <Shrews> well, we might need to fix that ourselves
19:51:23 <devananda> i think it won't be too hard, at least the volume stuff seemed *almost* there when I read it
19:52:37 <devananda> eol
19:55:03 <jeblair> mtaylor: endmeeting?
19:55:20 <mtaylor> #endmeeting