=== timrc is now known as timrc-afk === timrc-afk is now known as timrc [00:47] marcoceppi: if you give me a min I'll fix that byobu-classroom thing I messed up [00:49] marcoceppi: s/server/service/ on line 51 https://github.com/juju/plugins/blob/master/juju-setall#L51 [00:54] jose: all charms that you did that for need updating, I noticed pictor as well [00:54] jose: if it didn't originally have a config.yaml there's no need to add one [00:54] yeah, I got that part now [00:55] byobu-classroom has been fixed [00:55] and, updating in what sense? [00:57] jose: as in [00:57] if it didn't originally have a config.yaml there's no need to add one [00:58] I didn't do that to all MPs, some of them are only a conversion from text to markdown [00:59] pictor is being fixed now === timrc is now known as timrc-afk [01:02] and pictor's been fixed [01:03] sorry for being a bit messy with my MPs [01:04] also, the bip MP has been checked by arosales but needs the word of a charmer [01:12] marcoceppi: the bip one was the one odd one where proff failed on a 2 character config key [01:13] jose: hello, btw [01:13] hey, arosales! how's it been? [01:14] goin well thanks, yourself? [01:14] all good, all good! [01:14] good to hear, jose: looks like you have been busy with mps :-) [01:15] yeah, did those a couple weeks ago and some of them are a bit messy, but fixes should be easy (in most cases) [01:15] jose: good to see the contributions [01:16] * arosales grabs some dinner, but will be back on line later tonight [01:16] enjoy! [01:18] for juju devs: thank you for version 1.18, it's simply awesome. I love it! === timrc-afk is now known as timrc [01:38] thanks, lazyPower :) === sarnold_ is now known as sarnold [02:08] jose: ping [02:08] lazyPower: pong [02:08] jose: the icon for pictor still doesnt meet guidelines. Can you rem it so i can ack this merge? [02:09] will do now [02:09] in the meantime, may I ask why? [02:10] it looks like a developer made it. We're looking for HQ icons that add diversity to the landscape of the charms, and have a tight attention to detail. I mean not to offend - only explain. [02:11] hmm, ok, then [02:11] the white pixel borders on the camera are what called it out for me. [02:11] it's been pushed [02:11] thanks jose [02:11] np [02:11] I'll ask Dustin if he has the sources for the icon and fix it then, no white pixel borders! [02:23] lazyPower: if you're still around, it'd be awesome if you could do a review for https://code.launchpad.net/~jose/charms/precise/owncloud/update-version/+merge/214649 [02:23] only updated the version to 6.0.2, just did a sucessful deploy [02:24] ok. subsequently did you try a merge with the efforts in the ceph charm? [02:24] there's been work on that front and i was goign to try to maintain compat with his work [02:24] jose: thanks for the review on the Meteor charm [02:25] lazyPower: is ceph having the same problem as owncloud (not in the repos and needs updating from time to time)? [02:25] tvansteenburgh: no worries, always glad to give a hand where possible :) [02:26] jose: well, its a ceph relationship that was added. I was curious if you attempted to deploy that with the ceph modifications [02:26] they will more than likely collide and require some massaging to work [02:26] hmm, nope, let me do that right now! [02:26] instance is still up :) [02:26] do you have experience in deploying ceph? [02:26] it can be a bit tricky if you dont have spare block devices to work with [02:27] you need to assign a UID and a blockdevice to get it to deploy [02:27] no experience, but I suppose the readme should be enough? [02:27] huh [02:27] * jose reads [02:27] yeah :) [02:27] give it a read and see how you fare [02:27] it'll be good to get some fresh feedback on it === arosales_ is now known as arosales [02:36] lazyPower: ceph's deployed and started, am I supposed to add a relation between owncloud and ceph? [02:36] if you have merged in zchander's changes [02:36] this is where it gets tricky, as its most likely goign to collide [02:38] * jose checks [02:40] do you have a link for that branch? I don't seem to find it anywhere and it's not fixed in trunk === axisys is now known as info [02:44] sure 1 sec [02:44] thanks [02:44] jose: https://code.launchpad.net/~xander-h/charms/precise/owncloud/ceph-support [02:50] jose: Pulling your branch now [02:50] cool, thanks === info is now known as axisys [02:55] lazyPower: found a bug on the ceph-support charm: once it's got status `started` port 80 is not open, which makes it unreachable [02:56] not even after it's related with ceph [02:56] jose: that was nacked in teh review [02:57] let's manually open it and see what happens [02:57] you should be able to pull the ceph bits from it - but if its too big of a change, it shouldn't be a problem for zchander to backport the changes and operate. I was going off of a "if it takes 15 minutes or less, lets maintain compatibilitiy" [02:57] jose: it also lacks the mysql migrations for the latest edition of owncloud for scale out usage. [02:57] so, its got a fair share of potential issues [02:58] but as POC it shows merit :) re: my text above. and having it integrate with an openstack component ootb would be attractive to some I think. [02:59] hmm, yep [02:59] after the relation and manual opening the port, it *seems* it's running good [03:00] add a mysql relation [03:00] * jose does [03:00] to owncloud or ceph? [03:00] owncloud [03:00] ok [03:01] w0ot, I had never gotten to machine #7 on my environment [03:06] I have now added the mysql relation to the owncloud charm and don't see any notable changes [03:06] seems to run seamlessly [03:08] lazyPower: ^ [03:10] bueno [03:10] nice, and the ceph relationship works? [03:10] like, it's there, I don't know if there's anything special that should appear on owncloud? [03:10] it should add a storage location [03:11] add a file, and use the ceph utility to validate it made it over to ceph's storage [03:11] i forget the name of the ceph cli command, may need some google fu [03:12] let me check, haven't used ceph before :) [03:21] jose: eyyy simple updates, i like these reviews [03:22] 'now that U1 no longer exists as a file storage service, deploy your own cloud file storage service with juju and owncloud!' [03:23] jose: jcastro filed that as a task last week :) Glad to know the community is on this as much as we are. [03:24] well, we try :) [03:24] (also, is there a task list?!) [03:24] its internal [03:24] oh, there we go [03:32] lazyPower: when I do `ceph osd -m $addr` I get a bunch of faults [03:32] did you add a block storage device + set a UUID? [03:33] and can you paste the list of faults you get? [03:33] yep, I did [03:33] second [03:33] lazyPower: http://paste.ubuntu.com/7219897/ [03:34] is it exposed? [03:34] yes [03:35] (even though port wasn't open, I manually opened it) [03:35] can you humor me and try from the owncloud host using the internal address? [03:35] sure, second [03:35] s/the internal/ceph's internal/ [03:37] lazyPower: same exafct series of faults [03:37] well, not exactly the same [03:37] jose: ok. Thanks for looking at it jose [03:37] np [03:38] i'm investigating an intermittant install hook error i got from the merge proposal [03:38] works as expected in debug hooks [03:38] is that from which MP? [03:38] the upgrade [03:38] ok [03:40] let me know if there's anything else I can give a hand with [03:40] I'm going to do a quick review of the graphite charm now [03:44] jose: so far so good. it was only once and i think it ws due ot network latency [03:45] I have an instance with the upgraded charm running atm (ec2-54-208-209-6.compute-1.amazonaws.com if you wanna try, hasn't even been configured) [03:45] just got it deployed. adding storage and scale out options now [03:45] this makes run #4 - so no worries. I think i've got it down [03:46] cool :) === timrc is now known as timrc-afk [03:54] jose, seafile is supposed to be excellent too [03:54] wrt u1 replacement [03:54] ~negronjl made a charm, it's in his namespace, I think all it needs is an update [03:55] uuh, I'll take a peek at it in a while! [03:59] yay, it's in Bash! I'll see what can I do to get it finalized before trusty [04:00] jose: your changes are great. ack'ing them. one suggestion for an improvement [04:00] owncloud deploys with a sqllite database, if you upload files and later attach it to mysql - it wipes the file content listing. It may be a worthy exercise to migrate the data to the mysql host [04:00] so, going to ask that you document that in teh README so its covered as expected behavior pending a patch, and this is g2g [04:01] ack! [04:02] ah 1 sec, let me run an upgrade on a predeployed file structure, i almost missed that. but i think its going to be fine [04:12] lazyPower: so, how are users supposed to migrate the info from sqlite to mysql? [04:13] let's say, I'm not a sql expert, I don't know a word of sql (apart from INSERT) [04:13] oh and DROP [04:13] jose: the idea is that the relationship hook would handle the translation. You would READ from the sqllite tables and transpose to mysql. I haven't looked at it in terms of effort [04:13] but the datastructure should be the same. and theory states you would backup the sqllite database in the event of a catastrophic unforseen data migration error [04:13] so its 1:1 copy'ing data across (in theory) [04:14] if you want, we can look at this closer later this week and see about making a migration script [04:14] sure, I was thinking on that too [04:14] I'll just add that note in the meanwhile [04:14] give it some cursory looking, examine the sqllite database, the mysql tables, and see difficult you think the migration will be [04:14] i'll do the same, and we'll convene on this when you're ready [04:16] ok! [04:16] I'm also going to take a look at the seafile charm and see if I can do something to it, may be good to have yet another option inside the charm store [04:16] Indeed :) [04:22] lazyPower: fix pushed! [04:22] jose: thanks for the quick turn around [04:22] :) [04:24] bummer [04:24] it fails upgrade [04:24] unit-owncloud-0: 2014-04-08 04:23:46 INFO upgrade-charm find: missing argument to `-exec' [04:24] huh? [04:25] if you deploy the existing charm revision, and merge in your branch and run an upgrade [04:25] it fails on upgrading the charm [04:25] hmm, I didn't write that upgrade-charm hook [04:25] let's take a look at it [04:25] i'm aware [04:25] but we need to triage it for existing users :( [04:26] yeah [04:27] is there a way I can upgrade the charm from a charm store revision to a local revision? [04:27] that way I could try and debug what's happening [04:27] charm get owncloud && deploy as local [04:27] oooh right [04:32] jose: the fix is terminating it with an escaped semicolon [04:32] find /var/www -mindepth 2 -maxdepth 2 -type d -name data -exec mv {} /var/tmp/ \; [04:32] i'm not sure how this ever worked... [04:33] lolwat [04:33] yeah, update the hook once you've got it confirmed as failing during upgrade and test the fix [04:33] it should clean it up and make it g2g [04:33] will do, bootstrapping the env [04:35] jose: ah well it makes it further, it also hangs on the data directory being moved in 6.0 [04:35] then, escaped semicolon again? [04:36] well the 2 lines of find need a semicolon, thats been patched [04:36] but it runs install, which deplys a different file structure [04:36] hmm [04:36] they moved the data directory for multi-user install isolation instead of having a "pool" of files on the server [04:37] actually no, i take that back, its just flat out missing the data directory which is whats causing this [04:38] which means files need to be moved where the data is now [04:38] yeah, this hook has some idempotency issues [04:39] if you rerun it after the upgrade, you're going to wipe up any uploaded data [04:39] which is a big nono [04:40] a better option would be to create a sentinel file that if present, dont backup the data, and when it successfully moves it back into owncloud, it removes the file so the next upgrade can do what its supposed to do [04:40] let me spec this and i'll show you some code [04:42] jose: also, the config file format has changed. [04:43] * jose checks [04:43] what's the difference? [04:43] 1 sec i'll pastebin it [04:43] ok [04:45] strange, pastebinit hates this [04:46] let me see if it accepts it as is - i haven't actually finished the migration to verify it wants all these extra config options [04:46] sure, I have no hurry [04:47] also, if you're tired and want to finish this tomorrow I'm good with it, I have no classes :D [04:49] nah i want to get this wrapped up [04:50] its a pretty simple fix [04:50] my cats keep distracting me [04:50] they are telling me its time for bed [04:50] I have no cats, but have a 6lb bag of gummy bears [04:52] thats a lot of gummy bears [04:52] indeed [04:53] boom [04:53] now its idempotent *and* works [04:53] http://paste.ubuntu.com/7220050/ [04:54] ok, and where is $CHARM_DIR defined? [04:55] thats a juju environment export [04:56] oh, got it [04:57] checking right now [04:57] Cannot redeclare class OC_Config in /var/www/owncloud/lib/config.php on line 41 [04:57] well, its nearly a win [04:57] :P [04:58] is that because of the old configs? [04:58] there... is no line 41 [04:58] i wonder if its picking upt eh sample config [04:59] huh, maybe [05:00] nope [05:00] I can't do much right now, bootstrapping, once it's done I'm going to check [05:00] i think there are extra files left over from the upgrade [05:01] maybe the -u flag can give some clues? [05:01] (set -u) [05:01] so, maybe what needs to happen is once the upgrade hook copies out the data, and configuration, it should completely wipe the owncloud application files... but this is bad news for usrs of plugins [05:01] thats only going to warn you of unset variables in bash hooks [05:01] this is coming from the apache logs [05:02] oh === timrc-afk is now known as timrc [05:04] the only simple fix i see here jose, is to target trusty and revisit this later [05:04] I think we can do that [05:04] unless you want to cycle on the upgrade hook and see if you cant track down what needs to happen [05:05] I'll take a look later on and see what's happening [05:05] but you have a few things to consider, 1) data integrity of the entire owncloud installation. that includes plugins that users may have installed. [05:05] and 2) data migrations for any upgrades that need to happen. eg: if a plugin format has changed from 4.x to 6.x - mayb eadd some owncloud apps once you get the base system working, then re-run the upgrade after you've added owncloud apps [05:06] i'm going add a note to the MP that its great on fresh installs, but needs work on upgrades [05:07] thank you for staying up to review this === timrc is now known as timrc-afk [05:16] lazyPower: thanks for the review and your work on this, have a good night! [05:16] * jose checks seafile [05:16] No problem :) === vladk|offline is now known as vladk === vladk is now known as vladk|offline === stub` is now known as stub === CyberJacob|Away is now known as CyberJacob === vladk|offline is now known as vladk === lseror_ is now known as ChaosMonkey === CyberJacob is now known as CyberJacob|Away === axw is now known as axw-afk [10:50] rbasak: morning. just released quickstart 1.3.1: https://pypi.python.org/pypi/juju-quickstart/1.3.1 . It only includes bug fixes, and a packaging module that can be used to switch juju packages source: http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/quickstart/packaging.py [10:52] frankban: great, thanks. I think this is fine to upload. I'll look at it today. [10:52] rbasak: thank you! [11:05] did juju at some point stop reusing machines with no services deployed to them? I just stuck destroy-service in a loop and then ran another deploy. To my surprise it just created new cloud instances rather than picking up the unused ones it already had in its brain. [11:09] ev: yes, since the golang rewrite [11:09] marcoceppi: :( [11:09] ev: I know :( [11:09] marcoceppi: if I deploy into containers on the machine, will that work around the problem? [11:09] I'm trying for really fast deployments [11:09] so my hope was that I could just destroy-service to a clean slate [11:09] and didn't have to provision the machines all over again [11:10] ev: yeah, you can actually run juju add-machine with no parameters to provision clean machines to be used during deploy [11:10] though I suppose that doubles the time of the first deployment, since it needs to create and upgrade the container [11:10] ev: but there's no "clean up" when you destroy service [11:10] which is why they're not reused, and in the future the machines may auto termiante when no remaining services are on them [12:13] word of warning - the new lxc cloning and squid-deb-proxy-client support in lxc do *not* work well together === timrc-afk is now known as timrc [13:16] for a boolean type in a charm's config.yaml, will `config-get` always print 'true' or 'false'? [13:17] or is it 0/1? [13:17] can't find this in the docs [13:18] tvansteenburgh: looks to be "true" or "false" to me (from looking at a live env) [13:18] thansk [13:18] thanks [13:23] yep. its true/false [13:27] lazyPower, hey, I just saw on the calendar, we have an OSX Workflow charm school this Friday [13:27] right on [13:27] i guess i should charge my air [13:27] hey you wanna announce it on the list? a reminder? [13:27] you just need to copy my template from my last one [13:28] sure. after i'm out of this meeting you got it my an [13:28] s/an/man === axw_ is now known as axw [13:50] bcsaller: Hi! Could you please review https://code.launchpad.net/~michael.nelson/charm-helpers/fresh-ansible-relations/+merge/214203 when you have time? [13:52] bcsaller / jcastro : Also, what's the policy for merging changes to charm-helpers? bloodearnest and I have been waiting for reviews/landings for a while, and I notice that (according to LP) I can also merge to lp:charm-helpers. Are you ok with me merging approved branches? [13:53] marcoceppi, ^^^ [13:53] noodles775: they should show up in the revq [13:53] lazyPower: the calendar link you emailed is canonical-only I think [13:54] obamaaaa [13:55] lazyPower, want me to make you a public one? [13:55] we've got the on-air link [13:55] https://www.google.com/calendar/render?eid=MDJiMzY0MDc2YmM1bGxtMzg0MGE2a2dzb3MgZG5vM2lwMG1zZzU1MmRlaTNlM3I3bThqbDBAZw&ctz=Etc/GMT&sf=true&output=xml should do good [13:56] it doesn't let me view it in private browsing [13:56] jcastro: that would be excellent [13:56] heh, that calendar link hilited me [13:56] marcoceppi: So maybe I did the wrong thing by marking this one as approved? https://code.launchpad.net/~bloodearnest/charm-helpers/add-ips-address-to-template-context/+merge/201455 [13:57] marcoceppi: but my question is more, can I merge that into lp:charm-helpers (ie. do you mind if i do so, or do you want to revert my privs there - I've not tried, but just going from LP) [13:59] noodles775, any help with the charm queue would be appreciated! *cough* [14:01] jcastro: great, bloodearnest and I are already reviewing each others charm-helper branches, but it'll be easier if we can land them too :-) [14:01] that would get a +1 from me [14:01] that's what we do for webops/IS. [14:01] marcoceppi, how do you guys feel about letting them review each other's branches? [14:02] jcastro: that's fine, but this is why I hate having an "inactive charmers" in the charmers team [14:02] we should have a charm-helpers team, with charmers in it [14:02] not the other way around [14:03] ok [14:03] so let's do that? [14:03] otherwise stuff falls out the queue and everyone has to be a charmer to do anything [14:03] jcastro: sure, that fixes this one case, but it doesn't resolve the other projects or resolve why we have to have inactive charmers [14:03] it's a bigger issue [14:03] noodles775: yes, you can merge stuff that others have approved for charm-helpers [14:03] ..... ok let's punt that one to the sprint then [14:03] then we'll just fix it [14:03] yes === benrodrigue is now known as brod [14:30] Congratulations jose your roundcube work was my first merge to the charm store! [14:31] Thanks for the work on that charm, it should be available in the store! [14:31] * lazyPower claps [14:31] awesome mbruzek! How's it feel to merge into the store? [14:31] scary [14:31] right?! [14:31] I don't want to mess it up and face the wrath of the other charmers! [14:32] * lazyPower readies the blackjack [14:33] congratulations to you, mbruzek, for becoming a charmer! :D [14:33] Thank you jose [14:50] frankban: "Support MachineInfo addresses" is the fix for bug 1301464, right? [14:50] <_mup_> Bug #1301464: The mega-watcher for machines does not include containers addresses

[14:53] rbasak: yes [14:53] OK, thanks. Testing a candidate package now. [14:54] rbasak: and "Support the --ppa flag for distro packaging." is the other commit, which introduces the packaging module that can be changed to switch the distro package to not use the ppa [14:54] rbasak: cool thanks === hatch__ is now known as hatch [15:07] Cannot deploy local charms after Juju upgrade | http://askubuntu.com/q/445025 [15:21] jcastro: hey! is lp:juju-core/docs the right branch to MP to get a fix in juju.ubuntu.com/docs? [15:21] no [15:21] github.com/juju/docs [15:21] cool, thanks [15:23] instructiosn in the readme there. === timrc is now known as timrc-afk [16:36] frankban: in testing, I'm stuck at "retrieving the Juju API address". Could this be related to the bug 1301464 fix? [16:36] <_mup_> Bug #1301464: The mega-watcher for machines does not include containers addresses

[16:37] frankban: I think I'll upload my candidate package to my PPA first. Would you be able to test that to see if it's any good, please? [16:37] rbasak: sure [16:38] rbasak: I don't think that's related. IIRC that's just a call to "juju api-endpoints" [16:38] frankban: OK. I think I've just found the reason. Out of space in / on my host test machine :-/ [16:39] I'll upload to my PPA anyway - I'm running out of time before my EOD today. [16:39] rbasak: running with --debug can help in general [16:39] yeah, same here, EOD in 20 [16:43] frankban: uploaded to ppa:racb/experimental. I'll test again first thing tomorrow if you don't beat me to it. If it's good, the PPA package is good to upload to the archive with just a version bump. [16:44] Sorry it took so long. Because it usually takes a while I just let it get on with it, and didn't see any errors about disk space on my KVM host :-/ [16:44] rbasak: perfect, thank you [16:44] :-/ [16:45] rbasak: I'll try to use the package with local and ec2 tomorrow morning [16:55] frankban: great, thanks. Looks like it built successfully. [16:58] rbasak: cool, I see it being published === roadmr is now known as roadmr_afk [17:02] anyone have a good pattern for making sure that a chunk of hook code only runs on one unit of a service? [17:03] for example, say i have 2 sugarcrm units deployed behind haproxy. i `juju set` some config values that cause the db that sugarcrm is using to be updated. i only want to run that db update from one unit, not both. [17:06] tvansteenburgh: use peer relations to do a leader election [17:06] marcoceppi: thanks, i'll look into that [17:06] * tvansteenburgh goes to read up [17:06] tvansteenburgh: something like "okay, this is my unit number, is it less than the unit I'm connecting to? no? them I'm the leader" [17:07] tvansteenburgh: you'll have to do a bit of round robin until everyone is settled [17:07] I've been planning on writing it in to charm-helpers for a while, just no time [17:08] marcoceppi: roger. i'd be interested in contributing that, once i grok how it should work === timrc-afk is now known as timrc [17:30] Question from Twitter: how is security handled? Is that on the cloud provider? [17:53] jcastro mbruzek tvansteenburgh et al, FYI, bug in 1.18.0 and here is the workaround: http://askubuntu.com/a/445101/41 === vladk is now known as vladk|offline === roadmr_afk is now known as roadmr === test is now known as Guest39717 === CyberJacob|Away is now known as CyberJacob === vladk|offline is now known as vladk [19:31] Makyo: are you talking firewall level security? === vladk is now known as vladk|offline [21:13] lazyPower, sorry, was out. I think this is wrt the OpenSSL bug today. How does one manage machine level security. [21:17] I am trying to deploy a local charm. I have the charm in ~/charms/percise/. Neither "juju deploy --repository=./charms rethinkdb" nor "juju deploy --repository=./charms local:rethinkdb" worked, both showing errors. I know I am probably missing something very stupid. [21:17] I've also check the charm structure with charm proof. [21:22] Jeffrey_, I believe it's looking for a repo that contains a charms dir, which contains series dirs. Thus, `juju deploy --repository=~ local:precise/rethinkdb [21:22] ` [21:22] I'm checking now, though, so I can verify in a sec. [21:24] Makyo: That was it... Thanks knew it was stupid. === CyberJacob is now known as CyberJacob|Away [23:09] ola! Does juju provide a simple library for idempotent tasks using bash? E.g. add a user if not already there etc? I can use ansible, salt, etc but was wondering if there is a lightweight alternative that only focuses on idempotent commands [23:12] lemao_: if they exist i am not aware of th em. [23:13] sounds like a useful thing to have :) [23:13] I've taken to using a few conventions in my own scripts when doing particularly destructive commands, if its just template population and somesuch, I'll let it fly regardless as its a fairly inexpensive operation. But as sarnold has said, that does sound like a fairly nice utility to have in the toolbox. [23:14] there were a set of convenience methods - charm-helpers, but they moved to python, and there will be a compatibility layer added at some point that allows other languages to leverage those conveniences added. Some of which would aid in idempotency through a cache layer, like checking config values against an key/value pairing [23:15] but thats in the future, so today, as far as I know, one does not exist. [23:15] lazyPower sarnold: yes, I find myself wanting to perform some simple tasks in a robust, idempotent way and bringing in something like chef, salt, ansible seems like over complicating things [23:18] lemao_: If you start the library, and its of good quality, i would be more than happy to promote its use as users ask about it [23:29] lazyPower: let's see how it goes. I don't want to get side tracked into a tangent. [23:33] lemao_: ack [23:33] just throwing that out there [23:34] lazyPower: sure! At this point it is more of a validation that this is a good idea. [23:36] lazyPower: assuming something like this exists and grows over time, what is the best practice in terms of sharing it across charms? Package it into a .deb package? [23:37] evaluate how charm-helpers works. I would do something similar that has a shared repository model that embeds the current revision of the helpers in the charm itself [23:37] but allows for easy upgrades with a configuration yaml [23:37] maybe, write a python driver to propigate the changes so you're not reimplementing a ton of stuff thats solved for you already.