[00:50] Is there a way to customize hostnames when launching machines with juju? Or are we stuck with the juju-... hostnames? [00:53] ryebot ... I'm not sure ... I think its a provider thing ... [00:54] like ... have you ever tried to change your instances host name on aws? [00:54] I have not [00:54] (I haven't either lol) [00:54] :D [00:54] alright, cool, I'll look in that direction; thanks bdx [00:54] np [00:59] you can change it post deployment without any reprocussions, but it does default to the juju- hostname schema. [01:00] if we ever start doing computed DNS that may change. [01:00] but that's a future ryebot problem, not a today ryebot problem. [01:01] lazyPower: ah, excellent, I'll give it a shot, thanks [01:03] actually rye, i think that may not be 100% true. I'm pretty sure we run dnsmasq on lxd [01:03] that'll break hostname resolveability [01:04] which matters if you care about specifying hostnames as the remote [01:04] eg: in the context of k8s nodes you'll no longer be able to kubectl exec or kubectl logs === frankban|afk is now known as frankban [07:50] can juju 2 authenticate against Keystone V2 API? [07:51] lazyPower: I've been looking at that example you sent me and its the one I started with - without success. Its perhaps me being stuck in some wrong mental view of how things work with states or something. But I can't so far get my head around how things work. The example http://interface-pgsql.readthedocs.io/en/stable/requires.html#example-usage for example doesn't mention anything about how to include this in the "metadata.yaml [07:51] " or how the "admin-pass" variables are to be used etc. I guess its somehow implicit or perhaps I'm also not reading the right things? Also, I've been trying to read and look how others have made this things and still don't really get it to work with states. I feel that using "hooks" is straight foreward and by using hooks, I can likely get further, but I need to work alot more to get a better understanding of the reactive frame [07:51] work. [07:54] I feel a bit worried about this since I also think its very important for my friends at work to be able to "understand" this concept. Most of them are not used to hard-core programming and the steep learning curve here worries me alot. If it takes weeks and months to get practical about juju charming, its likely not going to take off at work either. Does anyone provide education on this matter today? [07:54] right now after setting endpoint: http://[ip]:5000/v2.0/ it's trying to access V3 path for tokens: http://[ip]:5000/v2.0/auth/tokens [07:58] lazyPower: I will try to summarize my technical problem later. I will try some more today and see if I manage to get through. I'm likely also just doing something wrong. [08:08] kjackal: I looked also at your example interface and I can "sort of" understand. However, the pattern of implementation used in that example is new to me and also I so far have not been touching with "interfaces" yet. Another hurdle I guess... [08:30] erik_lonroth3: Nice to hear you are moving forward with this [08:31] erik_lonroth3: If you have your code public somewhere I would be pleased to take a look and give hints on any problems you may have [08:36] erik_lonroth3: I just read what you wrote above, do not be afraid about the learning curve. Do not be scared with the docs. You are probably over the hard part (understanding hooks) [08:36] Thanx! [08:38] can I disable lxcfs for containers spawned by Juju, or is this going to lead to even more sadness? [08:38] I've come to the understanding that you normally mix "hooks and states" only in "interfaces" or "layers" ? [08:38] erik_lonroth3: only in interfaces [08:39] erik_lonroth3: regarding the metadata.yaml entries, you will need to specify if you require or provide the interface you want to use and you will also need to add the 'interface:foo' in your layer.yaml [08:40] OK, because I've looked at https://api.jujucharms.com/charmstore/v5/trusty/python-django-19/archive/hooks/hooks.py to try to understand how "other charms" have used the postgresql charm and that "python-django" charm does mainly use hooks to use the postgre-sql. Then I've been looking at https://github.com/johnsca/juju-relation-mysql/ (an interface) which I don't yet understand. [08:41] erik_lonroth3: You are on a wrong path :) [08:42] I probably am =D [08:42] erik_lonroth3: ok, lets fix this :) [08:42] let me grab some example code [08:43] My intention is to be able to create a simple charm using a postgre-sql database. [08:43] and to "join"them with a relation. [08:44] I can commit my test to github so you can se what I've been doing so far [08:44] erik_lonroth3: yes please do that [08:48] erik_lonroth3: and let me know where the repo is [08:48] Setting it up as we speak [08:49] thanks [08:51] erik_lonroth3: btw stub is the maintainer of postgresql so if we hit any wall we will call for his help :) [08:51] https://github.com/erik78se/pgtest [08:52] Mind that what I just commited is not working. Let me fix it and lett you know when you can pull [08:53] There, you can pull now [08:55] What I currently was failing on, was/is that my charm never see the state "db.connected'. https://github.com/erik78se/pgtest/blob/master/reactive/pgtest.py I believe thats because its not any "interface" acctually setting that state - so. I'm left with acting on "hooks" instead. [08:57] erik_lonroth3: gitve me 15 minutes [08:58] No worries, I'm going to try to clone the mysql interface and see if I can replicate it to work the way it does for mysql [09:03] Oh, I managed to get "db.connected" to execute once I implemented the interface:pgqsl by simply cloning the mysql and replacing all Mysql stuff with postgresql. However, I'm sure I'm doing this very akwardish [09:09] erik_lonroth3: nope, please give me 5 minutes :) [09:13] Oh, and after breaking through that wall . I found this : https://git.launchpad.net/interface-pgsql [09:14] ... so now I'm rebuilding the charm to test again. [09:14] (after having cloned this repo) [09:19] erik_lonroth3: Have a look here: https://github.com/ktsakalozos/pgtest/blob/master/reactive/pgtest.py [09:20] first of all NEVER mix reactive and hooks [09:20] remove all the @hook from your reactive part [09:21] Cool. I understand the code. [09:21] But so far, I nver got the part "db.connected" to execute. [09:21] doing a deployment right now to see if it works [09:22] Great! I believe my problem is that I need the "interface" code added also to my charm. [09:22] erik_lonroth3: The example with hookenv.config()['admin-pass'] is exactly that - an example. That one is just a handler that is retrieving a password from somewhere and setting a reactive state. [09:23] erik_lonroth3: You have no handler setting the admin-pass state, but you are using it to guard the pgtest.connected handler and it never gets run [09:24] oh, its guarding the handler with pgtest.available. So that would be a different issue to the pgtest.connected guarted handler being called. [09:25] Its OK. I don't care about that admin-pass thing. [09:26] I could have removed that part, but I stilll wont see the "db.connect" code beng run. [09:26] Do you have a relation named 'db' with interface 'pgsql' defined in your metadata.yaml ? [09:27] I think this is that part where my knowledge breaks [09:27] requires: [09:27] db: [09:27] interface: pgsql [09:27] Yes I do. [09:28] And it is called db ? Because that name needs to match the state name 'db.connected' [09:28] This is the part where I'm really confused in how these names repate to interfaces or just some user-defined name/strings ? [09:29] Because in the documentation, I've read that these "states" are really only just that - some user-defined names. [09:30] So, how would I know that @when(".." ) is supposed to be related to a interface, rather than to just some random dead-code or acctually something that is being enforced by the framework ? [09:30] stub: can you tell me if I am using the interface correctly here: https://github.com/ktsakalozos/pgtest/blob/master/reactive/pgtest.py#L29 [09:31] stub: i get "Got connection string None" [09:32] In the example above, the relation name is 'db' and you get to choose that. The interface is 'pgsql', which declares the type of relation and needs to match the interface in the charm you are connecting to. It is also used by charms.reactive to discover and install an implementation of that protocol so you have less work to do. [09:33] charms.reactive uses the name to set states for that particular relation. So when you join the 'db' relation, the 'db.foo' states get set and it isn't confused with any other relations you have declared. [09:33] kjackal: .connected is when the relation is connected. You won't have a connection string until .available [09:34] thanks stub [09:35] In the example it states that "db.master.available" is when I acctually seem to be able to access configuration items... [09:39] Its confusing because we are crossing three bounaries here. Relations are a juju thing, and is documented there. Then we go through charms.reactive, which defines how the relation states work. Then the interface, which defines what the relation states are, when they get set and how it can be used. [09:39] But I think there are some all-in docs now in the main Juju docs? Probably nothing PostgreSQL specific though. [09:43] stub: I agree and can recognize the situation as we are interscting alot of areas within juju. This is also part of my worries, since this kind of maneuver is very common for "sysadmins" who likely are target for juju-related things. I'm struggeling with all of this and I can immagine that others are too. Its very easy to "give up". [09:45] Building "services/applications" with juju should ideally be easy (given the powerful framework). But the number of hurdles, complexities are dauting. Also consider that sysadmins normally are not hardcore programmers. These "concepts" with interfaces, relations etc. are really not trivial things to grasp. [09:47] Having a few "tutorials" that takes one though some common tasks within juju would be great and in the case of connecting an application to a (mysql,postgresql,oracle,mongodb,...)-database should be really well covered... if you ask me.database [09:48] Also - thank you alot for helping me out so far... I wouldn't have made it so far without you help... [09:49] ... if I only could get this pgtest to work today. I've been fighting with it for a few days not. [09:49] now* [09:49] There have been things like that in the past, but they tend to get lost in the sea of blog posts rather than into the official docs [09:50] (I could have sworn there was at least one example in the main docs, but not having success finding it) [09:51] stub: I understand. I do think the documentation site would be good to place a few "best practices" or "common tasks" tutorials. [09:55] erik_lonroth3: here is the PR with how to get pgtest running: https://github.com/erik78se/pgtest/pull/1 [09:55] For example. I'm about to try package a system we have built in my startup. We have some code-base which involves setting up database, connecting our software to it and get going with juju. However, its taken me almost 3 weeks now to get to where I am. I do think this is the right path for us, worth the time, but I'm sure there are alot of other companies/persons that do not come to the same conclusion. Getting to apoint when yo [09:55] u can deploy your system on juju really have to be alot easier. [09:55] kjackal: Thanx! I'll merge [09:57] erik_lonroth3: indeed the juju has its complexities. The abstractions imposed are there to make sure the approach you are taking in setting up your cluster can scale [09:57] just from the peanut gallery, for us part timers getting the hooks reacting correctly in a new charm can be an absolute ballache, of that there is no doubt. Also I come from a Java background so we have IDEs and validation and stuff that tells us when we're being stupid. Clearly with relations and states its a lot harder, but I do dream of that day in Juju land [09:58] on the flip side, compared to non reactive charms, this shit is a breeze [09:59] kjackal: I will test and I saw the changes you did and understand them. [10:00] Would it make sense to add url:s that points to where the interfaces are kept that makes the charm work ? [10:00] erik_lonroth3: so honestly some toy examples indeed seem overengineered. But if you have a big infrastructure with many services juju will realy help. I am not aware of any other framework that allowes you to handle the complexity of large infrastructures so elegantly [10:02] magicaltrout a "part-timer"... yeah right.... You heard it here at #juju first! [10:03] erik_lonroth3: two points to remember 1. Never mix hooks and reactive 2. What you use in the metadata.yaml to reference an interface will be used in the states that interface sets [10:04] erik_lonroth3: for exmample we used "db" to ref pgsql interface so the states this interface set are "db." [10:04] I'm not arguing juju isn't good. Really the contrary. I'm arguing that having a few paths that assists you into acctually producing "common task" juju charms will make it easier to grow a community aroud it also. I'm happy to help here. [10:04] erik_lonroth3: I think we actually want to replace interface:pgsql with a URL to a repo, because people want to pin versions, test forks etc. [10:05] erik_lonroth3: (but I don't think that has moved beyond the vague notion stage yet) [10:06] stub: I think thats really important. Its critical to be able to know how to reproduce a charm. [10:06] erik_lonroth3: would you be able to tell us your experience in this list: juju@lists.ubuntu.com Your feedback is much appreciated and deserves more visibility! [10:07] kjackal: I would love to at some stage. I do however need to get to a point where I'm experienced enough to differentiate between my "novelty-beginner-experience" and "inherent problems with juju". [10:08] I don't want to bloat your input when I'm still so new to this. [10:09] erik_lonroth3: I can comfort you as I started with 0 knowledge of Juju last October and I was as confused as you are now. But after multiple trials and errors things just slowly started to make sense [10:10] erik_lonroth3: I think it is right the oposite. We know what to do for the experienced users. We need to understand what we are doing wrong with the begginers [10:10] Our team has now developed for our internal use multiple charms and I like the simplicity of reactive framework and how that eases the deployment [10:11] anrah: Thanx. But wouldn't you also agree from your opinion that its not so good that it takes well over a year to get to a point where you can do more advanced stuff? [10:11] anrah: I like to hear that you are saying so. [10:11] about your team. [10:12] erik_lonroth3: well yes, the learning curve was quite steep [10:13] kjackal: testing your stuff now. [10:13] We've refactored our charms couple times after we got something working.. First it was just bash that was run through Juju hooks [10:14] And after getting comfortable with reactive we rebuilt everything from scratch using reactive only [10:19] anrah: sonds like a common path =) [10:23] Yes :) And well I don't know whether half a year is long period to learn something [10:24] It took also half a year of me to learn how to write chef cookbooks in a decent way [10:25] anrah: Perhaps its me wanting too much. =) [10:30] But I can comfort you that after you get your head around with states and interfaces things get lot easier and charming is quite straight-forward [10:31] kjackal: Thanx, it works. After my lunch, I'll try to wrap up some of my experiences and maybe provide an email to the list. [10:36] thanks erik_lonroth3 [12:18] magicaltrout: well you do know that galgalesh is working on the whole IDE part... so your dream is coming together one piece at a time [12:19] if there were some kind of clairvoyance.py we could tap into to lint your intent, we would totally be able to deliver your entire dream ;) [12:27] true that [12:45] Kubernetes made it to HN https://hackernoon.com/what-is-kubernetes-and-why-should-you-care-f4c8da25b143 [12:49] Well thats an interesting way to cross promote [12:50] I wish it had more substance though, it seems like its missing a lot of detail === mup_ is now known as mup === frankban is now known as frankban|afk [14:22] probably a really low priority item but it looks like the juju charm store counts tags rather than charms when you search for a charm [14:22] https://jujucharms.com/u/cloudbaseit/#charms [14:22] charm count 17, but only 10 charms [14:23] there are 17 tags though [16:04] magicaltrout: https://twitter.com/lazypower/status/862699798654275586 [16:04] #lol [16:05] indeed lazyPower [16:05] we use it to stalk you! [16:05] even better [17:27] NOTICE with usso having some issues logging into JAAS and such is going to have issues. Apologies to those that choose now to "I'll just logout and back in" === rick_h changed the topic of #juju to: NOTE: USSO is currently out causing login issues to JAAS | Juju as a Service - Beta now available at https://jujucharms.com/beta | https://review.jujucharms.com/ | https://jujucharms.com/docs/ | http://goo.gl/MsNu4I || https://www.youtube.com/c/jujucharms === rick_h changed the topic of #juju to: Juju as a Service - Beta now available at https://jujucharms.com/beta | https://review.jujucharms.com/ | https://jujucharms.com/docs/ | http://goo.gl/MsNu4I || https://www.youtube.com/c/jujucharms [17:58] as such anyone attempting to build layers hosted out of launchpad will also have similar issues assembling charms. [17:59] stub: FYI - during the outage i repointed layer-snap to point @ your github mirror until its resolved. I'll revert to launchpad once we get the all-clear signal from IS [18:24] kjackal: I wrote that mail you asked for to the juju mailing list. [18:57] erik_lonroth: that was a solid and well-detailed write up. Thank you for sharing [19:01] erik_lonroth: Great write up. We've been deploying Juju stuff for a year and now more into developing/fixing charms and we feel the same. Major need for better docs, tutorials and more opinionated guidelines/best practices [19:07] erik_lonroth: zeestrat +1 on the great feedback. One note, I'm looking to pull together juju material for https://tutorials.ubuntu.com/ if anyone's interested I'm happy to help put tutorials together for things. === frankban|afk is now known as frankban === scuttle|afk is now known as scuttlemonkey [20:11] Hello, is there a arch doc that describes communication between Juju and MAAS to provision services? [20:12] * arosales understand its communications via the MAAS API, but didn't know if there was an arch doc out there that described that a bit better [20:18] stokachu hi [20:19] Conjure-up kibernetes returns unable to locate package kibernetes. What may go wrong? [20:19] Snaps is the latest. [20:19] Snapd [20:20] Snapd 2.24.1, conjure-up 2.1.5 [20:21] rick_h: not sure if you would know of any doc that exists [20:21] catbus: try ‘conjure-up kubernetes’ :-) [20:22] * arosales poking around https://github.com/juju/juju/tree/develop/provider/maas atm [20:22] Tried that, it was a typo in my irc msg [20:23] It was a copy and paste from the doc. [20:24] Conjure-up openstack works. But not kuberbetes. [20:24] Catbus: hey! [20:24] Hey [20:25] so what's happening? [20:26] Conjure-up kubernetes returns unable o locate package kubernetes [20:26] Conjure-up openstack works. [20:26] strange [20:26] this on 16.04? [20:26] Me is on the phone, pardon my typos here [20:26] np [20:27] Catbus: are you typing that or is someone else? [20:27] im bringing up a 16.04 system now [20:28] arosales: hmm, so there's the https://github.com/juju/gomaasapi which was basically built for the provider and I there was a new provider checklist spreadsheet that lists calls/etc but I can't seem to find that doc now [20:29] Helping someone else at Marcos hands on session at openstack summit. Only one person on the room has this problem. They are using VM on aws. [20:29] that is crazy [20:29] i just booted a aws vm and tried it [20:29] are they sure they are on correct Ubuntu? [20:30] Aws credentials are prepare by Marco. [20:30] i dunno :( [20:31] it works for me [20:31] and obviously everyone else [20:31] so it's gotta be something with that vm [20:31] Yeah [20:31] conjure-up doesn't even have an error message like 'unable to locate package kubernetes' [20:31] arosales: tim drove most of that maybe he's got something personally that'll cover that better. [20:32] Wow, ok. [20:33] Catbus: if they just run conjure-up [20:33] can they select kubernetes from the list? [20:36] rick_h: thanks I'll ping thumper [20:36] Tried that, but the menu doesn't appear. [20:36] uh [20:37] im out of ideas [20:37] It complains a spell is required to run. [20:37] other than kill the vm and try again [20:37] Catbus: what does dpkg -l |grep conjure-up show [20:37] Yeah, I just gave him another VM. [20:38] Catbus: i bet he apt install conjure-up [20:38] he/she [20:39] No, he used snap [20:40] Catbus: you sure? i have a feeling they have an older conjure-up installed [20:40] the old old version of conjure-up pre-snap used to look for deb packages in the form of `openstack` [20:41] so conjure-up openstack would apt-get install openstack which was a metapackage we used [20:41] there is no deb package named kubernetes [20:41] that's why they are hitting the error [20:44] It works on the new VM. But your explanation makes sense. [20:46] We just moved on, I don't want to verify so he can focus on the session. [20:46] Thanks. [20:46] Again. [21:04] np === frankban is now known as frankban|afk