=== redir is now known as redir_eod === redir_eod is now known as redir_afk === natefinch-afk is now known as natefinch === thumper is now known as thumper-afk === cos1 is now known as c0s [07:30] Hi [07:58] hello. marcoceppi marked my bug as "Fix Released" but my charm is still not recommended in the charmstore: https://bugs.launchpad.net/charms/+bug/1538573 [07:58] Bug #1538573: New collectd subordinate charm [07:58] I would like to have a node with mesos, hadoop, spark to run my charm; I'm using cs:~tads2015dataart/trusty/mesos-master-0 as "scope: container"; but how can I add trusty/apache-spark-7 on the same node ? [07:58] is there anything I need to do? If not when shoudl I expect my charm to be in the charmstore? [08:22] Morning, Someone knows if its possible to re-bootstrap one enviorement? I am trying to install services with juju in maas, and all the time I need to create all === thumper-afk is now known as thumper [10:15] jamespage, anytime for https://review.openstack.org/#/c/301637/ ? [10:15] gnuoy, my n-ovs review for enabling DPDK is good for initial review; I need to figure out one other thing which is how to get libvirt to switch to using the root user for qemu processes - but that will require a n-compute change as well [10:15] gnuoy, sure [10:16] gnuoy, swap you for https://review.openstack.org/#/c/301761 [10:16] done [10:16] well, deal is what I mean [10:17] gnuoy, :-) [10:17] gnuoy, also have https://review.openstack.org/#/c/302236/ up as well [10:17] and https://review.openstack.org/#/c/300384/ [10:20] gnuoy, did you figure out whether the switch to apache+wsgi works OK with https? [10:20] jamespage, Yes I did, not it didn't, it does now [10:20] is the existing support re-used i.e. haproxy -> apache SSL -> apache-wsgi [10:20] yes [10:21] jamespage, see how I cunningly stole the keystone.conf context which has the port shuffle logic [10:21] gnuoy, right - so we kinda double hop through apache now? [10:21] jamespage, yes we do [10:21] gnuoy, that's fine - just wanted to check... [10:22] jamespage, I think the seperation makes sense tbh. It allows the charm to still talk to the local keystone on localhost without ssl [10:22] gnuoy, agreed [10:23] gnuoy, +2 on that review - lgtm [10:23] landing now [10:24] ta [10:32] gnuoy, going to focus on the network-spaces -> ceph bits now and will come back to sorting out the last bit of dpdk/libvirt/ovs madness after that [10:32] jamespage, ok, enjoy [10:36] jamespage, can I just clarify that your saying that once a device has been given to dpdk you can still see the device via lspci etc but there is no way of accessing the MAC ? [10:36] gnuoy, it is still in lspci and there might be a way of discovering it still via /sys [10:37] but I did not dig that deep [10:42] Has someone just broken the mysql-server package on Xenial? As of this morning, deployment of the mysql charm on Xenial is failing for me, whereas yesterday it was fine. [10:44] Hi All [10:44] I have a query related to getting values in Interface. [10:46] I am trying to get the contents of a file from the consumer charm . In the interace (requires side) can I get this value ? [10:47] In require side, I am trying something like this : subprocess.check_output("sudo cat /root/.ssh/id_rsa.pub") [10:47] I am getting the error that the file doesn;t exist , where as actually the file exists. [11:10] neiljerram, just had one of our automated tests fail using the mysql charm on xenial. Looking into it now [11:16] neiljerram, might be that 5.7 landed... [11:16] rbasak, ?? ^^ [11:16] gnuoy: possibly bug 1566406 [11:16] Bug #1566406: postinst fails on mysql_upgrade if database is already upgraded

[11:18] gnuoy, hmm - are you aware of any test isolation problems in any of the charms? [11:19] gnuoy, I was expecting mock state to be rest between indivivdual tests, but I'm not seeing that in ceph-mon [11:19] reset rather [11:27] gnuoy, jamespage, thanks - certainly 5.7 is the version now being installed. [11:33] gnuoy, jamespage It is still possible to install version 5.6.28-1ubuntu3 of mysql-server, and that appears to go through... [11:34] (although a manual step of 'rm -f /var/lib/mysql/debian-*.flag' is needed) [11:45] I'm seeing http://paste.ubuntu.com/15667815/ [11:46] proper context http://paste.ubuntu.com/15667822/ [11:47] I'm getting below error when deploying juju-gui [11:47] root@maas61:~/.local/share/juju# root@maas61:~/.local/share/juju# watch juju status Every 2.0s: juju status Thu Apr 7 16:42:06 201 [Services] NAME STATUS EXPOSED CHARM juju-gui unknown true cs:trusty/juju-gui-52 [Units] ID WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE [11:49] [Machines] ID STATE DNS INS-ID SERIES AZ 0 error pending trusty [11:51] http://paste.ubuntu.com/15667891/ [11:52] jamespage, yes, I had test isloation problems with the action unit_tests specifically but I don't think the issue is limited to them [11:53] i have deployed juju-gui and also expose it..but when i type watch juju status i get this outputn: http://paste.ubuntu.com/15667891/ [11:53] anyone pls help [11:54] freak__: see help in #juju-gui === urulama|eod is now known as urulama [11:56] rick_h thanks [12:07] gnuoy: a fix for the known mysql-5.7 packaging bug is on its way. Please let me know if you're still broken after that lands. [12:08] neiljerram: ^^ [12:08] We'll be deleting mysql-5.6 soon. [12:09] rbasak, thanks! But I suggest not deleting mysql-5.6 until you're really sure that 5.7 is good! [12:09] neiljerram: we don't really have a choice now. Going back would be more effort than fixing whatever's broken in 5.7. [12:11] jacekn: looks like ingestion is broken [12:11] rbasak, I don't understand. I just managed to work around the current 5.7 breakage by installing version 5.6.28-1ubuntu3 of mysql-server. There is no 'more effort' needed - you just need to leave 5.6 there. [12:15] neiljerram: the archive is in a pretty inconsistent state. [12:15] neiljerram: we can't release like this. [12:16] neiljerram: for example we couldn't do a security update for 5.6 right now without breaking 5.7. [12:16] (and we wouldn't want double the maintenance effort to support both for five years in any case) [12:17] rbasak, will do, thanks [12:18] rbasak, OK, but all I said was "I suggest not deleting mysql-5.6 until you're really sure that 5.7 is good!" That could just mean for the next couple of days - it doesn't have to mean beyond the Xenial releas. [12:18] If we wanted to go back to 5.6, we'd need to upload a new 5.6 from the 5.6 source and have it build anyway. [12:19] So deleting it or not deleting it doesn't actually make any difference. [12:19] Are you saying that you've deleted 5.6 already? [12:20] No, but we will. [12:20] I appreciate your sentiment, but in practice it makes no difference from an archive management perspective. [12:20] We can't delete 5.6 until all the reverse dependencies are switched to 5.7. [12:20] I'm working on that actively now. [12:21] I'm sorry, I have no clue what you're actually saying. Sounds like nonsense to me. [12:21] 5.6 and 5.7 are not independent. They are intertwined. Between each other and with their reverse dependencies. [12:22] Right now, I can install 5.6 to work around 5.7 breakage. If you delete 5.6, I won't be able to do it, and I won't have a working 5.7 either. To my mind, that definitely does "make a difference". [12:22] I have uploaded a fixed 5.7. [12:22] If it does not work, please tell me so that I can fix it. [12:28] rbasak, Cool, I will try that. Probably will be an hour or so, because of my Juju deployment cycle time. [12:30] neiljerram: make sure you pick up the fix for bug 1566406 please - 5.7.11-0ubuntu5, which isn't built and published yet. [12:30] Bug #1566406: postinst fails on mysql_upgrade if database is already upgraded

[12:30] neiljerram: I don't know that this is your issue either. I only know that we were getting reports and this was a bug. You might have another. [12:40] rbasak, I looked at the bug, but can't tell where to get the fixed package from. [12:41] neiljerram: when the bug is marked Fix Released, wait half an hour and it should be available from archive.ubuntu.com. [12:41] Just check the version you end up with (it'll be announced in the bug) to be sure you have the fix. [12:42] rbasak, BTW it appears that my latest deployment using 5.6 instead doesn't fully work - which I guess is the point that you were making above. [12:42] rbasak, Thanks, will do. [12:48] gnuoy, I think I'm going a little mad [12:48] I have no idea why I'm suddenly hitting this isolation problem [12:49] jamespage, are you adding a new unit_test file ? [12:49] gnuoy, yes [12:49] jamespage, does its name feature alphabetically before the others? [12:50] gnuoy, kinda in the middle [12:50] jamespage, well, I'd try renaming in temporarily test_zzz and go from there [12:50] s/in/it/ [12:51] gnuoy, nope - its completely due to when two tests get scheduled on the same testr process [12:52] gnuoy, its like the cleanup is not getting run between individual tests... [12:52] afaict [12:52] jamespage, engage the tinwood would be my advice [12:54] jamespage, can you run them both individually? (e.g. tox -e py27 -- -n unit_tests.xxxx) [12:56] tinwood, no [12:56] oh [13:02] tinwood, its really weird - the mocks are different for each test case... [13:02] but something odd is going on [13:02] which charm is it? === matthelmke is now known as matthelmke-afk [13:08] tinwood, ceph-mon [13:08] tinwood, https://review.openstack.org/#/c/302681/ [13:10] * tinwood is having a look ... [13:12] jamespage, do you mind if I pull it down and have a look at it? [13:12] tinwood, please do [13:12] I'm baffled [13:12] what should have taken me 2 hrs todo across three charms is completely blocking me now... [13:12] okay, will do. === terje is now known as Guest72484 [13:16] tinwood, sorry I'm being a dimwit [13:16] please stop looking at my complete stooopidity... [13:16] have you tracked down the problem. [13:16] @cached - wish I'd never written that decorator... [13:16] ah. [13:17] yes, that would do it. [13:19] tricky to mock as it happens at loadtime. [13:20] tinwood, yah - I fixed this before [13:20] tinwood, reseting the cache in tearDown works OK [13:20] ah, good idea. Like it. [13:31] gnuoy, https://review.openstack.org/#/q/status:open+branch:master+topic:network-spaces they should all be good now [13:31] to much copy/paste in the ceph charms atm - cholcombe, icey - it would be nice to try address that next cycle... [13:32] jamespage: I'd love to take a whack at layering up the charms, the ceph-mon and ceph inherit from a ceph-base, and then we could maintain the ceph charm as a POS charm because it would just depend on ceph-mon and ceph-osd [13:32] icey, +1 sounds neat... [13:33] icey, https://review.openstack.org/#/q/status:open+branch:master+topic:network-spaces might be of interest to you as well [13:33] I'm about to want a review to add the storage hooks (in the ceph charm) to the ceph-osd charm as well :) [13:43] tinwood, pxc pause/resume lgtm - ok for me to push that through to landing? [13:43] jamespage, pxc == percona? [13:44] tinwood, yes [13:44] yes, it should be. [13:45] jamespage, I also need to talk to you about ceph and pause/resume. I'm still unsure about use case now I've dug into it more [13:57] gnuoy, arghhhhhh [13:57] gnuoy, how many amulet tests check for 'keystone' as a running service now... [13:58] jamespage, ? amulet was passing for me with the move to mod_wsgi or am I missing your point? [13:58] gnuoy, well yes in keystone [13:58] oh [13:58] yeah [13:58] but how many other charms deploy keystone as part of their amulet tests... [13:58] ceph-mon [13:58] \o/ [13:59] jamespage, I don't think other charms should test that tbh [14:01] gnuoy, yeah - I think our amulet test approach needs a rethink/refactor... [14:02] beisner and I where chatting about that a while back [14:09] gnuoy, ok reviews raised for ceph* for that change... === matthelmke-afk is now known as matthelmke === cos1 is now known as c0s [14:43] mbruzek - when you get a sec i need a hotfix review on https://github.com/juju-solutions/layer-docker/pull/34 [14:45] gnuoy, I had a run through the apparmor reviews; I don't think they are ready to go in yet... [14:46] jamespage, ok, I'll take a look at your review comments === spammy is now known as Guest10665 [14:58] cory_fu nvm on the ping, [14:58] gnuoy, https://review.openstack.org/#/q/status:open+branch:master+topic:network-spaces are testing OK [14:59] lazyPower: What ping? [14:59] from 10:17 [15:00] sa'll good man, you missed it :) [15:00] jamespage, not sure canonical ci agrees with you [15:00] gnuoy, oh not those ones [15:01] gnuoy, https://review.openstack.org/#/q/status:open+branch:master+topic:keystone-apache [15:01] kk [15:01] lazyPower: Odd, I didn't get a ping from you at that time. [15:01] Hope I'm not missing other messages [15:02] jamespage, are you suggesting an amulet full would be overkill ? I tend to agree is thats what your proposing [15:02] gnuoy, +` [15:02] 1 rather [15:02] kk [15:11] What's the status of payloads in juju 2? I'm running beta3 and `juju list-payloads` throws "ERROR unknown object type "payloads" (not implemented)" [15:11] marcoceppi: lazyPower ^^ [15:11] :O [15:12] cherylj - did payloads get dropped? [15:15] `juju help payloads` is dead, too. :( [15:15] lazyPower, no [15:15] that is a bug [15:15] can you please open a bug [15:15] you betchya alexisb [15:15] alexisb: will do! [15:15] we can get eyes on it [15:19] cory_fu: how do oyu guys handle the upgrade charm hook in reactive / layers [15:25] gnuoy, I suspect that our mysql woes are charm related [15:26] jamespage, well, a fresh install on xenial without the charm did not result in an error [15:26] rbasak, ^ [15:26] gnuoy, yah - confirmed [15:26] jamespage, but I can't see what the charm is doing to mess up the install [15:26] It wouldn't surprise me if some behaviour changed in 5.7 causing this though. [15:26] Eg. authentication. [15:26] gnuoy, I think it pushed a config file onto disk prior to install [15:26] We're using socket auth by default now, so a few bits have changed, especially if automatic. [15:27] rbasak, did 5.7 just go in? [15:27] bug 1567098 for example. [15:27] jamespage, yes [15:27] Bug #1567098: Cannot log in as root user when not root Unix user

[15:27] jamespage: yes [15:29] icey: Basically the same as other hooks, really. The charm dependencies (wheelhouse) is upgraded automatically, and you can have a @hook('upgrade-charm') decorated block if you need to do anything special during upgrade. [15:30] I think upgrade-charm is probably the one remaining case where it really makes more sense to use @hook [15:42] gnuoy, rbasak: I think its something todo with the fact that the charm writes password files into /var/lib/mysql [15:42] jamespage, gnuoy - yah i'm still +1 for yanking irrelevant checks from amulet tests (focus on the charm and its services only). [15:43] jamespage, gnuoy - we also need to a spike on xenial test enablement. [15:44] gnuoy, looks like the charm writes a conf file, then apt installs with confold. maybe we're breaking there? [15:45] beisner, that sounds likely [15:46] Do you need to tell apt to tell dpkg to use your conffile and not overwrite? There's an option for that AIUI. [15:46] rbasak, Sorry for not asking this earlier - but how long would you expect until that mysql-server bug shows Fix Released ? [15:46] neiljerram: by now I'd have thought. I see an issue. Looking. [15:46] rbasak, Thanks... [15:48] jamespage, gnuoy (ftr consider that a standing +1 to prune such tests as drive-bys with your other changes) [15:48] ta :) [15:59] is it possible to have action executed when we remove a service , as an uninstall script ? === terje is now known as Guest79665 [17:04] hey suchvenu - you were asking about getting a remote unit name from an interface? [17:05] i'm assuming you want to do this from the "requires" side of the interface.. if the scope of that interface is scopes.UNIT, then you can have a method that simply returns self.conversaion().scope [17:05] (scope will be the name of the unit) [17:05] Yes [17:06] i want to get the require side unit name [17:06] and my scope is global === redir_afk is now known as redir [17:07] (one sec, gotta meet the schoolbus) [17:07] ok, np [17:13] sorry abou that suchvenu, i'm back [17:13] ok.. so you have an interface, and in the requires.py, you want to return the remote unit name? [17:13] (bcsaller may have some tips here ^) [17:14] in provides.py i want remote unit name [17:17] ok, so you're providing a service, and the provider needs to know the remotely connected unit name? i'm guessing this is to do something like create a db2 instance name based on whatever requires the db2 relation? [17:17] kwmonroe - there's an environment variable for $JUJU_REMOTE_UNIT during a relationship hook sequence [17:18] yes, right... kwmonroe [17:18] https://jujucharms.com/docs/devel/reference-environment-variables#juju_remote_unit [17:18] doc link if its helpful ^ [17:18] oh hey! there's an idea.. that may be an easy thing to do do suchvenu ^ [17:19] the env variable $JUJU_REMOTE_UNIT will work in the interface a? [17:19] I have used it in the reactive layer.. [17:19] But this i want in the interface [17:19] suchvenu - that environment variable is set during the relationship context, so it's important ot remember that you should only depend on that during the @hook('relation-name-joined') joined/changed/departed/broken [17:20] if you attempt to reference that environment variable during say, config-changed, its not going to be there [17:20] suchvenu: in a more complicated example -- say, for example, you needed to know *all* the remote units connected to your interface, you could create an "endpoints" method simliar to how the monitor interface does it: https://github.com/juju-solutions/interface-monitor/blob/master/provides.py [17:23] suchvenu: i think lazyPower's suggestion is that you not worry about the remote unit name in the interface, and use it in the reactive layer during a @when '-relation-changed' state is present. [17:24] ugh, sorry, i meant provides.. so like in the db2 reactive layer, @when 'db2-relation-changed' [17:24] echo $JUJU_REMOTE_UNIT, or whatever you need to do with that [17:24] The issue i am facing is, I need to get the remote-unit name to create DB and users based on the unit name. If i miss to set accept_license to true and add-relation between db2 and consumer, I get the remote unit name in the reactive layer. But since accept_license was not set the install will not happen [17:25] Then I set the accept_license flag and after this, when it comes to relation hooks I am not getting the $JUJU_REMOTE_UNIT name [17:26] Before install, when the add-relation was called, it actually goes to the relation hooks and gives the $JUJU_REMOTE_UNIT name [17:26] But not after install. So I thot of getting this value from Interface [17:26] ah yeah, so that gets back to what lazyPower was saying.. when add-relation was called, you were in a "db2-relation-[joined|changed]" hook, which is a relation hook, which is why $JUJU_REMOTE_UNIT was available [17:27] right [17:27] first time i get it [17:27] when you set accept_license, you were in a "config-chagned" hook, which has no remote relation information available [17:27] so you would need to adjust your states to handle the case when both license is accepted && relation is available [17:27] But doesn't it go to relation hook again after config-changed ? [17:28] like "@when 'license.accepted' 'db2-relation.joined'" [17:28] then echo $JUJU_REMOTE_UNIT [17:28] the 2nd clause in that @when decorator will ensure it happens in a relation context, so remote unit info should be available [17:29] no, relation hooks may not fire after a config-changed hook, and even if a conifg and relation hook are both set to fire, you have no guarantee which one will happen first [17:29] hmm [17:29] that's the nice part about reactive charming.. you can create a combination of states so that it does not matter which happens first [17:30] simply define a method that requires both states -- in this case, license.accepted and db2.ready (or whatever the db2 state is called) -- and you can do both config and relation-related things in there. [17:30] ok.. [17:31] let me try this way and see [17:31] does that help? if not, please point me to a repo so i can take a look (it doesn't have to be working code :), or paste the reactive code that isn't working to http://paste.ubuntu.com/ [17:32] Thanks Kwmonroe and lazypower [17:32] I will try and let you know [17:32] Sure thanks [17:34] mthaddon, https://jujucharms.com/docs/devel/tools-charm-tools [17:35] kwmonroe, suchvenu, lazyPower: Sorry I'm late to the party, but I'd highly recommend against using $JUJU_REMOTE_UNIT, because it will *only* be valid within a @hook('*-relation-*') handler and almost certainly not in any @when handler. Instead, you can always get the list of unit names from a conversation with conv.units [17:35] ah thats right [17:36] cory_fu - as usual, to the rescue ;) [17:36] oh dear -- sorry suchvenu! don't do that [17:36] kwmonroe: I'm also now recommending *against* ever using conv.scope directly. That was a bad pattern that I started and now regret. [17:36] cory_fu - we need some of that knowledge in the docs, if i bug that can I point you at it? [17:36] heh [17:36] lazyPower: Yes, please do. conv.units isn't even in the docs anywhere and definitely needs ot be [17:37] lazyPower: I've also been thinking about scrapping the Conversation pattern entirely (or at least hiding it) because it seems to cause more confusion than it saves [17:37] aisrael, can you loop back around to this today? https://bugs.launchpad.net/charms/+bug/1562944 [17:37] Bug #1562944: Please review and add auditd charm as a recommended charm [17:38] And there is at least one bug now that's damned hard to fix with people relying on conv.scope [17:39] jcastro_: Yep, I'll hit it again tonight. The AWS test finally ran and passed. \m/ [17:39] I'd love to have an example of a relation where the leader sets a password that all units set on their relation, cause then I might understand how I can use conversations ;) [17:39] does the review queue bot not post immediately to lp when the test passes? [17:39] or is it like a nightly thing or something? [17:39] all I see on the bug are the failed tests [17:40] jcastro_: Not sure. I'm going by this: http://review.juju.solutions/review/2620 [17:40] mthaddon, ^^ [17:40] aisrael, thanks! [17:40] stub: You've pretty much convinced me that not only are conversations and scopes harder to understand, but they lead to an incorrect mental model of how relations work under the hood. [17:40] jcastro_: no worries. I'm on the case === Guest10665 is now known as spammy [17:41] jcastro_: thx, will pass on to Tim [17:42] cory_fu: I was hoping I'd missed some important fact that was stopping me grokking it :-( [17:43] cory_fu: how would you get the current remote unit name from a globally scoped provides.py? [17:43] cory_fu, kwmonroe -> So are ou suggesting me to use conv.units ? [17:44] cory_fu: conv.units gets me all remote (requiring) units, right? i just want 1 in particular. [17:44] stub: The intention originally was to model the progression of states that one unit assigns to another as a conversation, but the asymmetry of how relations actually work in Juju, and the variation in the use-cases led to it ending up being less useful than we'd originally hoped [17:46] kwmonroe: When you're dealing with states (@when), there *is* no "current" remote unit. You could be in a config-changed hook, if that happened to be the last thing that changed to satisfy all of your @when conditions. All you know is that the state you referenced applies to a set of one or more remote units [17:46] suchvenu: Yes, I am recommending that you use conv.units which will be a list of unit names. [17:50] But I want only one unit for which I am creating the DB name and user [17:52] suchvenu: If you have two services connect to the database, they should both get a database, right? So, if the timing works out that you are handling two at once, it means you need to loop over them and create a database for each. [17:53] But if I have already created for one ? [17:53] suchvenu: Unless you only want to create one database per service and the connected service has multiple units? [17:56] In that case, you'll need to convert the unit names to a (shorter) list of service names and create one per service. [17:59] how about this cory_fu suchvenu... in the db2 charm, @when 'db2.ready', loop through all units from conv.units, test if user/db/whatever already exists, and if not, create what you need based the data in the current loop iteration. [18:00] +1 [18:00] I got this warning : charm URL should include a revision [18:00] because i think you're right in that all units connected to db2 will need a user/db/whatever, so just always loop through all of them and create the missing pieces [18:00] yes that will work [18:00] is it in metadata.yaml ? [18:00] A-Kaser: Where did you get that warning? [18:01] juju bundle proof [18:01] Hrm. I think that's an out-of-date warning [18:01] Oh, bundle proof! [18:02] A-Kaser: That means that bundles should include specific revisions for charms. I.e., "charm: cs:trusty/mysql-5" instead of "charm: cs:trusty/mysql" [18:02] it's my owns charms [18:02] A-Kaser: That's to ensure that bundles are a set of specific charm revs that are known to work together [18:03] and there are only local, I'm lookig to how publish it [18:03] A-Kaser: Really, that only applies to bundles that you want promulgated. They will work w/o revs, but for promulgated bundles we basically require them to be rev locked [18:03] ok [18:04] so I can add -1 at the end of "charm:" line [18:04] A-Kaser: But you can put a bundle in your own namespace, that refers to charms in your own namespace, w/o rev locking them [18:04] and I suppose I will be able to create this revision [18:04] ok ok, I need to check how to publish it [18:04] Cory_fu , do you have any example where I can look at conv.units ? [18:04] launchpad use only bzr ? [18:05] A-Kaser: Whenever the charm is published to the store (either by having it be automatically ingested from Launchpad, or using the new `charm push` / `charm publish`, it will create the rev [18:05] suchvenu: Not off the top of my head, and I have to step away for a few minutes. I will find one and get back to you shortly, if kwmonroe doesn't find you one first [18:05] bbiab [18:06] sure [18:15] kwmonroe: cory_fu : a quick question about ArchiveUrlFetchHandler. If I am using in the form of [18:15] fetcher.install(my_url, my_dest, checksum="deadbeef", hash_type="md5) [18:15] where the checksum and hash type would be coming from ? Assuming my_url is defined in the config.yaml, shall the other two be defined there as well? [18:15] sorry for the silly question [18:17] oh I see - I guess I just can add the checksum to the url itself. [18:17] cory_fu, kwmonroe, admcleod-, who is where do we set the "namenode.joined" ? [18:23] suchvenu: i don't know of a conv.units example either, but i think in your provides.py, you'd just define a method that does "return self.conversation().units" and then call that method from your db2 layer when license.accepted and db2.ready. [18:24] cory_fu, kwmonroe, admcleod-, interface:dfs [18:24] yup c0s, you can either have the sum and hashtype as separate config vars (and only call install when all pieces are configured), or stick those onto the url as url?md5=deadbeef [18:25] k, thanks! [19:24] jamespage, gnuoy, thedac: way past eod for a few of you but rockstar needs this fix if any of you happen to be free to review. https://review.openstack.org/#/c/302427/ [19:47] coreycb, do we have full passing on that ^? [19:48] beisner, no, I'm waiting for a +2 and full recheck [19:48] beisner, or can the full passing come first? [19:48] coreycb, yah let's get charm-recheck-full passing [19:48] beisner, ok [19:48] fyi thedac is on hols today/tomorrow [19:48] beisner, ok thx [20:28] neiljerram: mysql-5.7 5.7.11-0ubuntu5 has landed in the release pocket now. If you're using the mysql charm though, I think gnuoy's working on that since it broke something there? [20:36] are charms building to the charmstore? [20:40] magicaltrout: wadda you mean by 'building to the charmstore'? [20:41] push charm to LP -> deploy charm to CS [20:42] just trying to unbreak my saiku charm so I pushed an update 50odd minutes ago but I don't see an update in the CS [20:44] magicaltrout: i believe the LP ingestion process is still a thing, but have seen it take an hour(ish). however, iiuc, if the charm has ever been published with the new "charm push && charm publish" commands, then the LP ingester doesn't look at that anymore. [20:45] magicaltrout: did you push an update to LP for this one? https://jujucharms.com/u/f-tom-n/saikuanalytics/trusty/3 [20:46] https://jujucharms.com/u/spicule/saikuanalytics-enterprise/trusty/ [20:46] its its up over an hour, i'll return to twiddling my thumbs, i thought it was ~40mins [20:49] magicaltrout: ingestion is broken at best [20:49] magicaltrout: use new charm workflow [20:50] magicaltrout: and help vet our documentation :) [20:50] that involes me doing things [20:50] link me up [20:51] magicaltrout: https://github.com/juju/docs/pull/975 [20:51] magicaltrout: https://github.com/marcoceppi/docs/blob/17b54ba8f49d464a0b26b11fab7087705166c6bf/src/en/authors-charm-store.md [20:52] magicaltrout: doc is very much WIP, but feedback on that pull request would be great [20:52] magicaltrout: hope to hvae it finished up by EOW [20:52] k i'll give it a spin [20:52] thanks [20:52] magicaltrout: the nice thing about the new workflow is that you push and it's immediate.. no waiting on an ingestion process to pull [20:54] dang marcoceppi, really nice job on the wip! that ascii art and pointer description are really helpful. [20:56] * thumper chuckles at the name of magicaltrout [20:56] cracks me up [20:56] morning folks [21:01] er right them marcoceppi problem #1 [21:02] where do I get a charm exec thats up to date enough to run charm login? [21:02] magicaltrout: ppa:juju/devel and ppa:juju/stable - you need both [21:02] er [21:02] right [21:04] oh I've got a charm in some anaconda dir stomping on my path [21:05] dont' even know what/how that got there [21:12] alrighty then marcoceppi [21:12] says its published to stable [21:12] whats the lag time on the UI? [21:14] because you said its immediate and either its not or I've ballsed up [21:16] kwmonroe: magicaltrout looks like ingestion run and your saikuanalytics imported: https://api.jujucharms.com/charmstore/v5/changes/published?start=2016-04-07 [21:16] that does indeed jrwren [21:16] oh arse [21:17]