[00:08] guys I get ` charm not found in repository` when deploying [00:08] I have correct folder tree (repo/oneiric/charm-name) and no syntax error in config.yaml or metadata.yaml [00:47] <_mup_> juju/local-cloud-img r487 committed by kapil.thangavelu@canonical.com [00:47] <_mup_> merge trunk [01:54] <_mup_> juju/local-cloud-img r488 committed by kapil.thangavelu@canonical.com [01:54] <_mup_> wip, scope is starting to feel to large on this one, leaving off === nijaba_ is now known as nijaba [16:02] Anyway to change the verbosity of the juju commands? IE If I want to get rid of the INFO messages on the client side? [16:04] marcoceppi: yes debug-log allows a level to be passed [16:05] marcoceppi: -l {DEBUG,INFO,ERROR,WARNING,CRITICAL}, --level {DEBUG,INFO,ERROR,WARNING,CRITICAL} [16:05] Log level to show [16:05] those are in the wrong order I think [16:05] I think CRITICAL should be between INFO and ERROR [16:07] hm no ... [16:07] should be DEBUG,INFO,WARNING,ERROR,CRITICAL [16:07] * SpamapS opens low bug w/ patch attached [16:09] Doesn't seem to wsork [16:09] juju status --level=WARNING [16:10] oh [16:10] that level of logging [16:10] yeah [16:10] marcoceppi: that -l has to go *before* the subcommand [16:11] SpamapS: Ah! Gotchya [16:11] Excellent, thanks [16:11] I believe that is going to be changed in the go version.. kind of annoying the way that works [16:31] imbrandon: I did know that nginx speaks other protocols... I'm not sure it warrants its own singular primary charm.. but definitely as a subordinate it will be a swiss army knife of fun. :) [16:35] <_mup_> Bug #964640 was filed: debug-log online help needs some minor tweaks < https://launchpad.net/bugs/964640 > [16:43] SpamapS: well i was thinking a Nginx charm with examples like you said in sites-available [16:44] but also a "sane" rockstar defaults too [16:44] for normal web serving [16:44] somthing that like omg-wp or others could depend on like the provies: db: mysql kinda thing and then build on [16:45] but also have some kick ass examples in the sites avail for those that use it alone [16:54] marcoceppi, logging options for the client, are just -v before the subcommand [17:01] imbrandon: right. All of that is good in the subordinate sense.. but nginx alone on its own host is only useful for specific uses like as a super high volume loadbalancer. [17:05] nah. its quickly becoming the goto webserver, i think another year and it will have a good 15% of the market [17:06] even for mom and pop shops that overoptimize [17:06] imbrandon: but what use is a static webserver with no way to get files onto it? [17:06] imbrandon: it will always be paired with something else [17:06] i mean yea me and you know its overkill but tell johny he dont need a farri when the farri is the same cost as the pento [17:06] ;) [17:07] sure we use it with php-fpm now [17:07] even for omg [17:07] i guess i'm missing someething or assume something your not [17:07] imbrandon: charms define all the things that go onto a server right now [17:08] when i said an nginx applince i mean a general suped up server charm - the db [17:08] imbrandon: when subordinates land, it will be easier to componentize things like nginx in a generic way. [17:08] well yea , i'm thinking ahead, and using the provides db mysql think as a platform in my head [17:09] thinking that drupal or wp can site onyop of a nginx provide and a mysql provide [17:09] and reallly cant that be done now, i mean there is an example i thought with like something that was using a ton of provides and then just did a relation on them all at the end [17:10] were they all on single instances ? i dident look close [17:10] imbrandon: 1 charm, 1 instance [17:10] ouch ok , yea i dident have that part in my head [17:10] ouch ouch [17:11] imbrandon: subordinates let you define special charms that will relate to services via the filesystem or 127.0.0.1 ... [17:11] anything i can do to put my code where my mouth is and help the [17:11] compartmentalizing up [17:11] or what you called it [17:11] imbrandon: so in that case, we can make every PHP app a subordinate to nginx, or lighttpd, or whatever, and just have them always run php5-fpm [17:11] right [17:11] yea [17:12] imbrandon: not really. The branches are in review and landing in trunk. Once that lands, you can write the nginx charm. :) [17:12] i like that idea, even better if it lets you overlay like somehinh along the lines of say [17:12] casperfs [17:12] i mean not litterly but thats the idea in my brain [17:13] a filesystem overlay of charm ontop of chamr [17:13] imbrandon: well they all just get extracted and run inside a single instance.. not sure where overlays would come in. [17:13] charm* so like a base nginx with and then a fcgi or fpm php and then a drupal but the drupal sets fpm settings "overlayed" etcv [17:14] instead of conflicts like the dpkg system [17:14] so drupal can come with a specialized php.ini [17:14] that overides the php-fpm php.ini charm [17:14] intentionaly [17:14] but in an overlayed type way [17:15] imbrandon: Ahh I see now [17:15] make any more sense, its like a brain puke i'm having here so some of its by the seat of my pants just learning charms are one per instance atm [17:16] imbrandon: I think we can make that work with just charm store policy on how files get written by subordinates [17:16] so not well thought out but still i think something along those lines is better than say a conflicts system [17:16] <_mup_> Bug #964658 was filed: juju crashes when talking to MAAS without an explicit port < https://launchpad.net/bugs/964658 > [17:17] right, the hard(er) part is what happens if the drupal is replaced by wordpress, but i guss in that case its just re-deploy [17:17] imbrandon: its more like Replaces in dpkg terms.. "let me overwrite that charm's files" [17:17] and ont worry about restoring back to php and overlay somehting new [17:17] yea [17:17] imbrandon: yeah, the beauty of the cloud.. if you want to repurpose.. you just spin up new ones. :) [17:18] yea like replaces, but i say overlay that way it can inderit defaults from the parent package even if that package normaly wouldnt support it [17:18] juju crew, do you have a team preference for Python editor or IDE? [17:19] ninjix: I know hazmat uses emacs [17:19] I prefer vim [17:19] like php.ini is a bad example because it lets you only specify some settingswing natively [17:19] but say ummm cant come up with a good example atm [17:19] lol [17:19] is there a any coding style? PEP8 etc? [17:20] ninjix, emacs and vim are most common among the dev team, although i've been playing with sublime.. specifically for python.. pycharm or wingide are two commercial well done python ides [17:20] imbrandon: there's also dotdee.. which lets you regenerate a config whenever files in a .d dir change [17:20] * imbrandon uses Zend Studio + Espresso.app + nano ( but my charms are in bash or php heh ) [17:20] I haven't seen a php charm yet, mostly bash/dash and Python [17:20] ninjix: pep8 yes [17:20] and vim-full when nessesary, but tryies to avoid it [17:20] I started writing one [17:20] marcoceppi: mediawiki has a hook in php :) [17:20] I'm starting in on a Proxmox provider [17:21] any debug env tips? [17:21] booya :D [17:21] marcoceppi: my drupal uber charm is in php [17:21] made it simpler to read the configs [17:21] yeah [17:21] bootsrapped in bash and majority of code is php [17:21] to do all the rest [17:21] ninjix, proxmox in what sense? [17:22] ninjix, as a local provider or controlling remote containers? [17:22] I want my juju instances to launch faster so I'm going to cut cobbler middle man out [17:22] gotcha [17:23] marcoceppi: basicly after apt-get install blah blah , then eveything else is in php, kinda half way intentional to be diffrent and since drupal sysadmins/users likely will know it more so than python [17:23] hazmat: remote proxmox qemu [17:23] ninjix: remind me again.. proxmox is a virtualization frontend, like libvirt or XenServer ? [17:23] ninjix, cool, there's a half implemented xen server provider as well.. but the nutshell is look at providers/common/base.py it basically defines the interface [17:23] imbrandon: yeah thats part of the reason juju just uses execs.. lets people write charms in whatever language they're comfortable in [17:24] SpamapS: proxmox is a virtualization env more along the lines of ESX [17:24] hazmat: there's one evil place in juju/unit/address.py where providers are ifelse'd [17:24] ninjix, here's a list of provider responsibilities, its a bit dated, we have constraints for machine/image selection now.. https://lists.ubuntu.com/archives/juju/2011-November/000906.html [17:24] SpamapS, yeah.. its a dispatch for provider specific logic [17:24] hazmat: thanks [17:25] hazmat: should be moved into the providers as a new method of MachineProvider [17:25] yea, its not rally the _best_ for cli apps, but its definately not unpresidented , using the pear Console class and Drush ( php drupal cli app ) the community is already familiar with and saves me alot of code [17:25] SpamapS, the things running that shouldn't have access to the provider [17:25] imbrandon: I wrote quite a few useful PHP cli apps at my former employer [17:26] sides release early realase often right, who knows maybe it will have some vb6 code before all said and done ;) [17:27] SpamapS, but yeah.. it could use for some restructuring to push/centralize that knowledge to the appropriate place [17:27] yea i have as well, most were / are just phing extenstions though :) [17:28] back in a bit [17:28] hazmat: ahh... wish I had the link last night... had to discover most of those behaviors and methods the hard way. :) [17:28] although, mostly its just a dictionary lookup based on provider type which is commonly known, its an additional responsibility that's not advertised very well [17:28] btw /waves , hi everyone else [17:28] hazmat: ultimately, IMO, it should only take a directory in juju/providers to recognize a provider.... [17:28] hazmat: they're so close to being plugins already :) [17:29] hazmat: just have to drop the hooks in juju/unit/address and juju/environment/config [17:32] so hows the namespace thing work with charms , first come first server ? are there plans to let remote charms be listed ( if anyone here is familiar with the "brew" and "tap" structure for OSS OS X apps is what i'm thinking, its like bsd ports and dpkg mixed up, but in a goood way ) [17:32] imbrandon: flat namespace just like packages. [17:32] hrm kk [17:32] SpamapS, while its true we could make them pluggable, my attempts to get independently distributed plugins into core have met with resistance [17:32] actually thats not entirelya ccurate.. [17:32] at least to the extent they relied on python specific mechanisms [17:33] imbrandon: local: and cs: are independent of one another.. [17:33] hazmat: hm.. I wonder why. :) [17:33] hazmat: heh i think thats what i'm asking about too in another way [17:33] any growth of the python version's capabilities means more for the go team to duplicate. I think its fair to resist non-essential extensions for that reason. [17:34] imbrandon: so your local:foo won't interfere with cs:foo [17:34] SpamapS: yea but what about dist, say i want something dist but not via the charm store [17:35] like akin to adding a source to apt.list ( obviosuly diff ) [17:35] so github:foo [17:35] or something [17:36] imbrandon: no, there's cs, and local, thats it [17:36] again alot of this is brain puking as i'm just now wrapping my head around alot of this , so if i'm being to bothersome tell me to stfu and rtfm :) [17:36] imbrandon, ninjix, at the moment, the best way to contribute a provider plugin is writing it in go.. but that won't be useful with 12.04. its not clear if we'd add any new pythons ones into 12.04.1 core if they didn't have go analogues. [17:36] imbrandon: of course, you can also have cs:~imbrandon/precise/foo [17:37] ahh gonna bake in lp like bzr did ? [17:37] imbrandon: its not LP actually, but yes [17:37] imbrandon: the charm store does pull from launchpad.. but it doesn't have to [17:37] cool [17:37] hazmat: no problem. I'm learning as I go here. Going to use the Orchestra provider as my starting template. [17:38] hrm i guess thats where the bit hazmat was talking about adding a provider [17:38] err wait [17:38] not really cuz thats a deployment target not [17:38] a source [17:38] hrm [17:39] ninjix, ugh.. the testing for that one is a bit gnarly [17:39] ninjix, i'd use the maas provider, its probably the simplest of the bunch [17:40] although its also the one with the least amount of real world usage. [17:40] so if it dont have to how do i specify cs:~imbrandon/precise/foo == github.com/bholtsclaw/charms/foo+branch_precise [17:40] i kknow there isnt now, but like is it planned or like a nono [17:41] and alot of it is just semantics as once the inital charm is downloaded then it can come from anywhere [17:41] i know that [17:42] okies, actually i got to run anyhow, thanks SpamapS and hazmat for entertaining my thoughts for a bit, i'll be back in hour or two to finish the drupal charm up today hopefully [17:43] and now i gotta come up with as uber name for it :) [17:43] s#as#a [17:44] hazmat: ok [17:45] SpamapS: btw dont you take weekends off ? hahaha j/k man [17:45] * imbrandon is out [17:48] I do [17:48] and I'm out too [17:48] :) === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away