[01:05] <kwmonroe> Bialogs: if you're using the gui, i think grey means the relation has been tentatively requested.. it goes green once you commit that request and the command gets sent to juju.  that's my best guess, but #juju-gui would have the authoritative answer.
=== scuttlemonkey is now known as scuttle|afk
[01:55] <rick_h_> kwmonroe: Bialogs correct
[01:55] <rick_h_> kwmonroe: Bialogs I think that the relation lines for subordinates are also grey though and deemphasized
[03:28] <thumper> lazyPower: I don't suppose you are working late into the night again are you?
[03:49] <jose> in his birthday?
[03:50] <jose> (actually, I was going to ask the same question :P)
[07:34] <suchvenu> Hi, I am an IBM charmer . I am getting the following error while trying to create a bug in Launchpad
[07:34] <suchvenu> Oops!  Sorry, something just went wrong in Launchpad.  We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience.  (Error ID: OOPS-fa7f47217944bd43836662fe22cb1415)
[07:35] <suchvenu> Can someone help with this
=== rogpeppe1 is now known as rogpeppe
=== brandon is now known as web
[11:00] <ludvigx> Has any of you guys ever experienced that the juju cli tools become unresponsive ? returning nothing. Only command that returns anything is juju version
[11:03] <andyjeffries> Does anyone know of a good blog post/document on how to run your own Juju charms store?  We want private charms that aren't publicly accessible (we may open source them later, but we'd like that to be an explicit action, we may not if they are complely custom to our systems).
[11:08] <marcoceppi> ludvigx: yes, typically means it can't connect to the environment you're trying to talk to/it thinks it's still bootstrapped (if it's not)
[11:09] <marcoceppi> andyjeffries: you'd have to just create a local charms repository https://jujucharms.com/docs/stable/charms-deploying#deploying-from-a-local-repository
[11:09] <ludvigx> marcoceppi : hmm, it was a functioning environment before. So possibly a problem on the bootstrap node ?
[11:10] <marcoceppi> ludvigx: it's possible,  best to run `juju status --debug --show-log`
[11:10] <marcoceppi> let that run until it completes, which may take a while
[11:11] <andyjeffries> marcoceppi: OK, so we couldn't use the Juju GUI to deploy charms from a local repository on our development machines?  Or we could, but we'd put the local repository on our Juju server and then would run the juju command only from that server (because our development machines wouldn't have the local repository on it)?
[11:11] <debochat> I am trying to install "libgcc1:i386" through my Juju install hook but the command is failing with the below error:
[11:11] <debochat> 2015-05-26 08:59:23 INFO unit.wxs/0.install logger.go:40 E: Unable to locate package libgcc1
[11:11] <andyjeffries> I saw there was a repo on GitHub https://github.com/juju/charmstore and thought there'd be a doc/blog somewhere on how to run this for a local/private/hosted install.
[11:11] <debochat> but the same command works when trying manually
[11:12] <marcoceppi> andyjeffries: you *can* deploy local charms to the GUI, by dragging and dropping zips of them, but it's not a perfect experience
[11:12] <debochat> my juju env is local
[11:13] <debochat> and working on ubuntu 14.04
[11:13] <marcoceppi> andyjeffries: you can also run a charmstore locally, but juju has no way of knowing how to point to it, so you'd have to poision DNS to get that to work. Also, charmstore ingests it's data from launchpad atm, so even if you did get it running still not perfect because you'd have to have a private launchpad running IIRC
[11:13] <andyjeffries> marcoceppi: Sorry, I may be confusing terms (I'm new to Juju and OpenStack).  We want to publish our charms to a local (inside our network) charm store, so that later they can be searched for in the same way as the rest of the charms.  We'd probably want to point our Juju server to our local charm store server and then we'd fork/clone any public charms we wanted to use to in to there (unless there's an easy way of having Juju use multiple stores and
[11:13] <andyjeffries> clearly differentiate them).  Clearer?
[11:14] <andyjeffries> marcoceppi: That's great, thank you.  So this isn't a use-case that's ready to run, it's a bit of hackery...
[11:15] <marcoceppi> andyjeffries: so that use case is coming, it's just not a clean story now. I'd say in the next 2-3 months that will be much stronger, running a private to you charm store
[11:15] <marcoceppi> debochat: that's odd, maybe run apt-get update before your install command?
[11:16] <andyjeffries> marcoceppi: Thank you.  We're going to be launching our env after that point, but will need a hacky solution until then - we'll work on that ourselves then (unless the work in making it a clean story is a public repo that we can test/contribute to?)
[11:17] <debochat> marcoceppi: you mean, include the code - apt-get update before calling apt-get install in my install hook?
[11:17] <marcoceppi> andyjeffries: you'd have to pop into #juju-dev to figure out that, I don't think it's yet been worked on
[11:17] <marcoceppi> debochat: yup
[11:17] <andyjeffries> marcoceppi: OK, thanks very much for the pointers :-)
[11:17] <andyjeffries> Appreciate it!
[11:18] <debochat> marcoceppi: many thanks, will try that.
[11:42] <schkovich> how to avoid downtime during upgrade-charm? i diligently tested everything in staging environment but still upgrading all units in production at once makes me feel uncomfortable.
[11:44] <marcoceppi> schkovich: we're working on ways to model blue-green upgrades in juju, though it's not entirely possible at the moment
[11:45] <schkovich> marcoceppi: define entirely possible ;)
[11:45] <schkovich> marcoceppi: is it possible to some degree?
[11:47] <schkovich> marcoceppi: the only idea that i have at the moment is to define a new environment but that is kind of way to complicated since there is a number of charms running and i need just to upgrade one
[11:47] <marcoceppi> schkovich: you could deploy the new charm under a different name
[11:47] <marcoceppi> lets say the service is mysql
[11:47] <marcoceppi> so you already have juju deploy mysql
[11:48] <marcoceppi> if you do juju deploy mysql mysql-green
[11:48] <marcoceppi> then do all the relations, you can then just "failover" to the green one
[11:48] <marcoceppi> and destroy the previous one
[11:49] <schkovich> marcoceppi: okay, does make sense, in that case i could deploy charm to each server one by one.
[11:51] <Odd_Bloke> jose: Thanks for your review, sorry for missing all the conflicts; I'll look at it today.
[11:51] <Odd_Bloke> I would have commented there, but LP isn't letting me. ;.;
[11:54] <schkovich> marcoceppi: i have local charm store trust/x-charm, will creating symlinks x-charm-green and x-charm-red work? eg will i be able to say juju deploy x-charm-green or juju deploy x-charm-red?
[11:54] <Odd_Bloke> jose: Or, alternatively, it was waiting so you could get the same comment 5 times. ¬.¬
[11:54] <marcoceppi> schkovich: no, all you need to do is type `juju deploy local:trusty/x-charm x-charm-green`
[11:55] <marcoceppi> it'll deploy x-charm but call it x-charm-green to avoid collisions
[11:55] <schkovich> marcoceppi: awesome! i was not aware of that. is it documented?
[11:56] <schkovich> marcoceppi: it's like charm alias
[11:58] <marcoceppi> schkovich: it really should be, doesn't appear to be. I'll fix that
[11:58] <marcoceppi> `juju help deploy` covers it, very sparsley too :\
[12:04] <schkovich> marcoceppi: <service name>, if omitted, will be derived from <charm name>. this one?
[12:05] <marcoceppi> schkovich: yes
[12:09] <schkovich> marcoceppi: i read that line so many times but it never came to my mind in which way could it be useful :)
[12:09] <schkovich> marcoceppi: thanks a lot!
[12:13] <web> wow active this morning.  :)
=== kadams54-away is now known as kadams54_
[13:14] <schkovich> marcoceppi: juju deploy local:trusty/charm-x charm-x-green --to y is not working. :( i am still getting the old version of charm
[13:14] <schkovich> marcoceppi: perhaps i should include revision number as well?
[14:54] <stub> If the leader updates the leader settings, is it possible that other units will see the changes first in any hook? Or is the first place they will see the changes guaranteed to be the leader-settings-changed hook?
[14:56] <stub> fwereade: Do you know off the top of your head?
[15:08] <Odd_Bloke> aisrael: I don't really know the charm MP process; are your +1s enough for me to merge things myself?
[15:10] <tvansteenburgh> Odd_Bloke: only a member of ~charmers can do the merge
[15:42] <fwereade> stub, it's not quaranteed to wait until leader-settings-changed
[15:43] <fwereade> stub, similarly to relation settings -- you may see values from the future that render future change hooks redundant
[16:22] <jose> Odd_Bloke: can you link me to that MP that has a +1 so I can take a quick look?
[16:22] <jose> Odd_Bloke: also, LP may be weird sometimes, don't forget it works with karma :P
[16:35] <Odd_Bloke> jose: But I've been a good boy! :p
[16:35] <jose> hehe
[16:35] <Odd_Bloke> jose: You mean https://code.launchpad.net/~daniel-thewatkins/charms/trusty/ubuntu-repository-cache/update_charm-helpers/+merge/260956 ?
[16:36] <jose> oh, I'm looking into that one right now
[16:36] <Odd_Bloke> (I don't mean to brag, but I have _several_ MPs with +1s ;) )
[16:37] <jose> check your email
[16:39] <Odd_Bloke> jose: \o/
[16:43] <Odd_Bloke> jose: Thanks! :)
[16:45] <jose> Odd_Bloke: thanks to you for the fixes - greatly appreciated!
[16:45] <Odd_Bloke> :)
[16:49] <Odd_Bloke> jose: Will those changes now have to pass CI to get published?  (If there's a link to a doc about the process, I'm happy to read up on it :)
[16:50] <jose> Odd_Bloke: when you create an MP, it goes into the review queue (review.juju.solutions). the CI instances catch up and process the tests, and then we review (accept/reject) based on what we see and the CI results
[16:50] <jose> and then we merge, which is the final step if it's all good
[17:23] <stub> fwereade: Ta. It may have been a pedantic question, but it actually affects my design :)
[17:25] <arosales> any folks knowledgable on how the "charm collection" is set up in LP?
[17:26] <stub> arosales: Its modelled as a distribution, like Ubuntu or Debian.
[17:26] <arosales> specifically why I see things like https://bugs.launchpad.net/charms/+source/platform-lsf/
[17:26] <arosales> and https://bugs.launchpad.net/charms/+source/crate
[17:27] <arosales> stub these aren't recommended charms, but  I still see their URLs in LP. However, no code attached.
[17:28] <arosales> I am guessing when folks push to a personal name space it still shows up in the charm collection but doesn't attach the code branch . .  .?
[17:29] <stub> arosales: I think every sourcepackage name has a URL in that space. https://bugs.launchpad.net/charms/+source/pytz works for example
[17:30] <stub> arosales: #launchpad might know more
=== kadams54_ is now known as kadams54-away
[17:44] <arosales> stub, hmm thanks
=== kadams54-away is now known as kadams54_
=== kadams54_ is now known as kadams54-away
=== web is now known as Web
=== kadams54-away is now known as kadams54_
[18:38] <marcoceppi> arosales: stub is correct
[18:38] <marcoceppi> every source package has a place holder in charms
[18:38] <marcoceppi> but only charmers can link the source package alias to the branch
[18:38] <arosales> marcoceppi, why isn't the source code branch attached?
[18:39] <marcoceppi> because there is no source code for it
[18:39] <arosales> ah, so its an alias
[18:39] <arosales> and I can't submit a bug against it either correct
[18:39] <arosales> ie I couldn't submit a bug against https://bugs.launchpad.net/charms/+source/pytz
[18:44] <marcoceppi> arosales: you probably could tbh
[18:44] <arosales> marcoceppi, I get the following error
[18:44] <arosales> "platform-lsf" does not exist in Juju Charms Collection. Please choose a different package. If you're unsure, please select "I don't know"
[18:44] <arosales> https://bugs.launchpad.net/charms/+source/platform-lsf/+filebug
[18:44] <marcoceppi> arosales: oh, well there ya go
[18:45] <arosales> so I was just trying to figure that piece out
[18:45] <arosales> it looks like IBMers are actually getting an oops from LP when trying to do this though
[18:45] <arosales> so I was trying to reproduce that oops
[18:45]  * arosales can't reproduce the oops, but I get an error message back from LP at least
[20:52] <upper--> hi guys, is it possible to reference variables inside an amulet sentry 'run'?
[20:53] <upper--> e.g. self.unit.run('grep ', somevariable, '/etc/whatever')
[20:53] <mbruzek> upper--:  how do you mean?  You can build the run command *with* variables.
[20:53] <mbruzek> string = 'grep {0} /etc/whatever'.format(variable)
[20:53] <mbruzek> self.unit.run(string)
[20:54] <mbruzek> upper does that help?
[20:54] <upper--> yep cheers
=== weblife is now known as Web
=== kadams54_ is now known as kadams54-away