[01:40] pdtpatrick: do you have at least two nodes ready in your maas? [02:43] jcastro: column80 ROCKS! dude, seriously. full stop [03:53] jcastro: your images are oversized :P [04:03] bkerensa: I bet you say that to all the community members... [04:03] ;) [04:03] heh [04:03] SpamapS: I didnt get to meet you at UDS.... Your like a ninja [04:03] ceph charm is basically totally rewritten and pointing at upstream "daily crack" repos now [04:04] bkerensa: I descended upon Oakland, and then poof! smoke bomb.. [04:06] SpamapS: I totaly intended to buy a MBA today at the apple store, but degressed and got an iPad3 [04:06] :) [04:07] i am however looking at ways to boot an andrioid kernel on it already ( its doable but a PITA and will likely wait until some of my more important projects are done ) [04:07] heh [04:08] imbrandon: haha [04:08] imbrandon: ipad3 is just a MBA w/o a keyboard and less CPU/RAM ;) [04:08] yea [04:08] well mostly the ram [04:08] cpu its pretty comparable [04:08] oh, and a crap OS ;) [04:08] a5x ( x 2 ) isnt a joke :) [04:09] No joke, but its no i7 [04:09] yea , the os isnt nice, well it IS nice, but not NICE [04:09] try running vms on that a5x :) [04:09] whoa you have a i7 in the mba ? [04:09] yeah :) [04:09] the ones i looked at today were i3 dual core [04:09] :( [04:09] hrm [04:09] Wait no I have i5 [04:10] that was actually a big factor , i5 quad ? [04:10] I forget now [04:10] been looking at getting an i7 desktop [04:10] cuz i "intend" to use this as my mobile machine 100% , with bluetooth keyboard [04:11] and sell the MBP and give the old crappy mb to someone in need [04:11] yeah whatever floats your mobile boat :) [04:11] hrm, i may head back tomarrow for another look, they are good about returns [04:12] well i want something ultra portable but 99% of the time is in ssh, even ios can do that [04:12] and the tablet formfactor is so nice [04:13] honestly if the asus transformers wernt so crippled ( even more than apple ) that would be perfect imho [04:13] or a ubuntu/andriod phone with laptop "dock" [04:13] but i think i'm ahead of the market a little bit on that one [04:14] anyhow, onto some "real" business [04:14] dude i've been looking into ways to get some "all the world php" coverage [04:14] its not looking pretty at all without a whole project unto its self [04:15] unless you have some ideas that i'm missing, i may have once again put my foot into mouth BUT the more i think about it the more i like the idea be it for 5.4 or just cuz [04:16] basicly i'm thinking it needs to be an extension of the php packing group in debian, because at minimium packing level knoledge of each project is needed to get even a smoke test , i *think* [04:17] not that it wouldent be a good thing, but a large under taking good thing [04:18] imbrandon: indeed, you will have a hard time figuring out the url of the exposed app [04:18] bbl [04:18] anyway, I'm out [04:18] oh and i did retest the debian pkg teams ppa, apc is now fixed [04:18] l8tr [04:22] SpamapS: ( i know your out, possibly retorical question for later as I know the policy but just wondering your thoughts ) what about a "semi official but totally unofficial" PPA for 12.04 that not only is the 5.4 upgrade but a parallel install of 5.4 in /usr/local/ ( yes a .deb no no ) or /opt ( another no no ) , apache/nginx/lighttpd all support multi php version installations [04:23] something along the lines of multi python's ( but not technicly the same obviously but policy wise ) [04:24] and even trying to put/push that into 12.10 since for the full life of 12.10 5.3 nd 5.4 will be supported [04:24] * imbrandon just needs to get back on the debian and ubuntu php mailing lists [04:30] >.< [04:34] sup bkerensa [04:34] nada just trying to find some packaging work ;P [04:35] bkerensa: juju charm or package package ? [04:35] imbrandon: debian package ;) [04:36] * bkerensa is perhaps submitting a patch for ia32-libs-multiarch atm [04:36] :D [04:36] bkerensa: wanna try something that i'm not even 100% sure is possible but if it is should be simple-ish , brew ( homebrew ) for Linux :) [04:37] it works , havent tested it all, but its just a little bit of ruby, mostly if anything needs patches for OS X assumed paths like /Library and /private/etc VS /etc [04:37] :) [04:37] i have it on my todo list but its WAY WAY down at the bottom [04:38] i'm thinking that I can do automated testing for the OS X "port" in Ubuntu once its available [04:44] bkerensa: if you are feeling froggy here is the installer script for OS X to give you an idea, i've never done any Ruby packaging myself so no idea on the policys https://github.com/mxcl/homebrew/blob/master/Library/Contributions/install_homebrew.rb [04:44] ;p [04:45] but at one point there was a linux port attempt and all patches are now in upstream code [04:45] so if any patches at all arte nneeded its minimal [04:46] imbrandon: https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/1000541 [04:46] >.< [04:46] <_mup_> Bug #1000541: ia32-libs-multiarch depends on gstreamer0.10-fluendo-mp3, causing problems when installing packages from partner

< https://launchpad.net/bugs/1000541 > [04:47] bkerensa: did you test that it works as intended without that dep ? if so i'll review/sponsor it here in a hour or two [04:48] well into Q i will, you'll need a bit more red tape after to get it into -updates [04:48] specificly [Regression potential] [04:48] Dropping the dependency might cause wine to FTBFS, contrary to Scott's assurances [04:50] imbrandon: yeah :) slangasek is in my loco [04:50] ;p [04:50] but the issue is building it [04:50] so I can test it [04:51] bkerensa: kk i'll look in a bit and lets take the rest to -motu chan as its more relevant there [04:51] kk [05:03] james_w, a client can have multiple rels of the same interface to a server just so as their named differently [05:04] hazmat, and presumably multiple rels of different interfaces [05:04] yup [05:04] cool, thanks [07:09] * SpamapS had an aha! moment on the way back home and is now almost done making a ceph charm that does not suck [07:10] btw we really need automatic leader election and a "service bucket" for things that need to be atomically consistent between all nodes of a peer relation [07:11] SpamapS, woot re ceph charm [07:11] SpamapS, doesn't charm helper have a leader election script? [07:11] hazmat: it will not work [07:11] and what do you mean by the latter? [07:11] we confirmed it [07:12] relation-list can sometimes *not* show the lowest member of a peer relationship [07:12] SpamapS, huh? [07:12] I think it happens if the lowest member is lagging and hasn't started yet [07:12] oh.. out of order joins [07:13] SpamapS, and on the service bucket? [07:13] right, so that was my only way of semi-atomically knowing enough to pick one place to run the bootstrap bits on [07:14] hazmat: ceph needs to pick a UUID for the filesystem... [07:14] hazmat: right now I have to just generate it on one box.. [07:14] hazmat: and then the other boxes have to know which box to expect it from.. based on a config item [07:16] hazmat: so a bucket that I can say something like config-set --if-empty fsid=`uuid` ;uuid=`config-get uuid` [07:16] hazmat: basically the same problem.. there are things that are just global to the service that are not human generated [07:17] SpamapS, so cluster wide atomic cas op [07:17] oops redundant [07:21] hazmat: CAS would be cool too.. but is slightly different as it implies a more stringent mode of operation. This is just "ADD" [07:22] hazmat: either one would solve the problem CEPH has. Actually, ceph is doing this upstream in their network protocol because their crowbar+chef solution needs it too. [07:22] hazmat: but I can see other complex storage solutions being hard to get right w/ the current peer relation scheme. [07:23] hazmat: having relation-* accept -r btw, has been really helpful [07:23] SpamapS, no doubt [07:24] * SpamapS realizes redshift wasn't working.. turns it on, and realizes he will probably fall asleep within 20 minutes now [07:25] hazmat: I'm getting around it now by having a config option to specify which unit ID to run the initialization on [07:26] hazmat: and the README just states.. wait until you have added all your initial ceph monitors.. and then run 'juju set ceph-service initializing-unit=ceph-service/0' [07:27] hazmat: its a one time thing, once it has run, the service can manage its own quorums and memberships [07:30] hazmat: there seems to be a bug with upgrade-charm too.. [07:30] services: [07:30] ceph-mon: [07:30] charm: local:precise/ceph-mon-92 [07:30] root@ip-10-252-23-71:/var/lib/juju/units/ceph-mon-16/charm# cat revision [07:30] 91 [07:36] SpamapS, hmm.. i can have a look at that in the morrow.. i'm past my bedtime [07:36] SpamapS, if you could though pls grab the unit-agent log for it [07:36] hazmat: I did.. I think its working normally [07:36] hazmat: the version is set to the one its supposed to be [07:36] hazmat: then there was an error [07:37] hazmat: 'nite [14:07] ok, so from the install hook ( or specificly a bash script called by the install hook ) can I config-set a variable , and assuming so is that the best way to inform a user ( juju user ) of a randomly generated admin pass or is there another way that is common/prefered ? [14:12] m_3: i'm gonna email the list with a reply but any thoughts on adding some bits to the official juju Makefile to allow a "make darwin" or similar that would generate a precompiled traditional .pkg for OS X, then we dont have the dependancy on Brew and can control easier the way Zookeeper is compiled ( default with brew has no zkpython ) and filesystem permissions on install , the two main problems I've noticed with the current way. Also I'm thinki [14:30] imbrandon: no, but I was just asking for a config-set last night. ;) [14:31] imbrandon: right now the way to communicate passwords back to the admin is juju-log [14:31] SpamapS: :( [14:31] imbrandon: I know. :-P [14:32] what about when another bit may need that same pass ? can i fake it by calling out to "juju config-set $service pass=$pass" ... [14:32] hrm thats nasty tho [14:32] imbrandon: perhaps we should develop a 'password safe' charm that stores all the generated passwords in a secure site that the admin can get access to. ;) [14:33] hehe , not a bad idea actually [14:33] imbrandon: for a large scale site it works. [14:33] along with the ssh key charm too [14:33] still gonna do that $someday [14:34] imbrandon: calling juju set would require enough access creds to find the ZK node and talk to it... not something you'll have unfortunately. [14:34] SpamapS: ok, hrm is there a way for the charm runner to see the log if they were not running debug-log at the time ? [14:35] imbrandon: juju ssh unit/# sudo cat /var/lib/juju/units/unit-#/charm.log (but that doesn't work on local provider.. doh) [14:35] SpamapS: even with access to the socket and such like a cron job ? still even so its too crufty that way [14:36] hrm, what about if i just stored it in a file that was not accessable via the webroot, then added into the readme that if they missed it in the log they need to run "blah ..." [14:36] and blah would be a one liner to ssh to the node and cat the file [14:36] assuming they have ssh key access they should have admin access [14:36] imbrandon: yeah a few charms put the admin creds in /var/lib/juju/something [14:37] imbrandon: we need config-set.. period [14:37] kk, that seem like the sensable thing to do until we grow a config-set [14:38] apart from the password safe, as that really is a good idea but maybe overkill for the lone sysadmin drupal guy [14:38] or gal [14:38] maybe support for both at somepoint :) heh [14:38] well we could build it into charm helper... [14:39] ok, well with that bit of information "super drupal" will be ready for peer review today and hopefully promstrangulation [14:39] sweeeet [14:40] still will have lots of interation as the nginx charm evolves but it will be in a useable form, just not as broken down into suboranates as i;d like to see it eventually [14:41] i figure i've put it off long enough though and will just need to update it as other subordnates make sense to replace bits of it [14:42] btw i never have ask but prom my own charms is taboo correct ? [14:42] i just assumed so [14:42] new charms need to be reviewed always [14:42] not by the author [14:42] actually I don't think thats actually in our "policy" doc [14:42] right, i;d feel better that way anyhow, but just makin sure i was clear [14:43] we need to get that in an rst and in VCS... [14:43] but updates to like newrelic-php i can commit directly ? or how should that work ? [14:43] I'd say thats at your discretion [14:43] also plain newrelic is ready for review too if you dident notice [14:44] I do request reviews for any change that isn't an obvious improvement. [14:44] kk, well if its minor stuff like i have ready to push ( readme updates and other minor misc stuff ) i'll push direct, larger changesets i'll likelly seek review just to cya [14:46] SpamapS: yea in the rst etc we can word it similar to bin-new, as in any charm thats 100% new needs non-packer review, and past that if your the maintainer listed then its your descression as you should be vetteted not to do something dumb by that point [14:46] or something along those lines [14:48] * imbrandon is semi afk while he implments the passwd bits and does a few last smoke tests [14:49] SpamapS: btw if you dident see jcastro blogpost about column80.com , zomg go look, soooo nice [14:52] hrm, install hook calling out to the python REST api to run config-set , hahahah ok ok tine to just do it the dirty way and moan for go port to hurry so we can add config-set [14:54] SpamapS: btw does run-as-hook not drop you in a tmux shell like debug-hook ? i could have swore that marcoceppi showed me that it did at UDS but i could have my commands mixed up a bit as I dident take notes at the time [14:59] imbrandon, run-as-hook does not drop you into a tmux shell. but you can use it to trigger a relational hook exec, and then that could be captured by a debug-hook [15:00] ahhh, did not think of that, i kept add-unit'ing [15:00] heh [15:00] so jitsu run-as-hook mysql/0 relation-set -r OUTPUT-FROM-RELATION-IDS refresh=NEW-VALUE [15:02] the output being possibly wordpress/0 wordpress/1 mysql/0 [15:02] ? [15:02] imbrandon, no the output of relation-ids. that would be something like db:0 [15:02] ohhhh oh oh ok, yea brain fart [15:03] imbrandon, np [15:03] hrm thats actually pretty powerfull [15:03] err very [15:03] imbrandon, yes. perhaps too powerful ;) [15:03] heh [15:03] rev up the chainsaw [15:03] `lol , right [15:05] ok last dumb question while we're on that train of thought, so i have debug-hook open , i trigger a config-change or relation-change , the tmux opens a window but dosent actually exec anythig right ? [15:05] as in the hook never fires, it just gets ready to [15:05] correct ? === marrusl_ is now known as marrusl [15:20] SpamapS, hey, https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-juju-charm-unit-tests mentions 'jitsu run-tests' but does that command already exist? [15:20] imbrandon, just flipped back to this screen - what you have in that tmux window is a shell environment where everything is setup so you can type commands as if it were in a hook context [15:21] (which it actually is, just to be clear!) [15:21] jimbaker: right, i got that, just not clear on if the hook its self fires or if its stoped [15:22] imbrandon, the hook is running. but it's the tmux session itself [15:22] pre-execution [15:22] not stopped, not pre-executed. this point in time [15:24] until you exit the shell, the hook is still running. which means no other hooks will run as well, since the hook scheduler serializes the execution of hooks [15:24] ok so the relation hook fires and the console output is dumped into my tmux window and then at somepoint i have a prompt that i can do additional task in the same context ? [15:25] imbrandon, in debug-hook mode, you are running in a hook context. you can take any action that the normal version of the hook would run. try running some relation hook commands. interact with the system in some way [15:25] ok, cool, i thought when the window was presented it had preped the enviroment to run whatever hook it was about to run but stopped the execution of the hook its self prior to giving the prompt to me [15:26] yea, pretty sure i have all that down. just wasent clear on if the hook its self ever actually fired or not [15:27] imbrandon, you can also try running the normal hook script. this can be useful if it's buggy. try running it. maybe insert some extra debugging. whatever. then repeat again if that's feasible to do, until you're finished debugging [15:27] ( not additional hooks , just the first ) [15:27] sure, exactly [15:27] imbrandon, you're right about the effect [15:27] ok cool, that makes things much clearer [15:27] imbrandon, the normal hook isn't fired [15:27] oh ok ... [15:28] the subtlety is that it [15:28] 's because the tmux window is itself being run as the hook [15:28] rather than what normally would be [15:28] ahhh ok thats what i thought but was not clear on [15:28] so if you want to run the normal hook in tmux you can [15:28] james_w: no that command is planned [15:29] or you can fire up nethack [15:29] imbrandon, it's subtle but very powerful once you get the hang of it [15:29] juju doesn't care [15:29] james_w: its the final piece of the puzzle for getting the per-charm tests going [15:29] SpamapS, ok, thanks [15:29] james_w: re jitsu run-tests [15:29] SpamapS, the nagios charm is getting mighty complex, so I'd like to write some tests [15:29] ahhh perfect , ok thanks james_w and jimbaker , yea i had most of it under wraps just not that last bit, but perfect [15:29] (in my local hacking of it) [15:30] imbrandon, cool. and remember not to cut off your foot with jitsu run-as-hook ;) [15:30] hahaha right [15:30] :) [15:30] james_w: you can write tests now, and just put 'local:' in front of the charm name until I get around to writing a wrapper [15:31] SpamapS, ah, true [15:31] good idea [15:31] * SpamapS really wishes JUJU_DEFAULT_NS hadn't been turned into "JUJU_EVERY_WAY_WE_MIGHT_WANT_TO_OVERRIDE_CS" [15:31] heh [15:31] james_w: export JUJU_REPOSITORY to get rid of the need for --repository [15:31] yep [15:32] SpamapS: does repository: work in env.y too ( i think i noticed that in the docs iirc ) [15:32] # repositories: [15:32] # - http://charms.ubuntu.com/collection/ubuntu [15:32] # - http://charms.ubuntu.com/collection/openstack [15:32] # - http://charms.ubuntu.com/people/miked [15:32] # - /var/lib/charms [15:33] crap, bad paste, was intended for pastbin , sorry [15:33] anyhow ^^ like so ? [15:33] imbrandon: no that was never implemented [15:34] darn [15:35] phone, afk brb [15:50] also, is it ok for a charm to execute commands sent to it from a relation? [15:51] normally that would be a really bad thing to do, but maybe relations are trusted in juju? [15:53] hazmat, ping [15:53] imbrandon: I do like having packaging targets be part of the source, but I'm not married to the idea [15:56] james_w: I think its a bad idea personally. [15:56] james_w: put the commands in a package, and dictate that "its time to run those commands we both trust" [15:57] james_w: PPA's are useful for that. :) [15:57] SpamapS, I think that may be too big of a hurdle in this case [15:57] arguments to the command would be ok, but then you have to sanitise them [15:57] it's for saying run "check_http" with these arguments... [15:59] james_w: thats too specific [15:59] james_w: abstract it. "check_type=http arg=url;http://foo/bar" [16:00] james_w: nagios is *not* the only monitoring solution [16:00] and in fact, will likely not be the most popular once we make it easy to choose :) [16:00] I don't want to try and write an abstract monitoring system [16:00] I'd love one [16:00] Why not? you can use Nagios as your guide [16:00] but I'd like to have *one* monitoring system working first [16:00] just don't be specific with cmdline args [16:01] because that's ok for check_type=http [16:01] I really care about check_type=custom [16:01] nooooo [16:01] its not custom [16:01] its mysupercoolthing [16:01] heh [16:01] then add support for mysupercoolthing to nagios, or make a subordinate for that plugin [16:02] otherwise, nagios will just refuse to monitor it [16:02] right [16:02] You can add a passive check for it to nagios, and just leave it as UNKNOWN forever [16:02] but then how do you tell nagios to actually monitor it? [16:02] that way its obvious to an admin that nagios can't check mysupercoolthing [16:02] monitor a service using the plugin [16:02] check_type=mysupercoolthing arg=what? [16:03] like I said, you either make a subordinate for your super plugin, or you add it directly to the charm [16:03] and then when Reconnoiter becomes popular, it can't do mysupercoolthing, but thats ok [16:03] because it's then tied to the nagios plugin interface, and so we no longer have a generic monitoring solution [16:04] not really. You probably have other monitors you want run [16:05] so you are proposing a "monitoring-check" interface that expects "check_type= arg=" [16:05] james_w: something like that yes [16:05] and if the monitoring system in question doesn't know how to handle the type then it doesn't monitor it? [16:06] james_w: *or* we go the other way and have an interface per monitor [16:06] but a subordinate can't add interfaces to the primary right? [16:06] james_w: right! [16:07] which is one of the reasons I don't like that plan ;) [16:07] heh [16:07] james_w: the "doesn't monitor it" is just an idea that I have not thought through. It may be better that some kind of error is generated [16:07] so how should arg=whatever be interpreted? [16:07] SpamapS: hey did we talk about subordinates opening ports at UDS? [16:07] jcastro: not really. Its a known bug that is being worked on [16:08] ok so nothing controversial then, whew. :) [16:08] yea i kinda came to that conclusion with the drupal charm too, i was trying to do too much all in one go, and decided to scale back and get "one monitoring system" working first then figured i could iterate as needed to get it to the sweet spot over time [16:09] jcastro: mornin ;) [16:10] james_w: though its perfectly fine, I think, for a subordinate to be related to in this case.. [16:11] SpamapS, ah, I guess at least for nagios the subordinate could set up the service in nagios' config directly, rather than through an interface [16:11] juju deploy mysuperthing ; juju deploy mysuperthing-nagios-plugin ; juju add-relation my-nagios-service mysuperthing-nagios-plugin ; juju add-relation mysuperthing mysuperthing-nagios-plugin [16:11] anyone else notice the stubleupon logo is very much like the juju one, even changed its color to orange too [16:12] james_w: perhaps an interface for non-generic plugins is a good thing [16:12] imbrandon: yeah I was shocked when I saw the orange color change. I think that was an accidental confluence ;) [16:13] http://su.edgesuite.net/KwIEec5utYGrKmzXYLgFzg [16:13] yea , used to be blue and green i think [16:16] SpamapS, that's good I think, assuming that all monitoring services will allow for a subordinate to define a new service to monitor, which they probably will [16:17] because the app charm only needs to understand the interface to monitor, and the monitoring charm doesn't need to know directly about the new check type [16:18] I just need to think through nrpe in this arrangement [16:19] james_w: yeah for NRPE you can just put stuff in a place where NRPE will find it. [16:19] much simpler to solve w/ NRPE [16:19] the tricky bit is getting nagios to monitor the service via nrpe [16:19] to actually do the check [16:19] defining the checks is easy I think [16:20] SpamapS: got a sec to talk juju debian? [16:20] check_type=nrpe arg=... [16:21] james_w: I think NRPE would be a subordinate actually.. its too specific to nagios [16:21] jcastro: sure [16:21] SpamapS, yeah, agreed [16:21] in fact it already is :-) [16:21] jcastro: its basically just one of my bazillion TODO's for the next week or two [16:21] james_w: yeah, so you just need to feed back the primary unit id and address info to nagios via the nrpe interface [16:22] to define the host? [16:23] james_w: yeah, do it some consistent way with the "monitoring" interface so you don't end up with two versions [16:23] I need to think it through [16:24] SpamapS: oh also, we appear to have work items unassigned on this spec: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-juju-charm-unit-tests [16:24] m_3: ^^ [16:25] just pointing it out, I dunno if that was on purpose or if you guys just put those there opportunistically [16:25] jcastro: huh? [16:25] jcastro: nope, just haven't been processed yet [16:26] of course we have work items on that spec. :) [16:28] james_w: btw, once you get Nagios working.. you can make add-unit on it work by farming jobs out via the nagios mod_gearman [16:28] ooh [16:28] james_w: scalable monitoring FTW [16:28] yeah [16:29] SpamapS, gearman has its own transport right, it's not build on rabbitmq? [16:33] james_w: correct [16:33] its *far* simpler than AMQP [16:33] yeah [16:40] ugh, unplaned RL detour , back in a hour or so ( hopefully ) [16:45] MarkDude, ping [16:50] sorry for the blueprint spam fellas, just rearranging bits [16:53] * MarkDude has been looking at a few of the Charms. As near as I can tell, only some of them would be relevant for Fedora [16:53] Differences in sytem files and such. [16:54] 1. So, does the idea of folks curating the stuff that will be useful sound like a decent long term solution? [16:54] 2. do you have any suggestions for a few very useful charms to include in my proposal [16:55] Keeping in mind I am not a dev, and to some extent am known as *Fedora's Jono* :D [16:55] MarkDude: oh man, how do you wash that off? ;) [16:55] * MarkDude just watched his recent video, and needs to steal the slide that said * I am not a programmer* [16:56] lol SpamapS I just figure beer as a cologne [16:56] MarkDude: The charms have remained simple because they're targetted at Ubuntu. I'm hesitant to introduce big case statements or lots of if statements to enable another platform that is for most purposes "equal" to Ubuntu for the intended task. [16:57] So far, the most interest I have gotten is for helping with rollouts [16:57] MarkDude: However, there may be things that one can do much simpler on Fedora.. (name one?) and for those, what might make sense is to have a store of fedora-only charms.. [16:57] MarkDude, realistically charms won't port [16:57] MarkDude: the beauty there would be you could deploy the fedora-only thing, and relate it to the ubuntu-only thing, and they'd just hug it out and get the job done. :) [16:57] MarkDude, we need a separate collection of charms for fedora [16:58] Ok, that was my read [16:58] A few seemed independant [16:58] We don't provide the abstractions for portability, and encourage free form tool usage.. to the extent that individual charms use portable tools they could be considered portable [16:58] but thats a case by case analysis [16:59] easier to just setup a separate archive for the two and allow ad-hoc cross-pollination and portability convergence [16:59] Ok, thats why I was thinking there are most likely a few of them that would *just work* [16:59] i think the initial focus should just be on getting the client running well on fedora [16:59] which is mostly just packaging afaics [16:59] * MarkDude can get that part going [16:59] and has a packager or two [16:59] hazmat: I bet we could just use the current "series" thing we have now... cs:beefymiracle/foo sounds too awesome to ignore. :) [17:01] lol [17:01] * MarkDude thinks his *gitbeefymiracle* is the best association I have over there [17:02] * MarkDude appreciates the input (and confirmation) [17:02] MarkDude: IIRC, fedora has recently grown cloud-init capability, has it not? [17:02] plans on now seeking out a few charms to include when I bring the proposal [17:03] I believe so. The new project lead Robyn was chosen due to her work with the CLOUD [17:03] She even had a cloud hat for last FUDcon [17:05] Hmmmm, so this all means I will need to volunteer to be on approval board (or some crap like that) to help curate charms [17:05] prolly sumthin' informal (hopefully) [17:06] Thx SpamapS hazmat :) [17:07] Keep an eye out for charms that relate to cloud, or rollouts if you could :) I plan on going forth next week :) [17:49] MarkDude !! [17:50] Hello imbrandon [17:50] MarkDude, hey man get me in touch with some .spec guys and i'll at minimum help with the initial "getting it running" [17:51] Sure, sounds good [17:51] that part should be fairly simple, its the all new charm collection thats the bear [17:51] * MarkDude just wanted to immerse himself in trying to understand this whole juju thing [17:52] :) [17:52] Right now tho, the guys that a willing to help, are at FUDcon in Asia [17:52] well pretend your a ubuntu full time user and anytime you want to type yum type apt-get instead , that should get you 80% there :) [17:53] * MarkDude would also have to pretend he a full time Fedora user also ;D [17:54] even better yet install apt for rpm as a depenancy of juju ( artificial ) and then chnage only package names in charms , hehe i dount that would work realizticly though [17:54] doubt* [17:55] I know an Ubuntu Memebr/Fedora Ambaasador that uses aot for package management [17:55] aot ? [17:56] apt [17:56] ahhh, you type as well as i do i see [17:59] so yea, hazmat and SpamapS are def the fellas to snag when things get a bit more in debpth, but like we talked about at uds, just gettting the initial rpm built and the cli "client" app running should be fairly streight forward and i could knock it out in an afternoon if i knew a bit more about .spec files [17:59] MarkDude: ^^ but even without knowing much about them should still be semi easy for that much at least [18:01] in fact, i'm gonna snag a fedora iso to load up in vbox after i push this drupal stuff today [18:01] just to see if i can make it work without actually making the rpm [18:01] i'm sure the deps are all available [18:08] SpamapS: wow, just got pointed the RPM howto, and its ummmm tiny, as in like 10 printed pages, I was expecting the "Debian New Maintainers Guide" heh [18:09] * imbrandon wipes forehead in welcome releif [18:10] MarkDude: yea tho seriously this will get your a little kick start but i have no intentions to maintain it long term or anything so eventually you'll want to round up a fedora packer [18:11] and there will be many more harder things, but this will enable fedora users to deploy and control juju environments on aws ( same as the mac client ) [18:14] Yep, mostly it will be sorting thru to get relevance === Guest97304 is now known as tobin === izdubar is now known as MarkDude [18:21]