| m_3 | senior7515: juju works against a local lxc provider for development | 00:14 |
|---|---|---|
| senior7515 | ohhh awesome… sooo how does it work when you say -n 3 | 00:17 |
| senior7515 | for example | 00:17 |
| senior7515 | ? | 00:17 |
| senior7515 | virtual instances over some virtual engine or ? | 00:17 |
| senior7515 | disregards ? | 00:17 |
| senior7515 | or ? | 00:17 |
| chefnewbie | 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:18 |
| m_3 | 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 |
| m_3 | 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:20 |
| m_3 | 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:22 |
| m_3 | 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:23 |
| imbrandon | SpamapS: ping , wanna prom this ? https://github.com/websitedevops/charms-newrelic-php | 00:24 |
| chefnewbie | 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 |
| chefnewbie | is this a correct 101 understanding? | 00:25 |
| m_3 | 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 |
| m_3 | chefnewbie: a lot of services are pretty simple installations and don't need manifests or cookbooks to configure them | 00:26 |
| senior7515 | m_3: thanks… testing this mongodb-hadoop api is becoming a pain.. meh.. still wishing I had a devops guy hehe | 00:27 |
| m_3 | chefnewbie: browse through the "install" hooks on a couple of charms in jujucharms.com and you'll see some simple examples | 00:27 |
| chefnewbie | Thanks, m_3. I am thinking of this long-term goal in my company.... | 00:27 |
| m_3 | chefnewbie: more complex things like rails apps or django apps might warrant using other tools for the configuration of each charm | 00:28 |
| m_3 | chefnewbie: sure... happy to discuss. | 00:28 |
| m_3 | senior7515: cool | 00:29 |
| * m_3 gotta run to dinner... catch y'all later | 00:29 | |
| chefnewbie | 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:29 |
| chefnewbie | if we introduce Chef, we are introducing Ruby prettey much as I understand. | 00:30 |
| chefnewbie | We want to avoid such scenario as much as possible. | 00:30 |
| chefnewbie | any suggestion? | 00:30 |
| m_3 | 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 |
| m_3 | chefnewbie: juju hooks can be written in any language (with an ubuntu runtime) | 00:30 |
| * imbrandon even does some in php | 00:31 | |
| senior7515 | 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:31 |
| chefnewbie | 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 |
| imbrandon | chefnewbie: certainly | 00:32 |
| imbrandon | its able to use pupet or others if you wish but certainly dont need them | 00:33 |
| chefnewbie | 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 |
| imbrandon | chefnewbie: many hooks are in python in juju | 00:33 |
| imbrandon | infact i'd say about 50% its by far the most comon choice | 00:34 |
| imbrandon | and those that arent are simple bash scripts | 00:34 |
| chefnewbie | thanks, I think I roughly got what I wanted from this chat :-) | 00:34 |
| chefnewbie | and the supportive chat room just gave me another reason to explore Juju... | 00:34 |
| imbrandon | :) | 00:34 |
| chefnewbie | 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:36 |
| imbrandon | 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:37 |
| imbrandon | 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:38 |
| imbrandon | 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 |
| imbrandon | and the app is fine | 00:40 |
| imbrandon | 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 |
| imbrandon | let juju care if there are 3 heas or 3 and making them work | 00:41 |
| imbrandon | once your to that point the os is really just a name on paper | 00:42 |
| imbrandon | 3 heads* or 30* | 00:42 |
| chefnewbie | 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 |
| chefnewbie | For example, Ubuntu's /etc/networking/... controls network stuff, but that may be different in Redhad (or other vendors) | 00:43 |
| imbrandon | 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 |
| imbrandon | and i then had 5 webheads and plenty of room for traffic | 00:44 |
| imbrandon | i juju took care of spinning up 4 more nodes, installing nginx, configing it | 00:45 |
| imbrandon | making it talk to the db | 00:45 |
| chefnewbie | imbrandon: here is my question.... | 00:45 |
| imbrandon | rsyncing the current wp relase adn code | 00:45 |
| imbrandon | etc | 00:45 |
| marcoceppi | 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:45 |
| marcoceppi | 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 |
| chefnewbie | marcoceppi: charm is the hook (i.e., the one defining the inidvidual node's configuration)? | 00:46 |
| marcoceppi | charms define the service to be deployed | 00:47 |
| marcoceppi | chefnewbie: these are all charms; http://jujucharms.com/charms | 00:47 |
| marcoceppi | rather, these are all services that have been charmed | 00:47 |
| imbrandon | chefnewbie: think of a hook as a init.d script, they are juju scripts that fire at the right times | 00:47 |
| imbrandon | on the node | 00:48 |
| imbrandon | 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 |
| imbrandon | whatever is in the config-changed hook, a bash or python or whatever script , is what gets done | 00:49 |
| chefnewbie | 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 |
| marcoceppi | charms are just a collection of hooks | 00:50 |
| marcoceppi | that comprise to build a service | 00:50 |
| imbrandon | hrm heh , well it would just bee the system that kicks those off | 00:50 |
| imbrandon | yea | 00:51 |
| marcoceppi | chefnewbie: you can browse what hooks make a charm at any of the charms here: http://jujucharms.com/charms | 00:51 |
| imbrandon | and keeps info about all the nodes | 00:51 |
| chefnewbie | 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 |
| imbrandon | 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:52 |
| imbrandon | and keeps track of weach service and its state | 00:53 |
| chefnewbie | thanks, I think I should be looking at Juju doc more. | 00:53 |
| chefnewbie | You guys are really supportive, many thanks | 00:54 |
| chefnewbie | what is the juju's license term? | 00:54 |
| imbrandon | yea thats one good thin, even as quick as juju is moveing the docs stay pretty upto date | 00:54 |
| imbrandon | they are great about that | 00:54 |
| chefnewbie | AGPL 3.0? what does that mean? | 00:54 |
| imbrandon | gpl 3 iirc, for the program its self, chamrs are lic on their own | 00:54 |
| imbrandon | charms* | 00:54 |
| imbrandon | afro gpl v3 | 00:55 |
| chefnewbie | yep, it is agpl v3. | 00:55 |
| imbrandon | but yea charms are lic individually they arent derivitive works | 00:56 |
| imbrandon | of juju at leaste | 00:56 |
| marcoceppi | 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:56 |
| imbrandon | marcoceppi: really ? shit mine is gpl v2 and that means drupal will never be in the cs | 00:57 |
| marcoceppi | s/must be at least GPLv3/must be under a free license: http:\/\/www.opensource.org\/licenses\// | 00:57 |
| imbrandon | ahhh ok | 00:57 |
| imbrandon | good god | 00:57 |
| imbrandon | :) | 00:57 |
| marcoceppi | Yes, I escape my chat regex lines. | 00:58 |
| imbrandon | ahahah | 00:58 |
| marcoceppi | GPLv3 is just recommended | 00:58 |
| imbrandon | 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:58 |
| chefnewbie | AGPL v3 is stricter than GPL v3? | 00:59 |
| imbrandon | chefnewbie: it covers webservice stuff | 00:59 |
| imbrandon | iirc | 00:59 |
| chefnewbie | imbrandon: what does this mean ("covers webservice stuff")? | 01:00 |
| chefnewbie | if someone use juju to provide a service like RightScale, it needs to pay license fee? | 01:00 |
| imbrandon | 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:00 |
| imbrandon | chefnewbie: and no | 01:01 |
| imbrandon | chefnewbie: only the src to juju, unless your modify juju to actually provide the web ui | 01:01 |
| imbrandon | if its a tools calleed on the backend | 01:01 |
| imbrandon | then no | 01:01 |
| imbrandon | you can write a webui and be 100% closed and still "call out" to juju | 01:02 |
| imbrandon | as a back end program as you would with say ummm ssh or somehting | 01:02 |
| chefnewbie | hmm, then please give me a scenario that I need to give out src, please. | 01:03 |
| imbrandon | 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:03 |
| chefnewbie | thanks, this is simple and easy to understand (for now, for my 101 understanding) | 01:04 |
| imbrandon | 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:04 |
| imbrandon | basicly if you dont madify juju your golden | 01:05 |
| imbrandon | and charms dont cound as part of juju | 01:05 |
| imbrandon | count* | 01:05 |
| imbrandon | okies, dinner time | 01:05 |
| imbrandon | afk a bit fellas | 01:05 |
| chefnewbie | many thanks, imbrandon | 01:06 |
| imbrandon | np | 01:06 |
| _mup_ | Bug #992329 was filed: Ensure Invoker.start is called from UnitRelationLifecycle usage. <juju:In Progress by jimbaker> < https://launchpad.net/bugs/992329 > | 01:06 |
| chefnewbie | thanks to marcoceppi, too. | 01:06 |
| imbrandon | btw , the internet meme applies IANAL :) | 01:08 |
| jimbaker | 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 |
| imbrandon | ( i am not a lawyer ) | 01:08 |
| imbrandon | chefnewbie: ^^ | 01:08 |
| jimbaker | (the only other change was to make it slightly more verbose on logging the caching of the relation hook contexts) | 01:09 |
| chefnewbie | yeah, layers make big bucks for good reason :-) | 01:09 |
| imbrandon | yup yup , just wanted to make sure, when it comes down to it , get real advice, but thats the general gist of it | 01:09 |
| chefnewbie | yeah, just get a ballpark of what I should pay attention to when thinking of choosing a technology for our small shop... | 01:10 |
| imbrandon | yup, you should be perfectly fine imho | 01:11 |
| chefnewbie | will ask 201 questions once I get another depth of understanding... | 01:11 |
| imbrandon | :) | 01:11 |
| chefnewbie | after that, layers get consulting checks :-) | 01:11 |
| imbrandon | heh | 01:12 |
| chefnewbie | thanks again, you have a good dinner time... | 01:12 |
| imbrandon | 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 |
| imbrandon | but if not you know :) | 01:12 |
| _mup_ | juju/unit-rel-lifecycle-start-invoker r534 committed by jim.baker@canonical.com | 01:37 |
| _mup_ | Fixed tests that saw augmented log changes | 01:37 |
| SpamapS | imbrandon: git is great, but the charm store lives in launchpad. can you push to a launchpad branch please? | 04:39 |
| imbrandon | 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 |
| imbrandon | but yea in the intrest of time right now i will :) | 05:32 |
| SpamapS | who? | 06:03 |
| SpamapS | who decided that? | 06:03 |
| SpamapS | imbrandon: I'm supportive of those who would shun git | 06:03 |
| SpamapS | but we have a distribution built on bzr | 06:03 |
| SpamapS | err | 06:03 |
| SpamapS | I'm supportive of those who would *use* git | 06:03 |
| SpamapS | 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 |
| SpamapS | imbrandon: where is it documented btw? | 06:04 |
| SpamapS | 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 |
| SpamapS | juju has no such method | 06:06 |
| SpamapS | so it is effectively GPLv3 | 06:06 |
| nathwill | SpamapS: https://juju.ubuntu.com/Charms | 06:07 |
| nathwill | in answer to your github question | 06:07 |
| SpamapS | yeah, thats confusing | 06:09 |
| SpamapS | since we've never discussed that as a group | 06:09 |
| SpamapS | nor have I ever looked at the github pull requests to see if there are new charms there | 06:09 |
| imbrandon | :) | 06:10 |
| SpamapS | nathwill: thanks tho | 06:10 |
| nathwill | fer sure. | 06:10 |
| imbrandon | SpamapS: iirc m_3 is writing some glue so LP wont need to support git | 06:11 |
| imbrandon | for the cs | 06:11 |
| imbrandon | using bzr-git-ng | 06:11 |
| imbrandon | least thats how jcastro splained it to me | 06:11 |
| imbrandon | anyhow i pushed the latests newrelic-php to LP and fixed up the bug | 06:11 |
| imbrandon | its ready for your worst | 06:12 |
| imbrandon | i got some more commits for drupal before i'm happy but working on them now | 06:12 |
| imbrandon | just had to stop for a omg hiccup | 06:12 |
| SpamapS | awesome | 06:12 |
| imbrandon | but back at it , i am | 06:12 |
| SpamapS | 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 |
| imbrandon | hahah np | 06:13 |
| imbrandon | i totaly understand | 06:13 |
| imbrandon | i think thats one reason he was like, yea do it that way, so we're forced to learn the workflow | 06:13 |
| imbrandon | like almost exact words :) | 06:13 |
| SpamapS | man | 06:14 |
| SpamapS | I hate that idea | 06:14 |
| SpamapS | lets have one workflow | 06:14 |
| SpamapS | choices lead to mistakes | 06:14 |
| imbrandon | heh | 06:14 |
| imbrandon | we're talking ppl that should be devs | 06:14 |
| SpamapS | 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:14 |
| imbrandon | 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 |
| SpamapS | Its an efficiency blunder | 06:15 |
| SpamapS | Debian has that ethos | 06:15 |
| imbrandon | nah | 06:15 |
| SpamapS | "choice is the almighty" | 06:15 |
| imbrandon | just make the tools work | 06:15 |
| imbrandon | like the glue to import from github :) | 06:15 |
| SpamapS | 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 |
| imbrandon | see i like the midground | 06:15 |
| imbrandon | not too man but dont cut my fingers off | 06:15 |
| imbrandon | many* | 06:16 |
| SpamapS | If its as superior as people seem to think.. | 06:16 |
| SpamapS | then it will win out with users anyway | 06:16 |
| imbrandon | it has | 06:16 |
| imbrandon | thst the problem :) | 06:16 |
| SpamapS | But it *has* to be on launchpad. | 06:16 |
| nathwill | oh snap | 06:16 |
| SpamapS | *has to be* | 06:16 |
| imbrandon | your statements just contradictoed | 06:17 |
| imbrandon | themselfs | 06:17 |
| nathwill | SpamapS, doesn't launchpad already have mechanisms for registering upstreams and importing from various VCS systems? | 06:17 |
| nathwill | automagically? | 06:17 |
| SpamapS | 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 |
| imbrandon | nathwill: yea for projects nothing else | 06:17 |
| nathwill | hrm | 06:17 |
| nathwill | bet that functionality could be leveraged pretty easily | 06:17 |
| SpamapS | nathwill: yes, launchpad can import from github | 06:17 |
| SpamapS | we can do that | 06:17 |
| SpamapS | But we lose linked branches | 06:18 |
| SpamapS | and linked merge proposals | 06:18 |
| imbrandon | 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 |
| imbrandon | :) | 06:18 |
| imbrandon | imho its LP thats broke tho not the cs or github, it should be easy to support both | 06:20 |
| imbrandon | i see your grip as its not now | 06:20 |
| imbrandon | but thats the problem , not that users wanna use something else | 06:20 |
| SpamapS | OpenStack has proved that you can successfully have LP for bugs and git for all else. | 06:20 |
| imbrandon | ok then let us do it | 06:21 |
| SpamapS | But, thats at the project level. We're building a distro with potentially thousands of branches. | 06:21 |
| imbrandon | exxactly a LP peroblem | 06:21 |
| imbrandon | SpamapS: whats 1k;s of branches got to do with it, branches are cheap | 06:21 |
| SpamapS | imbrandon: the management of them, is not. | 06:21 |
| nathwill | SpamapS: ah, i see what you're saying about losing merge proposals/links | 06:22 |
| imbrandon | the management of them is automated either way or should be | 06:22 |
| SpamapS | no, bugs cannot be automated | 06:22 |
| SpamapS | else we'd have entered the singularity and be fighting off skeletal robots | 06:22 |
| imbrandon | 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:22 |
| SpamapS | I'm honestly ignorant of any other bug system that allows bug tracking across concerns the way LP does. | 06:23 |
| imbrandon | 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:23 | |
| imbrandon | SpamapS: inho that a useability nightmre and should be removed with fire | 06:24 |
| SpamapS | 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 |
| imbrandon | yes | 06:24 |
| imbrandon | make 10000000 ppl change or fix the tool ? hrm | 06:25 |
| SpamapS | 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 |
| imbrandon | or fix lp to relate to github bugs and branches as well | 06:25 |
| imbrandon | or twoway mirror git | 06:25 |
| imbrandon | or both | 06:25 |
| SpamapS | linking to an external bug tracker is not really what I"m talking about | 06:26 |
| imbrandon | 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 |
| imbrandon | etc | 06:27 |
| SpamapS | 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 |
| imbrandon | yea its not the one ring but still works great | 06:27 |
| SpamapS | 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:27 |
| imbrandon | 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:28 |
| imbrandon | either way as much as we want it to be it CANNOT be absolutely tied to LP or any ONE place | 06:29 |
| imbrandon | even github | 06:29 |
| imbrandon | so to fix it, we make LP the easiest way, and supopiort the other ways without hacks | 06:29 |
| SpamapS | err | 06:29 |
| SpamapS | somehow ubuntu succeeds where this will fail? | 06:30 |
| imbrandon | ubuntu did only because it already had critical mass | 06:30 |
| imbrandon | it took years | 06:30 |
| imbrandon | and juju dont have that mass | 06:30 |
| SpamapS | I come at it from a different angle | 06:30 |
| SpamapS | The tools are of some slight concern | 06:31 |
| nathwill | that maas | 06:31 |
| SpamapS | but as long as I know *how* to contribute | 06:31 |
| SpamapS | I don't care that its not my favorite method | 06:31 |
| SpamapS | If there are 49 islands out there with charms on them | 06:31 |
| SpamapS | how do I pick one? | 06:31 |
| SpamapS | paradox of choice | 06:31 |
| imbrandon | 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:31 |
| imbrandon | if they are forced to choose they WILL choose github | 06:32 |
| SpamapS | So, VCS is all on LP, or its all somewhere else. | 06:32 |
| imbrandon | and make their own | 06:32 |
| imbrandon | why | 06:32 |
| imbrandon | why not support both | 06:32 |
| SpamapS | github is great, but this is still different | 06:32 |
| SpamapS | in fact | 06:32 |
| imbrandon | vcs is distributed for a rewason | 06:32 |
| imbrandon | it shoud not matter where it is | 06:32 |
| SpamapS | 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 |
| nathwill | 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 |
| imbrandon | no | 06:33 |
| imbrandon | omg no | 06:33 |
| imbrandon | nathwill: your right but they choose to contrib to it or not based on that | 06:33 |
| imbrandon | and the frequency of their conriubs | 06:33 |
| imbrandon | SpamapS: your missing my point entirely tho | 06:34 |
| imbrandon | and its hard for me on irc to articulate it | 06:34 |
| SpamapS | 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 |
| imbrandon | 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 |
| imbrandon | SpamapS: thats an infrastructure problem for the store, should not be a user issue in any way | 06:35 |
| imbrandon | transparent | 06:35 |
| SpamapS | 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:36 |
| imbrandon | 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:38 |
| imbrandon | 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 |
| SpamapS | 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 |
| SpamapS | note, bzr, lp, not mentioned | 06:39 |
| imbrandon | SpamapS: hehe | 06:39 |
| imbrandon | sure tho | 06:39 |
| imbrandon | and i fully suport that | 06:39 |
| imbrandon | but then drop down on step | 06:39 |
| imbrandon | thats at the store level no one else care | 06:40 |
| lifeless | mmm skeletal robots | 06:40 |
| imbrandon | so at the next meta step down in distrib vcs | 06:40 |
| imbrandon | they are all over the place | 06:40 |
| SpamapS | dvcs is fine | 06:40 |
| imbrandon | so make some glue to brong em togtaher and your both happy | 06:40 |
| SpamapS | but the *official* charms need a single place to tie them together | 06:40 |
| SpamapS | there needs to be *a mainline* | 06:40 |
| imbrandon | they are in the storwe with a vcs | 06:40 |
| SpamapS | I know, git blasphemy | 06:40 |
| imbrandon | no | 06:41 |
| imbrandon | no | 06:41 |
| imbrandon | absolutely not | 06:41 |
| imbrandon | ok | 06:41 |
| imbrandon | every app in itunes is in one place | 06:41 |
| SpamapS | imbrandon: I don't have to make that glue. LP exists, and does this, now. | 06:41 |
| imbrandon | every dev has crap everywhere | 06:41 |
| imbrandon | SpamapS: LP is fucking broken if it wont support that then | 06:41 |
| SpamapS | and bzr is not limiting in any way other than politics. | 06:41 |
| imbrandon | there is no glue | 06:41 |
| imbrandon | bullshit | 06:42 |
| imbrandon | it fucked up the omg merges 3 or 4 times last month where git worked perfect | 06:42 |
| SpamapS | this is editor wars. ;) | 06:42 |
| SpamapS | imbrandon: perhaps because it was git users trying to use bzr the wrong way? :) | 06:42 |
| imbrandon | ok look, itunes, apps all in one place, all reviews by apple, all done in diffrent palces | 06:43 |
| imbrandon | why do i care that apple wants to keep them all in an NFS share on win3.1 | 06:43 |
| imbrandon | i dont | 06:43 |
| SpamapS | 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 |
| imbrandon | once they take it to review i dont care at all | 06:43 |
| imbrandon | that dont fix tthe probme | 06:43 |
| imbrandon | gaqd i hate irc | 06:43 |
| SpamapS | imbrandon: app store apps are not integrated with one another | 06:44 |
| imbrandon | it lets the issue get away | 06:44 |
| SpamapS | they are, in fact, an island unto themselves. | 06:44 |
| imbrandon | SpamapS: they certainly are | 06:44 |
| imbrandon | no | 06:44 |
| imbrandon | in store purchaes , receipts | 06:44 |
| imbrandon | all kinda intergrations | 06:44 |
| imbrandon | but that dont matter either | 06:44 |
| imbrandon | wtf | 06:44 |
| imbrandon | ugh | 06:44 |
| imbrandon | you totally side steped it | 06:45 |
| SpamapS | Its pretty rare, right? | 06:45 |
| SpamapS | 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 |
| imbrandon | 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:45 |
| SpamapS | Because you need your charm to work w/ mysql/memcached/etc. | 06:46 |
| imbrandon | 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 |
| imbrandon | hplly shit | 06:46 |
| imbrandon | SpamapS: | 06:46 |
| imbrandon | common man | 06:46 |
| imbrandon | i'm not even on that subject | 06:46 |
| imbrandon | that has to do with zk and juju when running | 06:46 |
| imbrandon | wtf does it have to do with the store | 06:46 |
| imbrandon | then the vcs the store uses | 06:46 |
| SpamapS | 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 |
| SpamapS | of course | 06:47 |
| SpamapS | there's no trust relationship with those URLs | 06:47 |
| imbrandon | umm thats how it shouldbe , maybe a db ya know ,21k centry and all | 06:47 |
| SpamapS | ~charmers is a trusted party, like ubuntu-core-dev | 06:47 |
| imbrandon | and ? | 06:48 |
| SpamapS | so right now we own all the branches and review all changes made to them | 06:48 |
| imbrandon | 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 |
| imbrandon | or at minimum into the charmers repo | 06:48 |
| imbrandon | on approval | 06:48 |
| SpamapS | cs *does* in fact work directly off ~charmers (well, lp:charms, same diff as its owned by ~charmers) for cs:series/charmname | 06:49 |
| imbrandon | that is done by hand as well as trust verify | 06:49 |
| imbrandon | ok my point still stands sans the first part | 06:49 |
| imbrandon | ( and wow really? ewwww ) | 06:49 |
| SpamapS | 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 |
| imbrandon | or we could fix LPO to do it too | 06:50 |
| imbrandon | and everyone benefits | 06:50 |
| SpamapS | imbrandon: cs:~user/series/charmname can be any LP user | 06:50 |
| imbrandon | SpamapS: i know but that dont mean the cs | 06:50 |
| imbrandon | well whatever | 06:50 |
| imbrandon | thats just routing like in a django app | 06:51 |
| imbrandon | could be anything | 06:51 |
| imbrandon | semantics | 06:51 |
| SpamapS | 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 |
| imbrandon | brew install jujutools/juju is the same as ~/jujutools/Forumla/juju.rb tooo | 06:51 |
| SpamapS | and furthermore, the process, while not super desirable, is single threaded and easy to follow right now | 06:52 |
| imbrandon | for that matter, its all routing | 06:52 |
| SpamapS | so until the glue exists | 06:52 |
| imbrandon | SpamapS: yes but then it needs to be , we shouldent do something the wrong way because of it | 06:52 |
| SpamapS | I do not want to pollute the contribution process, as flawed as it may be, with more VCS's | 06:52 |
| imbrandon | so until it exists it should be manual | 06:52 |
| SpamapS | there is already some work inside juju to hide these details as well | 06:54 |
| imbrandon | right | 06:54 |
| imbrandon | as it should | 06:54 |
| SpamapS | 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 |
| imbrandon | cool but how would it verify me then | 06:54 |
| SpamapS | (but this gets into where now they are playing a weird game w/ VCS because of that revision file..) | 06:54 |
| imbrandon | oh wait | 06:54 |
| SpamapS | imbrandon: same way LP does, ssh key | 06:55 |
| imbrandon | i would have to care and put a ssh key | 06:55 |
| imbrandon | :) | 06:55 |
| SpamapS | or perhaps OAuth | 06:55 |
| nathwill | imbrandon, you do for github as well... | 06:55 |
| imbrandon | nathwill: sure but i care for github | 06:55 |
| imbrandon | :) | 06:55 |
| imbrandon | i was playing devils advocate as in yes charmers will still need to care and strust lp | 06:55 |
| imbrandon | but users wont | 06:56 |
| imbrandon | but thats minor | 06:56 |
| SpamapS | users are implicitly trusting ~charmers if they deploy charms unqualified w/ username | 06:56 |
| imbrandon | jup | 06:56 |
| imbrandon | sure | 06:56 |
| imbrandon | and ? | 06:56 |
| SpamapS | well its really a trust transfer | 06:57 |
| SpamapS | since they get juju from Ubuntu or a PPA, they are already trusting those entities | 06:57 |
| SpamapS | or brew.. :) | 06:57 |
| imbrandon | see the whole thing here is you are working with tools that exist only, instead of how the ideal situation is an going there | 06:57 |
| SpamapS | idealism is the quickest path to failurre | 06:57 |
| imbrandon | not with release eaarly and often | 06:58 |
| SpamapS | "My goal is perfection." ... you have just failed. | 06:58 |
| imbrandon | iteration is the quickest path to success | 06:58 |
| SpamapS | yeah, we're going to iterrate | 06:58 |
| SpamapS | a LOT | 06:58 |
| imbrandon | ok so in the meantime that means some things are a bit un fun or suck like manually pulling github , untill its iterated that lp can pull shiut in like it should | 06:59 |
| SpamapS | But I'd like to keep that iterration focused on things that clarify the picture for new contributors, not muddy the waters. | 06:59 |
| imbrandon | ios my WHOLE point | 06:59 |
| imbrandon | SpamapS: all the more reason to leave it that way then as it will work someday | 06:59 |
| SpamapS | so basically "please bend over backward for me because I don't have time to write a tool as powerful as LP with my preferred VCS available?" | 06:59 |
| imbrandon | and not change it then go back and say oh but now its ok | 07:00 |
| SpamapS | I'm down with that. :) | 07:00 |
| SpamapS | <-- seriously will bend over backward for anybody who writes a charm | 07:00 |
| imbrandon | SpamapS: no | 07:00 |
| imbrandon | fuck man | 07:00 |
| SpamapS | I'm serious. :) | 07:00 |
| imbrandon | i hate that, what does that have to do with it= | 07:00 |
| SpamapS | (^) I will look like that | 07:00 |
| imbrandon | yea but you just threw awaay when i thought you finaly understood | 07:00 |
| SpamapS | well pulling git branches manually is bending over backward | 07:01 |
| SpamapS | and I'm willing to do it. | 07:01 |
| imbrandon | the bug tracking and awesomness of lp KEEP, force bzr dont | 07:01 |
| imbrandon | if it pains you that you cannot pull git into your store | 07:01 |
| imbrandon | fix the store | 07:01 |
| SpamapS | I'm just not willing to do it forever. | 07:01 |
| imbrandon | right but why muddy the waters | 07:02 |
| imbrandon | and make a policy change then to stop it | 07:02 |
| imbrandon | and then start it or say "but now its ok" | 07:02 |
| imbrandon | later ? | 07:02 |
| imbrandon | or leave as is, and as you put it take one | 07:02 |
| imbrandon | till its fixed | 07:02 |
| SpamapS | Adding things slowly, as you understand their impact better, is a good method of iterration. | 07:03 |
| imbrandon | it can be | 07:03 |
| SpamapS | It will be very hard to convince me that the "how to submit a charm" page should have more than one method. | 07:04 |
| SpamapS | I hope when juju grows a 'publish' command, that we can just ditch the BZR instructions entirely | 07:04 |
| imbrandon | damnit man, screw all this lets do it over beer as its not gonna change this week , and prom my newrelic | 07:05 |
| imbrandon | :) | 07:05 |
| SpamapS | We *SHOULD* say "if you want to use git, do x, y, z, to get your git branch in front of us." | 07:05 |
| imbrandon | agreed on the publish | 07:05 |
| imbrandon | nah | 07:05 |
| imbrandon | it should only take a gpg signed tarbal, quit thinking of lone devlopers, on their side 5 ppl might need to sign off on the release before sumitting to the itunes^W store | 07:06 |
| SpamapS | Right now that bit is "push your git branch to a bzr branch, then follow all these other steps like bzr users do" | 07:06 |
| imbrandon | rember this has all been done before and will all be done again, juju is NOT the first to havetheese problems, amazon, apple, google, and COUNTLESS others | 07:07 |
| SpamapS | imbrandon: I have definitely considered the team story a lot. We suggest in the policy that if a team wants to own a branch we're willing to share ownership of it. | 07:07 |
| imbrandon | SpamapS: right, imho any form os submition that is not under lock and https key via a single signed archie | 07:08 |
| imbrandon | like ohhhh hte deb build servers | 07:08 |
| imbrandon | is wrong | 07:08 |
| SpamapS | ~charmers is as secure as ubuntu-core-dev in theory. | 07:08 |
| imbrandon | thats how you solve the trust issue,i sign the package for relewase with gpg or whatever | 07:09 |
| imbrandon | publish on that not if i';its in a certain vcs | 07:09 |
| SpamapS | in practice, I have not reviewed the cs: code to see if it actually does https verification | 07:09 |
| imbrandon | zomg | 07:09 |
| SpamapS | I just now got EC2 doing that | 07:09 |
| imbrandon | wtf does that have to do with it | 07:09 |
| imbrandon | ~chamers dont let me upload | 07:09 |
| SpamapS | yes it does! | 07:09 |
| imbrandon | it dont take tarbalss | 07:09 |
| imbrandon | it dont take zips | 07:10 |
| imbrandon | iot dont verify gpog | 07:10 |
| SpamapS | ~charmers takes bzr push which is as good as an upload | 07:10 |
| imbrandon | nope | 07:10 |
| SpamapS | SSH keys are the exact same crypto as GPG | 07:10 |
| imbrandon | only if you use bzr it is | 07:10 |
| imbrandon | then again your forcing somehting on the submistions that effect code | 07:10 |
| SpamapS | the publish code will just talk to the cs: daemon and verify that you have write access via cryptographic means, then publish whatever you ask it to. This will have to make use of public key crypto in some form, either local client SSL certs, or gpg keys, or SSH keys | 07:12 |
| imbrandon | right that verifies ME | 07:12 |
| imbrandon | what verifies my code | 07:13 |
| SpamapS | I do think we should be signing our commits | 07:13 |
| imbrandon | therre ya go | 07:13 |
| imbrandon | NOW | 07:13 |
| imbrandon | with what bzr ? | 07:13 |
| SpamapS | but there's nothing in there to verify those sigs | 07:13 |
| imbrandon | fail | 07:13 |
| imbrandon | sign a tarbal | 07:13 |
| imbrandon | SpamapS: so | 07:13 |
| SpamapS | <sigh> ... so much code you're suggesting we write | 07:13 |
| imbrandon | SpamapS: fix it, dont not do it cuz there is nothing to veruify | 07:13 |
| imbrandon | make something to verify | 07:13 |
| SpamapS | which should we do first? | 07:14 |
| imbrandon | SpamapS: sure | 07:14 |
| SpamapS | glue for github? | 07:14 |
| SpamapS | gpg signing of commits? | 07:14 |
| imbrandon | SpamapS: something of this magnatude IS alot of code | 07:14 |
| imbrandon | and alot of man hours etc | 07:14 |
| SpamapS | you see now why I don't want to f*** with the way LP+BZR are used, even though I know it must change. | 07:14 |
| SpamapS | I'm hoping its hidden from users | 07:15 |
| SpamapS | Also hoping ZK is hidden from the client | 07:15 |
| imbrandon | :) | 07:15 |
| SpamapS | imbrandon: you have brought up an important bug in my mind though, and I think we have to get this done sooner rather than later. | 07:16 |
| SpamapS | We have to start signing the code commits. | 07:16 |
| * imbrandon writes some git hooks to checkin and push bzr on push | 07:16 | |
| SpamapS | I know you're saying tarballs, but for now, bzr supports this. | 07:16 |
| imbrandon | right i get ya | 07:16 |
| imbrandon | babysteps | 07:16 |
| SpamapS | We have a closed authentication loop.. | 07:16 |
| SpamapS | but not a tamper proof repository | 07:16 |
| * SpamapS prepares a bug report | 07:17 | |
| imbrandon | really imho as much as it is diffrent it also is the same as packaging | 07:17 |
| imbrandon | e.g all brit or soyuz | 07:18 |
| SpamapS | imbrandon: yeah its integration, not development | 07:18 |
| imbrandon | etc steps | 07:18 |
| imbrandon | not the finished | 07:18 |
| imbrandon | product | 07:18 |
| imbrandon | i mean the charms | 07:18 |
| imbrandon | and how they are p[ublished | 07:18 |
| imbrandon | packaging not using a deb | 07:18 |
| imbrandon | your right charmer != kde dev, charmer == motu | 07:19 |
| imbrandon | security and steps should be similar to be published, anyone can make their own repo, to be in cs its some work] | 07:19 |
| SpamapS | imbrandon: yeah. The vision I have for this is that we have a single place for interested parties in a given service can collaborate on the best way to scale it, secure it, etc. etc. | 07:20 |
| imbrandon | me too, but just rember there can be lots of middleware | 07:21 |
| imbrandon | :) | 07:21 |
| SpamapS | imbrandon: so let the forks roll, but I'd prefer that the forks stay close to the cs: charm ... which probably means we need to have cs: charms pull from github or risk having forks go off the reservation. ;) | 07:22 |
| imbrandon | bah the place dont matter | 07:22 |
| imbrandon | if your tool dont support tracking them | 07:22 |
| imbrandon | SpamapS: see thats what i HATE about drupal, frak worring about if the charms go too far from the cs: make and trying to controll everything and pre think of everything | 07:23 |
| imbrandon | just make the cs: and the workflow that should be best | 07:23 |
| imbrandon | the easiest | 07:23 |
| imbrandon | and the most solid | 07:23 |
| imbrandon | then screw the rest, let em stray way the hell off | 07:24 |
| imbrandon | it will police it self eventually and then it wont happen | 07:24 |
| imbrandon | if its true | 07:24 |
| imbrandon | then we dont have to "over think shit" | 07:24 |
| imbrandon | we make a great store | 07:24 |
| imbrandon | and a great juju | 07:24 |
| imbrandon | and thats all | 07:24 |
| SpamapS | imbrandon: yeah, I don't want to control.. I want to enable actually. | 07:25 |
| SpamapS | imbrandon: I just want to maintain influence over the forks if I can. | 07:25 |
| imbrandon | right but there is a fine line | 07:25 |
| imbrandon | nag | 07:25 |
| imbrandon | nah | 07:25 |
| imbrandon | thats control , not enablement | 07:25 |
| SpamapS | like, if somebody just fundamentally does something that is awesome to some, but anathema to the cs policy.. I'm fine w/ that.. just keep the merges between us flowing. | 07:26 |
| SpamapS | imbrandon: influence means you maintain a voice, control means you squelch other voices. | 07:26 |
| SpamapS | I'll give up control gladly.. if they go away.. fine, we lose influence too. | 07:26 |
| imbrandon | well even thats against some of your coworkers, i was explained that every person should have their own local forks | 07:26 |
| imbrandon | thats what was wnanted | 07:26 |
| SpamapS | *bwahahahahaha* | 07:27 |
| SpamapS | yeah | 07:27 |
| SpamapS | Thats going to be *AWESOME* | 07:27 |
| SpamapS | right? | 07:27 |
| imbrandon | i think so, everyone has their own cookbooks | 07:27 |
| imbrandon | *chef* | 07:28 |
| SpamapS | so | 07:28 |
| SpamapS | why not just use chef? | 07:28 |
| SpamapS | its more mature | 07:28 |
| imbrandon | zomg | 07:28 |
| imbrandon | ok _everytolls_ has their own local configs | 07:28 |
| imbrandon | tool* | 07:28 |
| imbrandon | irc , missing , point, context sucks, ugh | 07:29 |
| SpamapS | I'm hoping we can shake that kind of B.S. out of ops thinking | 07:29 |
| SpamapS | no I get what you mean :) | 07:29 |
| SpamapS | I was a busy op once upon a time | 07:29 |
| SpamapS | and I didn't have time to contribute back either | 07:29 |
| imbrandon | no you dont, you want ever site to be configured exactly the same on the internet ? yea THATS gonna work | 07:29 |
| SpamapS | I'd just apt-get source.. change something, build it, install it, and forget about it | 07:29 |
| imbrandon | no charms will always need local mods | 07:29 |
| imbrandon | SpamapS: excactly | 07:30 |
| SpamapS | long term, I'd like for juju to give users a single cmdline opportunity to turn that into a merge proposal against the charm you just forked. | 07:30 |
| imbrandon | SpamapS: but that is absolutely needed | 07:30 |
| imbrandon | juju will FAIL if not | 07:30 |
| imbrandon | rember the php talk we had | 07:30 |
| SpamapS | yeah I'll enable that | 07:30 |
| imbrandon | you NEED to be abloe to do it | 07:30 |
| SpamapS | I'll enable forking and forgetting | 07:30 |
| SpamapS | I want to also enable forking and feeding back | 07:31 |
| imbrandon | fast and not give two craps | 07:31 |
| imbrandon | SpamapS: exactly | 07:31 |
| imbrandon | but enable dont hunder | 07:31 |
| imbrandon | hinder | 07:31 |
| SpamapS | because the next time we update the charm w/ awesomeness | 07:31 |
| imbrandon | your mixing the two | 07:31 |
| SpamapS | and they can't use said awesomeness because they have to merge w/ us | 07:31 |
| imbrandon | they will learn | 07:31 |
| imbrandon | exactly | 07:31 |
| SpamapS | I want it to be obvious how to say "crap, I don't want to maintain my awesomeness anymore" | 07:31 |
| imbrandon | thats bullshit | 07:32 |
| imbrandon | thats the same kinda of billshit that is "dont hack core" of drupal | 07:32 |
| SpamapS | and if that is just 'juju propose-merge cs:~myuser/precise/foo' | 07:32 |
| imbrandon | we make software like this to enable ops and dev | 07:32 |
| SpamapS | and it just creates a bug, proposes the merge, and moves on with life.. *zang* | 07:32 |
| imbrandon | not to make them do it our way | 07:32 |
| SpamapS | we win | 07:32 |
| imbrandon | bah | 07:32 |
| imbrandon | thats ignorant and arrogant | 07:32 |
| SpamapS | what would you propose differently? | 07:33 |
| imbrandon | we need to make the tools good, so good there is no question about the process, NOT make them do shit the way we think it should be | 07:33 |
| imbrandon | at all | 07:33 |
| SpamapS | uhm.. ok? | 07:34 |
| SpamapS | I just said that?? | 07:34 |
| imbrandon | no, you said how it would be ideal now if they was so incliuned | 07:34 |
| imbrandon | and not have their own agenda | 07:34 |
| imbrandon | not how the best tool would make that not even matter | 07:34 |
| SpamapS | Yeah I guess I'm failing to see where we got disconnected. | 07:35 |
| imbrandon | yea, i cant get enough speed out of my keyboard to get my full point accross | 07:35 |
| SpamapS | I'm saying, they're off in their own world and it gets harder and harder to maintain that long term... we should make it easy for them to get back on the mainline by submitting their stuff for inclusion. | 07:35 |
| imbrandon | or even a good chunk of it | 07:35 |
| imbrandon | SpamapS: ok stop | 07:35 |
| imbrandon | read | 07:36 |
| imbrandon | that again | 07:36 |
| imbrandon | what you just said | 07:36 |
| imbrandon | ok see, thats where | 07:36 |
| imbrandon | we fix the problem of it becominng harder and harder, not just make another damn tool that enforces that to be the hardwr way | 07:36 |
| SpamapS | go through the scenario, only the way you'd see it working, instead of my arrogance :) | 07:36 |
| imbrandon | not all stuff is or will be suitable for includsion | 07:37 |
| imbrandon | nor will they goive two damns if it is | 07:37 |
| imbrandon | even if its easy | 07:37 |
| imbrandon | so we need to make it easy for them to stay inline IF we even want to at all | 07:37 |
| imbrandon | without any | 07:37 |
| imbrandon | expectations of them | 07:38 |
| imbrandon | none | 07:38 |
| SpamapS | how? | 07:38 |
| imbrandon | that needs to be worked out by us group of smart ppl, isnt that why we're here | 07:38 |
| SpamapS | code changes, forks beget merges.. this is a constant that I cannot see being factored out | 07:38 |
| imbrandon | or are we just making something else thats already out there with another companies name on it | 07:38 |
| imbrandon | the only thing constant in the universe is c | 07:39 |
| SpamapS | we can minimize it, sure. we can have more declarative, simple to merge stuff in charms. I've proposed that for charm helpers already. | 07:39 |
| imbrandon | 5 years ago we would have got laughed at for a tool like juju as its not needed for those kids playing in the cloud | 07:39 |
| imbrandon | shit chnages fast | 07:39 |
| imbrandon | then lets work to minimising it, and then again and again, and seriously not worry about the voice | 07:40 |
| SpamapS | but if we both change the same bit of a charm, for good reasons.. thats not going to resolve itself. | 07:40 |
| imbrandon | it will be there if we do that | 07:40 |
| imbrandon | SpamapS: gawd man you get tied up in the technical bits like they cant be changed | 07:41 |
| imbrandon | then lets fix ist or find another route etc | 07:41 |
| SpamapS | I don't think a realistic goal of juju is "solve the problem of merging forks" | 07:41 |
| imbrandon | then it cant enable forking | 07:42 |
| SpamapS | you may need some sleep or something. | 07:42 |
| imbrandon | mqybe not from day one, maybe not by me and you but it needs to | 07:42 |
| imbrandon | no | 07:42 |
| SpamapS | We're already aiming at the stars w/ juju. :) | 07:42 |
| imbrandon | :)' | 07:43 |
| imbrandon | and i just woke up damn you | 07:43 |
| imbrandon | lol | 07:43 |
| imbrandon | i'm just really set on not letting ppl think that old way | 07:43 |
| imbrandon | in anything software eng, not just juju | 07:43 |
| imbrandon | its too wrong and 15 years old | 07:44 |
| SpamapS | What old way? | 07:44 |
| imbrandon | the way i cant get you to seem to even notice i've been talking about a diffrent one for an hour | 07:44 |
| imbrandon | heh | 07:44 |
| SpamapS | is this "have a trunk" vs "there is no trunk" ? | 07:44 |
| imbrandon | lol no, its if you have a blue button in the website and a user cant click his mouse on the button cuz he is color blind , what do you do, fix the button ? i say make it able to preform the command via voice | 07:46 |
| imbrandon | ( example is not practical but the idea of night and day ) | 07:46 |
| SpamapS | so, we should make juju impervious to color blind users (aka, Solaris admins?) | 07:47 |
| imbrandon | i want new software to fix the real problems , not fix the ones they can and try and control the ones they cant | 07:47 |
| imbrandon | LOL | 07:47 |
| SpamapS | I think I get that | 07:47 |
| SpamapS | You do realize that juju is pushing *REALLY* hard to be disruptive, and change the way people think about services/machines/etc., right? Its not like we picked the tiniest problem and went to tackle that first. | 07:48 |
| imbrandon | hahah | 07:49 |
| imbrandon | right | 07:49 |
| imbrandon | another reason i'm so adament about it | 07:49 |
| SpamapS | So there's also such a thing as focus | 07:49 |
| imbrandon | and why we cant force things, that we need to embracce they way it flows and enable THAT way to be bets | 07:49 |
| imbrandon | even if we dont think it is | 07:49 |
| imbrandon | we make it the best it could be , and then encpourage others | 07:49 |
| imbrandon | not say "no" and encourage other | 07:50 |
| imbrandon | SpamapS: sure focus, but we need to also grow fast, imho every canonical employee and then some could be on this and it would not be enough just yet | 07:51 |
| imbrandon | like you said to be distruptive takes alot fo work ( to get right ) | 07:51 |
| imbrandon | one way to do that is enable EVERYONE even the stuff we dont like | 07:52 |
| SpamapS | The nice thing about being disruptive though is that you can bet on others saying your idea is worthless for a while. :) | 07:52 |
| imbrandon | once we have critical mass then start making things more ideal | 07:52 |
| imbrandon | heh | 07:52 |
| SpamapS | imbrandon: shotgun approach is not really my cup of tea. I'd like to win over the influencers first. | 07:52 |
| SpamapS | imbrandon: I welcome all with open arms, but I seek out a few key types. | 07:53 |
| imbrandon | sure those key types will be quick to bury you too tho | 07:53 |
| SpamapS | indeed, I want their raw unadulterated feedback | 07:53 |
| imbrandon | look at the mass exodus over the last 2 years at google | 07:53 |
| imbrandon | and the rewasons for it | 07:54 |
| imbrandon | they are all the same | 07:54 |
| SpamapS | yeah, it created a nice sucking void that pulled Canonical people into it. ;) | 07:54 |
| imbrandon | google was king | 07:54 |
| imbrandon | LOL | 07:54 |
| SpamapS | oh now you're going to tell me google is dead | 07:54 |
| imbrandon | no not dead | 07:54 |
| SpamapS | "was king" | 07:54 |
| imbrandon | but that they have left room for compatition | 07:54 |
| SpamapS | so has microsoft | 07:55 |
| imbrandon | as in the king got marriwd and has tons of inlaws | 07:55 |
| imbrandon | so maybe the prince wont be the next king, maybe his new nephew in law will | 07:55 |
| imbrandon | :) | 07:55 |
| imbrandon | google is too worried about facbook , and forced g+ on employees, a company that used to foster inovation , now forces their innovators into a single stream of g+ or its shit | 07:56 |
| imbrandon | thus the innovators left, quickly | 07:56 |
| imbrandon | and made it very clear as to why | 07:56 |
| imbrandon | http://blogs.msdn.com/b/jw_on_tech/archive/2012/03/13/why-i-left-google.aspx | 07:58 |
| imbrandon | not even quote a month ago | 07:58 |
| imbrandon | SpamapS: ^^ gogo read that whole post | 07:58 |
| SpamapS | meh I've read enough of the same type of arguments | 07:59 |
| SpamapS | and I think they're wrong frankly | 07:59 |
| imbrandon | no this is from an exac | 07:59 |
| SpamapS | being at war means making hard decisions | 08:00 |
| imbrandon | and exec and its personal | 08:00 |
| imbrandon | Publishers willing to put the Facebook brand before their own. Exhibit A: www.facebook.com/nike, a company with the power and clout of Nike putting their own brand after Facebook’s? No company has ever done that for Google and Google took it personally. | 08:00 |
| SpamapS | google was at peace for a long time.. going to war is going to chase off some peace loving folk | 08:00 |
| imbrandon | SpamapS: ok sure, i'll buy into that, but their culture was those ppl | 08:01 |
| imbrandon | if they leave its not google | 08:01 |
| SpamapS | and clinging to that would probably mean death | 08:01 |
| imbrandon | nah, its made them a billion dollar company, trying to force somehting will be theior daeth,. they need to embrace the change | 08:02 |
| imbrandon | like they would have 10 years ago | 08:02 |
| SpamapS | Taking it personally seems a bit silly.. but.. I get it. "Oops, we f'd up and thought nobody would abuse power because we wouldn't abuse our power" | 08:02 |
| SpamapS | I think this is just their way of embracing change. | 08:02 |
| SpamapS | but I could be very wrong | 08:02 |
| SpamapS | I am poorly informed, and DEFINITELY bike shedding now | 08:03 |
| imbrandon | pretty sure your wrong on this one | 08:03 |
| imbrandon | hehe | 08:03 |
| * SpamapS holds up mirror to imbrandon | 08:03 | |
| imbrandon | heheh | 08:03 |
| imbrandon | well he stuff is visable | 08:03 |
| SpamapS | see anybody else bike shedding back there? ;) | 08:03 |
| imbrandon | like all the programs that got cut | 08:03 |
| imbrandon | Suddenly, 20% meant half-assed. Google Labs was shut down. App Engine fees were raised. APIs that had been free for years were deprecated or provided for a fee. As the trappings of entrepreneurship were dismantled, derisive talk of the “old Google” and its feeble attempts at competing with Facebook surfaced to justify a “new Google” that promised “more wood behind fewer arrows.” | 08:03 |
| imbrandon | dont tell me they needed the money | 08:04 |
| imbrandon | or investors cared, | 08:04 |
| imbrandon | :) | 08:04 |
| imbrandon | so no google is not dead, far from it, but its about to be a very very diffrent google, and in that respect control is bad | 08:05 |
| SpamapS | seems to me its more about positioning than money | 08:05 |
| imbrandon | oh and the funny thing | 08:06 |
| imbrandon | this "exec" that left here a month ago and wrote this | 08:06 |
| imbrandon | he was the exec over the initial dev and launch of G+ | 08:06 |
| imbrandon | heh | 08:07 |
| SpamapS | G+ is interesting | 08:07 |
| SpamapS | I'd *rather* all my friends were on there instead of FB | 08:07 |
| SpamapS | but they're not | 08:08 |
| SpamapS | and might never be :-P | 08:08 |
| imbrandon | heh and if they were all the crap would come too | 08:08 |
| SpamapS | so I toil away w/ 4 social networks (twitter, facebook, google, and linkedin) | 08:08 |
| imbrandon | seee here is one line that i DONT want to see happen with juju "The days of old Google hiring smart people and empowering them to invent the future was gone. The new Google knew beyond doubt what the future should look like. " | 08:09 |
| imbrandon | we need to attract those key ppl like you say, but not think we know how it should look when they are done | 08:09 |
| imbrandon | just enable them along the way to de what they want, only the best way | 08:10 |
| imbrandon | maybe not our way | 08:10 |
| imbrandon | did you promstrangulate me ? | 08:11 |
| imbrandon | man i just need to get some good voice software that i could code with | 08:11 |
| imbrandon | that would be fantastic | 08:11 |
| imbrandon | but whats out there i cant even chat with let alone code with | 08:12 |
| imbrandon | mmmm pure java implmentation of php 5.4 | 08:14 |
| imbrandon | sexy | 08:14 |
| imbrandon | and faster than the official runtime :) | 08:14 |
| SpamapS | imbrandon: lol that is almost comedy | 08:15 |
| SpamapS | Java whips crappy C code's butt. Film at 11 | 08:15 |
| imbrandon | heh, why is that ? | 08:15 |
| imbrandon | LOL | 08:15 |
| imbrandon | there is jython and jruby too :) | 08:15 |
| imbrandon | but yea | 08:15 |
| imbrandon | i wonder what php would be like if re-written | 08:16 |
| imbrandon | and without 100000 functions to do everythiong, but more like python with 74 | 08:17 |
| imbrandon | but still keep the same syntax , runtime idiums etc | 08:17 |
| SpamapS | Isn't that hiphop? | 08:17 |
| imbrandon | nah hiphop == php to c converter | 08:17 |
| imbrandon | then you can compiler the c with g++ | 08:18 |
| imbrandon | it just now grew a jit compiler | 08:18 |
| imbrandon | but its buggy | 08:18 |
| imbrandon | it would look more like django with php syntax | 08:19 |
| === fenris is now known as Guest733 | ||
| imbrandon | infact i what i'm thinking of is exactly that | 08:19 |
| imbrandon | django with only in php syntax | 08:19 |
| === Guest733 is now known as ejat | ||
| imbrandon | not php current runtime a whole new one | 08:19 |
| imbrandon | but same token parser | 08:20 |
| imbrandon | hrm | 08:20 |
| imbrandon | that might actually be cool | 08:20 |
| imbrandon | and i bet with llvm compilers its pissible now a days witout a bajillion man hours | 08:20 |
| imbrandon | mmmm python with a php tokenizer runtime, that sounds sexy | 08:21 |
| _mup_ | Bug #992454 was filed: Charms are not sufficiently tamper proof <juju:New> < https://launchpad.net/bugs/992454 > | 08:21 |
| SpamapS | alright | 08:22 |
| imbrandon | i mean the java php project shows it can be done in very little time | 08:22 |
| SpamapS | I've filed my bug for the night | 08:22 |
| imbrandon | :) | 08:22 |
| imbrandon | func init() { http.HandleFunc("/", handler) | 08:23 |
| imbrandon | } | 08:23 |
| SpamapS | alright, sleep time | 08:24 |
| imbrandon | how fast you think we could make the dev_appengine.py sticking nginx and sdy infront ? | 08:24 |
| imbrandon | gnight man | 08:25 |
| imbrandon | i just woke up like 3 hours ago so i'll be up till noon | 08:25 |
| imbrandon | or more | 08:25 |
| imbrandon | see ya in a few | 08:25 |
| imbrandon | ohh before ya go | 08:25 |
| imbrandon | where is that test charm | 08:25 |
| imbrandon | for spdy, i wanna play with it a bit | 08:25 |
| * imbrandon looks on SpamapS lp branches and hopes | 08:26 | |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| === CORP\rkather1 is now known as krondor | ||
| senior7515 | hey m_3: soo I restarted my cluster of hadoop on ec2, but yesterday i simply shut themed down via the aws console, not juju and… I can't juju ssh into any machine today even though bootstrap and status work just fine. | 15:28 |
| senior7515 | any tips ? | 15:28 |
| SpamapS | senior7515: can you ssh directly to them? | 15:29 |
| senior7515 | well… not sure how. juju does not associate any keypar with them on install | 15:30 |
| senior7515 | i suppose I can try the debug thing | 15:30 |
| senior7515 | lets see | 15:30 |
| senior7515 | nope it detects the machine | 15:30 |
| senior7515 | it says | 15:30 |
| senior7515 | connecting to machine <public dns name> | 15:31 |
| senior7515 | then hangs | 15:31 |
| senior7515 | soo I suppose status does work, cuz otherwise how would it pick up the dns name | 15:31 |
| senior7515 | connection time out | 15:31 |
| senior7515 | debug_hooks finished successfully | 15:31 |
| senior7515 | that's what it says | 15:32 |
| SpamapS | senior7515: it associates your ssh key to the machines | 15:34 |
| SpamapS | senior7515: are you sure status sees the correct DNS name? | 15:34 |
| SpamapS | senior7515: like, in the AWS console, are the DNS names the same? | 15:34 |
| senior7515 | hmm checking. | 15:35 |
| senior7515 | probably… where would it make up the names ? | 15:35 |
| senior7515 | let me check | 15:35 |
| senior7515 | ohh good point… | 15:36 |
| senior7515 | why did the juju bootstrap | 15:36 |
| senior7515 | picked up the wrong dns name dunno | 15:36 |
| senior7515 | I mean I dont know how else to do it ? | 15:36 |
| senior7515 | shouldn't the bootstrap detect that ? | 15:36 |
| senior7515 | based on like private ips | 15:36 |
| senior7515 | or smth more permanent than the public DNS which is dynamic | 15:37 |
| SpamapS | senior7515: it doesn't poll amazon | 15:41 |
| SpamapS | senior7515: shutting down instances like that is not something juju fully supports | 15:41 |
| SpamapS | senior7515: you can reboot them, but shutting them down is still going to cause issues unfortunately | 15:42 |
| senior7515 | ohhh so how does one shut down the instances but keep the configs | 15:44 |
| senior7515 | like I need to install some jars on haddop and stuff. compile git repos | 15:44 |
| senior7515 | etc. | 15:44 |
| senior7515 | soo that takes some time | 15:44 |
| senior7515 | I don't necessarily want to shutdown | 15:44 |
| senior7515 | errr... | 15:44 |
| senior7515 | reboot | 15:44 |
| senior7515 | not destroy the environment | 15:44 |
| senior7515 | I just want to shutdown while I go home | 15:44 |
| senior7515 | and resume in the morning | 15:44 |
| SpamapS | senior7515: we've been talking about that lately | 15:45 |
| SpamapS | senior7515: I think shutdowns should be supported somehow | 15:46 |
| SpamapS | senior7515: perhaps with a "refresh-provider" command or something that goes and re-pulls all the addresses from the provider | 15:46 |
| senior7515 | the easiest way would be to install some sort of coordination software | 15:47 |
| senior7515 | exactly | 15:47 |
| senior7515 | welll on amazon | 15:48 |
| senior7515 | i knprivate IP's are not supposed to change for the life of that instance | 15:48 |
| senior7515 | so store that instead of the public dns | 15:48 |
| senior7515 | and it would work as is for now.. | 15:49 |
| senior7515 | ok… sooo solution is to terminate and then install again ? | 15:49 |
| SpamapS | senior7515: but how would you ssh to the private IP? ;) | 15:51 |
| SpamapS | senior7515: and FYI, I don't believe that private address guarantee extends to shutdown instances | 15:51 |
| senior7515 | ohhh ok | 15:53 |
| senior7515 | just thinking out loud, should have confirmed before. | 15:54 |
| senior7515 | I guess I was thinking private ip is fine within amazon | 15:54 |
| senior7515 | i can definitely ssh to 10.* | 15:54 |
| senior7515 | from my other machine | 15:54 |
| SpamapS | the reason I say that is that I'm pretty sure when I shutdown bootstrap, it changes both addresses | 15:55 |
| senior7515 | not sure how they segment their network… I guess it has worked for me in the past because I use all of the instances on est coast | 15:55 |
| senior7515 | ohh got you | 15:55 |
| SpamapS | which is why you cannot shutdown node 0 :) | 15:55 |
| SpamapS | we should actually have some way to fix that | 15:56 |
| senior7515 | oh so that's the main problem then haha… I shut all of the services down when I go home | 15:56 |
| senior7515 | ok | 15:56 |
| SpamapS | though perhaps the best way would be to make bootstrap HA and make sure the 'leader' corrects the addresses when it is time. | 15:56 |
| senior7515 | hmmm terminating.. instances | 15:56 |
| SpamapS | senior7515: one thing you might consider is pre-handling most of that stuff and dropping a big tarball in the charm w/ all the stuff | 15:57 |
| SpamapS | senior7515: this is actually why I encourage use of packages/PPA's because you can do that fairly easily | 15:57 |
| senior7515 | got you… sometimes is more than packages is port numbers, configs, custom software, firewall rules, etc. | 15:58 |
| senior7515 | packages in ubuntu is a breeze with apt-get\ | 15:58 |
| SpamapS | that stuff should all be saved in juju config options | 15:59 |
| SpamapS | you can save them off with 'juju get' | 15:59 |
| SpamapS | actually I wonder if juju get will save the whole of them in the proper yaml format | 15:59 |
| SpamapS | if not, it should | 15:59 |
| senior7515 | juju is great so far for 'deploy' | 16:00 |
| imbrandon | SpamapS: and json :) | 16:08 |
| SpamapS | imbrandon: json would not wor | 16:08 |
| SpamapS | k | 16:08 |
| imbrandon | :( | 16:08 |
| SpamapS | because juju set only takes yaml | 16:08 |
| SpamapS | imbrandon: patches accepted | 16:09 |
| SpamapS | :) | 16:09 |
| imbrandon | oh right , $whatever app could conert it back i guess | 16:09 |
| imbrandon | hehe | 16:09 |
| imbrandon | speaking of , you know any good php <--> zk bridges ? | 16:09 |
| * imbrandon is thinkin of a ui on the bootstrap node | 16:09 | |
| imbrandon | would be kinda cool to do add-unit / remove unit from the web | 16:11 |
| imbrandon | and see some nice bar graphs :) | 16:11 |
| phschwartz | does open-port open the local firewall on a node or update the security group to allow for outside access to the port? | 16:12 |
| imbrandon | the aws security grp firewall | 16:12 |
| imbrandon | iirc | 16:12 |
| imbrandon | no idea on anything else | 16:12 |
| phschwartz | imbrandon: ok, so doesn't touch iptables. TY | 16:13 |
| imbrandon | SpamapS: how can i "force" juju to update its ip info in zk | 16:13 |
| imbrandon | phschwartz: as far as i know thats correct, least thats how its been working on my deploys | 16:14 |
| imbrandon | i KNOW it does the aws security grps, not sure if it does the ufw in addition or nor | 16:14 |
| imbrandon | not* | 16:14 |
| SpamapS | imbrandon: what you're describing is best done via a REST API.. https://launchpad.net/jrapi | 16:15 |
| imbrandon | SpamapS: yea i figured i'd have to write one tbh | 16:15 |
| imbrandon | thus started lower | 16:15 |
| imbrandon | :) | 16:15 |
| imbrandon | doh twistd | 16:17 |
| imbrandon | bah | 16:17 |
| imbrandon | SpamapS: btw is zk really needed on the client, would be nice to drop some deps on the osx build | 16:18 |
| SpamapS | imbrandon: absolutely | 16:18 |
| SpamapS | its *the only thing* the client does | 16:18 |
| imbrandon | k thiought maybe only bootstrap needed it | 16:19 |
| SpamapS | client changes ZK | 16:19 |
| SpamapS | agents make ZK true | 16:19 |
| SpamapS | or report errors | 16:19 |
| imbrandon | right but it dont workj like sql where there is only the "server" running remote on the bootstrap | 16:19 |
| imbrandon | and i only need bindings local ? | 16:20 |
| imbrandon | total zk newb so .... yea | 16:20 |
| imbrandon | mmm this reset interface looks like it could be functional | 16:21 |
| imbrandon | not a fan of twistd but i could use it untill i got a "roundtuwit" and did it in node or php | 16:22 |
| imbrandon | hrm | 16:22 |
| === carif_ is now known as carif | ||
| SpamapS | imbrandon: well the problem is the C library is included w/ ZK proper | 16:25 |
| SpamapS | imbrandon: don't be silly | 16:25 |
| SpamapS | imbrandon: the REST API will be built into juju. Save your precious time. | 16:25 |
| SpamapS | imbrandon: the twistd jrapi is there as a stop-gap until the real one lands. | 16:25 |
| imbrandon | really, why complicate it, least a seperate go module i hope | 16:26 |
| * imbrandon graps the jrapi and to see if it still is working with current juju' | 16:27 | |
| imbrandon | oh wait | 16:29 |
| imbrandon | its only a few days | 16:29 |
| imbrandon | old | 16:29 |
| imbrandon | nice | 16:29 |
| SpamapS | imbrandon: the client will be using the REST API when it is done | 16:31 |
| imbrandon | sweet | 16:31 |
| imbrandon | ok | 16:31 |
| * imbrandon hugs SpamapS | 16:31 | |
| SpamapS | so yeah, don't make a 3rd one | 16:31 |
| SpamapS | :) | 16:31 |
| imbrandon | well i still may just fo that | 16:31 |
| imbrandon | lol | 16:31 |
| imbrandon | j/k | 16:31 |
| * imbrandon fires up Zend Studio, too much bash, time for some php | 16:32 | |
| imbrandon | def to_yaml( self ): | 16:33 |
| imbrandon | try: | 16:33 |
| imbrandon | return( yaml.safe_dump( self.to_dict() ) ) | 16:33 |
| imbrandon | except yaml.YAMLError: | 16:33 |
| imbrandon | return( None ) | 16:33 |
| imbrandon | def to_json( self, pretty = True ): | 16:33 |
| imbrandon | args = dict( skipkeys = True ) | 16:33 |
| imbrandon | if pretty: | 16:33 |
| imbrandon | args["sort_keys"] = True | 16:33 |
| imbrandon | args["indent"] = 4 | 16:33 |
| imbrandon | return( json.dumps( self.to_dict(), **args ) ) | 16:34 |
| imbrandon | HAH! | 16:34 |
| imbrandon | wow this code isnt half bad | 16:36 |
| imbrandon | maybe its django i dont like ... /me hushes before he has to eat a few words | 16:36 |
| imbrandon | ok back to my problem tho, SpamapS how can i inform the juju got to refresh its info about the ips of the member nodes | 16:37 |
| imbrandon | e.g. i got a webhead or 3 that have changed IP's and juju still thinks they are on the old ones | 16:38 |
| imbrandon | preferably without invoking any hooks | 16:39 |
| SpamapS | imbrandon: it doesn't have any routines to do that. as I was suggesting, we need something like 'refresh-provider' | 16:39 |
| imbrandon | ahh ok | 16:39 |
| imbrandon | dident catch that | 16:39 |
| imbrandon | musta been typing too much | 16:40 |
| SpamapS | and in theory, you would also need to invoke all hooks around that service, and any connected to it | 16:40 |
| SpamapS | because they may have consumed private/public address | 16:40 |
| imbrandon | yea, i just manyualy fixed where it filled in the wrong ip | 16:40 |
| imbrandon | figured id spin a new env up sometime | 16:40 |
| imbrandon | but trying to put it off as long as possible | 16:40 |
| imbrandon | and atm if i add/remove anythign then the hooks fire and refill in the wrong ips | 16:41 |
| imbrandon | :) | 16:41 |
| imbrandon | i could make the configs read only i guess :) | 16:42 |
| imbrandon | lol | 16:42 |
| imbrandon | ohh got me a shiney new email ( just got activated ) you.should.hire@me.com heh | 16:43 |
| * imbrandon orders some business cards | 16:43 | |
| tooth | well done | 16:46 |
| imbrandon | :) | 16:47 |
| ihashacks | niemeyer: you mentioned here "http://irclogs.ubuntu.com/2012/01/20/%23juju.txt" that juju won't survive a reboot with local/LXC | 19:26 |
| ihashacks | Is that still the case? (seems like it is) | 19:26 |
| SpamapS | ihashacks: it is | 19:29 |
| SpamapS | ihashacks: a few of the daemons don't get started properly on reboot | 19:29 |
| ihashacks | Is manually starting up the containers sufficient or still best to destroy-environment and bootstrap again? | 19:30 |
| SpamapS | ihashacks: I believe zookeeper also won't start back up properly | 19:30 |
| SpamapS | ihashacks: though you might be able to get it started | 19:31 |
| ihashacks | crap, it was here: https://juju.ubuntu.com/docs/provider-configuration-local.html | 19:37 |
| ihashacks | I need to RTFM better next time. Thanks. | 19:38 |
| jimbaker | adam_g, were you able to verify that one of the 2 branches (debug or what's in review, otherwise no functional diff) worked for you in terms of working with relation ids? | 19:41 |
| mapu | I am wondering - performing a 'juju deploy mysql' - my resulting juju status shows "state: start_error" | 20:03 |
| mapu | if I connect directly to the system- I find myql is running | 20:04 |
| adam_g | jimbaker: i haven't had a chance to test yet, sorry | 20:12 |
| jimbaker | adam_g, no worries, just want to make sure this isn't blocking | 20:12 |
| jimbaker | from what i could tell, it now works fine in debug-hooks however | 20:12 |
| adam_g | jimbaker: i can try now, where is the branch ? | 20:12 |
| jimbaker | adam_g, lp:~jimbaker/juju/unit-rel-lifecycle-start-invoker | 20:13 |
| adam_g | thanks | 20:13 |
| jimbaker | adam_g, you might also find the new jitsu run-as-hook command useful for triggering relation hooks | 20:13 |
| adam_g | jimbaker: am i wrong in assuming something like this should work: http://paste.ubuntu.com/960962/ | 20:33 |
| jimbaker | adam_g, yes | 20:34 |
| adam_g | i'd like to have a relation service A -> B. When a relation is added from B -> C, I'd like to be able to inspect relation data between A and B | 20:34 |
| adam_g | specifically the private-address of A | 20:34 |
| jimbaker | adam_g, you need to specify the remote unit as part of the relation-get | 20:34 |
| adam_g | ok | 20:34 |
| jimbaker | since it's different than what the relation hook would imply - and that's on a different relation | 20:34 |
| jimbaker | so pretty easy | 20:34 |
| adam_g | jimbaker: is there a way to resolve the JUJU_REMOTE_UNIT of a relation id? | 20:35 |
| jimbaker | adam_g, you could use relation-list -r relation_id | 20:35 |
| adam_g | jimbaker: ah! exactly what i need. thanks | 20:36 |
| jimbaker | adam_g, i suspect that it might be a nice feature if JUJU_REMOTE_UNIT was simply set that way | 20:36 |
| jimbaker | when specifying -r... could definitely change that behavior | 20:36 |
| adam_g | jimbaker: cool, that branch seems to do everything i need. | 20:41 |
| adam_g | from debug-hooks at least | 20:41 |
| jimbaker | adam_g, cool! | 20:41 |
| adam_g | thanks for the quick fix | 20:41 |
| jimbaker | np, please tell how it works in practice and what edges we can smooth | 20:41 |
| adam_g | definitely | 20:41 |
| nathwill | i'm trying to get the remote unit ip in a relation-joined hook, but i'm getting an empty string... i'm using: UNIT_IP=$(relation-get ip), is that the right way to be doing this? | 21:16 |
| bkerensa | imbrandon: this is going to be my new laptop http://www.slashgear.com/samsung-series-7-gamer-busts-out-ivy-bridge-01225472/ | 21:22 |
| bkerensa | :D | 21:22 |
| bkerensa | It will start shipping to stores for consumers in the last quarter of this year ^ but I get one when I get back from UDS :D | 21:23 |
| mars | Hi guys, I think I just found a bug where the machine-agent.log consumes all the harddrive space after reboot. Has anyone seen that yet? | 21:26 |
| mars | 2012-05-01 17:24:46,172:1198(0x7f2743605700):ZOO_ERROR@handle_socket_error_msg@1579: Socket [192.168.122.1:54477] zk retcode=-4, errno=111(Connection refused): server refused to accept the client | 21:26 |
| mars | ^ my system was just killed with a 45GB logfile containing what was likely the above message. | 21:26 |
| mars | Actually, that explains why my laptop has been mysteriously shutting down every night... | 21:27 |
| mars | FWIW, I'm using juju from the PPA. | 21:30 |
| m_3 | mars: yeah, that's a problem! please file a bug on it | 21:31 |
| mars | m_3, yep, doing so now | 21:31 |
| m_3 | thanks | 21:31 |
| jimbaker | re the machine log, there was a recent fix for that, but it has not been merged to trunk yet: bug 958312 | 21:47 |
| _mup_ | Bug #958312: Change zk logging configuration <juju:Fix Released by hazmat> < https://launchpad.net/bugs/958312 > | 21:47 |
| jimbaker | however marked fix released as above, so really needs to be merged | 21:48 |
| jimbaker | mars, ^^^ | 21:48 |
| _mup_ | Bug #992887 was filed: machine-agent.log grows after boot until all disk space is used <juju:New> < https://launchpad.net/bugs/992887 > | 21:51 |
| mars | jimbaker, thanks | 21:51 |
| mars | m_3, filed: bug 992887 | 21:51 |
| _mup_ | Bug #992887: machine-agent.log grows after boot until all disk space is used <juju:New> < https://launchpad.net/bugs/992887 > | 21:51 |
| m_3 | mars: cool | 21:53 |
| mars | jimbaker, looks to be the same. Someone should confirm and dupe the bug I just filed. | 21:53 |
| SpamapS | nathwill: "ip" is not always present, it would need to be set by the other side | 21:59 |
| SpamapS | nathwill: only 'private-address' and 'public-address' are always present in relations | 21:59 |
| nathwill | hrm | 21:59 |
| nathwill | SpamapS: sounds like i should use one of those then | 22:00 |
| nathwill | SpamapS: will can private-address be used for internode comms? | 22:00 |
| nathwill | s/will can/can/ | 22:01 |
| SpamapS | nathwill: the distinction is purely up to the provider, but usually you would want to use private-address for inter-node communication, and public-address only when you need to send an external party to that service | 22:03 |
| nathwill | perfect. ty :) | 22:03 |
| SpamapS | nathwill: you might see some older charms doing weird things to get the IP because those values were added later | 22:07 |
| * SpamapS thinks we should probably go back through the older charms and do some spring cleaning. | 22:07 | |
| nathwill | SpamapS: aha. that would explain the confusion... | 22:07 |
| hazmat | ugh | 22:08 |
| _mup_ | juju/trunk r533 committed by kapil.thangavelu@canonical.com | 22:10 |
| _mup_ | [merge][trivial] minimize zk logging, workaround local provider problems with restart, ie. filling disks [r=jimbaker][f=958312] | 22:10 |
| hazmat | jimbaker, yeah.. i totally got on a plane before i committed.. done now | 22:11 |
| SpamapS | hazmat: I figured as much. :) | 22:11 |
| nathwill | anyone have time to review bug 991897 ? my first charm attempt... | 22:15 |
| _mup_ | Bug #991897: new-charm: vsftpd <new-charm> <Juju Charms Collection:New> < https://launchpad.net/bugs/991897 > | 22:15 |
| SpamapS | nathwill: I'll be reviewing charms later today or early tomorrow | 22:18 |
| jimbaker | hazmat, if you have a chance to take a look at lp:~jimbaker/juju/unit-rel-lifecycle-start-invoker, that would be great. adam_g was able to use it to fix the problem he saw with using relation ids - just a one-line fix, everything else is just testing to ensure Invoker.start is actually yielded upon | 22:18 |
| nathwill | SpamapS: cool,thankee | 22:18 |
| jimbaker | so i would call it a trivial | 22:18 |
| hazmat | jimbaker, saw it, it looked good, just haven't had a time to examine it carefully | 22:21 |
| hazmat | jimbaker, i'll do it this evening after we wrap up the sprint | 22:21 |
| jimbaker | hazmat, np | 22:21 |
| bkerensa | jcastro: I was just going to ask out of curiosity why you choose dell laptops instead of zareason or system76? | 22:35 |
| SpamapS | bkerensa: perhaps the dell laptops chose jcastro, not the other way around ;) | 22:40 |
| === mcclurmc is now known as 31NAA87MH | ||
| === SpamapS_ is now known as SpamapS | ||
| === elmo_ is now known as elmo | ||
| === marcoceppi_ is now known as marcoceppi | ||
| === telmich_ is now known as telmich | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!