[06:32] <bashok> can someone shed some light on this bug? https://bugs.launchpad.net/juju-core/+bug/1261780
[06:32] <_mup_> Bug #1261780: go 1.1.2 TLS-enabled client does not accept our CACert <security> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1261780>
[06:37] <sarnold> bashok: ignoring the fact that the question is about node.js :) ... http://stackoverflow.com/a/14090402/377270
[06:45] <bashok> sarnold, thanks for the pointer, does it mean that my cert needs to have subjectAltName that points to the IP in the URI,
[06:47] <davecheney> i'm pretty sure you can't use ip addresses in subjectAldNames
[06:47] <davecheney> but it's been a while
[06:48] <sarnold> bashok: I don't know if the request is being made by IP or not, but if it is, that would make sense to try
[06:49] <sarnold> davecheney: I don't know if future RFCs removed the ability, but RFC 2818 says in part, "In some cases, the URI is specified as an IP address rather than a
[06:49] <sarnold> hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI."
[06:49] <bashok> sarnold, thanks i will give a try to that
[06:50] <davecheney> sarnold: right
[06:50] <davecheney> thanks
[06:50] <davecheney> this would only be for self signed certs
[06:51] <davecheney> no CA would sign a cert for an IP
[06:52] <sarnold> hahaha
[06:52] <sarnold> davecheney: man I hope you're right :)
[06:52] <sarnold> course worse things have happened..
[09:47] <Shamaria> Hi all
[09:47] <Shamaria> I'm a bit new to juju .. and I have a basic question
[09:48] <Shamaria> What is the difference/relationship between openstack and juju
[09:48] <Shamaria> ?
[09:52] <Shamaria> is it based in anyway on openstack??
[09:57] <lazypower> Shamaria, its not based on openstack. Juju sits a layer above openstack
[09:57] <lazypower> Juju is an orchestration layer, that interfaces with your provisioner and deployer
[09:58] <Shamaria> lazypower: thanks for the answer
[09:59] <lazypower> Anytime
[09:59] <Shamaria> so, does it require the presence of openstack?
[09:59] <Shamaria> for any reason?
[09:59] <lazypower> Nope. It runs on HPCloud, AWS, Azure, and has support for LXC Containers via the local provider.
[09:59] <lazypower> Its important to know you can deploy openstack with juju - since I left it off that last list.
[10:00] <Shamaria> interesting!
[10:00] <Shamaria> so it is good to have tool anyway!
[10:01] <lazypower> That it is. I encourage you to head over to jujucharms.com and interface with the demo gui to get a feel for what it can offer you
[10:01] <Shamaria> I've seen a list of supported applications, they call it charms
[10:02] <Shamaria> that can be delpoyed for me
[10:02] <Shamaria> which very good
[10:02] <Shamaria> I will take the venture and try it
[10:02] <lazypower> Yep, and anything that's not there you can write a charm for in your deployer of choice. Whether that be shell script, ansible, chef, compiled bins.
[10:02] <Shamaria> Wow
[10:03] <Shamaria> lazypower: I'm really glad talking to you today
[10:03] <lazypower> Glad I could be of help. If you have any questions don't hesitate to ask
[10:03] <Shamaria> sure I will :) ... what is the best place to get stared?
[10:04] <lazypower> I'm assuming you're running Ubuntu on a rig with at least 8gb of ram and 20gb of free disk space?
[10:04] <Shamaria> not really, but I'll handle such requirement
[10:04] <lazypower> I got started with the local provider - https://juju.ubuntu.com/docs/config-local.html
[10:05] <Shamaria> does it need all the 8GB of ram??
[10:06] <lazypower> Only if you're planning on deploying 3+ services on a local provider configuration
[10:06] <Shamaria> I see
[10:06] <lazypower> it runs quite well on AWS small instances
[10:07] <Shamaria> v.nice
[10:07] <ashipika> actually i'm playing with virtual machines and null environment :D
[10:07] <Shamaria> ya!
[10:07] <lazypower> Hows that coming ashipika? I haven't taken a look at the null provider in about a month. I htinkt hey just pushed another rev this week didn't they?
[10:08] <ashipika> it's going great..
[10:09] <Shamaria> one last question friends ... is the MAAS to Juju is like Hypervisor to Openstack??
[10:09] <ashipika> i created two images.. a "controller" image and a "compute" image.. controller is automatically bootstrapped when it starts (and has at least 5GB of persistence partition - labeled casper-rw) and when i boot up a compute VM (again with at least 5GB of persistence) it automatically adds itself to the juju environment..
[10:09] <lazypower> awesome :)
[10:09] <ashipika> you can check it out here: xmaas.xlab.si (no connection to maas)
[10:09] <ashipika> just writing a short tutorial for our guys
[10:09] <lazypower> Shamaria, Correct. Maas is a provisioner, same as the hypervisor.
[10:10] <lazypower> only, it works with bare metal not virtual machines.
[10:10] <Shamaria> u mean real servers?
[10:10] <lazypower> Correct
[10:10] <Shamaria> and can't be VMs
[10:10] <ashipika> yes.. read servers
[10:10] <Shamaria> Oh .. I see
[10:11] <lazypower> well, dont say can't be vm's
[10:11] <Shamaria> LOOL .. I get you
[10:11] <lazypower> because as I understand it, there is support for LXC containers coming to MAAS in the future
[10:11] <lazypower> no ETA on it from me though, because its from the rumor mill at this point.
[10:11] <ashipika> but MAAS requires you to have a separate network, because it needs to set up its own DHCP and DNS servers
[10:11] <lazypower> I want to play with MAAS so bad, i just dont have the setup for it.
[10:12] <ashipika> try my images.. close to maas, but not quite :)
[10:12] <ashipika> and it works in VMs
[10:12] <Shamaria> that's great to hear ... isn't MAAS a base rquirement for Juju?
[10:12] <Shamaria> that juju can't work without?
[10:12] <lazypower> Tell ya what ashi, when I'm not writing a plan for reducing cost of ownership on a network I'll do that.
[10:13] <lazypower> Shamaria, incorrect. Juju is independent of MAAS
[10:13] <Shamaria> when mass is needed then
[10:13] <Shamaria> ?
[10:13] <ashipika> only when you want to provision bare metal servers..
[10:13] <ashipika> and deploy your services on the
[10:13] <lazypower> When you want to use MAAS as a provisioner, it would assume the role that one of the other providers is assuming (Read: AWS, HPCloud, LXC, Etc.)
[10:13] <ashipika> them\
[10:14] <Shamaria> does this mean juju uses a similar architecutre of openstack's??
[10:15] <Shamaria> database, rabbitmq, ...
[10:15] <Shamaria> etc.
[10:15] <ashipika> juju can deploy those for you..
[10:15] <lazypower> It uses a controller unit, rabbitmq, zookeeper, mongodb.
[10:15] <lazypower> so not quite like openstack
[10:15] <Shamaria> but the same idea
[10:15] <lazypower> i'm going to disclaim this - i'm not an openstack expert by *any* sense of the phrase
[10:16] <lazypower> so take my comparisons with a grain of salt and maybe some light research.
[10:16] <Shamaria> Ok
[10:16] <ashipika> openstack does not deploy services for you, does it?
[10:16] <Shamaria> it is an IAAS
[10:16] <lazypower> i dont think so
[10:16] <ashipika> yes
[10:17] <Shamaria> so it doesn't help you providing any service
[10:17] <ashipika> juju deploys services and does orchestration in a beautiful way :)
[10:17] <ashipika> exactlly
[10:17] <Shamaria> but it helps managing your cloud of servers
[10:17] <Shamaria> Yes
[10:17] <Shamaria> That's what I newly knew :)
[10:18] <ashipika> so if you say juju deploy something it will by default as the provider to provision a new machine.. unless you specify --to option that lets you decide where you want to deploy stuff
[10:19] <Shamaria> so, can I make use of virtual cloud machines to be that new machine?
[10:19] <lazypower> yep
[10:19] <ashipika> yup
[10:19] <Shamaria> so it can be utilized on top of openstack
[10:19] <Shamaria> that;s really good
[10:19] <ashipika> yes
[10:20] <Shamaria> why Juju is not that famous
[10:20] <ashipika> or use maas if you have some extra machines around
[10:20] <Shamaria> does it have bugs or it is unreliable in any way?
[10:20] <Shamaria> ashipika: Yes
[10:21] <ashipika> well.. it is in development.. so yes, expect some bugs.. i stumbled upon a few while testing.. but the good thing is that development is really active and bugs get fixed quickly
[10:21] <lazypower> Shamaria, its gaining steam. The best part of juju is the quality gating through the charm store
[10:22] <lazypower> your work will not be listed as public unless it passes the community review process
[10:22] <lazypower> This works for building block charms, i'm helping a company here in Pittsburgh onboard with juju for their proprietary stuff since the orchestration just "makes sense"
[10:24] <Shamaria> I see
[10:24] <Shamaria> what is the mature similar application out there, I'm talking about open source ones?
[10:24] <lazypower> I think the big draw for juju is the gui, and the fact you're not tied to a specific framework for your deployer.
[10:24] <ashipika> br
[10:24] <ashipika> b
[10:24] <lazypower> The wordpress charm works really well, discourse, mongodb
[10:25] <lazypower> I'm getting pretty close to pushing a release candidate for errbit
[10:26] <Shamaria> I thought Juju's power is its GUI
[10:26] <Shamaria> what do you mean by "specific framework for your deployer"??
[10:26] <lazypower> The gui is slick, but everything you do in the gui you can do with the CLI
[10:26] <Shamaria> of course
[10:26] <lazypower> Meaning you're not tied to just chef, or ansible, or bash.
[10:27] <lazypower> you can literally use whatever deployer framework you want
[10:27] <Shamaria> is that a bad thing?
[10:27] <lazypower> nope, its flexible
[10:27] <Shamaria> yep
[10:28] <Shamaria> brb
[10:28] <ashipika> the only thing i REALLY miss in GUI is the --to option
[10:33] <Shamaria> I'm back
[10:33] <Shamaria> One very important question
[10:34] <Shamaria> after installaing some architecture with the required connections between the apps
[10:34] <Shamaria> then I decided for any reason to uninstall the juju
[10:34] <ashipika> yes?
[10:34] <Shamaria> will this affect by any mean the installed architecture
[10:34] <ashipika> well.. no.. unless juju gets stuck destroying a unit or something..
[10:35] <lazypower> I don't think that's recommended. You can power down the controller unit when its not in use to help reduce overhead costs if thats you're concern
[10:35] <ashipika> but i would say that really depends on the charms you deploy
[10:37] <ashipika> lazypower: do i understand correctly that i must subscribe "charmers" if i want a charm to go through the review process?
[10:38] <lazypower> Correct
[10:38] <lazypower> https://juju.ubuntu.com/docs/authors-charm-store.html
[10:39] <lazypower> in-case you need a refresher.
[10:39] <rawang> hello guys , i wonder after I installed ceph-radosgw, how do i test it from cli?
[10:41] <Shamaria> lazypower: , ashipika: one point is still not so clear to me ... is it possible that MAAS will consider VMs as bare-metals
[10:42] <ashipika> i never played with VMs and MAAS.. since it uses PXE boot to provision new machine it need to set up its own DHCP server or change the existing one -> our admins would go bat-crazy if i tried that..  so i created a dedicated network just for MAAS testing..
[10:43] <lazypower> Shamaria, http://www.slideshare.net/openstackindia/maas-juju-introduction
[10:43] <Shamaria> this makes you opt for the virtualization
[10:44] <lazypower> really good set of slides over Juju, Maas, and whats capable at a high level.
[10:44] <Shamaria> moreover, there must be a way to disable the isntallation of DHCP and DNS servers
[10:47] <Shamaria> lazypower: the presentation you sent means yes
[10:47] <Shamaria> MAAS can handle cloud instances as bare metal
[10:48] <Shamaria> Did I get it right?
[10:48] <lazypower> Not a MAAS expert, last i tried maas it wanted bare metal.
[10:48] <lazypower> i think theres a VMAAS coming down the tube, but its going to be experimental if its available
[10:49] <Shamaria> what if I wanted to deploy the service on multiple VMs
[10:49] <Shamaria> what shall be done
[10:49] <Shamaria> will I have to handle this manually?
[10:50] <lazypower> Depends on the provider. If you're using one of the supported providers - no. It talks to the provider via their API and spins up a new server, bootstraps it, and then loads your service
[10:50] <lazypower> if you're going with the null provider, provisioning machines is a manual process
[10:51] <Shamaria> I'm afraid I have a very basic question ... what is the provider ?
[10:52] <lazypower> Juju supports provider environments. Think of the provider as whatever service is going to be "providing" your machines. If thats bare metal, virtual, or otherwise.
[10:54] <Shamaria> I see your point
[10:54] <Shamaria> do you have examples of providers?
[10:54] <ashipika> Shamaria: as i wrote earlier.. if you want to play with VMs you can always try the images at xmaas.xlab.si and the null environment/provider
[10:55] <ashipika> it also gives you the option of creating bootable CD/USB, plug it into a machine and have it "bare metal"
[10:55] <ashipika> i.e. without virtualization
[10:55] <Shamaria> ashipika: Yes, you already said that .. exuese my novelty :)
[10:55] <Shamaria> Thanks a lot
[10:56] <lazypower> ashipika, bookmarked for later :)
[10:56] <Shamaria> hahaha
[10:56] <ashipika> > /dev/null :D
[10:56] <Shamaria> LOL
[10:59] <Shamaria> lazypower: , ashipika:  I really thank you both a lot
[10:59] <Shamaria> I learned much from you today
[10:59] <lazypower> Anytime. Happy to help
[10:59] <Shamaria> I'll keep returning to this room
[10:59] <ashipika> Shamaria: you're welcome.. i'm just a juju beginner myself
[11:00] <Shamaria> but you helped a lot :)
[11:00] <Shamaria> You both have a really good day/night
[13:53] <InformatiQ> Hei guys anyone care to test this charm for me https://bugs.launchpad.net/charms/+bug/795480
[13:53] <_mup_> Bug #795480: Charm needed: Trac <bitesize> <Juju Charms Collection:Incomplete by rhanna> <https://launchpad.net/bugs/795480>
[15:17] <marcoceppi> jcastro: remember when you used to be able to get PNGs of a juju deployment
[15:17] <marcoceppi> was that in jitsu?
[15:17] <jcastro> it wasn't png's it was a gource thing
[15:17] <jcastro> we just piped status to gource
[15:17] <jcastro> or do you mean like a picture of a deployment? I don't think we ever did that did we?
[15:18] <marcoceppi> jcastro: we def did. I can't remember if it was juju status --format=png or if it was in jitsu
[15:19] <jcastro> huh
[16:18] <jcastro> marcoceppi, ok here we go
[16:18] <marcoceppi> jcastro: where are we going!
[16:18] <jcastro> I am going to test negronjl's sharding mongo config via the local provider
[16:19]  * marcoceppi holds breath
[16:19] <negronjl> jcastro: good luck ( you'll need it ) :)
[16:29] <jcastro> negronjl, load is 10!
[16:30] <negronjl> jcastro: never tested it on local provider ... better you than me :P
[16:30] <jcastro> yeah
[16:30] <jcastro> it's not bad
[16:30] <jcastro> machine is totally usable
[16:31] <jcastro> load is now 15 and climbing
[16:37] <jcastro> negronjl, dude, it's working
[16:37] <jcastro> well, well on its way to working
[16:37] <negronjl> jcastro: cool
[16:47] <lazypower> Nice! You're swamping me already, i only deployed 12 units
[16:47] <lazypower> 3 shards, x repls + config servers + arbiter
[16:48] <lazypower> Let me see your YAML when you're done please
[19:26] <jcastro> jorge@jilldactyl:~$ sudo juju bootstrap
[19:26] <jcastro> ERROR cannot use 37017 as state port, already in use
[19:26] <jcastro> marcoceppi, any ideas there?
[19:32] <jcastro> hi fwereade
[19:32] <jcastro> any idea why I would get this:
[19:32] <jcastro> jorge@jilldactyl:~$ sudo juju bootstrap
[19:32] <jcastro>  ERROR cannot use 37017 as state port, already in use
[19:32] <marcoceppi> jcastro: it means you've already got juju-db running
[19:32] <jcastro> oh ok
[19:32] <jcastro> so restart it?
[19:32] <marcoceppi> initctl list | grep juju
[19:33] <marcoceppi> sounds like a bad destroy
[19:33] <jcastro> it is not running
[19:33] <jcastro> but yeah, probably a bad destroy
[19:33] <marcoceppi> something is using that port, what does ps -aef | grep mongo show?
[19:33] <fwereade> jcastro, yeah, that sounds most likely
[19:33] <jcastro> mongod is using the port
[19:33] <jcastro> do I stop or restart it?
[19:33] <fwereade> jcastro, if you set api-port and state-port you should be able to run multiple local providers fwiw
[19:33] <marcoceppi> stop it
[19:34] <jcastro> when I stop it it seems to fire back up
[19:34] <marcoceppi> jcastro: ohhhhhh
[19:35] <marcoceppi> jcastro: these are probably per user upstart jobs
[19:35] <marcoceppi> maybe not, idk if juju is using thatyet
[19:35] <marcoceppi> what does sudo initctl list | grep juju show?
[19:36] <jcastro> http://paste.ubuntu.com/6722577/
[19:37] <marcoceppi> jcastro: yeah, sudo stop juju-db-root-local
[19:37] <marcoceppi> jcastro: then
[19:37] <marcoceppi> jcastro: I want you to try something different
[19:37] <jcastro> ok
[19:37] <marcoceppi> don't use sudo during bootstrap
[19:43] <marcoceppi> jcastro: the suspense is killing me
[19:47] <jcastro> ok
[19:47] <jcastro> errors out with the normal "sudo must be used"
[19:48] <marcoceppi> jcastro: ah, damn. Thought something magically had happened
[19:48] <jcastro> should I try to sudo bootstrap again?
[19:49] <marcoceppi> jcastro: yes
[19:49] <jcastro> ERROR Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused
[19:49]  * thumper looks briefly at chatter
[19:49] <thumper> you guys tring to get multiple local providers working on one machine?
[19:49] <jcastro> no
[19:49] <marcoceppi> thumper: no, just one
[19:49] <thumper> oh
[19:49] <jcastro> I am trying to get one local working
[19:50] <marcoceppi> jcastro: try your good 'ol .jenv dump
[19:50] <thumper> jcastro: what is the tl;dr of the situation?
[19:50] <jcastro> I ran out of disk space
[19:51] <jcastro> so I added a drive and remounted /var/lib/lxc
[19:52] <jcastro> ERROR environment is already bootstrapped
[19:52] <jcastro> when I try to bootstrap, but there are no containers running
[19:52] <marcoceppi> delete the local.jenv ?
[19:52] <jcastro> yep
[19:52] <thumper> jcastro: are you looking for the definitive list of shit to delete?
[19:52] <marcoceppi> jcastro: rm -f /etc/init/juju-* ?
[19:53] <thumper> there are to init files in /etc/init, one for the machine agent and one for the mongo db
[19:53] <thumper> there is a file in /etc/rsyslog.d for the logging
[19:53] <thumper> there are the containers defined in /var/lib/juju/containers
[19:53] <thumper> there are the containers themselves in /var/lib/lxc
[19:53] <thumper> there is the directory in ~/.juju/<environ>
[19:54] <thumper> there is the .jenv file in ~/.juju/environments
[19:54] <thumper> nuke all those
[19:54]  * marcoceppi makes notes
[19:54] <jcastro> which is the file for mongo?
[19:54]  * thumper looks
[19:54] <jcastro> mongodb.conf?
[19:55] <thumper> nope
[19:55] <thumper> /etc/init/juju-db-<user>-<envname>.conf
[19:55] <thumper> /etc/init/juju-agent-<user>-<envname>.conf for the machine agent
[19:56] <jcastro> should I move back to 1.16.5?
[19:56] <thumper> /etc/rsyslog.d/25-juju-<user>-<envname>.conf
[19:56] <thumper> jcastro: this hasn't really changed between 1.16.5 and 1.17
[19:56] <jcastro> sigh
[19:56] <jcastro> this never works for me
[19:57] <jcastro> I'll just skip this and come back to it
[19:58] <jcastro> I'm supposed to be reviewing 2 charms a day, not one charm in 2 days!
[19:58] <thumper> :-(