[01:18] I have software license question regarding charms [01:19] Do charms automatically inherit the AGPL license by calling Juju services? [01:20] Use case 1: I write a charm from scratch [01:21] Use case 2: I write a charm that requires a relation to a charm that has an AGPL license [01:24] roy-feldman: charms can be any license, though if it's to be in the charm store it needs to have an approved OSI Open license [01:25] thanks [01:26] roy-feldman: https://juju.ubuntu.com/Charms#Charm_Inclusion_Policy_for_Reviewers those are the criteria for inclusion [01:27] The issue came up at Crowbar presentation I just attended. [01:29] Do you know if adding a relation to a GPL or AGPL licensed charm trigger the copyleft clause? [01:29] IANAL, but I don't think AGPL's service clause applies in charm relations since technically charms are communicating with the juju bootstrap and not directly to each charm, but not being a lawyer [01:30] That make two of us ;-) [01:30] Thanks Marco [01:30] juju add-relation causes the juju-agent to ping each service individually, and their response is reported to the juju-agent which then passes the information to the other charm and the cycle continues [01:31] Personally, I will publish my charms with a OSI license, but when I talk to business people the issue inevitable comes up [01:31] right, I would check with SpamapS or one of the juju core devs, they are more knowledgeable on things of this nature [01:32] I believe it was designed in a way that mixing charms with different licenses wouldn't be an issue [01:32] Music to my ears [01:33] I am talking to people who are pushing Crowbar, which is comparable to Juju + MaaS [01:34] They jumped on the issue that Juju was AGPL, so I was put on the "backfoot." [01:36] Short of consulting a lawyer, can you suggest a way to confirm the licensing status of Juju charms? [01:36] Talk to one of the devs, they're all asleep now [01:37] Any suggestions as to which ones? [01:38] jcastro, negronjl? [01:39] SpamapS is knowledgeable with license stuff [01:45] Thanks again [01:45] Ciao [02:49] charms are any license [02:49] juju is agpl [02:50] charms are effectively input outputs to it [02:50] their is no linking [02:50] in this context, there is little point to it being agpl.. its effectively gpl [02:50] hmm.. two charms communicating [02:51] its not really linking by any common definition.. its basically each charm writing its own file and reading different files. [02:52] yea i think of it as each charm is calling anothers public api [02:52] in that case its not bound by agpl etc [02:53] http://www.gnu.org/licenses/gpl-faq.html#GPLOutput [02:53] that's exactly on point to this topic [02:55] well the agpl triggers on offering a network service to users [02:55] in this case its the same user deploying the different charms.. [02:56] hazmat / SpamapS : you know how --placement was taken but you can still use palcement: local etc etc etc , i was thinking about that , what if ( not littraly ) but as far as juju is concerned the bootstrapped zk node is a charm too so things could become a subordiate of it, like say a 3rd party api or webui or whatever [02:58] maybe show up as the juju-info interface [02:58] or i dunno , not real well thought out yet [03:51] imbrandon: thats the eventual plan.. to make "juju" a charm that is no different than the others, except it is deployed without ZK [03:58] woot, juju SRU accepted === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [10:40] hi guys, trying to use juju on quantal I encountered an issue where the /var/log/syslog says 'zookeeper respawning too fast, stopped' [10:40] does that ring any bell ? [10:41] note that I arrived there because after 'juju bootstrap', 'juju status' couldn't connect to my instance (whereas it succeeded in the same environment with a precise image) === chuck__ is now known as zul [12:51] vila: that would indicate that zookeeper keeps crashing [12:51] please can you look in /var/log/zookeeper and see if there are any interesting error messages [12:51] jamespage: yup, but if I then connect via ssh , I can 'service start zookeeper' [12:52] jamespage: before I start it manually, there is *no* log file there [12:52] had anyone faced issue with juju creating massive log [12:52] vila, you can try but that message comes from upstart trying to restart it [12:52] like in few GB [12:52] koolhead11, I think there is a SRU in progress for that [12:53] koolhead11, https://bugs.launchpad.net/juju/+bug/958312 [12:53] <_mup_> Bug #958312: Change zk logging configuration < https://launchpad.net/bugs/958312 > [12:53] ooh cool. so i am not the only one who hit this bug. cool [12:53] jamespage: awesome. [12:53] koolhead11, you could verify the fix in -propose if you like [12:53] jamespage: i will do that coming week :) [12:53] vila: does it start OK when you do it by hand? [12:53] jamespage: I scp'ed the log files after a juju bootstrap, install went well AFAICS [12:54] or can do right away :) [12:54] jamespage: 'by hand' == ? (I have always use juju so far ;) [12:54] gah - I have to duck out for a bit - vila - I'll be back in about 1.5 hours if you can wait... [12:54] jamespage: sure, ping me then [12:55] jamespage: i was looking for you last week [12:55] trying to get hadoop working, ended up using source from there website [13:39] niemeyer: ah excellent. So much activity that we need another list. mwahaha. [13:39] and second project :) [13:54] jcastro: Well, the list wasn't really based on activity [13:54] jcastro: The project was [13:54] jcastro: The list is a division of topics for real [13:54] * jcastro nods [13:54] jcastro: Most people interested in using juju would be extremely bored with the topics we've been debating around the port [16:14] SpamapS: so I just saw mhall119's django generating charm [16:14] thing [16:14] 'morning [16:14] it's basically awesome. [16:21] sweet [16:21] wait, mhall did that? [16:21] I thought somebody else did one [16:21] yea there are like 3, but mhall119 is the best so far imho [16:24] * mhall119 will do a writeup on it [16:25] first I need to change it's name [16:25] and create an LP project [16:36] mhall119: its that big? [16:36] mhall119: would you consider folding it into charm-tools? [16:37] SpamapS: it adds on to Django [16:37] like, it's a django app you have to add to your project [16:38] SpamapS: reminder ping on cloudopen CFP [16:39] jcastro: I submitted to cloudopen 2 days ago [16:39] jcastro: what I'm not sure about is the AWS conference [16:39] <3 [16:39] mhall119: can you take me through the workflow? [16:40] SpamapS: sure [16:40] first, you get the code: https://launchpad.net/naguine [16:41] it's a django app, you can either branch it locally into your Django project directory, or (when I build it) install it system-wide as a package [16:41] then, in your django project, you run "python manage.py charm --settings naguine" [16:41] and it spits out your new charm into ./charms/precise// [16:43] then you check it for missing dependencies, and add any custom actions you need to install, and also anything custom to do on db-relation-changed [16:44] sounds perfect for charm tools :) [16:45] charm create django ./myapp ? [16:46] :) [16:47] i bet i could wrangle a php version of the same thing to spit out a skeleton symphony2 php-app , could be the basis for some of those defaults we talked about , in any case i do think mhall119's would make a great addition to charm-tools [16:48] using composer.phar to do the dependancy stuff [16:49] mhall119: yeah, this should be in charm tools unless you are just against giving up control of it to the whole of ~charmers [16:50] mhall119: basically 'charm create --django yourapp' [16:50] mhall119: I'm worried about exploding the ecosystem with many many projects and names and such, so if you'd consider moving it into charm-tools.. I'd consider giving you a gold star sticker. ;) [16:50] quick question: is there a drupal charm for precise? it seems like work was started them stopped [16:50] +1 charm tools [16:50] *then [16:50] shazzner: poke imbrandon [16:51] mhall119: the cake is a like i dident get the last gold sticker [16:51] shazzner: he's been sitting on my review comments for about a month :) [16:51] shazzner: i'm on it, actually i was gettting raely to upload it today [16:51] ok cool :) [16:51] if you contribute [16:51] to charm tools [16:51] you will have cake [16:51] SpamapS: cuz i went to 7 [16:51] there is cake for drupal charmers [16:51] heh cake is a lie [16:52] I was thinking of creating a drupal theme sub-charm [16:52] shazzner: no, for real though , i'd welcome any help etc etc but i'm getting ready to push a big update to it later today, got a little busy post-uds [16:52] shazzner: perfect [16:52] we'll see I don't know I've been slacking [16:53] imbrandon: cool :) [16:53] shazzner: i can show you the interfaces, its made to accept themes and plugins from a seperate charm [16:53] imbrandon: the 6 one was *SO* close [16:53] imbrandon: awesome, probably just point me to the lp directory [16:53] SpamapS: i finisied it too [16:53] so where is it? [16:54] github till i get em both done [16:54] :) [16:54] [16:54] haha [16:54] * SpamapS goes back to bug traiage [16:54] heh [16:55] shazzner: just watch the ~drupal namespace, i renamed the druapal 6 one to cs:precise/drupal6 and the 7 one will be the drupal one [16:55] SpamapS: marcoceppi: I'd be happy to get it into charm-tools if you guys can help me [16:55] should be pushed here in just a few hours max, likely sooner [16:55] imbrandon: ok awesome [16:55] the problem is that it needs to be run by django, using the same environment as django [16:55] thanks for the quick reply :) [16:55] which often means inside a virtualenv somewhere [16:56] np, email me anytime if i'm not on irc [16:56] <-- @ubutnu.com [16:56] bah, but spelled right [16:58] shazzner: btw if your sub charm looks for a webroot interface on the local container relation that will give you the base drupal install [16:58] so you can dump things in say webroot/sites/all/{themes,libraries,modules/contrib,modules/custom} [16:58] etc [16:59] * shazzner writing this all down === shazzner is now known as shazzner_otl [17:01] mhall119: thats no problem I think [17:02] mhall119: We can make 'charm create' do anything to bootstrap the point where you pull in your django app and run the necessary bits to spit out the charm. [17:02] We should perhaps do the same thing with rails in parallel so we abstract at the right level [17:09] SpamapS: good idea [17:12] like maybe it should be '--framework django --app /path/to/my/django/app' [17:13] and then we can have an alias for that which is 'charm create-django /path/to/my/django/app' [17:13] you'll want an optional --python /path/to/executable/for/python [17:13] charm create webapp --framework djgano ..... [17:13] mhall119: perhaps there should be a bootstrap.sh or virtualenv.sh in the dir that is automatically run ? [17:14] mhall119: seems like there should be a convention for that [17:14] most likely they will already have a local environment setup [17:15] with php there is composer.phar that is run from the dir that has packages.json to do the same type of thing [17:15] all the webapp frameworks and languages are so different, do we gain much by trying to make a single "webapp" target? [17:16] sure, i think thats what makes it perfect for abstration [17:17] take the hard bits and make it all uniform , i mean we're mostly talking about spitting out skeletons anyhow [17:17] for someone to build on, not complete apps [17:18] Pylons RoR Django Symphony2 ZF2 Drupal Wordpress ... etc [17:18] pretty complete skeletons in my case [17:18] mhall119: they have different mechanics, but they all have the same concepts which can lead to a rich charm. settings, dependencies, etc. [17:19] mhall119: :) [17:19] mhall119: you don't need to worry about that though. I'm just suggesting that we should abstract properly so nobody has to duplicate the same process when we add rails, symfony, etc. etc. [17:20] right well, if somebody is going to take on this task, I'll help make the Django part work, but it's more than I'm going to be able to do myself [17:20] mhall119: there is huge value for a sysadmin to be able to take their process knowledge of charming one type of app, and be able to map it to another framework entirely. HUGE value. [17:21] sysadmins will be doing this? not app developers [17:21] ? [17:22] devops [17:29] imbrandon: SpamapS: hey you guys wanna get together later on G+ to talk debian and RPMs? Or do you prefer to head down and skate? [17:31] i'm good either way [17:34] mhall119: well I'd hope that devs and ops would take equal responsibility [17:34] mhall119: so if the dev knows juju, she does it, and if the ops knows juju, she does it.. ;) [17:35] jcastro: I'm actually downloading a Debian iso so I can test juju + local provider right now [17:44] <_mup_> Bug #1007544 was filed: test suite assumes /etc/lsb-release will exist < https://launchpad.net/bugs/1007544 > === shazzner_otl is now known as shazzner [18:15] crap.. just realized.. local provider won't work on Debian [18:15] since its tied to uptstrat [18:16] upstart even [18:16] ok, so its EC2 only.. oh well === koolhead17 is now known as koolhead17|afk [18:17] whats tied to upstart ? cloud-init ? [18:17] everything ;) [18:17] machine agent [18:17] provider agent [18:17] unit agaents [18:17] upstarts packaged for debian isnt it ? [18:20] sort of [18:20] its not really usable [18:20] nor is it allowed for packages to embed .upstart files along side .init files [18:20] pretty much useless [18:21] well we don't have it in packages [18:21] we generate them and drop them on disk during initialization [18:21] as long as we have cloud-init we can parameterize the startup stuff as needed [18:21] oh.. local provider.. [18:22] SpamapS, is cloudinit in debian? [18:22] yeah.. same principle there.. what's the default/recommended init sys for deb? [18:22] interesting.. [18:22] debian has invalid certs [18:22] hazmat: its going into debian, at some point soon [18:22] are they going down the sysd, or are they still doing the old sysv jaunx [18:23] debian is going down the path of most insanity IMO [18:23] "we'll have ALL init daemons" [18:23] choose your own adventure, if you will [18:23] SpamapS, but packages can't support more than one init sys? [18:23] hazmat: that policy is about to change [18:24] hazmat: steve langasek has been working on it for some time, and I've been promising to help him at some point too ;) [18:25] huh [18:25] erc is being weird [18:27] damn, txaws bug [18:27] this seems a bit evil [18:28] it defaults to reading *.pem from the cwd [18:28] with no warning [18:28] like "you are running from a dir owned not by you... you may be trusting an evil .pem" [18:29] ok well juju in Debian works fine for EC2 [18:29] * SpamapS uploads [18:33] SpamapS, the new txaws in trunk.. is a bit borked imo [18:33] hazmat: whats broken? [18:34] its basically throwing deprecation warnings on its own internal usage.. so if you use the only available std api, you can get hit with deprecation warnings with no recourse to fix [18:34] hazmat: half-done transition? [18:35] SpamapS, appears so.. i haven't really dug into it.. outside to identify the rev.... 147 afaicr [18:35] * hazmat disappears in a puff of busy === shazzner` is now known as shazzner === izdubar is now known as MarkDude [22:11] SpamapS: marcoceppi: if you guys are interested http://mhall119.com/2012/06/charming-django-with-naguine/ [22:11] mhall119: nice [22:12] * SpamapS skims.. likes.. reads more [22:16] * SpamapS fixes last lintian warning in juju package and hopefully does one final sbuild [22:18] mhall119, sounds like the making of a good generic django charm ;-) [22:20] hazmat: nope [22:20] I was very intentionally not making a generic charm [22:21] mhall119, i remember, just teasing [22:21] ah :) [22:22] jcastro, what do you use for doing screencasts? [22:22] recordmydesktop [22:23] hazmat: http://askubuntu.com/a/4433/235 [22:23] jcastro, danke [22:24] Alright, juju 0.5+bzr539 uploaded to Debian [22:24] \o/ [22:24] will sit in NEW queue for probably a week [22:24] HEY .. juju users.. there's a juju version in precise-proposed [22:24] PLEASE TEST [22:24] SpamapS, did you test it? ;-) [22:25] hazmat: extensively actually [22:25] hazmat: local does not work, but ec2 does [22:25] SpamapS, awesome.. i think i hit a regression somewhere [22:25] hazmat: local could be made to work if we rip out the upstart bits [22:25] SpamapS, upstart bits? [22:25] yes, the machine agent running on bootstrap [22:25] SpamapS, or just finish the upstartification ? [22:26] SpamapS, got a minute for a g+? [22:26] If we want local to work on non-Ubuntu platforms, we're going to have to abstract upstart completely [22:26] hazmat: cerrtainly [22:27] SpamapS, jcastro invites out [22:37] mhall119: nice! [22:56] hazmat: FYI, the proposed source bootstraps ok. Deploying stuff now [23:14] done for the day ... enjoy your weekend everyone. [23:20] SpamapS, hmm.. cool [23:21] negronjl, have a good one [23:26] hazmat: ahh, local provider is broken [23:29] elif [ $JUJU_ORIGIN = "proposed"]; then [23:29] missing a space [23:29] * SpamapS wonders if shell code even cares that it just made him curse [23:30] shell code don't care. shell code don't give a F*** [23:34] <_mup_> Bug #1007657 was filed: proposed origin does not work with local provider < https://launchpad.net/bugs/1007657 > [23:46] alright, brain officially melted.. will have to solve that on Monday