[00:04] <donu7> Hello, juju is giving me an error in the later stage of bootstrapping the environment. Is there a way to "resume" the bootstrap? I've been releasig the node from maas, deleting the environment and recreating it to try again
[00:21] <donu7> The node is up and commissioned according to maas; however, i can't ssh into it. if i reboot the node into single user, i see that the passwd file does not have any users and there appears to be no maas keys that were supposed to be set up in juju and maas
[00:23] <donu7> Also, running `juju status` or any `juju *` commands just hangs with no output — why is that?
[00:31] <donu7> actually, here's a different direction if anyone has any ideas - is there a resource on configuring network interfaces for the box that juju is trying to bootstrap?
[00:55] <cloudgur_> is the git repo for juju experiencing issues ?
[00:55] <cloudgur_> Nice pic of unicorn
[01:07] <bolthole_> mbruzek yeah looks good thanks :)
[01:07] <bolthole_> now I need to learn how to access webapp-path
[01:10] <bolthole_> https://jujucharms.com/docs/stable/authors-charm-writing is unbalanced. it shows bash using an apparent external command "relation-set", but doesnt show the corresponding other side accessing the value
[03:14] <bolthole_> mbruzek I just submitted https://code.launchpad.net/~s-phil-s/charms/trusty/tomcat-webapp/trunk
[03:14] <bolthole_> not fully tested, but figure the earlier I get feedback the better :)
[03:15] <bolthole_> oh he left. oops. well, feedback from anyone else would be appreciated too :)
[04:12] <bolthole_> there seems to be something wrong with instructions on https://jujucharms.com/docs/1.24/authors-charm-store
[04:12] <bolthole_> The instructions for (to main charm store) vs (to personal space), seem to say to push to the exact same URL
[04:13] <bolthole_> bzr push lp:~<your-lp-username>/charms/trusty/<your-charm>/trunk
[04:13] <bolthole_> vs
[04:13] <bolthole_> bzr push lp:~your-launchpad-username/charms/series/nagios/trunk
[04:13] <bolthole_> which. is. the. same. thing.
[04:37] <bolthole_> kwmonroe that tomcat code is bugged.
[04:37] <bolthole_> i updated https://bugs.launchpad.net/charms/+source/tomcat/+bug/1538715 with details
[04:37] <mup> Bug #1538715: need relation webcontainer <tomcat (Juju Charms Collection):Fix Released by mbruzek> <https://launchpad.net/bugs/1538715>
[04:37] <bolthole_> lol
[06:13] <bolthole_> kwmonroe I submitted a merge request for a fix for that syntax err  in tomcat charm
=== urulama__ is now known as urulama
=== stokachu_ is now known as stokachu
=== ionutbalutoiu_ is now known as ionutbalutoiu
[10:22] <D4RKS1D3> Hi
[10:22] <D4RKS1D3> Someone has problems downloading charms?
=== redelmann is now known as ridi|wfh
=== ridi|wfh is now known as rudi|wfh
[12:57] <marcoceppi> D4RKS1D3: I haven't, what problems are you seeing?
[14:02] <marcoceppi> cory_fu: do we have virtualenv for layers? instead of installing on the bare machine
[14:15] <cory_fu> Not yet
[14:15] <cory_fu> Shouldn't be difficult to add, though
=== xnox is now known as s390x
[15:08] <marcoceppi> stub: your leadership layer is badass! Thnks for uploading it
[15:09] <stub> Your about to get an apt layer too
[15:09] <marcoceppi> idk if I can handle all of this
[15:09] <marcoceppi> it's too much for my heart!
[15:11] <stub> All the bits of behaviour shared between the PostgreSQL and Cassandra charms in fact.
[15:27] <marcoceppi> stub: how very exciting
=== s390x is now known as xnox
=== rudi|wfh is now known as rudi|wfh|brb
[15:46] <geetha> mbruzek: Hi, I have got a comment for WebSphere Base product where its mentioned that we should add configuration options for profile options like profile name, path, and admin username and password. But once Websphere product installed and if user set new username and password through config option, there is no way to replace existing was admin username and password. So there is no benifit to the user if we provide config options for adm
=== CyberJacob is now known as zz_CyberJacob
[16:03] <mbruzek> geetha: hrmm...
[16:07] <mbruzek> geetha: It is strange that you can't change the admin user.  I will have to read the documentation for WAS on that.  The admin password can not be default, generate a password and save it to a file only root can read in the charm dir or something like that.  I still think the user will want to change the profile name, path and regular user.
[16:08] <mbruzek> geetha: The point is we can not have default username/password for network services so people can not guess or know what the password is by reading the charm.
[16:09] <mbruzek> geetha: The charm had very few configuration parameters and it will be more useful if you provide some of the things a user would change like profile or path and user/pass.  Can you change non-admin usernames and password?
[16:13] <geetha> mbruzek: Its not system admin user name and password..its specific to Websphere, once we create profile using username and password we can not change it, but we can create new profile with diffrent username and password
[16:13] <mbruzek> geetha: https://www-01.ibm.com/support/knowledgecenter/SSYJ99_8.5.0/security/was_filereg.html
[16:15] <mbruzek> geetha: If someone needs a specific profile. path and username I think that is reasonable that the old profile is removed/
[16:15] <mbruzek> If you charm could control those values form the config that would be a useful charm, but setting all those values to default is not likely going to work for many users
[16:26] <geetha> mbruzeK: As per document, "websphere_install_directory/profiles" is the default directory for profiles. so  I am using that only to create profiles. And If we try to delete old profile, before deletion we have to stop the server with old username and password. If that is the case, how can we get old user name and password?
[16:27] <mbruzek> Again if you wrote the password to a file readable only by root, the charm code could read that and use it to delete the old profile, and after you are done stopping/starting you could write the new password
[16:28] <mbruzek> This all is seems possible with charm code.  I just want this charm to be useful to people, having only the default values will not be very useful.
[16:28] <jmalcaraz> jamespage, D4RKS1D3 and jmalcaraz have been working hard these days, testings a lot your "odl" charms. We believe you would welcome this feedback. 1) Relationship  openvswitch-odl:neutron-plugin nova-compute:neutron-plugin. This relationship should be in charge of "removing any existing bridges in OVS", "population the ODL version of the ml2_conf.ini and setting the manager and controller to OVS and br-int. However, it only does the "manager in OVS". 2)
[16:28] <jmalcaraz>  There is a conceptual missing relationship between openvswitch-odl and neutron-gateway. The problem is that the  neutron gateway does not provide the interface "neutron-plugin" and thus is cannot be applied. The aim is to achieve exactly what I decided in the prevision step but now over the neutron-gateway rather than over the nova-compute. We hope you find this feedback useful and hopefully you may like to address them in order to close a prototypical
[16:28] <jmalcaraz>  integration using charms. Thanks a lot, in advance for the excellent work you are doing.
[16:29] <kwmonroe> geetha: you won't need the old user name and password.  if the user changes the configurable profile name, you would stop WAS, then run 'was_install_dir/bin/manageprofiles.sh -listProfiles' to get the profile name, then 'manageprofiles.sh -delete -profileName <profile', then create a new profile, then start the WAS with the new profile.  that should happen in config-changed.
[16:29] <jmalcaraz> jamespage, sorry, I was refering to the relationship openvswitch-odl:neutron-plugin nova-compute:neutron-plugin
[16:31] <jmalcaraz> jamespage, notice that in the own documentation of the charms the relationship between openvswitch and gateway is there. Literraly: "juju add-relation neutron-gateway openvswitch-odl", however the interfaces does not match in the metadata.yaml
[16:33] <geetha> kwmonroe: To stop WAS we need usename and password. Because we have enabled security. we have to run command to stop server ./stopServer.sh server1 -username "user" -password "password"
[16:35] <kwmonroe> oh i see geetha - you're talking about changing the admin username/password.  i was thinking about how it would work to change the profile name.
[16:35] <kwmonroe> let me think about an admin user/pass change for a minute..
[16:42] <geetha> kwmonroe: yes, if user change just profile name we can stop WAS, delete old profile and create new profile. but user change admin username/password also how can we do that? as matt said, we have to store it in a file and we can use it while stopping the server. After stopping again we have to rewrite the file with new username/password right?
[16:51] <kwmonroe> geetha: it seems like you can reset the WAS admin without knowing the old password.  run wsadmin and then perhaps an expect script to execute '$AdminTask changeFileRegistryAccountPassword -userId <newuser> -password <newpass>' (http://ibmdocs.com/2011/11/04/resetting-was-admin-password-when-the-browser-console-does-not-work-anymore/)
[16:51] <kwmonroe> once the new user/pass has been set, you should be able to stop/start WAS using the newly configured user/pass.
=== rudi|wfh|brb is now known as rudi|wfh
[17:04] <geetha> thank you Kevin & Matt...I will try this way.
[17:23] <bolthole> i posted a question late last night but got disconnected, so I'll ask again :-/
[17:24] <bolthole> The url at https://jujucharms.com/docs/stable/authors-charm-store describes "two methods" of putting up charms; one for the store, and one for personal space. however, they seem to tell me to do the same thing. what am I missing
[17:24] <bolthole> example:
[17:24] <bolthole> to publish to charm store it says,
[17:24] <bolthole> bzr push lp:~<your-lp-username>/charms/trusty/<your-charm>/trunk
[17:25] <bolthole> but to publish to personal name space, use
[17:25] <bolthole> bzr push lp:~your-launchpad-username/charms/series/nagios/trunk
[17:25] <bolthole> but... that's the same thing, seems to me.
[17:28] <marcoceppi> bolthole: yes, they are both published to the store, however one goes on to say how to get it "promulgated" or approved past the personal namespace
[17:29] <marcoceppi> bolthole: these docs (and process) are pretty confusing, we have a more streamlined process coming on next month
[17:31] <bolthole> whie I remember: docs are out of date. they claim, "Name Spaced charms will be displayed under the other category in the GUI". but thre's no such category now, that i can see. I presume they mean in the search widget for the GUI
[17:33] <bolthole> suggestion for rewrite: make the first section a single unified, "[whether you plan for your charm to be in the store, or just in your personal area, you do the same first step: ... (details)]"
[17:33] <bolthole> now a followup question...
[17:34] <bolthole> I dont see what you describe, about something getting approved past the personal namespace.
[17:34] <bolthole> i'm presuimg that getting in the store, is NOT the same thing as a "charmer team recommended charm"
[17:48] <bloodearnest> is there a way for a tool that is installed on a juju machine to query the units running on it?
[17:49] <bloodearnest> (this is for logging purposes)
[17:51] <lazypower|travel> bloodearnest i'm not sure i follow
[17:51] <lazypower|travel> what are you wanting to do?
[18:03] <kwmonroe> bolthole: the Recommended Charms section of the doc you linked (authors-charm-store) is the process for going past personal namespace and making it "charmer recommended", which is indeed the same thing as "getting it in the store".
[18:03] <bolthole> okay thanks
[18:04] <kwmonroe> bolthole: i like your rewrite suggestion -- i know marcoceppi already mentioned the docs were in transition, but that's an important one to clear up.  thanks!
[18:04] <bolthole> i previously pushed my own charm, to "lp:~s-phil-s/blahblahblah".  This time, I tried just "bzr push". It said it was pushing to (...)//bazaar.launchpad.net/(...). Is there some difference between bazaar.lp, and.. the other stuff? more confusion :(
[18:05] <marcoceppi> bolthole: that's just a limitation of bzr. "lp:" is basically bazzar.lp.net/...
[18:06] <marcoceppi> bolthole: next month you'll be able to use whatever code hosting you'd like and publishing to the charm store is decopued from launchpad
[18:07] <bolthole> cool. okay, soo... i finally have a charm that is "charm proof" clean. and I pushed it. that means in around an hour, I will finally be able to use    juju deploy lp:~s-phil-s/Mystuff ?  previously, i pushed it, but didnt have unique icon, so i guess it didnt allow that.
[18:09] <bloodearnest> lazypower|travel, I want to look in some file or similar to know what unit(s) are deployed on this machine. Would like to differentiate between primary and subordinate units
[18:10] <bolthole> (side comment.. it's... "interesting".. that I can view the same code tree, through both bazaar.lp.net and code.lp.net)
[18:10] <kwmonroe> yeah bolthole, if proof passes, it should ingest into the store in about an hour.  note that your invocation will be "juju deploy cs:~s-phil-s/trusty/Mystuff" though.  the 'cs' syntax tells juju that you want a trusty charm from the charmstore (cs), in ~s-phil-s's namespace.
[18:11] <kwmonroe> you could skip waiting for ingestion with "juju deploy local:trusty/Mystuff", but i think you already knew that.
[18:11] <kwmonroe> cs:blah is the right way to pull from the store
[18:15] <bolthole> kmonroe: kewl. done and done. also, officially submitted topcat-webapp to charms. now, I just need someone to aprove my bugfix merge request for the mainline tomcat charm so it actually *works* ;-)
[18:16] <bolthole> doh... kwmonroe
[18:19] <bolthole> btw i'm going to try to change my lp id from s-phil-s to match my github name, bolthole
[18:19] <kwmonroe> bloodearnest: you could do something like this on the machine: sudo find /var/lib/juju/agents/unit-* -name metadata.yaml -exec echo {} \; -exec grep subordinate {} \;
[18:20] <bloodearnest> kwmonroe, right. I was wondering if there was a better way than sniffing files
[18:20] <kwmonroe> bloodearnest: even better (in caes you don't want to see pathnames..
[18:20] <kwmonroe> sudo find /var/lib/juju/agents/unit-* -name metadata.yaml -exec grep name {} \; -exec grep subordinate {} \;
[18:21] <kwmonroe> ah, i see bloodearnest.  i'm not sure of a utility on the juju deployed machine that can tell you that info (other than looking in /var/lib/juju/x)
[18:21] <kwmonroe> bloodearnest: on the juju client machine, you can run 'juju status' and perhaps grep/awk your way to the data you'd like
[18:21] <bloodearnest> kwmonroe, yeah, I was wondering if I could query a juju agent or something
[18:22] <bloodearnest> kwmonroe, I want to discover it automatically on the unit itself
[18:23] <bloodearnest> fwiw, the use case is that I want to add a juju-unit tag to all log statements my app generates (and subsequently forwards to logstash)
[18:23] <bloodearnest> as the complete disconnect between hostname and juju-unit name is real PITA when debugging distributed failures
[18:26] <bloodearnest> I think I'll just have to get the each charm to set it explicitly in an env var, but I was hoping to avoid having to do that
[18:37] <marcoceppi> bloodearnest: there's no way to really tell about other units if you're not related to them
[18:37] <marcoceppi> querying /var/lib/juju directly will only end in pain
[18:38] <bloodearnest> marcoceppi, I only really want to know which unit I am
[18:38] <marcoceppi> bloodearnest: what do you mean
[18:38] <marcoceppi> the subordinates unit number?
[18:38] <marcoceppi> or the primary attached to?
[18:39] <bloodearnest> marcoceppi, the primary, in most cases
[18:39] <bloodearnest> which unit installed/configured me
[18:39] <marcoceppi> bloodearnest: oh, that's easy. Create a relation for juju-info interface
[18:39] <marcoceppi> then during that relation you can do `JUJU_REMOTE_UNIT` which will give you the service/unit name you're related to
[18:40] <bloodearnest> I can't create a relation - I'm on a unit
[18:40] <bloodearnest> I don't have juju client/creds
[18:41] <bloodearnest> some context: I already include the hostname automatically, which I don't need to explicitly configure
[18:41] <bolthole> Hm.. is there some equivalent of "juju query cs:blah" to match "juju deploy cs:blah", where you dont want to deploy, you just want to verify or find out info on a charm in the store?
[18:41] <bolthole> the juju help stuff doesnt see to mention anything
[18:42] <bloodearnest> bolthole, charm search?
[18:42] <bloodearnest> charm-tools pkg
[18:44] <bolthole> juju charm search works nice for my immediate needs. thanks. Although seems like it would be nice to have a "pull more details" varient of that.
[18:49] <marcoceppi> bloodearnest: I don't understand.
[18:49] <marcoceppi> you have to create a realtion to get a subordinate on to a machine
=== marcoceppi is now known as marcoceppi|airpl
[18:57] <marcoceppi|airpl> nick marcoc|airplane
=== marcoceppi|airpl is now known as marcoc|airplane
[19:14] <bolthole> having problems deploying from personal space.
[19:15] <bolthole> juju charm search tomcat, lists, among other things, lp:~bolthole/charms/trusty/tomcat/trunk
[19:15] <bolthole> but when I try to do,   juju deploy lp:~bolthole/charms/trusty/tomcat/trunk   it says invalid charm name?
[19:16] <bolthole> doesnt work if I use cs:~bolthole/charms/trusty/tomcat/trunk either
[19:18] <bolthole> bzr branch lp:~bolthole/charms/trusty/tomcat/trunk works fine though
[19:26] <marcoc|airplane> bolthole: cs:~bolthole/trusty/tomcat is the url, that charm search is woefully out of date in how it performs lookups
[19:26] <marcoc|airplane> bolthole: https://jujucharms.com/u/bolthole/
[19:27] <marcoc|airplane> bolthole: it can take a few hours before showing up, once it does, you'll see it there
[19:27] <marcoc|airplane> bolthole: next month we'll have instant publishing! which doesn't help you now...
[19:27] <bolthole> oh. so reguardless of what "juju charm search" says.. it isnt REALLY available, until it shows up  in that special url?
[19:29] <bolthole> thats kind of odd though, becuae I branched and pushed the thing hours and hours ago.
[19:30] <marcoc|airplane> bolthole: yeah, charm search search launchpad, which is instant, but it takes a few hours to go from launchpad to charm store
[19:30] <bolthole> Is there a magic incantation I can use to deploy direct from launchpad?
[19:31] <marcoc|airplane> bolthole: not really, as you can see this is one of the many reasons we're moving to the much more concise and quick publish tool next month
[19:32] <bolthole> mkaaay.... sooo.. how many hours should it take? :-/
[19:42] <kwmonroe> bolthole: juju deploy cs:~bolthole/trusty/tomcat should work for you
[19:42] <marcoc|airplane> bolthole: 1-6 :\
[19:42] <kwmonroe> it's listed in the store at the url marcoc|airplane referenced
[19:42] <marcoc|airplane> bolthole: oh look! it just showed up
[19:42]  * marcoc|airplane wipes brow
[19:44] <kwmonroe> cory_fu: if i have a @hook('start')\n def myfunc(), can i call myfunc from outside the start hook?
[19:44] <cory_fu> Absolutely
[19:44]  * kwmonroe wipes brow
[20:02] <adam_g> machine-0: 2016/01/28 11:47:23 http: TLS handshake error from 192.168.122.115:53369: remote error: bad certificate
[20:02] <adam_g> machine-0: 2016-01-28 19:47:23 ERROR juju.provisioner provisioner_task.go:655 cannot start instance for machine "2": kvm container creation failed: exit status 1
[20:02] <adam_g> any debug tips for this?
[20:02] <adam_g> my local env magically broke overnight
[20:08] <aisrael> cory_fu: lazypower|travel: The devel docs link to https://github.com/juju-solutions/layer-basic (from https://jujucharms.com/docs/devel/developer-layers) but that repo doesn't exist
[20:14] <cory_fu> Does anyone have an objection to renaming the repo from reactive-base-layer to layer-basic?  That's more in line with the convention we've been using.
[20:20] <cory_fu> Looks like github does the reasonable thing with repo renames, and I'll update interfaces.juju.solutions, so it won't affect anyone.  I'm gonna do it.
[20:28] <aisrael> thanks, cory_fu!
[21:07] <bolthole> marcoc|airplane ha ha, strategic lunch break for the win! :)
[21:41] <bolthole> i'm writing a subordinate charm. it requires a value to be set by relation-set by the master. But itseems (according to juju debug-log) that its install and config hooks are being called AFTER the primary's relation-joined hooks. What am i supposed to do about that?
=== natefinch is now known as natefinch-afk
[22:50] <adam_g>   "1":
[22:50] <adam_g>     agent-state: error
[22:50] <adam_g>     agent-state-info: 'kvm container creation failed: exit status 1'
[22:50] <adam_g>     instance-id: pending
[22:50] <adam_g>     series: trusty
[22:50] <adam_g> where do i debug this? local provider /w kvm
[23:07] <bolthole> my connection with juju debug-log keeps breaking if I leave it up. with errors like
[23:07] <bolthole> ERROR: juu.apiserver debuglog.go:102 .... write tcp ... connection timed out
[23:08] <bolthole> last time I did a restart of the whole local juju service (juju-agent-$USER-local.service). Is there a shorter way to recover the log capabilities?
[23:19] <bolthole> okay... anyone awake still? :)   I just did another round of tests for my subordinate class andf
[23:20] <bolthole> primary class... and it would seem that the primary "relation-joined" hook comes after even the SUBORDINATE relation-joined.
[23:20] <bolthole> Bug, or feature?
[23:43] <blahdeblah> bolthole: I'm not an expert in this, but I'm pretty sure there is no guarantee on which order hooks will execute in, especially across units.
[23:46] <bolthole> generally spekaing i can understand that. but inthe specific case of a subordinate container, I wuld think having deterministic behaviour is pretty crucial