[00:14] senior7515: juju works against a local lxc provider for development [00:17] ohhh awesome… sooo how does it work when you say -n 3 [00:17] for example [00:17] ? [00:17] virtual instances over some virtual engine or ? [00:17] disregards ? [00:17] or ? [00:18] a newbie's question, and I appreciate if anyone give me a quick answer: can I say Juju does exactly what Chef wants to achieve? Or can someone give me an intro to Juju and Chef's different goal? [00:20] senior7515: well, it depends on your local resources... perhaps I'd try it with a small stack of services first (it creates lxc VMs on a single box) [00:20] senior7515: if you have a large machine available... or pay for a large instance in ec2, then you can run a larger set of service in your local lxc cloud [00:22] chefnewbie: chef's a great tool... it's for configuration mgmt. Where chef is lacking atm is in "coordination" or what we're calling "service orchestration". That's what juju's solving.. it's an eventing/coordination layer. You could coordinate services using juju where each machine was configured with chef or puppet [00:23] chefnewbie: the way that would work would be to have juju charms that call puppet manifests or chef cookbooks... a charm is just a set of hook scripts that get called by juju at the right time. [00:24] SpamapS: ping , wanna prom this ? https://github.com/websitedevops/charms-newrelic-php [00:25] so Chef cookbook is responsible for individual machine configuration (i.e., "setup a machine as MySQL server"); where juju is responsible for a group of machine collaborating with each others ("Apache Server A talks to App Server B, B talks to MySQL server C" [00:25] is this a correct 101 understanding? [00:26] chefnewbie: it _could_ work that way, but it really depends on the service [00:26] <_mup_> juju/unit-rel-lifecycle-start-invoker r533 committed by jim.baker@canonical.com [00:26] <_mup_> Ensure that invoker.start is called to get relation hook caching for lifecycles [00:26] chefnewbie: a lot of services are pretty simple installations and don't need manifests or cookbooks to configure them [00:27] m_3: thanks… testing this mongodb-hadoop api is becoming a pain.. meh.. still wishing I had a devops guy hehe [00:27] chefnewbie: browse through the "install" hooks on a couple of charms in jujucharms.com and you'll see some simple examples [00:27] Thanks, m_3. I am thinking of this long-term goal in my company.... [00:28] chefnewbie: more complex things like rails apps or django apps might warrant using other tools for the configuration of each charm [00:28] chefnewbie: sure... happy to discuss. [00:29] senior7515: cool [00:29] * m_3 gotta run to dinner... catch y'all later [00:29] We are a small Python shop, right now we are planning to use OpenStack / Swift as our backend -- so, this is pretty much a python shop from infrastructure layer to application layer [00:30] if we introduce Chef, we are introducing Ruby prettey much as I understand. [00:30] We want to avoid such scenario as much as possible. [00:30] any suggestion? [00:30] chefnewbie: after you've looked at a couple of charms like wordpress or node.js, take a peek at mysql (the hooks there are done in python) [00:30] chefnewbie: juju hooks can be written in any language (with an ubuntu runtime) [00:31] * imbrandon even does some in php [00:31] is it customary for a person to take a charm, modify the confi of the charm and then deploy or the other way around. Say you need other services etc. [00:32] we are trying to avoid Ruby as much as possbile, that's what I am trying to say :-), and that's why I am asking if Juju can serve as a complete Cloud Management stack [00:32] chefnewbie: certainly [00:33] its able to use pupet or others if you wish but certainly dont need them [00:33] I know people saying Juju can work with Chef, but my motivation is to have python programmers take care of the Management Stack as well (i.e., the Devops job) [00:33] chefnewbie: many hooks are in python in juju [00:34] infact i'd say about 50% its by far the most comon choice [00:34] and those that arent are simple bash scripts [00:34] thanks, I think I roughly got what I wanted from this chat :-) [00:34] and the supportive chat room just gave me another reason to explore Juju... [00:34] :) [00:36] another question: how would other OS vendors treat Juju? --I know Ubuntu will support this effort as long term commitment, but how about centos? [00:37] hrm one of the juju core dev probably would be better to awsner that but IMHO its a blessing it dont, gives you a excuse to kill that abomina^W centoos with fire [00:38] really with services orchstration tho service should not matter, e.g thats one rewason to use a something like this is you care about the app, not the reast of below the app [00:40] the os and software running the app then becomes a commodity , not a asset, and can be started/stoped/moved thrown out etc at will [00:40] and the app is fine [00:41] e.g. stuff like i dont care how many mysql cluster heads or if its just one, i care that my app has a db to connect to [00:41] let juju care if there are 3 heas or 3 and making them work [00:42] once your to that point the os is really just a name on paper [00:42] 3 heads* or 30* [00:43] well, this goal is what Chef claim to serves (i.e a layer to hide the specific OS systems), here I'd like to see how well juju has done this job. [00:43] For example, Ubuntu's /etc/networking/... controls network stuff, but that may be different in Redhad (or other vendors) [00:44] chefnewbie: not sure exactly what your meaning , but real example with omgubuntu.co.uk , when it was release day a few days ago, we had it running on 1 webhead and 1 db, needed mroe capacity so i said "juju add-unit omgubutu-wp -n4" [00:44] and i then had 5 webheads and plenty of room for traffic [00:45] i juju took care of spinning up 4 more nodes, installing nginx, configing it [00:45] making it talk to the db [00:45] imbrandon: here is my question.... [00:45] rsyncing the current wp relase adn code [00:45] etc [00:45] chefnewbie: Charms are written currently with Ubuntu in mind since Juju is such a recent release, as the Juju core is Python it should be relatively easy to port Juju to most any other Linux based system. The charms are less portable, so you'd have to tailor each charm to its intended platform [00:46] While this might change in the future the primary goal is to build the charms in the Ubuntu ecosystem then I'd imagine branch out. Unless someone wanted to work on an RPM port of the project, etc [00:46] marcoceppi: charm is the hook (i.e., the one defining the inidvidual node's configuration)? [00:47] charms define the service to be deployed [00:47] chefnewbie: these are all charms; http://jujucharms.com/charms [00:47] rather, these are all services that have been charmed [00:47] chefnewbie: think of a hook as a init.d script, they are juju scripts that fire at the right times [00:48] on the node [00:49] so like when juju adds more of the "webserver" service , the units all fire "config-changed" hook so that they can add ip's and whatever else they may need to their own configs etc [00:49] whatever is in the config-changed hook, a bash or python or whatever script , is what gets done [00:50] imbrandon: your comparison of "think of a hook as a init.d script" made understand hook crystal-clear (for now for this 101 discussion, at least), can you further talk about charm? -- can you give a metaphor for that? [00:50] charms are just a collection of hooks [00:50] that comprise to build a service [00:50] hrm heh , well it would just bee the system that kicks those off [00:51] yea [00:51] chefnewbie: you can browse what hooks make a charm at any of the charms here: http://jujucharms.com/charms [00:51] and keeps info about all the nodes [00:52] so charm basically is a collection of "Cookbooks", but it does a little more ---it defines how each cooked machine should talk to each other? [00:52] chefnewbie: yea marcoceppi said it perfect "charms are all the hooks it takes to build , configure, and maintain a server, wrapped into one place a.k.a a charm" [00:53] and keeps track of weach service and its state [00:53] thanks, I think I should be looking at Juju doc more. [00:54] You guys are really supportive, many thanks [00:54] what is the juju's license term? [00:54] yea thats one good thin, even as quick as juju is moveing the docs stay pretty upto date [00:54] they are great about that [00:54] AGPL 3.0? what does that mean? [00:54] gpl 3 iirc, for the program its self, chamrs are lic on their own [00:54] charms* [00:55] afro gpl v3 [00:55] yep, it is agpl v3. [00:56] but yea charms are lic individually they arent derivitive works [00:56] of juju at leaste [00:56] All official charms in the charm store must be at least GPLv3 license to be included, though you can license your charms to whatever you'd like, if you want it in the store it needs to follow that and a few other criteria [00:57] marcoceppi: really ? shit mine is gpl v2 and that means drupal will never be in the cs [00:57] s/must be at least GPLv3/must be under a free license: http:\/\/www.opensource.org\/licenses\// [00:57] ahhh ok [00:57] good god [00:57] :) [00:58] Yes, I escape my chat regex lines. [00:58] ahahah [00:58] GPLv3 is just recommended [00:58] yea i about craped my pants there, i really dislike v3 and use v2 mostly or a simplified BSD but drupal is v3 incompatable too [00:59] AGPL v3 is stricter than GPL v3? [00:59] chefnewbie: it covers webservice stuff [00:59] iirc [01:00] imbrandon: what does this mean ("covers webservice stuff")? [01:00] if someone use juju to provide a service like RightScale, it needs to pay license fee? [01:00] chefnewbie: think of it like this ... gpl , website dont have to give out src, its not distrubuted, website in agpl , website must also give out src due to lic provisions specificly for that [01:01] chefnewbie: and no [01:01] chefnewbie: only the src to juju, unless your modify juju to actually provide the web ui [01:01] if its a tools calleed on the backend [01:01] then no [01:02] you can write a webui and be 100% closed and still "call out" to juju [01:02] as a back end program as you would with say ummm ssh or somehting [01:03] hmm, then please give me a scenario that I need to give out src, please. [01:03] chefnewbie: think about it this way makes it easy, about you said the word "use" , any case where that is true then no src is needed, when you say "modify juju to do ....blah" [01:04] thanks, this is simple and easy to understand (for now, for my 101 understanding) [01:04] then src and webservice would be needed to be handed out IF JUJU IS PART OF THE ACTUAL WEBSERVICE CODE , not just another tool of many it may use under da hooh [01:05] basicly if you dont madify juju your golden [01:05] and charms dont cound as part of juju [01:05] count* [01:05] okies, dinner time [01:05] afk a bit fellas [01:06] many thanks, imbrandon [01:06] np [01:06] <_mup_> Bug #992329 was filed: Ensure Invoker.start is called from UnitRelationLifecycle usage. < https://launchpad.net/bugs/992329 > [01:06] thanks to marcoceppi, too. [01:08] btw , the internet meme applies IANAL :) [01:08] adam_g, lp:~jimbaker/juju/unit-rel-lifecycle-start-invoker now contains the fix (this also adds unit testing of the fix vs the debug version i pointed to you earlier, otherwise should be about identical) [01:08] ( i am not a lawyer ) [01:08] chefnewbie: ^^ [01:09] (the only other change was to make it slightly more verbose on logging the caching of the relation hook contexts) [01:09] yeah, layers make big bucks for good reason :-) [01:09] yup yup , just wanted to make sure, when it comes down to it , get real advice, but thats the general gist of it [01:10] yeah, just get a ballpark of what I should pay attention to when thinking of choosing a technology for our small shop... [01:11] yup, you should be perfectly fine imho [01:11] will ask 201 questions once I get another depth of understanding... [01:11] :) [01:11] after that, layers get consulting checks :-) [01:12] heh [01:12] thanks again, you have a good dinner time... [01:12] most of the time you can get clarification on the fsf site as they have spelled out 99% of common cases as lawyers [01:12] but if not you know :) [01:37] <_mup_> juju/unit-rel-lifecycle-start-invoker r534 committed by jim.baker@canonical.com [01:37] <_mup_> Fixed tests that saw augmented log changes [04:39] imbrandon: git is great, but the charm store lives in launchpad. can you push to a launchpad branch please? [05:32] SpamapS: sure but jcastro told me to force yall yo learn the other workflow since its documented that github is a valid src too [05:32] but yea in the intrest of time right now i will :) [06:03] who? [06:03] who decided that? [06:03] imbrandon: I'm supportive of those who would shun git [06:03] but we have a distribution built on bzr [06:03] err [06:03] I'm supportive of those who would *use* git [06:04] Until Launchpad supports git, or the charm store supports pulling from github, new charms for the official charm store need to be on launchpad [06:04] imbrandon: where is it documented btw? [06:06] imbrandon: also btw, the AGPL's only difference from GPL is that *if* the service has a method for downloading the source over any network ports it opens, you cannot disable it. [06:06] juju has no such method [06:06] so it is effectively GPLv3 [06:07] SpamapS: https://juju.ubuntu.com/Charms [06:07] in answer to your github question [06:09] yeah, thats confusing [06:09] since we've never discussed that as a group [06:09] nor have I ever looked at the github pull requests to see if there are new charms there [06:10] :) [06:10] nathwill: thanks tho [06:10] fer sure. [06:11] SpamapS: iirc m_3 is writing some glue so LP wont need to support git [06:11] for the cs [06:11] using bzr-git-ng [06:11] least thats how jcastro splained it to me [06:11] anyhow i pushed the latests newrelic-php to LP and fixed up the bug [06:12] its ready for your worst [06:12] i got some more commits for drupal before i'm happy but working on them now [06:12] just had to stop for a omg hiccup [06:12] awesome [06:12] but back at it , i am [06:13] It would be really awesome if somebody would actually tell *me* that so I don't feel like an idiot telling you something else. ;) [06:13] hahah np [06:13] i totaly understand [06:13] i think thats one reason he was like, yea do it that way, so we're forced to learn the workflow [06:13] like almost exact words :) [06:14] man [06:14] I hate that idea [06:14] lets have one workflow [06:14] choices lead to mistakes [06:14] heh [06:14] we're talking ppl that should be devs [06:14] its already new and crazy and weird enough to be writing charms.. to have 2 workflows to choose from and maintain and monitor... ugh [06:15] dont cut the wheels off, it should be embraced or your gonna see alot more of like what i put in the comments [06:15] Its an efficiency blunder [06:15] Debian has that ethos [06:15] nah [06:15] "choice is the almighty" [06:15] just make the tools work [06:15] like the glue to import from github :) [06:15] And while I'm proud to wear my new Debian Developer badge (granted this weekend) I hate that part about Debian. Just pick one way and get stuff done. [06:15] see i like the midground [06:15] not too man but dont cut my fingers off [06:16] many* [06:16] If its as superior as people seem to think.. [06:16] then it will win out with users anyway [06:16] it has [06:16] thst the problem :) [06:16] But it *has* to be on launchpad. [06:16] oh snap [06:16] *has to be* [06:17] your statements just contradictoed [06:17] themselfs [06:17] SpamapS, doesn't launchpad already have mechanisms for registering upstreams and importing from various VCS systems? [06:17] automagically? [06:17] Unless you know of another system which groups many branches by series and allows bug tracking across those branches (i.e., packages in distro, and charms in our case) [06:17] nathwill: yea for projects nothing else [06:17] hrm [06:17] bet that functionality could be leveraged pretty easily [06:17] nathwill: yes, launchpad can import from github [06:17] we can do that [06:18] But we lose linked branches [06:18] and linked merge proposals [06:18] SpamapS: the way your doing it in LP , github, the unicorn you describe no where without hacks like NEEDING /precise in my url or branch names for that matter like /trunk [06:18] :) [06:20] imho its LP thats broke tho not the cs or github, it should be easy to support both [06:20] i see your grip as its not now [06:20] but thats the problem , not that users wanna use something else [06:20] OpenStack has proved that you can successfully have LP for bugs and git for all else. [06:21] ok then let us do it [06:21] But, thats at the project level. We're building a distro with potentially thousands of branches. [06:21] exxactly a LP peroblem [06:21] SpamapS: whats 1k;s of branches got to do with it, branches are cheap [06:21] imbrandon: the management of them, is not. [06:22] SpamapS: ah, i see what you're saying about losing merge proposals/links [06:22] the management of them is automated either way or should be [06:22] no, bugs cannot be automated [06:22] else we'd have entered the singularity and be fighting off skeletal robots [06:22] and also why can i not link a branch to my repo on github, that should be renamed to something else reflicting that it only works with bzr and LP hosted code [06:23] I'm honestly ignorant of any other bug system that allows bug tracking across concerns the way LP does. [06:23] SpamapS: bah, this is better high bandwidth, but i promis you it all comes down to LP "bugs" [06:23] * nathwill nods i think it's a killer feature [06:24] SpamapS: inho that a useability nightmre and should be removed with fire [06:24] were it me, I'd suggest that people just use the git-bzr thing that just pushes into a bzr branch but does git locally. Is that too hard? [06:24] yes [06:25] make 10000000 ppl change or fix the tool ? hrm [06:25] imbrandon: so, just list out the packages that a bug affects in the comments, or have 10 bugs that duplicate the same error and how it affects each package? [06:25] or fix lp to relate to github bugs and branches as well [06:25] or twoway mirror git [06:25] or both [06:26] linking to an external bug tracker is not really what I"m talking about [06:27] it accomplishes the same thing by linking bugs, we handel it all the time in drupal issue tracking, diffrent upstreams, projects, codepbases but some the same [06:27] etc [06:27] I'm saying, when we change charm store policy to not allow anything to have default passwords, we should have *one* bug to track all 20 charms that have violated it across the 2 series we have. [06:27] yea its not the one ring but still works great [06:27] If all the charms are on github, we can just paste links to the fixed branches, thats not even that much of a concern. [06:28] huh ? still a bug in LP if you NEED that function and it only support LP 1 of 2 things are gonna happen, users will NOT use LP to track bugs at all and you fail or whole projects will not use the cs and you fail [06:29] either way as much as we want it to be it CANNOT be absolutely tied to LP or any ONE place [06:29] even github [06:29] so to fix it, we make LP the easiest way, and supopiort the other ways without hacks [06:29] err [06:30] somehow ubuntu succeeds where this will fail? [06:30] ubuntu did only because it already had critical mass [06:30] it took years [06:30] and juju dont have that mass [06:30] I come at it from a different angle [06:31] The tools are of some slight concern [06:31] that maas [06:31] but as long as I know *how* to contribute [06:31] I don't care that its not my favorite method [06:31] If there are 49 islands out there with charms on them [06:31] how do I pick one? [06:31] paradox of choice [06:31] i come at it from sf.net has been THE place for floss since it came out in 96ish, github toppled them in one year, ONE , the best way to fight that is not with force but embrace it and make your shit better [06:32] if they are forced to choose they WILL choose github [06:32] So, VCS is all on LP, or its all somewhere else. [06:32] and make their own [06:32] why [06:32] why not support both [06:32] github is great, but this is still different [06:32] in fact [06:32] vcs is distributed for a rewason [06:32] it shoud not matter where it is [06:33] the fracturing that github encourages which is why its so awesome for rapid dev of new things, is a detriment to the integration that we need w/ charms [06:33] imbrandon, i don't think developers choose to get involved with a project because of the vcs it uses... but because they like the project [06:33] no [06:33] omg no [06:33] nathwill: your right but they choose to contrib to it or not based on that [06:33] and the frequency of their conriubs [06:34] SpamapS: your missing my point entirely tho [06:34] and its hard for me on irc to articulate it [06:35] imbrandon: the strong tie between the charms in each release is there for a reason. Throwing the charms' VCS out to the wolves means having to use some other meta-storage to bind them together to create a cohesive release. [06:35] and now i'm irritated cuz i know via other convos we've had you would agree if i can figure out how to put it [06:35] SpamapS: thats an infrastructure problem for the store, should not be a user issue in any way [06:35] transparent [06:36] well realistically the juju team seems to think thats important too, but I think they're going to run into the wall because VCS matters and they're halfway to a new VCS already [06:38] SpamapS: see t5hough i'm of the firm thinking that "plan and do how it should be, if the tools, and that means ANYTHING from asm code on up to the keys on my remote to the tv dont supoort that, then fix it or change it, no compromise because of tools" [06:39] in this case LP dont support git or remote bug association and a few other key things that wouold make all this moot [06:39] Yeah, and my plan is, have the same VCS for all charms, bind them together in a single place, and track bugs in a single place. [06:39] note, bzr, lp, not mentioned [06:39] SpamapS: hehe [06:39] sure tho [06:39] and i fully suport that [06:39] but then drop down on step [06:40] thats at the store level no one else care [06:40] mmm skeletal robots [06:40] so at the next meta step down in distrib vcs [06:40] they are all over the place [06:40] dvcs is fine [06:40] so make some glue to brong em togtaher and your both happy [06:40] but the *official* charms need a single place to tie them together [06:40] there needs to be *a mainline* [06:40] they are in the storwe with a vcs [06:40] I know, git blasphemy [06:41] no [06:41] no [06:41] absolutely not [06:41] ok [06:41] every app in itunes is in one place [06:41] imbrandon: I don't have to make that glue. LP exists, and does this, now. [06:41] every dev has crap everywhere [06:41] SpamapS: LP is fucking broken if it wont support that then [06:41] and bzr is not limiting in any way other than politics. [06:41] there is no glue [06:42] bullshit [06:42] it fucked up the omg merges 3 or 4 times last month where git worked perfect [06:42] this is editor wars. ;) [06:42] imbrandon: perhaps because it was git users trying to use bzr the wrong way? :) [06:43] ok look, itunes, apps all in one place, all reviews by apple, all done in diffrent palces [06:43] why do i care that apple wants to keep them all in an NFS share on win3.1 [06:43] i dont [06:43] and perhaps that is enough of a reason to step back and say "git users:bzr users seems to be about 1000:1, so perhaps we should use git" [06:43] once they take it to review i dont care at all [06:43] that dont fix tthe probme [06:43] gaqd i hate irc [06:44] imbrandon: app store apps are not integrated with one another [06:44] it lets the issue get away [06:44] they are, in fact, an island unto themselves. [06:44] SpamapS: they certainly are [06:44] no [06:44] in store purchaes , receipts [06:44] all kinda intergrations [06:44] but that dont matter either [06:44] wtf [06:44] ugh [06:45] you totally side steped it [06:45] Its pretty rare, right? [06:45] Like, *every* charm that is worth anything will have multiple integration points/interfaces which need to be tested as working on each target release of Ubuntu. [06:45] it dont matter , why do i as an apple dev care what the hell apple does with my app once its in their store, awnser is i dont , so why should i be forced to care about the charm store ? [06:46] Because you need your charm to work w/ mysql/memcached/etc. [06:46] it can sorrte my stuff in sabdfl's pinto i dont care, but you make me care if i need to load up the pinto [06:46] hplly shit [06:46] SpamapS: [06:46] common man [06:46] i'm not even on that subject [06:46] that has to do with zk and juju when running [06:46] wtf does it have to do with the store [06:46] then the vcs the store uses [06:47] well if that subject is off the table, and we are not going to care about integration, then yes, we can make all the branches live wherever we want and just punt this to a text file that maps charm namespace <-> branch URL [06:47] of course [06:47] there's no trust relationship with those URLs [06:47] umm thats how it shouldbe , maybe a db ya know ,21k centry and all [06:47] ~charmers is a trusted party, like ubuntu-core-dev [06:48] and ? [06:48] so right now we own all the branches and review all changes made to them [06:48] your bikesheding , it dont matter because the cs dont work directly off ~charmers it still needs to be pulled into the store repo [06:48] or at minimum into the charmers repo [06:48] on approval [06:49] cs *does* in fact work directly off ~charmers (well, lp:charms, same diff as its owned by ~charmers) for cs:series/charmname [06:49] that is done by hand as well as trust verify [06:49] ok my point still stands sans the first part [06:49] ( and wow really? ewwww ) [06:50] Ok, so we can make that work w/o LP and bzr too, as we can have automated pulls that we review from all the branch URLs [06:50] or we could fix LPO to do it too [06:50] and everyone benefits [06:50] imbrandon: cs:~user/series/charmname can be any LP user [06:50] SpamapS: i know but that dont mean the cs [06:50] well whatever [06:51] thats just routing like in a django app [06:51] could be anything [06:51] semantics [06:51] so, my point is still that this glue you speak of, that I acknowledge can be used and written, is not written, and does not exist [06:51] brew install jujutools/juju is the same as ~/jujutools/Forumla/juju.rb tooo [06:52] and furthermore, the process, while not super desirable, is single threaded and easy to follow right now [06:52] for that matter, its all routing [06:52] so until the glue exists [06:52] SpamapS: yes but then it needs to be , we shouldent do something the wrong way because of it [06:52] I do not want to pollute the contribution process, as flawed as it may be, with more VCS's [06:52] so until it exists it should be manual [06:54] there is already some work inside juju to hide these details as well [06:54] right [06:54] as it should [06:54] there should be a 'juju publish' command that will push your local charm up to the charmstore w/o you caring about LP [06:54] cool but how would it verify me then [06:54] (but this gets into where now they are playing a weird game w/ VCS because of that revision file..) [06:54] oh wait [06:55] imbrandon: same way LP does, ssh key [06:55] i would have to care and put a ssh key [06:55] :) [06:55] or perhaps OAuth [06:55] imbrandon, you do for github as well... [06:55] nathwill: sure but i care for github [06:55] :) [06:55] i was playing devils advocate as in yes charmers will still need to care and strust lp [06:56] but users wont [06:56] but thats minor [06:56] users are implicitly trusting ~charmers if they deploy charms unqualified w/ username [06:56] jup [06:56] sure [06:56]