[00:16] hazmat_: right. i was thinking more in terms of deferring executiion of start until some configuration has been completed [00:40] adam_g: Yeah, that'd be fine [00:40] adam_g: I mean, deferring start of the service to another hook [00:47] adam_g: definitely.. i do something similiar in the mongodb-config server, it only starts when there is a relation to a mongos server (else its just a regular mongodb server) === franciscosouza_ is now known as franciscosouza [02:10] <_mup_> txzookeeper/trunk r41 committed by kapil.foss@gmail.com [02:10] <_mup_> merge session-event-handling. Much improved session event and connection error handling with zk cluster tests. [03:38] It's past bed time here.. night all [07:26] kim0, [08:02] koolhead17: Morning [08:13] kim0, i don`t want to see some executive in Tie/Coat surfing cloud in the logo :D [08:18] koolhead17: lol :) [08:18] it's too early to choose hehe [08:19] cool, then :D [08:19] yeah [08:19] * kim0 checks Inbox [08:48] hi et_ [08:53] koolhead17: holla [08:53] notthing much [12:39] Hi everyone, just letting you know we're having the Ubuntu Cloud Days irc event on the 25th/26th. Everyone is invited to add a session at https://wiki.ubuntu.com/UbuntuCloudDays/Timetable Please add your session as soon as you can, if unsure about the title, just write TBD. Ping me for any details, thanks [13:14] Morning all! [13:18] g'morning [13:19] hazmat: Hey man, how're things there [13:20] niemeyer, pretty good, just got back from a long drive === sidnei-away is now known as sidnei [14:17] morning gang [14:22] kim0: do I need the PPA for oneiric? In oneiric itself python-txzookeeper is uninstallable [14:22] jcastro: r u on oneiric again ? [14:23] I was contemplating an upgrade :) [14:23] jcastro: yeah you generally want the ppa [14:23] jcastro: to get the daily builds [14:23] ok [14:23] m_3: o/ [14:44] jcastro! [14:45] jcastro: Rock the world [14:45] fwereade: Welcome, officially! :) [14:46] niemeyer: thanks! [14:46] Folks, William is joining the Ubuntu Server team to help developing Ensemble _today_! [14:46] * fwereade waves shyly [14:46] still figuring a lot of things out, but looking forward to the sprint [14:47] fwereade: and here comes your first code review [14:47] fwereade: https://code.launchpad.net/~hazmat/ensemble/auto-peer/+merge/66913 [14:47] fwereade: Can you please have a look at the change and see what you think of it? [14:47] niemeyer: gladly [14:47] fwereade: Then just approve/needs fixing/comment [14:48] fwereade: The change is almost trivial [14:48] fwereade: But I'm sure you'll have to step back a bit and understand the context [14:49] fwereade: Check out the bug (linked from the merge request), and the documentation for more details about what was wrong [14:49] niemeyer: yep, it'll probably take me a little while [14:49] niemeyer: I'll hassle you if anything seems unduly confusing [14:49] fwereade: Absolutely [14:49] hello fwereade :) [14:49] fwereade: I'm stepping out in a bit for lunch, but I'll be around soon, and others are around to give a hand too [14:49] hi niemeyer kim0 [14:49] koolhead17: Yo! [14:50] koolhead17: hey :) [14:50] niemeyer, finish up your lunch. [14:50] koolhead17: hello :) [14:50] fwereade: wow welcome :) [14:50] koolhead17: I have to start it first! ;-) [14:50] kim0: thanks :) [14:50] kim0, i have changed content of my pycon talk, it will mainly focus on cloud-init and ensemble now :) [14:50] koolhead17: Wow, that's _awesome_ [14:50] niemeyer, :D [14:51] koolhead17: that sounds good :) If that'll make you work on your first formula LOL [14:51] kim0, yes sir!! [14:51] don't sir me man :) [14:51] kim0, :) [14:54] fwereade: welcome! [14:54] hi m_3 [14:54] m_3: thanks :) [14:58] fwereade: just started a couple of weeks ago... feel free to ping me and I'll share the little I know! [14:59] fwereade: utlemming's new on the server team too [14:59] m_3: awesome, I'll be taking you up on that shortly I think :) [15:02] fwereade greetings and welcome [15:02] hazmat: and thanks also :) [15:03] hazmat: am I right in thinking you'll be in Miami next week? [15:03] bcsaller: I'm assuming your review on ~hazmat/ensemble/status-w-peers was an Approve [15:03] niemeyer: yes, sorry [15:04] bcsaller: Hey! [15:04] fwereade, sadly not [15:04] hi :) [15:04] bcsaller: Wasn't sure if you were already around [15:04] bcsaller: Morning :) [15:04] bcsaller: Cool [15:04] barely [15:04] hazmat: ah, shame :( thought I saw you on one of the related pages [15:04] trying to get some coffee down [15:05] fwereade, there's always a next time, hope your enjoy your first sprint, i'll be participating remotely [15:06] hazmat: cool, I look forward to it [15:10] * niemeyer => lunch [15:26] <_mup_> ensemble/status-w-peers r265 committed by kapil.thangavelu@canonical.com [15:26] <_mup_> adjust comments per review. [15:50] default-instance-type: accepts what as a setting in environments.yaml? I am assuming the instance API name right? t1.micro, etc. [16:06] <_mup_> ensemble/trunk r265 committed by kapil.thangavelu@canonical.com [16:06] <_mup_> merge status-w-peer [r=bcsaller,niemeyer][f=804120] [16:06] <_mup_> Fixes a bug with ensemble status subcommand when displaying [16:06] <_mup_> peer relations. === koolhead17 is now known as koolhead11|Afk [16:20] ensemble in particular I guess ;) [16:22] jcastro, indeed just that re instance-type.. m1.large, t1.micro.. eg. ec2 api symbols for instance-type [16:23] s/eg/ie [16:23] thanks, I'll add a note in the docs [16:33] a question for formula authors in the room, which directory would you want your hooks to run in.. The formula hooks directory, the formula directory, or the root of the unit directory (the formula for the unit lives at '/formula' under the unit root)? [16:35] jcastro, m_3, jimbaker SpamapS, fwereade, serge_ , kim0 ^ [16:37] what else lives in the unit root at the moment? [16:37] the formula directory feels natural to me but I am basically 100% ignorant [16:39] fwereade, with lxc, the unit root will be the fs root "/" of the container [16:39] ah ok [16:39] at the moment, there's just the service unit log file and the formula directory in the root [16:41] ok, the hooks directory feels wrong because... well, it's the formula's interface, and if we run in that dir we encourage people to clutter it up with other stuff [16:43] I don't think I have a context to judge the distinction between running in the formula dir and the unit root [16:44] fwereade, agreed, authors can include arbitrary library or configuration stuff in the formula, its probably nicer to address that from the root, then including a '..' everywhere or cluttering up the hooks directory [16:44] er... s/root/ i mean the formula directory [16:44] yep [16:45] * hazmat makes it so [17:00] * niemeyer puts aside his bricklayer cap and goes back to software development [17:01] hazmat: we've been starting from `pwd` [17:01] hazmat: i.e., not assuming it's anywhere in particular [17:02] hazmat: doesn't really matter with anything I've seen so far... pick one [17:08] m_3, pwd isn't reliable atm [17:08] it will be shortly [17:10] hazmat: great, we're starting to do more library sorta stuff [17:11] templates in separate files and such [17:22] hazmat: id personally prefer it run in formula hooks directory. in the formulas ive written, im usually keeping some file that contains common stuff that i source in, and currently need to do some extra steps to get the location of that file [17:24] adam_g, i think the notion is that what's in the hooks directory is the public interface of the formula, its fine to put that stuff in anywhere in the formula, you could put in the root of the formula, and still continue to source 'common.env' with the hook executing in the formula directory [17:25] but perhaps executing it in the hooks directory is the most obvious/intuitive understanding of where it will be executed [17:25] adam_g: With the new approach it will be predictable as well [17:25] adam_g: You'll just have to source hooks/... instead of ./... [17:28] consistent good [17:35] my first impression was to be under hooks/ with my templates ..etc .. but sourcing hooks/* is fine as well [17:43] kim0: That's actually one of the reasons we're leaning towards the formula dir as cwd [17:43] kim0: templates should be under templates/, rather than hooks/ [17:46] indeed cleaner +1 [17:54] but also probably a faq [17:56] kim0, niemeyer how's this for an faq entry? http://paste.ubuntu.com/638989/ [17:56] hazmat: That's very nie [17:56] nice [17:57] hazmat: great indeed .. just a question do we have other "resources" other than templates [17:58] when you mentioned templates should be under templates/ .. I didn't know formulas should have a templates/ directory ?! [17:58] kim0, libraries is the other one that comes to mind, but potentially also binaries [17:58] wonder if formulas should have a directory structures, where authors know where to put stuff [17:58] kim0, they don't per spec have one, but formula authors are atm free to organize any resources needed by their hooks how they like [17:59] ah got it [17:59] we might develop more best-practices with time as the formula collection goes, and have those enforced for an official formula distribution [18:00] <_mup_> ensemble/debug-with-formula-dir r262 committed by kapil.thangavelu@canonical.com [18:00] <_mup_> hooks executed in the formula directory, and a new faq entry regarding [18:03] <_mup_> ensemble/hooks-with-formula-dir r262 committed by kapil.thangavelu@canonical.com [18:03] <_mup_> merge the debug-with-formula-dir, forget this was setup as a bzr-pipeline [18:08] kim0: I've been using hooks/templates/... [18:09] but templates/ works fine too [18:10] yeah it's just a convention [18:15] simple deb packaging question, how do you go about creating empty directories (like /var/log/ensemble) for a package? [18:16] hazmat: mkdir? :) [18:17] niemeyer, ah.. but the magic is where? in such a way that is compatible with the python-distutils packaging helper [18:17] niemeyer, just put in in preinst? === daker is now known as daker_ [18:18] hazmat: I'd say in the binary section of rules [18:18] hazmat: Ah, no.. I'd include it in the package itself [18:20] niemeyer, it looks like dh_installdirs is the right place, spec'd in debian/package.dirs [18:21] or maybe its just debian/dirs [18:21] hazmat: I belive it's .dirs [18:22] hazmat: I don't claim to know much, though :) [18:33] niemeyer, bcsaller regarding [0] on sans-ami branch.. i'm looking at switching ensemble-branch config option to ensemble-install-source with the value being either 'distro' (default for official releases in ubuntu releases), 'ppa:location', or 'lp:~xxx' [18:34] so it would be one option to support default distro packages, ppa packages, or published bzr branches [18:36] hazmat: Hmm [18:36] hazmat: That sounds pretty good [18:40] <_mup_> txzookeeper/trunk r42 committed by kapil.foss@gmail.com [18:40] <_mup_> [trivial] fix changelog spacing for daily deb builds [18:41] hazmat: nice [18:49] niemeyer, bcsaller the only caveat i can think of is if we want to test a branch of txzookeeper in the wild, then the lp location spec is incomplete [18:49] as it references the ensemble bzr branch [18:50] I really like the concept of Ensemble and am interested in potentially converting some of my AWS EC2 scripts to Ensemble formulas. Are the principia formulas going to be the best resource for learning how to write them or is there other documentation for creating formulas? [18:51] dvestal, and the docs https://ensemble.ubuntu.com/docs/write-formula.html [18:51] also https://ensemble.ubuntu.com/docs/formula.html [18:52] hazmat: Thank you. [18:52] dvestal: feel free to ping me with questions while you're writing formulas [19:01] Is the target of ensemble primarily for the creation / maintenance of machines as a whole? More explanation following... [19:07] dvestal, its more about automating service deployment and orchestration, as a consequence it also manages machine deployments. regarding it maintenance, it currently handles those tasks as needed for inter service dependencies [19:09] particular tasks like service specific maintenance action, and overall maintenance of the machines aren't handled atm (for example managing security updates for packages on a machine). [19:14] I made a small doc fix to learn the workflow for ensemble, I don't think it's large enough to like file a bug, etc, so do I just leave it in the merge queue? [19:15] you probably should still file a bug [19:16] like "docs need updating to mention changing default instance type" [19:16] ok [19:18] niemeyer: so we talked about how 12px font in the cloud portal is a little too small. I know understand the reason this font size was chosen is because it's the canonical design team's standard size set. As per the design guideline document (http://design.canonical.com/brand/D.%20Ubuntu%20Web%20Guidelines.pdf) page 16 .. they mention paragraphs should be font 12px [19:18] RoAkSoAx: Welcome! [19:18] niemeyer: thank you! [19:19] I also checked ubuntu.com like (http://www.ubuntu.com/business/cloud/overview) and it's 12px as well .. so I'm little reluctant to change that now [19:19] <_mup_> Bug #806638 was filed: Docs need updating to mention what it expects as a value for instance type < https://launchpad.net/bugs/806638 > [19:19] kim0: I'm not a designer.. all I know is that my eyes hurt when I have to read that text [19:20] obino: o/ [19:26] niemeyer: can you put me in ~ensemble so I can edit the wiki? [19:27] jcastro: Of course [19:27] thanks! [19:28] jcastro: Your Canonical email isn't found in Launchpad? [19:28] it should be, my username is "jorge", usually that's enough to add me to a team [19:29] jcastro: Cool [19:29] jcastro: That's done [19:29] jcastro: Might be good to associate your Canonical address there too [19:29] jcastro: I usually look for people by the email, to avoid mixing [19:30] hi kim0 [19:31] got your request earlier: yes we would like to do something for cloud days :) [19:38] hazmat: Is the individual machine maintenance, etc. something that would be of an interest for the community? Being able to orchestrate the specific machine maintenance items, as well as app upgrades (Tomcat war's, etc.) is something that I will need to do anyway. [19:39] jcastro, if it becomes a common enough activity, it might be worthwhile separating the docs into a separate repo [19:40] obino: Awesome [19:40] it might already be worthwhile [19:40] obino: I'd love it if you guys would add an event to the table (even if it says TBD) while you discuss what you want to present [19:40] obino: if eucav3 is ready for a sneak peak, that'd be awesome indeed :) [19:41] obino: if you think you want 2 sessions .. it's perfectly fine [19:41] obino: thanks for your interest .. as usual ping me if you need anything [19:41] dvestal, its definitely something ensemble will need to grow into fulfill the existing feature set of traditional configuration management, how its implemented (reuse or build) is still tbd [19:42] dvestal, at the moment there is a notion that's being explored (in specification form) of co-locating service units. where one of those units could be some sort of policy formula. [19:43] dvestal, like installing a separate configuration management system or gui machine management facility, or monitoring, network volume, etc. [19:43] although the last is doable now with just relations..