[05:12] <rock> h
[05:58] <rock> Hi all. We pushed our charm to charm public store using Ubuntu SSO account. Charm will be present in store as cs:~hareeshk/kaminario-cinder-10 .  Here "hareeshk" is the account username. we removed this user account. And using same mailID we created another user account. and pushed charm to public store again. cs:~kaminario2/kaminario-cinder-0.   But in store previous pushed charm also there. We forgot to revoke the permissions of that c
[05:59] <rock> How do we remove that charm from store. We tried to create same user account. But It was showing "hareeshk" username already in use. But we deleted that user account.
[05:59] <rock> "hareeshk" will be stored some where in server Cache.
[06:22] <rick_h___> rock: file a bug in https://github.com/canonicalltd/jujucharms.com and will mention it to the folks that manage the charmstore
[06:52] <rock> rick_h__: Thank you.
[09:12] <SimonKLB> how do i install the charm-terms commands? they don't seem to be in by default in charm-tools 2.1.5
[10:35] <pascalmazon> Hi, I've recently reinstalled charm tools (2.1.5-0ubuntu1~ubuntu14.04.1~ppa2) on a trusty. However when I try to call `charm proof`, it complains that pip isn't the correct version: "pkg_resources.DistributionNotFound: The 'pip>=7.1.2' distribution was not found and is required by charm-tools". Any ideas?
[10:36] <SimonKLB> pascalmazon: https://github.com/juju/charm-tools/issues/274
[10:37] <pascalmazon> SimonKLB: oh thanks, I should have checked there…
[12:34] <anrah> Hi all! I was about to ask what the prefer-ipv6 option should do and is it still available on juju 2.0?
[12:35] <anrah> At least when that is set to a model nodes private-address still is ipv4
[12:44] <BlackDex> Hello there. I want to know if it is somehow possible to have multiple hacluster's on one node?
[12:44] <BlackDex> Currently it seems that it doesn, because haproxy isn't getting configured
[15:20] <kiko> morning
[17:07] <lazyPower> bdx - should i resched the elastic stack planning session?
[17:18] <bdx> lazyPower: shit
[17:18] <bdx> I'm so sorry
[17:18] <lazyPower> bdx no worries, we'll reschedule and reconvene
[17:18] <lazyPower> bdx and family friendly language *shakes a finger*
[17:18] <bdx> was stuck in a  bit of traffic ... just getting in now
[17:18] <marcoceppi> this is...the internet ;)
[17:18] <bdx> my b
[17:18] <lazyPower> i think the meeting time is a bit early for your TZ
[17:19] <lazyPower> i was trying to overlap with le magicaltrout's EU TZ as well
[17:19] <bdx> usually I'm online by 8
[17:19] <bdx> so 9 is ok
[17:19] <lazyPower> ok, would you want to try to do this again later this week?
[17:20] <bdx> definitely
[17:21] <lazyPower> ok, i'll send something out later today :)
[17:22] <lazyPower> marcoceppi - FYI, we're blocked atm on completing that PR for the test infra. they moved some files and i'm tracking down their result munging scripts
[17:22] <bdx> perfect
[17:58] <vmorris> lazyPower: https://goo.gl/images/kkpQ8j
[17:58] <lazyPower> that ^
[18:28] <x58> charm proof is complaining I don't have any "provides", so I set a provides... and now it's complaining that I don't provide hooks for that...
[18:28] <x58> Is there a way to have charm proof not complain, yet not really "provide" anything, and thus not need hooks for it.
[18:29] <x58> My charm only sets information in the OS, it doesn't provide any services or anything that anyone can relate with.
[18:41] <x58> What is the best way to use the juju-info interface? charm proof complains about using juju-info as the requires name, yet that is what the docs tell me to use...
[19:00] <bdx> concerning juju resources, is the jujuresources pkg the recommended path to managing resources?
[19:00] <bdx> I'm looking at this documentation here -> http://pythonhosted.org/jujuresources/index.html
[19:00] <bdx> wondering if its current
[19:01] <jrwren> bdx: that is not current for juju 2.0
[19:01] <bdx> jrwren: thx, do you know of current api docs for 2.0 resources?
[19:01] <jrwren> bdx: https://jujucharms.com/docs/stable/developer-resources
[19:02] <bdx> jrwren: no python api tho?
[19:02] <jrwren> bdx: there is a wrapper around resource-get in charmhelpers.
[19:02] <bdx> other than what is offered throught hookenv?
[19:02] <jrwren> bdx: I don't know.
[19:03] <bdx> gotcha, ok ... just wanted to make sure I wasn't missing something here
[19:03] <bdx> jrwren: thx
[19:05] <bdx> cory_fu: really nice job on the jujuresources pkg and docs
[19:05] <bdx> cory_fu:  would you mind updating them to indicate juju 1.x only pls
[19:07] <bdx> concerning resources, does the 'upgrade-charm' hook run when `charm attach` is ran?
[19:08] <jrwren> bdx: no.
[19:08] <jrwren> bdx: you can run that yourself, or write an action which uses the resource and run that action.
[19:10] <bdx> jrwren: I'm thinking abount a ci use case, where say jenkins might run `charm attach` following successful build of the resource
[19:11] <bdx> jrwren: what you are saying is this might be best implemented having jenkins run `charm attach`, following that an action that gets and unpacks the resource
[19:11] <jrwren> bdx: that is fine. it can just as easily run juju upgrade-charm or juju action run BLAH as a next step.
[19:15] <bdx> jrwren: ah, so a better workflow might be; `charm attach` to get the new resource in the charm store, then `juju attach` to get the resource onto the controller, then `juju action run` to get the charm to grab the new resource
[19:15] <marcoceppi> bdx jrwren yes it is
[19:15] <marcoceppi> bdx jrwren when you attach resources, upgrade-charm is run
[19:16] <marcoceppi> bdx: it's either charm attach, then juju upgrade-charm, or juju attach
[19:16] <jrwren> oh no!
[19:16] <jrwren> sorry bdx
[19:16] <marcoceppi> then upgrade-charm runs for both.
[19:16] <bdx> marcoceppi: oh nice, so I can just react to the upgrade-charm hook instead of a custom action following the attaching oof a new resource
[19:16] <jrwren> bdx: for a CI scenario you describe, I'd skip the charmstore entirely.
[19:16] <x58> I am trying to use juju-info interface as a requires to allow my charm to be a sub-ordinate, however as soon as I add the updated charm to the relation and run juju add-relation <other charm> <my charm> it says no relations found.
[19:17] <marcoceppi> bdx: yeah, lazyPower has done this a lot
[19:17] <marcoceppi> oh, and he left
[19:18] <bdx> jrwren: but when new deploys happen, I want the charm to deploy with the latest resource
[19:18] <marcoceppi> bdx: it will
[19:18] <marcoceppi> bdx:  whatever is in the charm store, will get deployed
[19:18] <marcoceppi> you don't need to attach post deployment
[19:18] <bdx> jrwren: hence why I feel keeping the charm store resource up to date is important too
[19:18] <jrwren> bdx: ok, its up to you.
[19:19] <bdx> jrwren: if the charm store step is skipped, then deploying a new instance of the charm would require the user having the rescource
[19:20] <marcoceppi> bdx: right, bdx I think you're on the right train of thought
[19:20] <bdx> jrwren: what I'm thinking, is if its just fully left up to jenkins, then the resource is always current, and the dev/user deploying doesn't have to know or care about it
[19:21] <x58> marcoceppi: I have: https://gitlab.com/bertjwregeer/juju_staticroutes/blob/master/metadata.yaml#L16 yet when I call juju add-relation ceph-osd:juju-info staticroutes:host-system it fails to work... documentation says to use "juju-info" as the requires name, but I can't push to the charmstore when I use that...
[19:21] <x58> (juju says "no relations found")
[19:22] <bdx> jrwren, marcoceppi: is there any juju<->jenkins plugins work currently being done, or pre-existing that you know about?
[19:22] <x58> This documentation is outdated: https://jujucharms.com/docs/2.0/authors-implicit-relations (can't require juju-info...)
[19:22] <marcoceppi> bdx: I'd check the mailing list, I'd just ask - I know  a few teams have done some simple stuff, but it's mostly just scripts
[19:23] <bdx> marcoceppi, jrwren: also, upgrade-charm shouldn't be ran on `charm attach`, because we are only interfaceing to the charm store at that point right?
[19:23] <marcoceppi> x58: I'm about to go offline, but if you don't get an answer in an hour I'll be back to take a look
[19:23] <marcoceppi> bdx: it's not, but the operator i stold there's an upgrade available
[19:24] <marcoceppi> bdx: charm attach -> juju upgrade-charm -> upgrade-charm hook run, new resource is available
[19:24] <x58> marcoceppi: Ok...
[19:24] <marcoceppi> x58: I think that should be provides....
[19:25] <x58> Nope, all charms implicitly PROVIDE juju-info.
[19:25] <marcoceppi> x58: is this a subordinate?
[19:25] <x58> Yes.
[19:25] <marcoceppi> okay, I'll be back soon
[19:25] <x58> It is not explicitly listed as a sub-ordinate though... because it may also be deployed stand-alone.
[19:28] <x58> marcoceppi: https://api.jujucharms.com/charmstore/v5/ntp-16/archive/metadata.yaml like this. requires juju-info.
[19:28] <thumper> x58: hey there, I think this week at the planning sprint we are discussing model level subordinates
[19:29] <thumper> charms that should be on all machines
[19:29] <thumper> which match the need for things like ntp and other base machine tweaks
[19:30] <bdx> marcoceppi: just to be clear, isn't `juju upgrade-charm` overkill if all i need is the new resource?
[19:30] <bdx> which I could get with `charm attach`
[19:30] <bdx> bleh
[19:30] <bdx> `juju attach`
[19:31] <aisrael> thumper: That would be a great feature.
[19:31] <bdx> thumper: +1
[19:31] <thumper> there is clearly a need for it
[19:32] <x58> thumper: That doesn't help me resolve the issue right now..
[19:33] <x58> thumper: I can't upload a charm that uses juju-info as the relationname under requires (like the ntp charm)
[19:33] <x58> and when I name it something else, add-relation fails with "no relation found"
[19:33] <thumper> x58: sure
[19:33] <x58> Also... the docs on the site are out of date... which as always is fantastic.
[19:34] <x58> What am I missing?
[19:34] <thumper> x58: I don't believe that the system supports a charm that is both a subordinate, and not a subordinate
[19:34] <thumper> I'm not sure why it is complaining about juju-info
[19:35] <thumper> I'm wondering if it is considered only available for subordinates
[19:35] <thumper> ?
[19:35] <thumper> perhaps?
[19:35] <x58> charm push .
[19:35] <x58> ERROR charm "staticroutes" using a reserved relation name: "juju-info"
[19:35] <thumper> if you mark the charm as a subordinate, does it work?
[19:35] <x58> Now, if I change it to be subordinate... I will break existing users that are not using it as a subordinate when they upgrade...
[19:36] <thumper> ah...
[19:36] <thumper> poo
[19:36] <thumper> perhaps you need two charms?
[19:36] <x58> Yeah... no.
[19:36] <x58> I really don't want to maintain two charms.
[19:37] <thumper> x58: what is the intent of the juju-info relation?
[19:37] <x58> To be able to add a relationship so that it is subordinate when related to an existing charm.
[19:38] <x58> Without breaking existing users by removing the ability to just deploy staticroutes --to <host.
[19:38] <thumper> I get a strong feeling that this is not a supported use case
[19:39] <thumper> I don't think you are missing anything, I think that this use case just was never thought about
[19:39] <thumper> or it was, and explicitly not supported
[19:39] <thumper> but I don't know which
[19:39] <x58> That'd be nice to have documented on https://jujucharms.com/docs/2.0/authors-implicit-relations
[19:39] <kiko> x58, out of curiosity, what are you charming?
[19:39] <x58> as well as the fact that you can't name the relation "juju-info" like it shows in that example.
[19:40] <x58> kiko: adding staticroutes becaue MaaS doesn't provide a feature for us to add routes on a specific interface.
[19:40] <x58> We have 3 racks of Ceph nodes.
[19:40] <x58> THe backend cluster network is on a /64, I need to add a static route to a /52 on the interface for that backend cluster network
[19:41] <x58> so that backend cluster traffic goes over the right interface, instead of over the default route (which is the frontend cluster interface where clients communicate)
[19:41] <kiko> x58, we are doing that work this cycle, fwiw -- why don't we work together to do that in MAAS instead?
[19:41] <x58> kiko: https://gitlab.com/bertjwregeer/juju_staticroutes/
[19:41] <bdx> x58: not sure if this is the best way, but what I use to do was just edit the maas dhcp conf
[19:41] <x58> kiko: Because I am already using it in production.
[19:41] <kiko> x58, I see, it's complete already
[19:41] <kiko> well
[19:41] <bdx> x58: or dhcp template that maas uses
[19:41] <x58> Oh yeah... I am just trying to make it a sub-ordinate.
[19:41] <kiko> if it makes you feel any better, we're adding the functionality now
[19:42] <kiko> because we're aware of that limitation
[19:42] <x58> bdx: No DHCP used for the IPv6 network...
[19:42] <bdx> oooh IPv6 .... nm
[19:42] <x58> bdx: As in the MaaS server doesn't even have an interface on that network.
[19:42] <kiko> bdx, how would dhcp help with static routes, though?
[19:42] <x58> You can push more routes with DHCP
[19:42] <bdx> yeah
[19:42] <kiko> interesting
[19:42] <bdx> I still have an openstack with that hack
[19:43] <bdx> lol
[19:43] <kiko> the more general case of not-DHCP is the killer there of course
[19:43] <kiko> anyway
[19:43] <x58> I really wish two things: 1. Juniper would support RFC4191 and 2. Linux would accept /52 routes from router advertisements.
[19:43] <bdx> totally
[19:43] <thumper> x58: how are you declaring the relation?
[19:43] <x58> thumper: juju add-relation ceph:juju-info staticroutes:system-host
[19:44] <thumper> x58: no, in the charm's metadata.yaml
[19:44] <x58> kiko: Basically on a subnet defined on a Fabric we would need the ability to specify extra routes that are added to the networking config when the host is brought up.
[19:45] <kiko> x58, yeah, ivoks has been asking for that since forever, and it's now on the plan for 2.3
[19:46] <x58> kiko: Also, please please please test that everything works with IPv6...
[19:47] <tychicus> I'm trying to get juju gui up and running, but it hang at "Connecting to the juju model"
[19:48] <tychicus> looks like a websocket issue Uncaught DOMException: Failed to construct 'WebSocket': The URL '<no value>' is invalid.
[19:48] <tychicus> are there any docs that I can consult to help me resolve this issue?
[19:50] <tychicus> following instructions from here https://jujucharms.com/docs/2.0/tut-google#use-juju%27s-gui
[20:04] <tvansteenburgh> tychicus: you could try `juju upgrade-gui` in case it's a bug that's been fixed
[20:06] <tychicus> Juju GUI at version 2.2.2
[20:08] <tychicus> if it helps it's the version that was automatically loaded when I ran juju bootstrap
[20:09] <tvansteenburgh> tychicus: yeah looks like that's the latest
[20:10] <tychicus> any other things I can do to troubleshoot?
[20:10] <tvansteenburgh> tychicus: hatch may be able to help you
[20:10]  * hatch waves
[20:10] <tychicus> hi hatch
[20:11] <tychicus> hatch: what information do you need from me?
[20:11] <hatch> hey tychicus I hear you have an issue in the GUI?
[20:11] <tychicus> correct
[20:11] <hatch> I just joined, so I have no idea what's going on :)
[20:12] <tychicus> Uncaught DOMException: Failed to construct 'WebSocket': The URL '<no value>' is invalid.
[20:12] <hatch> oh kay, that's a new one
[20:12] <tychicus> ran juju bootstrap test-maas-controller test-maas —to=test-juju.maas
[20:13] <hatch> ok and then to load the gui, `juju gui` }
[20:13] <hatch> ?
[20:13] <tychicus> yep
[20:13] <tychicus> ran juju gui --show-credentials
[20:14] <hatch> hmm
[20:14] <tychicus> browser renders "Connecting to the Juju model"
[20:14] <hatch> can you try `juju upgrade-gui` ?
[20:14] <hatch> and then try again
[20:14] <tychicus> Juju GUI at version 2.2.2
[20:15] <hatch> ok give me a few minutes to dig into this
[20:15] <tychicus> sure
[20:15] <tychicus> thanks
[20:15] <hatch> tychicus: oh, what browser?
[20:16] <tychicus> hatch: tried FF 49.0.2, chrome 54.0.2840.87 (64-bit), and safari 10.0.1 (10602.2.14.0.7)
[20:17] <hatch> hah ok
[20:18] <tychicus> safari gives a divvernt error
[20:19] <tychicus> Wrong url scheme for WebSocket and SyntaxError (DOM Exception 12): The string did not match the expected pattern.
[20:19] <hatch> yeah I think I know what might be causing the issue
[20:19] <tychicus> ok
[20:19] <hatch> could you open the browser console and copy the value in `juju_config` and pm me the values?
[20:20] <tychicus> sure
[20:20] <hatch> thanks
[20:22] <x58> thumper: Looks like setting it as subordinate did the trick...
[20:23] <x58> thumper: Think the only users are internal to $WORK, I'll just make this breaking change.
[20:24] <thumper> hmm... the docs need to be more clear if juju-info is only available to subordinates
[20:24] <thumper> seems a bit weird to me
[20:26] <x58> Not the first time I've had issues with docs...
[20:29] <bdx> concerning resources, is there a way to attach a specific revision of a resource?
[20:30] <bdx> say if you wanted to roll back or something
[20:33] <thumper> bdx: I would say you should be able to, but I don't know they syntax
[20:42] <lazyPower> bdx - doesn't appear to be the case when using resources from the charm store. juju deploy cs:~containers/kubernetes-e2e --resource e2e_amd64=e2e_amd64-0  -- but the --resource flag seems to assume its coming from local disk
[20:58] <bdx> lazyPower: do you feel this is a functionality that should exist?
[20:58] <bdx> should I create a bug/feature request against charmstore, or charmstore-client?
[21:02] <lazyPower> bdx - i haven't tested this, but i think the way it would work is if you rolled back to a previous version of the charm... you would get the resource thats associated with that revision of the charm.
[21:04] <lazyPower> s/would work/does work.
[21:04] <bdx> I see
[21:04] <rick_h___> bdx: resources are revisioned just like charms and follow the released channels/etc. It should be possible.
[21:04]  * rick_h___ goes to look for syntax
[21:07] <bdx> lazyPower: I dont see any mapping though .. take mattermost for example `charm show cs:~cmars/mattermost` and `charm show cs:~cmars/mattermost-16` both show rev 3 for the resource
[21:07] <lazyPower> bdx - its entirely possible to use the same resource between two revisions of the charm
[21:08] <bdx> lazyPower: but the mapping that charmstore keeps
[21:09] <lazyPower> bdx: it appears that its been the same resource since revision 8 of the charm
[21:09] <lazyPower> charm show cs:~cmars/mattermost-8 resources
[21:09] <lazyPower> anything  prior to that, no resource that i can see, has been associated with that charm release.
[21:15] <bdx> lazyPower: I see, thx
[22:59] <tychicus> hatch: sudo add-apt-repository ppa:juju/stable did the trick
[22:59] <tychicus> thanks again for the help
[22:59] <hatch> tychicus: glad to hear it, np
[23:00] <tychicus> now to see if I can get ceph up and running :)
[23:05] <hatch> good luck!
[23:14] <tychicus> will juju show you all of the machines that you have commissioned in maas?