=== CyberJacob is now known as zz_CyberJacob === redir is now known as redir_afk [03:48] Hi, how to deploy a service to lxc auto select the machine or add a new machine with lxc? [07:31] jamespage, morning, we need to define an interface for the peer relation for the openstack api charms. Each Openstack API charm uniquely names the interface atm (eg keystone-ha, nova-ha, neutron-api-ha etc). I propose that we create an openstack-ha interface and have new charms use that. Sound ok? [08:33] gnuoy, well so long as the interface uses the same data semantics, I think its ok to use a single type [08:33] gnuoy, so we might endup with charms that have two peer relations - one general, one specific [08:33] but leader storage should avoid most of that [08:33] gnuoy, can you take a peek at https://review.openstack.org/#/c/317910/ [08:33] its the peer to one that's already landed in ceph-mon [08:34] gnuoy, I also have a few stragglers for a general charm helpers resync across master and stable charms yesterday [08:34] I'll fix those up this morning [09:26] gnuoy, hey - could you nudge https://review.openstack.org/#/c/318220/ [09:27] beisner and I agreed not todo full rechecks for the syncs... [09:28] jamespage, done... [09:28] ta [10:38] gnuoy, governance review ressurected and companion email sent to openstack-dev! [10:38] here we come .... [10:38] that was worth an extra dot [10:43] gnuoy: https://review.openstack.org/#/c/318231/ and https://review.openstack.org/#/c/318221/ are good to go [10:43] beisner, I had to create some offical charm branches on launchpad to get the stable amulet tests to pass... [11:07] jamespage, oh yah, i suspect for the newbies, mon, lxd, et al? [11:08] jamespage, this --> https://review.openstack.org/#/q/topic:switch-to-bundletester should allow us to use the version of amulet that contains the git branch fix. [11:08] ie. be able to resurrect that change review you took a stab at a while back [11:24] welcome back, gnuoy :) [11:25] jamespage, ceph-osd + odl-controller stable sync passed, ready to land? [12:10] beisner, yes [12:11] gnuoy got 'em [12:12] I did! [12:12] Hey lazyPower [12:12] Quick questio [12:12] where does the kibana charm live? [12:13] its source? [12:14] gnuoy, beisner: https://review.openstack.org/#/c/317910/ [12:15] done [12:15] jamespage, curious - are ceph-mon or -osd affected similarly? [12:16] asked, with my 'keep the cephs in alignment' hat on [12:19] beisner, erm for which? [12:19] beisner, oh -mon already fixed; ceph is the sync [12:19] then I'll stable branch cherry pick them both [12:20] beisner, no - -osd was effected - not -mon [12:20] that's the other one... [12:21] well look, there it is :-) [12:25] beisner, gnuoy: https://review.openstack.org/#/c/317313/ [12:25] that should sort out the deployment race for the landscape team [12:54] kjackal - i based my branch off of the upstream charmer repo - https://code.launchpad.net/~charmers/charms/trusty/kibana/trunk [12:54] lazyPower, I have a fix for the Kibana test that is failing [12:55] should I submit the fix upstream? Is it well maintained? [12:55] is it maintained by us? [12:55] never checked [12:57] hey lazyPower [12:57] are you on the latest beta? [12:58] i am [12:58] do you have any issues with it getting stuck on creating units with "pending"? [12:59] not with the clouds, i haven't been using LXD [12:59] so ymmv [12:59] i'm on lxd, no probs [12:59] huh. [12:59] kjackal well... yeah :) [13:00] but i wouldn't say its well maintained. its a long lived charm. As i'm sure you can tell poking around in there its long in the tooth [13:00] prior to this last round of updates, i think icey upgraded it to kibana4, so its got a few hands looking after it [13:17] tvansteenburgh: do you leave your deployments running for a long period of time? [13:17] seems for me it only acts up when I leave it running overnight [13:18] don't answer! its a trap! [13:18] jcastro: yeah, overnight quite a bit [13:21] kjackal - with these pr's are you still seeing the failure wrt the relations? [13:22] Nope! Everything is GREEN :) [13:22] Solid, thanks for the contributions [13:22] I'm not real excited about the sleeps... but i see why its a pain. I had intermittent failures during test runs myself because of that [13:22] we kind of need a more deterministic way to sniff that out [13:35] anyone know where actions went in 2.0? [13:35] list-actions and juju actions are missing now [13:36] http://paste.ubuntu.com/16506582/ [13:36] i call schenanigans [13:36] bugg@tomsdevbox:~$ juju list-actions joshua-decoder [13:36] No actions defined for joshua-decoder [13:36] does something for me [13:37] http://paste.ubuntu.com/16506594/ [13:37] what's happening to me [13:37] indeed jorge! thats a very prudent question [13:38] well are you gonna specify a service name?? [13:38] i am on beta4 so they may have gone away [13:38] ah yeah lol [13:38] Ok, lazyPower! The patch for the failing Kibana test is here: https://bugs.launchpad.net/charms/+source/kibana/+bug/1576706 [13:38] Bug #1576706: Tests are failure prone [13:38] oh, lol [13:38] kjackal on it [13:38] jcastro - i love how it told you what was wrong xD [13:39] never underestimate the power of reading [13:39] in my defense I was following instructions for a charm written for 1.25 [13:40] $ juju action do spark/0 smoke-test [13:40] ERROR unrecognized command: juju action [13:40] defense rejected [13:40] run-action [13:40] * jcastro nods [13:41] ooo tim swingin the gavel of readme/2.0-translation justice [13:41] Juju Judge Judy [13:41] and to get the results of an action? [13:41] it's not in the devel docs [13:41] show-action-output [13:42] show-action-status for just the status [13:42] man, I am really missing tab completion now [13:43] mine still works [13:44] I am failing at computers today it seems [13:46] cory_fu: hey so I got bigdata-dev/apache-processing-spark running, the readme says it's a standalone cluster, but the status for spark says it's waiting for a relation to hadoop plugin [13:48] tvansteenburgh: how long should CI test results stay around? I'm seeing runs less than 2 weeks old go 404 on me: https://code.launchpad.net/~timkuhlman/charms/trusty/rsyslog-forwarder-ha/nrpe/+merge/292987 [13:48] aisrael: not unusual, it only keeps the latest 300 iirc. the new revq caches the results forever [13:49] kjackal: Is that status message a known issue with that bundle? ^ [13:49] tvansteenburgh: ack. I will make an offering of redbull and daycare to the revq gods in that case. [13:54] aisrael: those gods prefer beer and pipe tobacco i think [14:01] kwmonroe: I fixed the charm references in the bigtop repo's tests, built and published the charms, and updated the bundle in the bigtop repo & store. So, both the PR and store are updated. [14:01] Hi All, I am developing IBM-Http Server on top of IBM-IM layer, Can we have separate license for HTTP server are do we need to use only one license that we are getting from ibm-base layer....? [14:05] Actually we are facing one issue when we use common license i.e when we use this state in reactive of HTTP server @when ('ibm-http-server.installed') @when_not ('ibm-base.license.accepted') and the below states in reactive of ibm-im @when ('ibm-im.installed') @when_not ('ibm-base.license.accepted') [14:05] it is picking randomly ibm-im state first and then ibm-http which should not happen bec IBM-Installation Manager will not be uninstalled till the products installed through IM are uninstalled. [14:06] Could you please suggest on the same.... [14:10] Shruthima: if the conditions for multiple handlers are true, you can't know which will run first [14:11] ya that is the issue ,can we use seperate license for http server ? [14:13] Shruthima: i'm not sure that is the right solution [14:14] jcastro, I am looking at the bundle issue [14:14] tvansteenburgh: ok thanks [14:14] how urgent is it? [14:15] kjackal: average I guess? I am blogging about it [14:15] but don't expect to publish it until closer to juju 2.0 [14:15] jcastro, thanks [14:43] Anyone know how to recover juju state server when it thinks it is upgrading after a reboot? [14:45] Would upgrading the tools to a later version and starting the jujud service solve it, or is there somewhere in mongo that needs to be tweaked? [14:55] Hi kwmonroe/mbruzek , I have sent an email regarding the issue with common license.. could you please suggest on the same....!! [15:01] hi Shruthima, the thought with a single config variable for the license in the ibm-base layer is that setting this to "True" would indicate that the user accepts whatever terms and conditions the charm requires -- whether it's one license or multiple licenses. [15:02] Shruthima: so yes, the http server can have a separate license. in the http server README, you would simply say "ibm http server requires the acceptance of license X, Y, and Z. if you agree, indicate your acceptance of these terms by entering "juju set license_accepted=True"' [15:03] Shruthima: i'll follow up to your email and we can decide if more thought is necessary to handle multiple licenses in your layered charms. [15:04] kwmonroe: oh ok thanks :) [15:04] np [15:08] dweaver ah thats a tricky one. I've only seen fixes to "unstick" an upgrade [15:08] not when it thinks its upgrading erroniously [15:24] lazyPower, OK, that's not good news. It thinks it should be upgrading and this was only after a reboot of the state server, not an upgrade request. I am prepared to modify the mongo database or fiddle with the versions installed myself. However, if this is not recoverable at all, then this is going to be a show stopper. And this is likely to be published as this is a case study [15:25] dweaver - dont abandon hope yet, we can likely get a core dev to lend a hand. I'm not even sure where to begin debugging other than starting with a bug and collecting the controller logs. [15:25] dweaver - which version of juju is this? 1.25.5 i assume? [15:25] lazyPower, OK, I'll raise a proper bug with lots of log information, it's actually 1.25.0, which means I can force an upgrade manually, if I need to. [15:32] can i get a hot review on this? I need to land it so i can rebase on top of it and prep/trim/rebase the tls branch on top of it. https://github.com/juju-solutions/layer-etcd/pull/13 [15:32] mbruzek ^ [15:40] So, I am new to working with juju, it looks like the cs branch of ~openstack-charmers-next/xenial/percona-cluster is out of date with the current branch. So mysql deployments are failing due to this bug https://bugs.launchpad.net/charms/+source/percona-cluster/+bug/1571789, I was curious a.) if this is something that should be reported somewhere, and b.) is there a way to force change over juju to use the up [15:40] Bug #1571789: install hook failing on Xenial with unmet dependency on mysql-client

[15:40] dated branch in the meantime? [15:42] xilet, fyi https://jujucharms.com/u/openstack-charmers/percona-cluster/xenial (cs:~openstack-charmers/xenial/percona-cluster-0) does contain the fix [15:42] fyi, the -next charms are dev/possibly-bloody versions [15:44] Good to know, stupid question, any idea why ubuntu 16.04 LTS ships with those as the defaults? [15:47] beisner: xilet, there is the latest openstack package in xenial-proposed that fixes this [15:47] as for the next question it was because those stable charms were released after xenial GA [15:47] stokachu, excellent. thanks for the clarification. so, a change is in flight to stabilize it in xenial main. [15:48] beisner: yea soon as someone marks verification-done on the sru [15:49] beisner: xilet, https://bugs.launchpad.net/ubuntu/+source/openstack/+bug/1576412 [15:49] Bug #1576412: package does not use released charms [15:50] stokachu: thanks! [15:51] though i was just made aware of some issues with ceph-osd which I think are being worked out now [15:51] but that wont require an update to openstack package [15:51] dweaver - just a follow up - many of our team members are at a planning sprint and thus responses have been latent. I'm trying to track someone down to lend a hand [15:52] it may take some time however, if you're willing to be patient and hand off the bug once its filed i'll be happy to run it up the pole [15:52] @kevin/matt: Hi! [15:53] hello [15:53] we need a clarification for state names that are set by interface. For ex: Websphere is connecting to DB2 and metadat.yaml file in Websphere charm has 'requires' definition and relation name as 'db' so in reactive script we are using state name as 'db.available'. But you suggested to use state name as 'ibm-was-base.db.available', if we give relation name as 'ibm-wa-base.db' in metadata.yaml, it's giving me error. [15:54] Should "juju upgrade-charm --force-units mysql --switch=cs:~openstack-charmers/xenial/percona-cluster-0" pull the correct version of mysql? I am still getting the error though juju status is showing the new repo. (Not sure if I have the correct syntax) [15:58] geetha: In this case "db" is the relation name, that has nothing to do with state names. [15:58] If I use same relation name i.e, 'db' in both(WAS and DB2) metadata.yaml file, it's not giving me any conflicts and state names set by interface is 'db.available' in both charms(without layer name prefix) is that ok? [15:58] geetha: kwmonroe and I recommended using the layer prefix (dot) state name. [15:59] lazyPower, yes, willing to be patient, thanks. I'll ping you with a bug ID once it is submitted with all the info. Will be most appreciative thanks. [15:59] geetha: I think we have a disconnect here. We were not recommending renaming the relation name. [15:59] and I don't think relation names can have dots in there. [16:00] dot/period etc [16:00] geetha: can you give me a code example? Perhaps I don't understand your question [16:01] An interface name is a string that must only contain characters a-z and -, and neither start nor end with -. It's the single determiner of compatibility between charms; and it carries with it nothing more than a mutual promise that the provider and requirer somehow know the communication protocol implied by the name. [16:01] pastebin or something [16:01] mbruzek - thats what i found here [16:01] mbruzek and typically they are decorated with @hook('{relation_name}-joined') [16:02] that hook decorator string is run through some helpful templating functions in reactive to expand that relation_name to expand to whatever you have defined in metadata [16:02] so in this example, it should probably be declared in metadata like so [16:03] requires: db2-database: ibm-db2 [16:03] where db2-database would be the relationship name [16:03] so the state would become @when('db2-database.available') [16:03] geetha ^ does that help? [16:04] and i totally biffed on that @hook decorator code... its not *that* simple, there's a bit more to it, and it declares the interface inline like so: @hook('{provides:db2}-relation-joined') --- sorry for the typo. i was going from memory :) [16:04] then it will be 'db2-database.available'. there is no prefix right? [16:05] geetha - right, its all predicated by what you name it in the metadata [16:05] it will take what ever relation name we give in metadata.yaml file. [16:05] the prefix is a convention we use in the layers, when setting states so we can avoid collision with other layers. Similar care should be taken when defining relationship names [16:08] geetha - here's a super simple interface class that illustrates the code i was typing out above https://github.com/juju-solutions/interface-consul/blob/master/provides.py#L11. Notice the use of that same template marco teh '{relation_name}' - that expands and controls the states you will subscribe to in your layer. [16:12] hi guys [16:14] dimitern, jamespage - "install error: private-address not set" artifact and traceback on bug 1583109 [16:14] Bug #1583109: error: private-address/public-address not set (1.25.5)

[16:14] Then we can give 'ibm-was-base-database' as a relation name in Websphere side right? [16:14] i can't bootstrap juju for openstack environment [16:14] beisner, \o/ [16:15] we have deployed openstack and would like to use juju to deploy software to it [16:15] then it will be @when 'ibm-was-base-database.available' [16:15] beisner: you mean you got repro + trace logging? \o/ indeed! [16:15] dimitern, yessir [16:15] but now i have got error ERROR juju.cmd supercommand.go:429 cannot set initial environ constraints: index file has no data for cloud {regionOne http://10.9.8.21:5000/v2.0/} not found [16:16] beisner: awesome! tyvm, will have a look shortly [16:16] it happens when it setups tools on machine 0 [16:16] i run it with: juju bootstrap -v --upload-tools --metadata-source /home/juju/.juju --debug --show-log [16:16] gennadiy is this juju 1.25? [16:16] machine-0.log is 11+MB and I'd like to turn trace off now if that gives you what you're after dimitern [16:17] beisner: can you point me to the log? [16:17] (too many logs there..) [16:18] yes, it's 1.25 [16:18] do i need to reinstall? [16:19] i'm not certain, i've never seen that error before [16:19] beisner: ah, got it - 0-var-log.tar.bz2 [16:19] our openstack has own regionname - regionOne [16:19] bingo dimitern [16:19] so we need to use custom --metadata-source [16:19] gennadiy https://bugs.launchpad.net/juju-core/+bug/1567763 [16:19] Bug #1567763: bootstrapping private openstack, with --metadata-source fails when instance-type constraint is specified

[16:20] i can't bootstrap env [16:21] right i get that, it seems like theres some streams you'll have to setup because of it but i'm not positive [16:21] but that bug looks applicable [16:21] but i don't use "--constraints" [16:22] beisner: great, the log has everything I need (and suspected as the cause) - feel free to reset the logging-config to lower level [16:22] dimitern, ack tyvm [16:23] i used this tutorial - https://blog.felipe-alfaro.com/2014/04/29/bootstraping-juju-on-top-of-an-openstack-private-cloud/ [16:23] i added image to openstack and generated metadata [16:30] bdx: ping [16:32] lazyPower, The bug is submitted here: https://bugs.launchpad.net/juju-core/+bug/1583683 log files are uploaded to the bug. [16:32] Bug #1583683: juju thinks it is upgrading after a reboot [16:52] dweaver - thanks for the bug. I'll send this over to the appropriate parties. You should get updates via email as the bug gets triaged/worked. That'll be our focal point for resolution/updates. === redir_afk is now known as redir [17:04] Hrmm cs:~openstack-charmers/xenial/percona-cluster-0 has the same mysql-client issue [17:18] why remote bootstrapped machine does't use provided image-metadata-url? [17:18] seems it tryiesto use https://streams.canonical.com/juju/images/releases/streams/v1/index2.json [17:18] hi xilet - i just did a juju bootstrap ... then juju deploy cs:~openstack-charmers/xenial/percona-cluster-0 to check/confirm sanity of that charm and it looks good from that: http://pastebin.ubuntu.com/16510376/ are you sure that charm is what is deployed? [17:19] i see in the log - " skipping index "http://cloud-images.ubuntu.com/releases/streams/v1/index.sjson" because of missing information: index file has no data for cloud {regionOne http://10.9.8.21:5000/v2.0/} not found" but i have provided own url - http://192.168.177.51:8888/ [17:26] beisner checking, [18:20] hows it going everyone? Have vlan tenant networks on a lxd openstack been verified as something that should work? Has anyone got their feet wet in this area yet, or is it just me? === zz_CyberJacob is now known as CyberJacob [19:52] lazyPower: you'll know the answer to this [19:52] if I use a layer like https://github.com/juju-solutions/layer-hadoop-client [19:53] do I need to define the provides/requires stuff in metadata.yaml ? [19:53] or does layers just sort that stuff out [19:53] it sorts it out as the metadata.yaml is already there [19:54] and it declares the interfaces in its layer.yaml [19:54] so it should be a single line include [19:54] ta [19:57] ooh yeah so it does [19:57] funky stuff [20:05] Hi All, if I have kvm machines listed in “virsh list” but not listed in “juju status” for kvm environment, Can I add such machines in juju kvm environment? [20:06] p.s. such machines can exist in some scenarios: deployed using libvirt api directly, was exist before juju installation and so on. === redir is now known as redir_lunch [20:58] Hi, I am using juju to deploy ceph using the command juju deploy cs:trusty/ceph -n 3 --config=ceph.yaml with just fsid and mon-secret in the yaml file. But when I try to do the same with cs:xenial/ceph it fails with this trace http://paste.ubuntu.com/16513817/. Am I doing something wrong here? [21:18] hi. does it juju support images-metadata-url from openstack env config? [21:18] i provided it but juju use standard ubuntu cloud url === redir_lunch is now known as redir [21:28] if we provide --metadata-source for bootstrap command it creates zero machine in openstack but throws error during software installetion(agent setup) [21:45] jcastro: sup [22:13] also how to use "juju metadata generate-image" in juju2? it requires model but model doesn't exist because controller is not bootstrapped