19:14:20 #startmeeting 19:14:21 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:16:45 anybody still around? heckj - soren? 19:17:05 * zul is lurking 19:17:19 hey zul! 19:17:39 * ttx lurks as well 19:17:49 zul: our private conversations about packaging changes after the public discussions about packaging changes seem to have upset ttx ... ;) 19:18:15 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 or at least my inability to write things in a tense other than "this is what we're going to do" 19:19:24 deathmatch much more interesting :) 19:19:32 mtaylor: Yeah. 19:20:45 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 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 mtaylor: ah. that was not very apparent from your email. 19:22:17 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 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 but certainly doable 19:22:38 ttx: well - pypi mirror will be for dev build testing 19:22:42 so it looked like you were talking about trunk ppa 19:23:24 well, the concern was release ppa - but trunk ppa _does_ wind up becomming problematic from a maint perspective 19:23:39 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 because if we're starting to run unittests with run_tests.sh instead of run_tests.sh -N 19:23:43 Well, so is everything else we do :) 19:23:48 soren: ++ 19:23:50 (problematic from a maint perspective) 19:24:07 since after a few days it's no longer that useful 19:24:27 then we will not have the "deps must be packaged before they can be used" blocking trunk commits 19:24:34 ttx: I think that's a great idea 19:24:54 I really don't mind if it ends up being replaced by essex-1, for example 19:25:35 but there is still value in 0-day release packages, imho 19:25:58 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 ttx: but I think we need a will behind the staffing and maintenance of the mini-distribution we'd be creating 19:26:58 ttx: because I do not support release packages that we then never update or pay attention to ever again 19:26:58 mtaylor: I think the effort is limited if we don't maintain it after release 19:27:02 mtaylor: I agree about it being less than ideal for openstack to maintain their own distro fork, like it currently is. 19:27:14 *However*, i don't agree that producing a PPA is bad. 19:27:24 Your recent mail was not what i thought we agreed. 19:27:43 (it's been on my todo list to reply, bit not sure it makes sense now) 19:27:48 mtaylor: having a "last milestone" PPA is just that, a way to install the last milestone. The 0-day package 19:27:51 so - producing a ppa is bad only if it's unmaintained 19:28:05 mtaylor: I agree the release PPA seem to hold a promise they won't keep 19:28:06 because no matter what we say ... people _WILL_ use it 19:28:15 ttx: ok. I think we're on the same page about that then :) 19:28:29 yes? 19:28:57 mtaylor: and the value of the release PPA is limited since the development version of Ubuntu carries something better 19:29:18 #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 mtaylor: So the PPA isn't going away as a development resource? 19:29:24 (unless I got that wrong ^^^) 19:29:39 Daviey: we're working back towards that I think. one sec 19:29:48 soren: does that work for you ? 19:30:06 we REALLY need the ubottu voting thing 19:30:19 why aren't we using that meetbot? 19:30:23 * mtaylor digresses 19:30:51 ttx: the thing our release ppa offered that ubuntu does not is packages for current openstack that work on lucid 19:31:11 ttx: which is the push back I've gotten from users I've talked to about pointing them towards ubuntu 19:31:24 ttx: thus far, none of them are wanting to run oneiric in prod 19:31:25 BUT 19:31:43 I think we can perhaps agree that solving that _might_ not happen this instant 19:31:55 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 I think the burden can be shared, but as yet - i haven't seen a request for help. 19:32:13 rather than drop it, if it's prooving to be too much work - a request for help should go out. 19:32:31 people will use distros for production me thinks 19:32:32 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 zul: or internal distros 19:32:56 ttx: yeah 19:32:59 zul: I do not think that people will use distros for production until P comes out 19:33:09 keep in mind that 12.04 is an LTS, so i would expect people to deploy that. 19:33:11 mtaylor: they already are apparently 19:33:15 ttx: Sorry, got distracted. /me catches up 19:33:23 so, let me say - I had a set of people who are not core devs approach me about this this weekend 19:33:46 mtaylor: and what did they say, and who were they? 19:33:46 and they were beside themselves upset that we were not maintaining the release PPA for lucid with bugfixes 19:33:56 ttx: Does it work for me to stop doing a release PPA? Sure. 19:34:15 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 Daviey: it was saturday, and there were at least three people in the conversation 19:34:42 which is a digression 19:34:48 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 because I think we've agreed that the current solutoin to this is to not produce the release PPA 19:35:04 mtaylor: right, so we are back on the promise the release PPAs apparently seem to carry with them 19:35:27 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 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 yes. so I think we've got this bit - the next question is maintenance of dev ppas 19:36:02 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 someone should get into the business of doing an openstack distro for lucid 19:36:26 or a next LTS ;) 19:36:28 yes. they should - it would be quite popular :) 19:36:37 at least for the next year 19:36:39 :) 19:36:47 mtaylor: let me find a VC that will fund that startup 19:37:02 ttx: sweet 19:37:13 ttx: I have £10 in my pocket if that helps. 19:37:22 zul: was the recipe fix a fix for dev ppa? 19:37:31 mtaylor: yeah at least 19:37:45 zul: well, sure - but that's not really the problem that needs solving for the dev ppa 19:37:49 making the packages is easy 19:37:53 mtaylor: and then i can break it when i upload to the bzr tree 19:37:57 the content of the packaging is harder 19:38:32 because of a) packaging version diversions and b) backport packages ... so I'm just wondering about maint of those things 19:38:42 packaging version diversions == dh_python2 problems 19:38:49 sorry - those were obtuse words 19:39:00 mtaylor: is it difficult, or too much work ? 19:39:18 Admittedly, I can't imagine a stable update would add new dependencies. 19:39:52 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 mtaylor: because we certainly can limit the number of flavors supported to current / current LTS 19:40:22 mtaylor: soren is the only openstack coredev that runs ubuntu under development :) 19:40:40 ttx: I think that would be great. 19:40:43 Hmm 19:41:09 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 I don't object if we do this ourselves 19:41:18 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 Or if it is handled ~openstack-ubuntu-packagers, or whatever 19:41:34 ttx: difficult 19:42:01 I am not worried about ubuntu dev release packages, because I _know_ that ubuntu devs will be working on those 19:42:24 and I have no problem with creating/uploading those and or triggering the ubuntu on-commit functional testing even 19:42:38 is that the needs of _that_ ppa is very specific ubuntu 19:42:49 mtaylor: We can probably take this aspect out of band TBH 19:43:06 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 Daviey: ++ 19:43:27 Daviey: I think there is very little consternation around packages targetted at ubuntu dev release :) 19:43:50 groovy 19:44:03 the question at hand is - should we, as the project, produce packages on each source commit for old ubuntu releases 19:44:10 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 mtaylor: lucid isn't old :-) 19:44:37 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 No. It's ancient :) 19:44:43 notmyname: to whom lucid is very olld 19:45:08 notmyname: thus far, swift is the only project that has indicated _any_ interest in maintaining such packages 19:45:09 soren: lucid is the current prod-ready version of ubuntu (no ops will not run LTS) 19:45:31 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 notmyname: some ops do though :) 19:45:39 jaypipes: no, it's not 19:45:44 jaypipes: it's running squeeze 19:45:51 oh, sorry, even better 19:45:52 all generalizations are wrong 19:45:56 which is the current released versoin of debian 19:45:58 notmyname: :) 19:45:59 anyway 19:46:02 bikeshed 19:46:10 jaypipes: heretics :) 19:46:16 lol 19:46:22 * jaypipes goes back in hole 19:46:25 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 #topic should we, as the project, produce packages on each source commit for old ubuntu releases 19:46:58 notmyname: who is this "project team" ? 19:47:12 nova/swift/whatever 19:47:40 ah ok 19:48:05 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 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 mtaylor: not necessarily for every trunk commit -- but maybe for milestone-proposed, and definitely for last-milestone 19:48:44 ttx: ok. the next question is why 19:48:52 so it's not that much more work to also do it for trunk 19:49:05 ttx: because if we are not going to releae those packages, what is the point of explcitly testing those packages 19:49:30 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 trunk is used for development, milestone-proposed for QA, last-milestone for evaluation 19:49:48 sure. but QA of what 19:49:59 I mean, what value does the PPA add to that process 19:50:05 if it's different than testing trunk commits 19:50:10 I guess we could limit it to a relatively-new ubuntu version 19:50:13 and if it isn't how the final release is packaged 19:50:19 This Topic is going a bit TL;DR, can we sumarise actions? 19:50:38 QA of the milestone itself 19:50:46 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 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 with 7 minutes left 19:52:30 YAY! 19:53:13 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 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 that worked. 19:54:32 really? 19:54:32 Now you tell me it doesn't work anymore and needs to be abandoned, at least partially 19:54:34 I don't think it did 19:54:41 nova was broken upon release 19:54:54 because people don't give a shit about fixing bugs 19:55:05 and only works in oneiric because ubuntu patched 19:55:07 patched it 19:55:07 not because of testing of the milestone-proposed 19:55:34 I don't see how removing the option people had to test actually improves that state 19:55:49 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 so, what does testing milestone-proposed from packages rather than from source tarballs gain us in this case 19:56:04 Although feature vs stability is a good point :) 19:56:17 I'm not saying it's related to the ppa - I'm just saying that ppa itself is an implementation detail 19:56:50 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 I guess I fail to see devstack as a usable way of testing. You probably know better 19:57:19 I think it made PERFET sense when the de-facto primary output of the project was the release PPA 19:57:28 packages themselves don't produce a working environment for testing, devstack has the advantage of doing so 19:57:32 I actually found the non-nova PPA's really useful for development of nova. 19:58:07 the juju charms has options to use the dev ppas as well 19:58:11 jeblair: For the project you are currently working on, i agree - for the depends, packages make more sense IMO. 19:58:42 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 but everyone has their own usecase/agenda so you are not going to get a good concensous 19:58:50 I suppose I should try devstack -- it must just be my aversion for shell scripts used to setup complex things 19:58:52 zul ++ 19:58:58 probably dates back from my ebuild past 19:59:03 lol 19:59:04 ttx: I totally hear that 19:59:09 it's no panacea. don't run it on anything important. :) 19:59:17 jeblair: ++ 19:59:24 ttx: funny i have the same aversion 19:59:28 jeblair: like our whole CI ? 19:59:37 our CI is disposable. :) 19:59:40 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 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 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 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 It's like installing python from source :) 20:00:56 Daviey: pip install -i http://pypi.openstack.org/ glance 20:00:58 mtaylor: maybe I was special, but my development workflow (based on installing deb packages) was totally reprodueable 20:01:21 ttx: yeah but you knew what you were doing i bet 20:01:21 because source gives you more reliable version pinning? 20:01:26 mtaylor: but I hear that it's a bit ubuntu-slanted 20:02:14 mtaylor: and that to be distro-agnostic you need to cut the special link we built between ubuntu and openstack 20:02:15 anyone want to join me behind the bikeshed for a smoke? 20:02:21 as fun as this has been ... we may or may not have a ppb meeting next 20:02:23 Daviey: please. god 20:02:40 ttx: yes. EXCEPT - that I'd like to _change_ the link between ubuntu and openstack 20:02:51 ttx: so that it's one that isn't exclusive 20:02:57 ttx: and it won't be totally cut 20:03:03 because we're still pinned to ubuntu release dates :) 20:03:21 #agreed we could all discuss this for ages and ages and cause Daviey to smoke more 20:03:23 mtaylor: "not totally cut", implies do damage to. 20:03:35 Daviey: only if change == damage 20:03:56 is ppb happening btw? 20:03:57 well it depends if it's a positive or a negative change :) 20:04:21 vishy: I'm here for PPB... 20:04:27 #endmeeting