[00:54] <aisrael> web: I responded to your question
[00:56] <flying_nomad> hi there, testing juju 1.22 with MAAS 1.7
[00:56] <flying_nomad> after bootstraping to kvm node
[00:57] <flying_nomad> machine-0: 2015-03-25 00:44:39 DEBUG juju.mongo open.go:122 TLS handshake failed: x509: certificate is valid for localhost, juju-apiserver, <juju-bootstrap-node-name-here>, not juju-mongodb
[00:57] <flying_nomad> after bootstrap it works but when jujud-machine-0 process is restarted (or host is restarted)
[00:58] <flying_nomad> above happens
[00:58] <flying_nomad> and environment becomes unusable, nothing works because API fails to start
[01:01] <flying_nomad> any idea?
[01:01] <flying_nomad> 1.20 with same MAAS 1.7 was working fine
[01:19] <web> I haven't
[01:20] <web> oops
[01:20] <web> typos:x
[09:09] <jamespage> gnuoy, if you have time https://code.launchpad.net/~james-page/charm-helpers/openstack-snippets/+merge/254057
[09:09] <jamespage> doing a few snippet refactoring for kilo templates
[09:13] <gnuoy> jamespage, approved. If you get a sec I have a larger mp https://code.launchpad.net/~gnuoy/charm-helpers/neutron-shuffle/+merge/253958
[09:13] <gnuoy> mostly stolen from quantum-gateway apart from NeutronAPIContext
[09:18] <jamespage> gnuoy, +1 and merged
[09:18] <gnuoy> fantastic, thank you
[14:09] <apuimedo> gnuoy: if a charm does not require any configuration, should it have a config.yaml?
[14:13] <marcoceppi_> apuimedo: no, it should be ommited
[14:13] <apuimedo> marcoceppi_: thanks ;-)
[14:14] <apuimedo> marcoceppi_: I guess then hookenv.config will return {}, right?
[14:14] <apuimedo> or None?
[14:14] <marcoceppi_> apuimedo: probably {}, not sure the implications
[14:14] <apuimedo> marcoceppi_: is there the possibility that something breaks?
[14:15] <apuimedo> i.e., is it tested?
[14:15] <marcoceppi_> apuimedo: well if there's no config.yaml why even invoke hookenv.config?
[14:16] <apuimedo> true ;-)
[14:16] <marcoceppi_> apuimedo: it'll parse however juju handle config-get without config, which should just be {}
[14:17] <apuimedo> it's just that I took neutron-api's charm test module and I'm making it into a test utility that can be used by any charm
[15:15] <Muntaner> hello guys
[15:15] <Muntaner> I need to be free in what distro I launch with my charms: CentOS, Kali, etc... can I actually do that with juju?
[16:09] <lp|sprint> Muntaner: we're getting support landing for centos this cycle, along with windows
[16:09] <lp|sprint> and debian
[16:10] <stub> mbruzek: Did you see my comments in https://bugs.launchpad.net/charms/+bug/1419116 ? It explains in more detail the problems  I'm seeing with the test environment and some of the pollution I've spotted.
[16:10] <mup> Bug #1419116: New trusty/cassandra charm <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1419116>
[16:10] <lp|sprint> I dont have an ETA on when it will be available, but i know that preliminary support is being landed between maas and juju for these "series"
[16:11] <lp|sprint> stub: we did, we're talking about it now actually
[16:11] <lp|sprint> stub: we're looking at containerizing our CI to get a better level of isolation and a distributable tool that will mirror CI a whole lot better than just saying "Run bundletester on your local setup"
[16:12] <mbruzek> stub: Yes thank you for the additional details. tvansteenburgh is taking a look at that.  We are discussing a new way to isolate the tests better with docker.
[16:12] <mbruzek> thanks lp|sprint
[16:12] <stub> lp|sprint: Yeah, without isolation its a timebomb (the python3 unittests *have* passed before, so this is new)
[16:13] <stub> lp|sprint: We have solved this problem before with thinks like the Ubuntu build daemons, but that is probably overkill for this.
[16:14] <lp|sprint> I'm not familiar with them - but yeah. This isn't a new problem :)
[16:14] <lp|sprint> I dont think we are re-engineering the wheel - but having a distributable docker container to leverage for your testing would be a big win in terms of isolation, and reusable everywhere
[16:15] <lp|sprint> stub: one of the things we've been looking at is taking whitmo's charmbox/jujubox as the base, and using that directly in jenkins to handle our isolation
[16:15] <stub> yes. I was thinking lxc container, but docker is distributable and probably a better choice.
[16:16] <stub> I'd actually love to not install juju at all on my actual machine, and have everything isolated in a VM.
[16:16] <lp|sprint> you can do that today with jujubox/charmbox
[16:16] <stub> I will look into that.
[16:17] <lp|sprint> https://github.com/whitmo/jujubox
[16:17] <lp|sprint> stub: you may want to use charmbox over jujubox - as it comes pre-installed with a lot of the common author deps
[16:17] <lp|sprint> like charmtools, bundletester, venv, et-al
[16:18] <stub> really low googlejuice on both jujubox and charmbox. I'd hate to see what I turned up with safesearch off.
[16:18] <stub> Ahh, there we go.
[16:19] <Muntaner> lp|sprint,
[16:20] <Muntaner> when is the support for CentOS, debian and windows released?
[16:20] <lp|sprint> Muntaner: I dont have an ETA on when it will be available, but i know that preliminary support is being landed between maas and juju for these "series"
[16:21] <lp|sprint> as is, windows support has snuck in during the 1.21 release, they may already be there for the other series - however - if the images aren't listed in simple streams its not officially supported.
[16:22] <mbruzek> stub charmbox is what we use to run tests.
[16:27] <lp|sprint> Muntaner: i'm going to guess months (I try to keep info like this in the public channel so others can benefit) - but thats hard for me to call as i dont work on core - so i don't really hae the insight into when that will land
[16:34] <Muntaner> lp|sprint, thanks
[16:35] <Muntaner> lp|sprint, thanks
[16:35] <lp|sprint> Muntaner: i would suggest to email the list, as someone thats working on the integration will more than likely be able to reply with more info on when it will land.
[16:35] <marcoceppi_> stub: mbruzek it's what we're looking to use to run tests in. It's a docker container with isolation
[16:36] <mbruzek> marcoceppi_: I already use it for testing/reviewing charms.
[16:36] <Muntaner> lp|sprint, thanks, how can I do that? never did it
[16:36] <marcoceppi_> Muntaner: butit's not usedon CI yet
[16:36] <lp|sprint> Muntaner: email juju@lists.ubuntu.com
[16:37] <lp|sprint> i'm not sure what marcoceppi_ was trying to say there, i think he's in 2 conversations
[16:37] <stub> marcoceppi_: yeah, I'll give it a shot tomorrow but you are more than welcome to beat me to it at the sprint :)
[16:41] <stub> marcoceppi_: If you haven't seen it already, have a look at amuletfixture.py in either my cassandra or the enable-integration-tests postgresql branch. You might want it in amulet core.
[17:07] <marcoceppi_> stub: awesome, thanks. I'll take a look at that and possibly put it in as amulet.fixture in the next release
[17:08] <Muntaner> guys, I have use floating-ip = true in my environemnts.yaml. I want to be able to deploy a service without a floating-ip, can I?
[17:38] <web> aisreal: Thank you again.  Your changes stopped the load failure on config-change but now a new issue "503 NO SERVER FOUND".  Hopefully I can hash this out real quick.
[17:39] <web> aisrael
[17:39] <web> oops
[17:39] <aisrael> web: Excellent good to hear!
[17:39] <web> ;)
[18:07] <web> aisrael: sorry to bug, but in that yaml model you made is `demo` is the name of the haproxy server?
[18:08] <aisrael> web: demo was the name of the charm I wrote to test it, so in your case it would be mindproject
[18:09] <aisrael> web: can you juju ssh haproxy/0 and pastebin the /etc/haproxy/haproxy.cfg file?
[18:10] <web> aisrael: sure deal.  let me try this fix real quick.
[18:20] <web> aisrael: http://paste.ubuntu.com/10679715/
[18:22] <aisrael> web: I think I see the problem. private-address is returning the internal amazon hostname.
[18:22] <web> aisrael: making sure the right address is associated
[18:23] <web> isn't supposed to be
[18:23] <web> I thought that was one of the beautiful things about haproxy is it hides the actual server
[18:24] <aisrael> what about getting public-address?
[18:24] <web> or is it because of ssl I have to use public?
[18:24] <aisrael> Hmm. Maybe you're right
[18:24] <aisrael> from the haproxy machine, can you ping that internal hostname?
[18:28] <web> aisrael: 82 packets sent and received with 0 loss http://paste.ubuntu.com/10679750/
[18:29] <aisrael> Does haproxy.log show anything relevant?
[18:29] <web> aisrael: gonna try and replace it with the internal ip instead of dns
[18:30] <web> oh good idea :x  haven't even looked(i know, stupied)
[18:55] <web> aisrael: the juju default log shows http://paste.ubuntu.com/10679839/.  Is there another Haproxy log beside `/var/lib/haproxy/dev/log`(present) and `/var/log/haproxy.log`(missing) I should maybe look at?
[18:57] <aisrael> There should be a /var/log/haproxy.log (or /var/log/haproxy/haproxy.log). Are you sure your service is listening on port 80?
[18:57] <web> i am reading that but its not there
[18:58] <web> sudo tail -v -n 1 /var/log/{syslog,messages,haproxy-*} <--should return all logs
[18:58] <web> but looking in there only related log is juju
[18:59] <web> there is supposed to be `/var/log/messages` also
[18:59] <web> not there
[19:00] <BungalowBoy> Hi folks, does anyone have any experience of deploying juju to Azure and can offer some help?
[19:01] <jcastro> what's the issue?
[19:01] <BungalowBoy> It doesn't work :)
[19:01] <BungalowBoy> More specifically:
[19:01] <BungalowBoy> Bootstrap fails
[19:02] <BungalowBoy> ERROR failed to bootstrap environment: PUT request failed: BadRequest - XML Schema validation error in network configuration at line 39,18. (http code 400: Bad Request)
[19:06] <jcastro> what version of juju?
[19:07] <BungalowBoy> stable from the ppa: 1.22.0-0ubuntu1~14.10.2~juju1 running from my utopic desktop
[19:10] <web> aisrael: The thing that is getting me is the only ports ever referenced are 80 and 82.  I opened 443 to the haproxy server in hopes it was an oversight, but no.
[19:12] <web> aisrael: I am trying the self signed option but still nothing here are my new logs and config setup.  Think I am gonna try a public NS to see if it works like you thought.
[19:13] <aisrael> web: The thing you want to make sure is that you can reach the mindproject unit on port 80 and 443
[19:16] <BungalowBoy> I'm guessing my problem is related to the fact I'm trying to deploy a juju environment to an Azure subscription that already has networking and subnets set up
[19:17] <web> aisrael: http://paste.ubuntu.com/10679974/ (conf) http://paste.ubuntu.com/10679983/ (log)  I thought maybe I could at least get though with a warning on the cert, but nope.  Gonna revert back and try messing with the config for 443 instead of public first, then I'll try public.
[19:18] <jcastro> sinzui, ^^ any ideas for BungalowBoy?
[19:19] <BungalowBoy> Looking at the source code for juju-core shows a hard coded network http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/provider/azure/environ.go
[19:19] <BungalowBoy> but I'm no coder so I could be wrong
[19:19] <sinzui> BungalowBoy, That happens a lot on azure. CI often fails and retries
[19:21] <sinzui> BungalowBoy, Azure is very slow at cleaning up resources. so after a failure, instance and networks take a 30 minutes to be removed before you can try bootstrapping again. Juju often doesn't have permission to clean up after a problem because Azure is blocking
[19:21] <BungalowBoy> @sinzui thanks. excuse my ignorance but what is CI?
[19:21] <sinzui> BungalowBoy, you can try renaming the juju-environment to minimise the reuse of existing networks and containers
[19:22] <sinzui> BungalowBoy, I run Juju's CI. It deploys stable and test juju's to verify cloud-health and juju's health
[19:22] <BungalowBoy> Commandline interface?
[19:24] <BungalowBoy> my environment.yaml file is set up correctly, I run 'juju bootstrap -e azure --constraints instance-type=Small' from bash and get the above error
[19:25] <BungalowBoy> I haven't defined networking anywhere
[19:25] <sinzui> BungalowBoy, Continuous Integration: We can see that Azure hasn't been very reliable. Each red/blue do it an hour;y health check http://juju-ci.vapour.ws:8080/view/Cloud%20Health/job/test-cloud-azure/
[19:25] <BungalowBoy> the Azure subscription I'm trying to bootstrap has a 172.16.x.x network
[19:28] <BungalowBoy> ah, so juju doesn't currently work with Azure very well at all then!
[19:28] <sinzui> BungalowBoy, "PUT request failed: BadRequest" means Azure's own resources are not available when they needed to be. There is little you or Juju can do about it
[19:29] <BungalowBoy> oh the joys of MS! :)
[19:35] <BungalowBoy> well thanks for taking the time @jcastro and @sinzui, guess I'm going to have to rethink
[20:03] <jcastro> sinzui, hey since I already bothered you once, any ideas on this one? http://askubuntu.com/questions/600168/juju-no-matching-tools-found-for-constraint
[20:04] <sinzui> jcastro, I am not making progress on that one, which is also https://bugs.launchpad.net/juju-core/+bug/1435644
[20:04] <mup> Bug #1435644: private cloud:( environment is openstack )index file has no data for cloud <juju-core:New> <https://launchpad.net/bugs/1435644>
[20:05] <jcastro> oh good, it's the same person at least
[20:05] <sinzui> jcastro, The failure is talking to the openstack, but I know know why since he clearly got a working instance
[20:15] <web> aisrael: Progress!!!! Now I am getting through on port 80 but when I force HTTPS it wont connect on 443 and now returns a 504 timeout response
[20:15] <web> aisrael: But progress!!!
[20:16] <aisrael> web: Excellent! I think there's something in Haproxy's readme about ssl needing to use apache.
[20:19] <web> aisrael: It looked to me what it was saying was that if you want to serve your own ssl certs then the common method is for apache distribution but i am using uncommon node.js application  using express to manage my certs.
[20:20] <web> aisrael: I am almost positive it is a port issue because I cant ping 443
[20:21] <aisrael> web: did you expose 443?
[20:21] <web> aisrael: using debug to view each request being sent instead of running as service for the time.
[20:21] <web> yep
[20:47] <aisrael> web: Unfortunately, I haven't done much with SSL.
[20:51] <web> aisrael: making my own SaaS cloud framework for the first time.  Never needed more than one SSL app server.  So my experience isn't huge either, I really appreciate the help you've provided.
[20:59] <web> aisrael:  Think I found the problem.  SSL pass though not possible without `mode tcp`.  https://serversforhackers.com/using-ssl-certificates-with-haproxy#ssl_passthru
[21:01] <aisrael> web: Ah, that makes sense. Let me know if it works for you!
[21:09] <web> aisrael: well I don't see ssl conn error in the browser anymore but my connection is being refused.
[21:12] <web> Wait damn charm keeps reseting config when I restart server, so maybe it will. trying again. May have to make a modified charm.
[21:28] <wgrant> What's the recommended way to deploy a custom SSH service using Juju?
[21:29] <wgrant> I need to run something other than OpenSSH on port 22.
[23:55] <web> aisrael:  Not done yet but I think I know what I need to do.  One thing I need to do is stop trying to create a HTTPS express application and leave it as HTTP.  SSL will initiate and be maintained though Haproxy only.
[23:55] <web> let you know what happens
[23:55] <aisrael> web: awesome, thanks! I'll update the haproxy docs with your findings
[23:56] <web> For sure!  Especially your findings yesterday