[15:40] <beisner> fwiw, seeing quite a few charm store timeouts today in CI.
[15:40] <beisner> getting 503 Service Unavailable
[15:43] <rick_h> beisner: there was a prodstack issue that's getting resolved right now
[15:43] <rick_h> beisner: it appears to be all back so please let me know if you're getting anything else
[15:51] <beisner> awesome thx rick_h
[16:00] <el_tigro1> What's the difference between 'juju deploy ubuntu' and 'juju add-machine'? Is it that 'juju deploy' will consider a machine created with 'add-machine' to be a candidate for deploying a unit to?
[16:10] <magicaltrout> yeah el_tigro1 if you're doing a manual deployment or similar you can add-machine then deploy --to X
[16:10] <magicaltrout> where as deploy will just start a new instance
[16:14] <el_tigro1> magicaltrout: I found that if I run 'add-machine', and then do 'juju deploy <charm>' *without* specifying '--to X', the machine created earlier with 'add-machine' is automatically used
[16:15] <el_tigro1> magicaltrout: which seems to be inconsistent with 'juju deploy --help': "juju deploy mysql               (deploy to a new machine)"
[16:17] <el_tigro1> magicaltrout: So if I 'juju add-machine', then 'juju deploy <charm>', then 'juju remove-application <charm>', the machine I created with add-machine is destroyed. Is that expected behavior?
[16:17] <magicaltrout> well it'll use what resources match the constrains and aren't allocated
[16:19] <el_tigro1> sounds good
[16:22] <el_tigro1> Maybe a small adjustment to the "juju deploy --help" would be helpful "juju deploy mysql               (deploy to a new machine *or a valid machine previously created with add-machine*)
[16:36] <el_tigro1> I guess I incorrectly used 'juju add-machine' when what I actually wanted was a new persistent machine with a blank ubuntu image under *my* control. So 'juju deploy ubuntu'. Not sure if its worth clarifying that in 'add-machine --help'
[18:55] <zeestrat> Hey rick_h, is there any magic in making a self-published charm available at cs:~username/charm, i.e. without revision number? I have pushed, release to stable and granted everyone.
[18:55] <rick_h> zeestrat: publish it to the stable channel
[18:55] <rick_h> zeestrat: what charm is it?
[19:00] <zeestrat> rick_h: Publish is charm release cs:~username/charm-rev right? Did that already and it says stable=true in charm show. Trying to run the charm release again just gets me an error with some ElasticSearch info. Charm is cs:~szeestraten/slurm-node
[19:00] <rick_h> zeestrat: ah, the ES info we're looking into. Another user hit it and we're trying to see what caused ES to be whiny atm
[19:00] <rick_h> zeestrat: so that's not your fault
[19:01] <zeestrat> Ah, yeah I saw you reported some issues earlier so I was wondering if it was just me screwing up
[19:01] <zeestrat> You need detailed bug report or info or already on it?
[19:02] <rick_h> zeestrat: no this is new and fresh. Was just trying to figure out what to file atm. Push works, but changing the permissions didn't. I'll keep you up to date as we figure out wtf.
[19:19] <skay> for charmhelpers.contrib.python.packages, why are the options for pip restricted? I need to use --find-links and --no-index in order to use a local cache
[19:22] <rick_h> zeestrat: can you make the release now?
[19:25] <zeestrat> rick_h: it seems to be working.
[19:25] <rick_h> zeestrat: coolio
[21:46] <el_tigro1> 'juju create-backup' creates a backup on the controller and downloads it to the client's current directory. Where does the backup file exist on the controller?
[23:08] <bdx> el_tigro1: I would assume it gets cleaned up