[00:56] <lazyPower> jose: still kicking around?
[01:00] <jose> lazyPower: yep!
[01:00] <jose> lazyPower: I'm testing the newly-fixed charm :D
[01:01] <lazyPower> jose: right on! Did you still need to PM me?
[01:01] <lazyPower> or are you unblocked?
[01:02] <jose> I think I'm good to go by now
[01:02] <lazyPower> allright cool. I didn't want to leave you hanging
[01:02] <jose> thanks!
[01:05] <lazyPower> Thats how we roll jose. Charmers 4 lyfe
[01:05] <jose> :P
[01:15] <lazyPower> jose: good work on the queue too man, you're killin it with the quality MP's
[01:15] <jose> thanks, just trying to :)
[01:15] <jose> let me know if any of those are buggy, maybe a couple will be
[01:16] <lazyPower> We'll have feedback on improvements if they are :)
[01:59] <jose> lazyPower: still around?
[01:59] <lazyPower> jose: indeed. Whats up?
[01:59] <jose> I'm having some problems printing a variable
[01:59] <lazyPower> pastebin?
[01:59] <jose> sure, second
[02:00] <jose> lazyPower: http://bazaar.launchpad.net/~jose/charms/precise/mailman/trunk/revision/32
[02:00] <jose> those exact lines in the diff
[02:00] <jose> they're printing literally "$DOMAIN" instead of the domain
[02:03] <lazyPower> jose: http://paste.ubuntu.com/7160367/
[02:04] <lazyPower> there's an illustration of whats going on. What you're seeing is a symptom of how single quotes work in bash
[02:04] <lazyPower> they are string literal annotations.
[02:04] <jose> hmm, got it!
[02:04] <jose> thanks
[02:04] <jose> w0ot, manually fixing it makes it work!
[02:06] <lazyPower> jose: you have single quotes surrounding those blocks, thats why you're getting the "$DOMAIN" printed. I dont understand what the 'manual fix' is - but happy its working :)
[02:06] <jose> yep, testing another deployment now!
[06:50] <jose> arosales: thanks for the heads up! :)
[06:51] <arosales> jose: oh, np. Thanks for your contributions. I see you have been busy :-)
[06:51] <arosales> good stuff.
[06:51] <jose> well, I thought juju could use some of my time :)
[06:51] <arosales> I too say that issue with Bip and we were wondering why proof was having an isue with a 2 character yaml key
[06:51] <arosales> s/say/saw/
[06:52] <jose> Marco mentioned it was because of a yaml issue, it needs to be 3chars min
[06:52] <arosales> jose: well the help with improving the overally charm quality is very appreciated.
[06:52] <jose> \o/
[06:53] <arosales> ya we didn't find anything in the yaml spec, but I too saw when I changed ip to any char with 3 char or greater proof was happy
[06:53] <jose> :P
[06:53] <arosales> jose: We are in the midst of a charm audit so it was nice to see your merge requests
[06:54] <jose> I just need to learn how to write amulet tests and I'll give a hand with tests
[06:54] <jose> maybe it can be considered for a charm school? 'Writing amulet tests for your charms'
[06:56] <arosales> jose, for sure a good topic we should revist. We have an initial one @ https://juju.ubuntu.com/resources/videos/
[06:56] <arosales> http://www.youtube.com/watch?v=KlTeRjGv4E4
[06:57] <jose> oh, missed it as it wasn't at ubuntuonair, not subscribed to Jorge :P
[06:57] <jose> anyways, I'll take a look at that one and see what can I do
[06:58] <arosales> we trying to make the video page complete in case someone does miss a charm school or just joins and wants to catch up.
[06:58] <arosales> jose: docs are also at https://juju.ubuntu.com/docs/tools-amulet.html
[06:58] <jose> seems easy enough
[06:59] <arosales> if you pull the source for charms such as rabbitmq, haproxy, or memcached you'll see some code examples in /test of amulet based tests
[07:00] <arosales> jose: our of curosity were you following jcastro's charm audit email, https://lists.ubuntu.com/archives/juju/2013-December/003331.html ?
[07:01] <jose> arosales: not actually, I've been mostly involved with juju this last two or three weeks
[07:01] <arosales> ah ok well your timing on fixing charms is perfect :-)
[07:01] <jose> cool!
[07:02] <jose> I'm also trying to convert most (if not all) READMEs to Markdown
[07:03] <arosales> +1
[07:03] <arosales> and I see you are using the teamplate from charm tools which is nice
[07:04] <jose> makes life easier
[07:08] <arosales> for sure
[07:11] <jose> well, time for me to go to bed, laters!
[07:13] <arosales> good night jose, good to talk to virtually here
[08:50] <jamespage> gnuoy, https://code.launchpad.net/~openstack-charmers/charm-helpers/ssl-everywhere/+merge/209301
[08:50] <gnuoy> looking
[11:44] <jose> marcoceppi: hey! is the minecraft server charm still good?
[11:52] <marcoceppi> jose: not really. it works but the version mineshaft is old
[11:53] <jose> hmm, ok
[11:53] <jose> I'm thinking on integrating some basic tests on my pagekite charm before it gets to the store
[11:54] <jose> that charm school is really useful in that matter :)
[11:56] <jose> marco_traveling: have a safe travel!
[12:00] <jose> uh, guys, I have a problem here... I am trying to write tests for pagekite but a config option would be the kite's secret
[12:38] <yolanda> jamespage, i added testing for databases to my MP also
[12:38] <yolanda> MPs
[13:36] <jcastro> man, content-fetcher looks like a great idea
[13:46] <lazyPower> jose: read that from an external source
[13:46] <lazyPower> jose: scratch that idea
[13:46] <lazyPower> i dont know what i was thinking.. need coffee
[14:14] <mgz> jcastro: would be good to have a mini blog post about content-fetcher I think
[14:14] <jcastro> nod
[14:17] <tvansteenburgh> where are charm's hook files located on a deployed node?
[14:24] <tvansteenburgh> also, is this a bug or something i'm doing wrong:
[14:24] <tvansteenburgh> tvansteenburgh@trusty-vm:~/src/charms/precise⟫ juju debug-log
[14:24] <tvansteenburgh> ssh: connect to host localhost port 22: Connection refused
[14:24] <tvansteenburgh> ERROR rc: 255
[14:26] <tvansteenburgh> and which bug list would i consult to see if it's a reported bug?
[14:26] <rick_h_> tvansteenburgh: is this in an lxc environment? debug-log doesn't work in lxc if I recall
[14:26] <tvansteenburgh> rick_h_: ok, yeah, it is
[14:26] <rick_h_> tvansteenburgh: ok, that's a known issue then. Looking for the hook path
[14:27] <tvansteenburgh> ok, hook path i can figure out, was just being lazy, hoping someone knew offhand
[14:27] <rick_h_> tv so checking real quick I find it in /var/lib/juju/agents/unit-juju-gui-0/charm/hooks
[14:27] <rick_h_> :)
[14:27] <rick_h_> all good
[14:28] <tvansteenburgh> cool, thanks
[14:51] <jcastro> ERROR cannot use 37017 as state port, already in use
[14:51] <jcastro> How do we resolve that error with the local provider? ^^
[14:52] <rick_h_> jcastro: ps aux | grep mongo
[14:52] <rick_h_> kill pid
[14:52] <jcastro> man, still?
[14:53] <rick_h_> not sure if there's a different thing but it's what I know/use
[14:53] <rick_h_> normally it's something went boom
[14:53] <jcastro> yeah
[14:53] <jcastro> something went bada-boom
[15:11] <lazyPower> big bada-boom
[15:12] <lazyPower> <3 fifth element, just saying
[15:26] <rick_h_> marco_traveling: delete charm/bundle landed and removed those vms ones.
[15:30] <rick_h_> jcastro: we can garden out the old bundles with poor names now. let me know when you want to check it out
[15:34] <jcastro> rick_h_, busy with a mongo cluster ATM, just clean em!
[15:54] <frankban> rbasak, rick_h_: quickstart 1.3.0 with the --distro-only flag just released on PyPI
[15:55] <rbasak> frankban: thanks! Please could you update bug 1282630 to match? Then we can change the FFe and MIR bugs.
[15:55] <rbasak> s/change/chase
[15:57] <frankban> rbasak: done
[15:58] <rbasak> frankban: thanks! I'll chase in #ubuntu-devel.
[15:58] <frankban> rbasak: thank you!
[16:02] <rbasak> frankban: is the goal to get juju-quickstart on the desktop CD, on the server CD, or both?
[16:03] <frankban> rbasak: I guess both, rick_h_? ^^^
[16:04] <rbasak> I never considered this aspect before. We'll need to check with the release team to do this at this late stage, assuming the MIR is accepted.
[16:04] <rbasak> I'm not sure if it needs an FFe or not, and we'll miss beta2.
[16:04] <rbasak> (and I hope there's space, etc)
[16:04] <rbasak> jamespage: ^^ any advice here, please?
[16:05] <rbasak> jamespage: I presume this is higher priority now that juju-core looks unlikely for main?
[16:06] <jose> lazyPower: it'd still be public, yeah. any other ideas on how to do that?
[16:06] <jose> otherwise, a test wouldn't be possible unless some values are set manually
[16:06] <jamespage> rbasak, frankban: I think that's out of scope for 14.04 now
[16:06] <jamespage> if we don't mir juju-core, we won't do the mir for quickstart
[16:07] <lazyPower> jose: reach out to the support dept/mailing list for the service and see if there are testing credentials that can be used that dont "actually" work, but will allow you to mock the login
[16:07] <rbasak> jamespage: that confuses me a little. My understanding is that we'll want juju-quickstart more in this case?
[16:07] <rbasak> rick_h_: ^^
[16:08] <jamespage> rbasak, surely juju-quickstart depends on juju-core?
[16:08] <rbasak> jamespage: no - it installs juju-core from a PPA (by default). On discussion from the MIR, it can also install from the archive only as an option.
[16:08] <jose> lazyPower: hmm, the point is not about the login, but checking that the tunnel works... that would need some valid credentials
[16:08] <rbasak> jamespage: the underlying idea for juju-quickstart is that it's cross-distro multiplatform etc - eg. from PyPI.
[16:09] <rbasak> jamespage: there's some talk around this subject in the MIR bug.
[16:09] <jamespage> rbasak, yes - but not for the distro packages which should IMHO always install from the distro
[16:09] <lazyPower> jose: no idea bud, i thought you were doing unit tests, not amulet tests
[16:09] <jose> yep, I started those :)
[16:09] <lazyPower> theory states you could have a config option for them, that the user would have to input, but they would fail consistently in CI
[16:09] <rbasak> jamespage: please could you comment on the MIR bug in this? I did raise this point, so the option to only install from the distro was added. But I didn't ask for any particular default.
[16:10] <rbasak> jamespage: I think it makes sense for the user to at least be able to ask for a PPA installation as an option, even if it is decided that from distro is default.
[16:10] <rbasak> jamespage: in this case, juju-quickstart is still useful even without juju-core in main.
[16:10] <lazyPower> jose: let me ping marco about this when you get back, as I have a PAAS charm in the store that needs amulet tests too, that require sensitive credentials.
[16:10] <lazyPower> s/you/he/
[16:11] <jamespage> rbasak, agree that having ppa as an option is fine
[16:11] <jose> lazyPower: awesome, thanks!
[16:11] <jamespage> rbasak, but I'm not sure I see the value of including this in main without juju-core
[16:11] <jamespage> 'use this fully supported tool to install a tool that's not fully supported'
[16:12] <rbasak> jamespage: I think the goal is to have it on the CD, and that was the driver for main inclusion, rather than support.
[16:12] <rbasak> rick_h_, frankban: ^^
[16:12] <jamespage> rbasak, I see juju-core and quickstart tied tbh
[16:12] <rbasak> jamespage: I guess there's a mismatch of expecations here, so we should talk soon.
[16:13] <rbasak> jamespage: I understand what you're saying - it's just that rick_h_ seemed quite keen on having juju-quickstart on the CD anyway, even without juju-core in main.
[16:13] <frankban> rbasak, jamespage: the goal is to gice to users/developers the ability to go from zero to a fully deployed environment (including the GUI and bundles support) in a single command
[16:13] <frankban> give even
[16:13] <rbasak> frankban: you can more or less get that from universe though. Two commands - apt-get install juju-quickstart, and juju-quickstart. Right?
[16:14] <rbasak> frankban: so I think what jamespage is asking is what is the additional benefit of this being in main/on the CD?
[16:14] <jamespage> rbasak, frankban: I don't see this as any different to the objections being made on the juju-core MIR re tools coming from simplestreams
[16:14] <rbasak> (if juju-core is not)
[16:14] <rbasak> jamespage: we agree that PPA is OK to be an option, so what's left is what should be the default.
[16:14] <rbasak> Oh, I see.
[16:15] <rbasak> With juju-quickstart in main and juju-core in universe, there's a dependency from main to universe, even if it's not expressly stated in metadata.
[16:15] <rbasak> I hadn't considered that.
[16:16] <frankban> jamespage, rbasak: IC, could you please add a comment on that regard on the bug?
[16:16] <jamespage> rbasak, you got it
[16:16] <jamespage> frankban, will do
[16:16] <frankban> thanks
[16:23] <rick_h_> jamespage: rbasak sorry catching up, was in a meeting
[16:23] <rick_h_> jamespage: rbasak the goal for quickstart in 14.04 is not on any cd.
[16:23] <rick_h_> jamespage: rbasak It's a post 14.04 goal, so we want to keep it in mind
[16:24] <rick_h_> jamespage: rbasak I'd say first priority would be desktop cd vs server cd
[16:24] <rick_h_> jamespage: rbasak but I'm assuming on that one. I think it fits that use case more and it's part of our argument on why it's ok to use a ppa for getting juju
[16:25] <rick_h_> jamespage: rbasak and yes, the goal of quickstart is that something small is in main that users can use to get juju-core and juju-local even though it's not in main
[16:25] <jamespage> rick_h_, tbh I think that breaks the rules
[16:25] <rick_h_> jamespage: rbasak so with core not in main it's even more useful to end juju users to have that available to them
[16:25] <rbasak> jamespage: only sort of, though. Eg. "pip install <foo>" is permitted in main.
[16:25] <rbasak> (I assume it is)
[16:26] <rick_h_> jamespage: understand, that's what I'm trying to learn/get a grip on. I'm not sure on the rules. We've got a vision for a tool for end users to be able to get started with juju as easy as possible and we're working on what we can do to deliver that
[16:26] <rbasak> As is wget, to take it to the extreme. I'd like to identify some kind of underlying principle to this kind of thing.
[16:27] <rick_h_> jamespage: rbasak the more steps we can automate and move away from the user from a fresh ubuntu install the happier everyone gets as it eases juju adoption, which is quickstart's #1 goal
[16:28] <rbasak> The actual rule is from here: http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-archive.html#s-main
[16:28] <rick_h_> looking
[16:28] <rbasak> "In addition, the packages in main...must not require a package outside of main for compilation or execution (thus, the package must not declare a "Depends", "Recommends", or "Build-Depends" relationship on a non-main package)"
[16:28] <rbasak> Now, what's the spirit of that, as well as the wording?
[16:28] <jamespage> rick_h_, rbasak: I think my argument is about how this adds value by being in main IF a) we don't want to get on the ISO and b) juju-core is not in main (think Recommends juju-core>juju-quickstart)
[16:29] <rbasak> juju-quickstart in main is useless without _some_ external source (eg. universe or PPA). Perhaps that's a factor.
[16:29] <rick_h_> jamespage: so if we can get it on the cd then awesome, but we set expectations it might take more time to make that happen.
[16:29] <rbasak> OTOH, so is "pip install".
[16:29] <rick_h_> jamespage: so if we can get it then let's assume the value add is there
[16:30] <rick_h_> jamespage: the end value is that "user installs ubuntu, wants to try out juju, juju-quickstart will get juju, configure a lxc environment, bootstrap, and bring up the gui in one single built in command
[16:30] <rbasak> jamespage: I don't hold Recommends juju-core>juju-quickstart as highly valuable. We should have it, but I imagine that docs could tell people to install juju-quickstart and go from there.
[16:30] <jamespage> rick_h_, I'm not comfortable proposing this for the ISO unless we also have juju-core in main
[16:31] <rick_h_> jamespage: ok, so you'd suggest we get quickstart into main as step #1 with juju in universe. Next release we work on getting juju into main and quickstart on the iso?
[16:31] <rick_h_> jamespage: I'm fine staging it out, but want to make sure we konw what we need to do to make the end vision happen
[16:31] <jamespage> rick_h_, no
[16:32] <jamespage> rick_h_, I think the policy that rbasak highlighted above applies even if the relationship is not declared in the package dependencies
[16:32] <jamespage> juju-quickstart depends on either universe or a PPA to function
[16:32] <jamespage> main can only depend on main
[16:33] <rick_h_> jamespage: ok, so we are in universe while juju is in univsere. When they get into main we can then also go for main & on the iso at that time?
[16:33] <jamespage> rick_h_, which is why I tie quickstart and juju-core together for main inclusion
[16:33] <jamespage> rick_h_, sure
[16:34] <rbasak> jamespage: what about stuff on the iso? Normally all dependencies are included, but they wouldn't be in this case.
[16:34] <rick_h_> jamespage: ok then. I can tell that story fine. I just need to know that we're on the right path per what we're supposed to be getting to
[16:34] <rbasak> jamespage: do you think the same bundling rule should apply to the iso? ie. require juju-core to be on it if juju-quickstart will be there?
[16:34] <jamespage> rbasak, I'm not sure tbh
[16:35] <rbasak> jamespage: I understand your point of view, but I'm not completely convinced about your position myself. I can see both sides. It's very fuzzy.
[16:35] <rbasak> It comes down to how to interpret the rule, and this is definitely a grey area.
[16:35] <jamespage> rbasak, good job its not actually up to us then :-)
[16:36] <rbasak> jamespage: perhaps we should open this up for wider discussion? ubuntu-devel ML?
[16:36] <jamespage> rbasak, I think the bug is fine
[16:40] <rick_h_> jamespage: rbasak ok, so 1) we'll have quickstart and juju-core in universe and quickstart's --distro-only flag will be ok for 14.04
[16:40] <rick_h_> jamespage: rbasak 2) Discussion is required to think on how/if quickstart can be in the iso once it and juju-core get into main in a subsequent release
[16:44]  * rick_h_ goes for lunch  afk
[16:49] <jose> lazyPower: btw, the charm is ready for review whenever you want
[17:05] <lazyPower> jose: Thanks. We're a bit slammed at the moment with stuff, we'll try to get the community charms out asap.
[17:05] <lazyPower> thanks for the heads up
[17:05] <jose> no worries
[17:05] <jose> and no hurries too
[17:19] <bloodearnest> hmm, is there anyway to assign a (fake?) public ip to a unit using local provider? From juju's pov, I mean
[17:20] <bloodearnest> some thing that will be returned from unit-get public-address
[17:58] <marco_traveling> rick_h_: ta!
[18:11] <jcastro> hazmat, any idea why -deployer would bail if you modify a charm locally?
[18:15] <hazmat> jcastro, see flags
[18:16] <hazmat> jcastro, its a safety valve with a cli flag
[18:16] <hazmat> jcastro, it should default to allowing local mods
[18:17] <hazmat> jcastro, there's a -L flag to disallow local mods afaicr
[18:23] <mbruzek> hazmat is there an opposite to the -L flag?
[18:23] <mbruzek> We want to allow local mods
[18:25] <hazmat> mbruzek, jcastro there's a bug that this is non obvious .. but try with and with out the -L flag ... one should work/toggle the behavior
[18:25] <jcastro> yeah I'll have to circle back
[18:25] <jcastro> the mysql charm is broken with master-slave for us anyway
[18:37] <blackboxsw> marcoceppi as a heads up,    we have gotten our storage proposal charm branches in order, reviewed and set to Fix Committed for block-storage-broker and storage subordinate charms.
[19:29] <Valduare> hi guys
[19:29] <Valduare> im new to juju
[19:29] <Valduare> how do I start
[19:38] <Valduare> trying to figure out how this all works, so I start a vm and install ubuntu server on it then install juju and then use juju to deploy a service I want on that specific server?
[20:12] <tvansteenburgh> Valduare: hi, i'm new here too
[20:12] <Valduare> hi
[20:13] <tvansteenburgh> https://juju.ubuntu.com/docs/ is a great place to start
[20:14] <tvansteenburgh> the machine you install juju on does not get services deployed to it. it's used to send commands to the environment that juju is controlling
[20:17] <Valduare> ah
[20:18] <Valduare> currently I have a freenas box serving storage through iscsi to an esxi host box that runs 14 vm’s
[20:24] <lazyPower> Valduare: using the manual provider you could use juju to power your workloads on that esxi host
[20:24] <lazyPower> create the vms manually, register them in juju, then juju deploy <service> --to <machine id>
[20:25] <Valduare> was just reading this http://insights.ubuntu.com/resources/tutorials/interested-in-maas-and-juju-heres-how-to-try-it-in-a-vm/
[20:25] <Valduare> looks like i could possibly make this all virtualized?
[20:26] <lazyPower> IMHO, remove the complexity of having maas as your provisioner and just use the manual provider
[20:26] <lazyPower> while maas is cool, its accomplishing the same thing youa re doing with ESXI, by registering the hosts yourself to juju
[20:27] <Valduare> gives an interface for rebooting vm’s and such too though?
[20:27] <lazyPower> actually, juju doesn't do machine management like that. Its pretty focused on service orchestration, so it sits a layer above configuration management.
[20:28] <lazyPower> in terms of the tech stack.
[20:28] <Valduare> I mean maas would
[20:29] <lazyPower> I'm not nearly as familiar with maas as I am with juju. Perhaps someone else with a bit more experience would be able to answer that.
[20:29] <lazyPower> sarnold: ^
[20:31] <Valduare> so on the juju subject, it lets you specify what machine to provision such and such service
[20:31] <lazyPower> Valduare: the intention behind maas is to turn bare metal into a cloud, so theres a domain controller to handle the provisioning via cloudinit so you get bare systems with an image, similar to what you would get by booting the ubuntu AMI's on aws.
[20:31] <Valduare> ie mysql
[20:31] <lazyPower> Correct, you pick a service from teh charm store, or charm up your existing app, and define what the relationships require to operate, such as a database name, host, user/pass combo, and juju handles setting up the services
[20:32] <lazyPower> eg: mediawiki has a sql dependency. You deploy mediawiki, teh charm does nothing, deploy mysql and relate it to mediawiki and whammo, you've got a functioning mediawiki installation being managed by juju
[20:32] <lazyPower> ready to scale up/down, and be configured via the juju settings.
[20:32] <lazyPower> and if you're using the gui, you have a nice network map to visualize your deployments
[20:33] <Valduare> so since I just have the one host right now
[20:33] <Valduare> I should deploy a juju bootstrap vm
[20:33] <Valduare> on there and then start migrating all my services over to vm’s provisioned by juju
[20:35] <lazyPower> if you use the manual provider, the provisioning would be manual.
[20:35] <lazyPower> juju would handle the configuration mangement and orchestration
[20:35] <lazyPower> ie: how a service should be deployed, and how relationships are handled with the service.
[20:37] <Valduare> does it launch a new vm for each service?
[20:37] <Valduare> ie mysql in its own ubuntu vm
[20:39] <lazyPower> It depends on your provider. Thats why i've been specific with terminology about the manual provider
[20:39] <lazyPower> as it implies, all provisioning is done manually with the manual provider
[20:39] <lazyPower> if you're using a maas provider, it pulls from the allocation pool in maas. if you're using a cloud provider like aws, hpcloud, or azure it performs the api calls to provision a new vm for you, so therefore yes it does it for you.
[20:40] <Valduare> so with the manual provider i’d specify I want mysql on such and such vm
[20:40] <lazyPower> correct
[20:41] <Valduare> and if I were using openstack?
[20:41] <Valduare> does it separate all services out to their own vm
[20:42] <lazyPower> openstack communicates to nova to spin up your machines for you. its got a provisioning api
[20:42] <lazyPower> sorry, juju communicates to nova to spin up your machines.
[20:42] <lazyPower> i mistyped.
[20:44] <Valduare> there are a ton of layers to do all this lol
[20:45] <lazyPower> It can be, however juju can spin up an openstack cluster in 25 minutes, i think we've benchmarked even shorter times
[20:45] <lazyPower> and hten, you're free to create a juju environment on top of that openstack cluster that juju deployed. Using juju to deploy juju. Juju ception?
[20:48] <sarnold> haha, jujuception :)
[20:48] <Valduare> lol
[20:49] <Valduare> how long would that take on amd e-350 processors :P
[20:50] <lazyPower> I haven't run any benchmarks on that, so good question
[20:50] <lazyPower> i actually dont have experience with those processors either
[20:52] <Valduare> amd version of atom processor basically
[20:53] <lazyPower> ah, well you wont be breaking any earth shattering speed records
[20:53] <lazyPower> but I would think it would do fine
[21:08] <Valduare> so juju sets up a full openstack system with storage and everything?
[21:20] <Valduare> hmm im not seeing a charm for nginx?
[21:20] <jose> Valduare: see bug #994699
[21:21] <_mup_> Bug #994699: Charm Needed: Nginx <Juju Charms Collection:Incomplete by imbrandon> <https://launchpad.net/bugs/994699>
[21:22] <Valduare> hmm
[21:24] <lazyPower> Valduare: thats been a very back and forth topic in the past, if we want to charm up nginx as a service and deploy content as subordinates or just include nginx in your service dpeloyment
[21:24] <lazyPower> thus far, including nginx as part of the service deployment has been the winner, but there are some new charms coming in that set a web host with subordinate based content deployments.
[21:25] <lazyPower> however, nothing thats landed in the store yet
[21:26] <Valduare> what kind of things are you using charms to deploy?
[21:26] <Valduare> im searching through the charms now and … there’s not much?
[21:26] <lazyPower> Valduare: what are you expecting to see thats not there? we have 158 services to date of charms promulgated
[21:28] <Valduare> things like gitlab, canvas-lms, openerp, nginx-php-fpm-mysql,
[21:28] <lazyPower> thare are give or take ~ 70 more in personal namespaces that are not in the store, as they dont follow the store guidelines, or are not ready for public consumption.
[21:28] <lazyPower> Valduare: gitlab is in there, openerp is in there
[21:28] <Valduare> just searched for gitlab 0 came up
[21:28] <Valduare> ah now it shows heh
[21:28] <lazyPower> i've actuallly got a prototype gitlab charm
[21:28] <lazyPower> er, gitlab-ci charm
[21:29] <lazyPower> its not ready for promulgation by any stretch, but ready for people to stress test and provide feedback
[21:30] <lazyPower> and there's an openrp bundle sitting int he review q waiting to be analized and acked for the store so its drag and drop deployment.
[21:30] <Valduare> whats the bundle do differently than the openerp charms already there?
[21:32] <lazyPower> the bundle is a deployment schema that has all the services required to utilize openERP in a client/server model
[21:32] <lazyPower> where the backend is split from the front end, ready to be scaled individually depending on your needs
[21:32] <lazyPower> Valduare: https://juju.ubuntu.com/docs/charms-bundles.html
[21:40] <Valduare> and it’d install it all on one vm?
[21:42] <sarnold> however many VMs are necessary..
[21:43] <Valduare> what specifies the necessity
[21:44] <tvansteenburgh> Gators#1
[21:44] <tvansteenburgh> gah. and now you all no the password to my vm
[21:44] <tvansteenburgh> s/no/know/
[21:45] <tvansteenburgh> if i had a nickel for every time...
[21:45] <Valduare> if you hadnt mentioned…. we’d all think you were rooting for a highschool basketball team or something...
[21:48] <tvansteenburgh> well, not high school: http://espn.go.com/mens-college-basketball/team/_/id/57/florida-gators
[22:01] <Valduare> lazyPower: I was just reading about juju some more :P they were talking about wordpress juju add-unit wordpress does juju have some sort of load balancing system in place?
[22:01] <lazyPower> you can deploy haproxy infront of it
[22:03] <Valduare> this is stuff i’ve never gotten into before.. :)
[22:03] <sarnold> .. and it all seems too good to be true when you just juju add-unit -n 10 wordpress or whatever AND IT JUST HAPPENS
[22:03] <Valduare> is there a way I could setup a remote server and haproxy between the two locations so if one goes down ie internet outage it’d serve from the other location>?
[22:03] <sarnold> scary :)
[22:08] <lazyPower> Valduare: actually, with manual provider, you can do cross datacenter orchestration like that
[22:09] <lazyPower> and haproxy already takes care of the load balancing in the event of an outage
[22:09] <lazyPower> but your latency will be a factor in that style of deployment
[22:10] <lazyPower> tvansteenburgh: whats your IP again?
[22:10] <lazyPower> ;)
[22:10] <Valduare> lol
[22:11] <Valduare> i sitll dont quite understand the logic behind the ha stuff
[22:12] <Valduare> things like a php process pegging out the cpu I could understand but internet outages that’d knock your ha proxy out too
[22:15] <sarnold> Valduare: normally something like haproxy would live in front of a dozen or two dozen machines in the same rack..
[22:15] <sarnold> Valduare: if you lose networking to the datacenter, so be it ;) hopefully your application has been designed to failover to another availability zone
[22:15] <Valduare> where would that be designed into? :P
[22:16] <Valduare> im only familar with bare metal hosting lol
[22:18] <sarnold> Valduare: it could be done at DNS level, you could do round-robin dns with haproxy IPs, one per data center..
[22:18] <sarnold> Valduare: or you could use IP Anycast if you're rich and powerful enough :)
[22:19] <lazyPower> sarnold: I couldn't have put it any better myself. *hat tip*
[22:19]  * sarnold bows
[22:19] <sarnold> lazyPower: thanks :) did I overlook another option?
[22:19] <lazyPower> sarnold: i'm giving a talk at CMU next friday and I need to get this abstract over to the orchestrator. Would you mind giving it a proof for me?
[22:19] <sarnold> it feels like there's got to be at least one more option. hehe.
[22:19] <sarnold> lazyPower: sure
[22:20] <lazyPower> sarnold: there are others, but round robin/latency based dns was my poison of choice.
[22:20] <lazyPower> it worked at the entry point of the stack, vs complex configuration over convention
[22:20] <lazyPower> and im a rails guy, so i'll always pick convention over configuration, any day of the week
[22:21] <sarnold> lazyPower: yeah, load-balanced DNS has worked awesome for OFTC for years; the servers periodically report their user load and above a certain number the server is pulled, below a certain number it's re-added, and when machines are going to be serviced, they can get taken out entirely two weeks ahead of time to let people gracefully age off the thing
[22:22] <sarnold> but "works for an irc network" vs "works for netflix" are two different things ;) hehe
[22:24] <Valduare> right now I got a djbdns vm running on my one mini itx server host :P
[22:24] <Valduare> godaddy points to that for the name server of all my domains
[22:24] <sarnold> djb <3
[22:25] <Valduare> coudlnt figure out bind for the life of me
[22:27] <lazyPower> bind is cool, until it stops being cool
[22:27] <lazyPower> then its a giant tree made of hate
[22:28] <Valduare> djbdns has been pretty darn good to me so far
[22:29] <sarnold> given all the wonderful alternatives, you'd have to pay me quite a lot to get me to use bind :) heh
[22:29] <Valduare> so I basically need to get a dns outside of my “data center” eh?
[22:30] <sarnold> heh I'm surprised you were able to convince godaddy to let you use only a single dns server :)
[22:30] <sarnold> I thought 'two servers in glue' was the requirement
[22:31] <lazyPower> thats easy enough of masquerade
[22:31] <lazyPower> s/of/to
[22:31] <sarnold> hahah
[22:31] <sarnold> evil :)
[22:35] <Valduare> you just put the same ip in both slots on godaddy
[23:23] <Valduare> sarnold: so with the wordpress example, and haproxy, how does it sync data
[23:24] <sarnold> Valduare: I've got no idea how you'd reasonably scale wordpress to multiple availability zones / datacenters ...
[23:24] <Valduare> http://www.jorgecastro.org/2013/07/31/deploying-wordpress-to-the-cloud-with-juju/
[23:24] <sarnold> Valduare: mysql data dumps on cold backups would be my first attempt if I didn't find something better from an expert :)
[23:29] <lazyPower> valduare read up on MySQL replication with master slave relations
[23:30] <lazyPower> with manual provider you deploy to multip!e azs or dcs and apply the theory we have already covered
[23:31] <Valduare> how would all the /var/www/sitedir sync?
[23:31] <Valduare> how do you deploy to multiple servers
[23:32] <sarnold> rsync from whatever host is used for authoring?
[23:40] <Valduare> and whatever host used for authoring is whatever host the haproxy connects you to?
[23:41] <Valduare> bear with me :P lol
[23:41] <sarnold> Valduare: It would be your laptop or something? :) I dunno how these things actually get -used- :)
[23:42] <Valduare> oh think I see whaty ou mean
[23:42] <Valduare> so from workstation rsync to all the hosts at same time?
[23:43] <sarnold> Valduare: ah! check out the "Handling wp-content" section here: http://manage.jujucharms.com/charms/precise/wordpress
[23:44] <sarnold> of course that makes more sense than rsync. haha.
[23:56] <Valduare> ok