19:14:20 <mtaylor> #startmeeting
19:14:21 <openstack> Meeting started Tue Oct 18 19:14:20 2011 UTC.  The chair is mtaylor. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:14:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:16:45 <mtaylor> anybody still around? heckj - soren?
19:17:05 * zul is lurking
19:17:19 <mtaylor> hey zul!
19:17:39 * ttx lurks as well
19:17:49 <mtaylor> zul: our private conversations about packaging changes after the public discussions about packaging changes seem to have upset ttx ... ;)
19:18:15 <zul> mtaylor: i expect a deathmatch in a week or two
19:18:20 * ttx lurks just enough to make sure another consensus is not made without him :P
19:18:22 <mtaylor> or at least my inability to write things in a tense other than "this is what we're going to do"
19:19:24 <zul> deathmatch much more interesting :)
19:19:32 <soren> mtaylor: Yeah.
19:20:45 <mtaylor> ttx: so, to be clear (and I'll respond to the list too) I was mainly talking about packages as an output/deliverable of the project - i.e. the release ppa
19:21:25 <mtaylor> ttx: because without ongoing updates to those packages, it is highly irresponsible to offer to them to someone as an installation source, largely due to security issues.
19:21:32 <ttx> mtaylor: ah. that was not very apparent from your email.
19:22:17 <mtaylor> dev ppas don't bother me nearly as much - although if it's not a project output, the logistics of actually maintaining the packaging of those packages becomes slightly weirder (since ubuntu upstream is not interested in maintaining packages that work as is on lucid)
19:22:20 <ttx> Maybe I read too much into "We will not be uploading nova/swift/glance/keystone to PPAs." next to "We will be setting up a PyPI mirror into which we will publish pip-able packages for every trunk commit"
19:22:21 <mtaylor> but certainly doable
19:22:38 <mtaylor> ttx: well - pypi mirror will be for dev build testing
19:22:42 <ttx> so it looked like you were talking about trunk ppa
19:23:24 <mtaylor> well, the concern was release ppa - but trunk ppa _does_ wind up becomming problematic from a maint perspective
19:23:39 <ttx> I fully agree that the release PPA can easily be replaced by the "last-milestone" PPA for the purpose of releasing the latest stuff
19:23:42 <mtaylor> because if we're starting to run unittests with run_tests.sh  instead of run_tests.sh -N
19:23:43 <soren> Well, so is everything else we do :)
19:23:48 <mtaylor> soren: ++
19:23:50 <soren> (problematic from a maint perspective)
19:24:07 <ttx> since after a few days it's no longer that useful
19:24:27 <mtaylor> then we will not have the "deps must be packaged before they can be used" blocking trunk commits
19:24:34 <mtaylor> ttx: I think that's a great idea
19:24:54 <ttx> I really don't mind if it ends up being replaced by essex-1, for example
19:25:35 <ttx> but there is still value in 0-day release packages, imho
19:25:58 <mtaylor> ttx: also don't get me wrong ... I ACTUALLY think it's extremely valuable for us to release packages
19:26:25 * Daviey reads up
19:26:33 <mtaylor> ttx: but I think we need a will behind the staffing and maintenance of the mini-distribution we'd be creating
19:26:58 <mtaylor> ttx: because I do not support release packages that we then never update or pay attention to ever again
19:26:58 <ttx> mtaylor: I think the effort is limited if we don't maintain it after release
19:27:02 <Daviey> mtaylor: I agree about it being less than ideal for openstack to maintain their own distro fork, like it currently is.
19:27:14 <Daviey> *However*, i don't agree that producing a PPA is bad.
19:27:24 <Daviey> Your recent mail was not what i thought we agreed.
19:27:43 <Daviey> (it's been on my todo list to reply, bit not sure it makes sense now)
19:27:48 <ttx> mtaylor: having a "last milestone" PPA is just that, a way to install the last milestone. The 0-day package
19:27:51 <mtaylor> so - producing a ppa is bad only if it's unmaintained
19:28:05 <ttx> mtaylor: I agree the release PPA seem to hold a promise they won't keep
19:28:06 <mtaylor> because no matter what we say ... people _WILL_ use it
19:28:15 <mtaylor> ttx: ok. I think we're on the same page about that then :)
19:28:29 <mtaylor> yes?
19:28:57 <ttx> mtaylor: and the value of the release PPA is limited since the development version of Ubuntu carries something better
19:29:18 <mtaylor> #agreed release PPA seems to hold an implicit maintenance promise which we are not interested in - we will replace it with the last-milestone PPA
19:29:21 <Daviey> mtaylor: So the PPA isn't going away as a development resource?
19:29:24 <mtaylor> (unless I got that wrong ^^^)
19:29:39 <mtaylor> Daviey: we're working back towards that I think. one sec
19:29:48 <ttx> soren: does that work for you ?
19:30:06 <mtaylor> we REALLY need the ubottu voting thing
19:30:19 <mtaylor> why aren't we using that meetbot?
19:30:23 * mtaylor digresses
19:30:51 <mtaylor> ttx: the thing our release ppa offered that ubuntu does not is packages for current openstack that work on lucid
19:31:11 <mtaylor> ttx: which is the push back I've gotten from users I've talked to about pointing them towards ubuntu
19:31:24 <mtaylor> ttx: thus far, none of them are wanting to run oneiric in prod
19:31:25 <mtaylor> BUT
19:31:43 <mtaylor> I think we can perhaps agree that solving that _might_ not happen this instant
19:31:55 <ttx> mtaylor: I think our PPAs are usable for development, evaluation, and QA. Not production -- you should use something more maintained for that
19:31:57 <Daviey> I think the burden can be shared, but as yet - i haven't seen a request for help.
19:32:13 <Daviey> rather than drop it, if it's prooving to be too much work - a request for help should go out.
19:32:31 <zul> people will use distros for production me thinks
19:32:32 <ttx> mtaylor: the stable-branchers /could/ produce a PPA that is usable in production, but I don't think they really want to
19:32:50 <ttx> zul: or internal distros
19:32:56 <zul> ttx: yeah
19:32:59 <mtaylor> zul: I do not think that people will use distros for production until P comes out
19:33:09 <Daviey> keep in mind that 12.04 is an LTS, so i would expect people to deploy that.
19:33:11 <zul> mtaylor: they already are apparently
19:33:15 <soren> ttx: Sorry, got distracted. /me catches up
19:33:23 <mtaylor> so, let me say - I had a set of people who are not core devs approach me about this this weekend
19:33:46 <Daviey> mtaylor: and what did they say, and who were they?
19:33:46 <mtaylor> and they were beside themselves upset that we were not maintaining the release PPA for lucid with bugfixes
19:33:56 <soren> ttx: Does it work for me to stop doing a release PPA? Sure.
19:34:15 <mtaylor> Daviey: various people who don't talk much in #openstack-dev , but who are apparently trying to deploy use at wherever they are
19:34:38 <mtaylor> Daviey: it was saturday, and there were at least three people in the conversation
19:34:42 <mtaylor> which is a digression
19:34:48 <Daviey> I don't think it was declared to be part of the openstack release.. therefore I'm not sure an active /effort/ is required to make it go away.. why not let it fade away if nobody pitches in?
19:34:55 <mtaylor> because I think we've agreed that the current solutoin to this is to not produce the release PPA
19:35:04 <ttx> mtaylor: right, so we are back on the promise the release PPAs apparently seem to carry with them
19:35:27 <Daviey> mtaylor: "various people" isn't much use.. they really need to identify themselves if they have any hope of getting their use case catered for.
19:35:35 <zul> mtaylor: simple fix, bzr mirror the stable git tree, then do a bzr reciepe, and let launchpad do the rest for you
19:35:37 <mtaylor> yes. so I think we've got this bit - the next question is maintenance of dev ppas
19:36:02 <mtaylor> zul: recipes don't make any sense to me - if someone wants to set that up there are more than welcome to
19:36:12 <ttx> someone should get into the business of doing an openstack distro for lucid
19:36:26 <zul> or a next LTS ;)
19:36:28 <mtaylor> yes. they should - it would be quite popular :)
19:36:37 <mtaylor> at least for the next year
19:36:39 <mtaylor> :)
19:36:47 <ttx> mtaylor: let me find a VC that will fund that startup
19:37:02 <mtaylor> ttx: sweet
19:37:13 <Daviey> ttx: I have £10 in my pocket if that helps.
19:37:22 <mtaylor> zul: was the recipe fix a fix for dev ppa?
19:37:31 <zul> mtaylor: yeah at least
19:37:45 <mtaylor> zul: well, sure - but that's not really the problem that needs solving for the dev ppa
19:37:49 <mtaylor> making the packages is easy
19:37:53 <zul> mtaylor: and then i can break it when i upload to the bzr tree
19:37:57 <mtaylor> the content of the packaging is harder
19:38:32 <mtaylor> because of a) packaging version diversions and b) backport packages ... so I'm just wondering about maint of those things
19:38:42 <mtaylor> packaging version diversions == dh_python2 problems
19:38:49 <mtaylor> sorry - those were obtuse words
19:39:00 <ttx> mtaylor: is it difficult, or too much work ?
19:39:18 <soren> Admittedly, I can't imagine a stable update would add new dependencies.
19:39:52 <soren> The trouble is that the things in the PPA that aren't openstack might have security problems. *That's* the part that freaks me out.
19:39:52 <ttx> mtaylor: because we certainly can limit the number of flavors supported to current / current LTS
19:40:22 <ttx> mtaylor: soren is the only openstack coredev that runs ubuntu under development :)
19:40:40 <soren> ttx: I think that would be great.
19:40:43 <Daviey> Hmm
19:41:09 <Daviey> Considering Ubuntu plan to run on-commit functional testing in the development release, we will need a PPA for the Ubuntu development version.
19:41:16 <Daviey> I don't object if we do this ourselves
19:41:18 <soren> ttx: We only got to this point, because noone ever had the heart to pull the trigger on the maverick builds and now the natty builds.
19:41:32 <Daviey> Or if it is handled ~openstack-ubuntu-packagers, or whatever
19:41:34 <mtaylor> ttx: difficult
19:42:01 <mtaylor> I am not worried about ubuntu dev release packages, because I _know_ that ubuntu devs will be working on those
19:42:24 <mtaylor> and I have no problem with creating/uploading those and or triggering the ubuntu on-commit functional testing even
19:42:38 <mtaylor> is that the needs of _that_ ppa is very specific ubuntu
19:42:49 <Daviey> mtaylor: We can probably take this aspect out of band TBH
19:43:06 <mtaylor> and does not address what ttx was talking about, which is the potential need of devs to have packages of trunk commits
19:43:10 <mtaylor> Daviey: ++
19:43:27 <mtaylor> Daviey: I think there is very little consternation around packages targetted at ubuntu dev release :)
19:43:50 <Daviey> groovy
19:44:03 <mtaylor> the question at hand is - should we, as the project, produce packages on each source commit for old ubuntu releases
19:44:10 <notmyname> I may be the slow one in the room here. why don't we provide "prod-ready" packages (with support, committed to by the projects) and "dev/beta/test/whatever" packages for those who want other projects that aren't yet ready for prody
19:44:15 <notmyname> mtaylor: lucid isn't old :-)
19:44:37 <mtaylor> notmyname: I'm aiming that sentence at the ubuntu devs in the room, which thus far have been the only people other than me in the conversation :)
19:44:38 <soren> No. It's ancient :)
19:44:43 <mtaylor> notmyname: to whom lucid is very olld
19:45:08 <mtaylor> notmyname: thus far, swift is the only project that has indicated _any_ interest in maintaining such packages
19:45:09 <notmyname> soren: lucid is the current prod-ready version of ubuntu (no ops will not run LTS)
19:45:31 <jaypipes> notmyname: uhm, Rax public cloud is running on Sid.. ;)
19:45:36 * mtaylor would like to table any disagreements about lucid age at the moment
19:45:37 <ttx> notmyname: some ops do though :)
19:45:39 <mtaylor> jaypipes: no, it's not
19:45:44 <mtaylor> jaypipes: it's running squeeze
19:45:51 <jaypipes> oh, sorry, even better
19:45:52 <notmyname> all generalizations are wrong
19:45:56 <mtaylor> which is the current released versoin of debian
19:45:58 <jaypipes> notmyname: :)
19:45:59 <mtaylor> anyway
19:46:02 <mtaylor> bikeshed
19:46:10 <zul> jaypipes: heretics :)
19:46:16 <jaypipes> lol
19:46:22 * jaypipes goes back in hole
19:46:25 <notmyname> so decide if an openstack core project is ready for prod and then support it as such with LTS packages and support from the project team
19:46:45 <mtaylor> #topic should we, as the project, produce packages on each source commit for old ubuntu releases
19:46:58 <ttx> notmyname: who is this "project team" ?
19:47:12 <notmyname> nova/swift/whatever
19:47:40 <ttx> ah ok
19:48:05 <notmyname> ie, if a team says they are ready for prod, they should provide some support for it in the way of bugfixes (security), etc
19:48:09 <mtaylor> notmyname: right. based on conversations at the ODS, we created an openstack-stable-maint team comprised of distro folks who will deal with patching released versions
19:48:24 <ttx> mtaylor: not necessarily for every trunk commit -- but maybe for milestone-proposed, and definitely for last-milestone
19:48:44 <mtaylor> ttx: ok. the next question is why
19:48:52 <ttx> so it's not that much more work to also do it for trunk
19:49:05 <mtaylor> ttx: because if we are not going to releae those packages, what is the point of explcitly testing those packages
19:49:30 <mtaylor> ttx: when the devs are most likely going to be using devstack to run local tests? (not trying to be snarky, just making sure I understand)
19:49:32 <ttx> trunk is used for development, milestone-proposed for QA, last-milestone for evaluation
19:49:48 <mtaylor> sure. but QA of what
19:49:59 <mtaylor> I mean, what value does the PPA add to that process
19:50:05 <mtaylor> if it's different than testing trunk commits
19:50:10 <ttx> I guess we could limit it to a relatively-new ubuntu version
19:50:13 <mtaylor> and if it isn't how the final release is packaged
19:50:19 <Daviey> This Topic is going a bit TL;DR, can we sumarise actions?
19:50:38 <ttx> QA of the milestone itself
19:50:46 <jeblair> if the CI team and the devs are all using devstack to test during development, then that same procedure seems suitable for testing milestones
19:52:00 <mtaylor> Daviey: I would love that - but I think we're still in discussion of the basic issue to figure out what it is that we're all actually talking about :)
19:52:26 <ttx> with 7 minutes left
19:52:30 <mtaylor> YAY!
19:53:13 <mtaylor> ttx: I'm really not trying to difficult, I'm just trying to make sure I understand the thing we're trying to accomplish
19:53:59 <ttx> mtaylor: so far I've been using trunk PPA for development, calling people to test the milestone-proposed using that PPA, and sent milestone release emails pointing to a milestone PPA
19:54:01 <ttx> that worked.
19:54:32 <mtaylor> really?
19:54:32 <ttx> Now you tell me it doesn't work anymore and needs to be abandoned, at least partially
19:54:34 <mtaylor> I don't think it did
19:54:41 <mtaylor> nova was broken upon release
19:54:54 <ttx> because people don't give a shit about fixing bugs
19:55:05 <mtaylor> and only works in oneiric because ubuntu patched
19:55:07 <mtaylor> patched it
19:55:07 <ttx> not because of testing of the milestone-proposed
19:55:34 <ttx> I don't see how removing the option people had to test actually improves that state
19:55:49 <Daviey> I think it's not that simple, Diablo nova was a special case due to many factors.  I'm not sure it's releated to the PPA.
19:55:53 <mtaylor> so, what does testing milestone-proposed from packages rather than from source tarballs gain us in this case
19:56:04 <Daviey> Although feature vs stability is a good point :)
19:56:17 <mtaylor> I'm not saying it's related to the ppa - I'm just saying that ppa itself is an implementation detail
19:56:50 <mtaylor> and that testing debian packages of the project vs. testing source tarballs of a version is an extra layer of code to test if the debian packages are not a project output
19:56:52 <ttx> I guess I fail to see devstack as a usable way of testing. You probably know better
19:57:19 <mtaylor> I think it made PERFET sense when the de-facto primary output of the project was the release PPA
19:57:28 <jeblair> packages themselves don't produce a working environment for testing, devstack has the advantage of doing so
19:57:32 <Daviey> I actually found the non-nova PPA's really useful for development of nova.
19:58:07 <zul> the juju charms has options to use the dev ppas as well
19:58:11 <Daviey> jeblair: For the project you are currently working on, i agree - for the depends, packages make more sense IMO.
19:58:42 <mtaylor> Daviey: only if you're an ubuntu dev - the python devs on the project all keep adding depends to pip-requires and then being confused why they don't work
19:58:46 <zul> but everyone has their own usecase/agenda so you are not going to get a good concensous
19:58:50 <ttx> I suppose I should try devstack -- it must just be my aversion for shell scripts used to setup complex things
19:58:52 <mtaylor> zul ++
19:58:58 <ttx> probably dates back from my ebuild past
19:59:03 <zul> lol
19:59:04 <mtaylor> ttx: I totally hear that
19:59:09 <jeblair> it's no panacea.  don't run it on anything important. :)
19:59:17 <mtaylor> jeblair: ++
19:59:24 <zul> ttx: funny i have the same aversion
19:59:28 <ttx> jeblair: like our whole CI ?
19:59:37 <jeblair> our CI is disposable. :)
19:59:40 <mtaylor> but it's certainly a simple way for a dev to get an installable/working version of the current version from trunk
20:00:00 <mtaylor> ttx: we're going to use devstack as the basis for CI testing because it's something that the devs can reproduce locally
20:00:25 <Daviey> mtaylor: No, i mean.. if you are developing nova - then use, use nova git checkout.. but for devenv - glance, why the heck would you use source when you don't care about it for the feature you are working on?
20:00:28 <mtaylor> which is something that the other solutions thus far for integrated testing (puppet, chef, vpc, smokestack, whatnot) have drastically failed to do
20:00:40 <Daviey> It's like installing python from source :)
20:00:56 <mtaylor> Daviey: pip install -i http://pypi.openstack.org/ glance
20:00:58 <ttx> mtaylor: maybe I was special, but my development workflow (based on installing deb packages) was totally reprodueable
20:01:21 <zul> ttx: yeah but you knew what you were doing i bet
20:01:21 <vishy> because source gives you more reliable version pinning?
20:01:26 <ttx> mtaylor: but I hear that it's a bit ubuntu-slanted
20:02:14 <ttx> mtaylor: and that to be distro-agnostic you need to cut the special link we built between ubuntu and openstack
20:02:15 <Daviey> anyone want to join me behind the bikeshed for a smoke?
20:02:21 <mtaylor> as fun as this has been ... we may or may not have a ppb meeting next
20:02:23 <mtaylor> Daviey: please. god
20:02:40 <mtaylor> ttx: yes. EXCEPT - that I'd like to _change_ the link between ubuntu and openstack
20:02:51 <mtaylor> ttx: so that it's one that isn't exclusive
20:02:57 <mtaylor> ttx: and it won't be totally cut
20:03:03 <mtaylor> because we're still pinned to ubuntu release dates :)
20:03:21 <mtaylor> #agreed we could all discuss this for ages and ages and cause Daviey to smoke more
20:03:23 <Daviey> mtaylor: "not totally cut",  implies do damage to.
20:03:35 <mtaylor> Daviey: only if change == damage
20:03:56 <vishy> is ppb happening btw?
20:03:57 <Daviey> well it depends if it's a positive or a negative change :)
20:04:21 <zns> vishy: I'm here for PPB...
20:04:27 <mtaylor> #endmeeting