[06:41] <PCdude> http://askubuntu.com/questions/817572/openstack-fails-to-install-caused-by-juju
[09:01] <kjackal> Hello Juju world
[09:02] <magicaltrout> hey kjackal
[09:03] <kjackal> Hi magicaltrout!
[09:16] <PCdude> hey kjackal  and magicaltrout
[09:18] <PCdude> I have a problem with JUJU and openstack
[09:18] <PCdude> here is the question
[09:18] <PCdude> http://askubuntu.com/questions/817572/openstack-fails-to-install-caused-by-juju
[09:19] <kjackal> Hi PCdude
[09:20] <magicaltrout> blimey
[09:20] <magicaltrout> that only took 15 hours
[09:20] <magicaltrout> finally got maas 2.0 to pxe boot on bloody virtualbox
[09:21] <PCdude> any idea on how to fix it?
[09:22] <kjackal> PCdude: Unfortunately not, but I would suggest you try #openstack-charms
[09:22] <magicaltrout> yeah i've never used openstack i'm afraid
[09:22] <kjackal> the people at #openstack-charms might be able to help you
[09:22] <kjackal> admcleod_: are you there?
[09:23] <admcleod_> yes
[09:24] <admcleod_> kjackal: hello
[09:25] <kjackal> admcleod_: you might have an idea about http://askubuntu.com/questions/817572/openstack-fails-to-install-caused-by-juju
[09:25] <admcleod_> kjackal: PCdude unfortunately i dont know anything about conjure-up - but that error makes me think perhaps there is a lib mismatch or something.
[09:26] <admcleod_> the first error anyway, the second look like a hardware problem
[09:27] <admcleod_> ...although fd0 is probably floppy disk? so perhaps its just complaining because theres a virtual floppy device attache
[09:27] <admcleod_> d
[09:27] <admcleod_> *guessing*
[09:29] <PCdude> admcleod_:  yeah, I thought about the floppy disk too, but the weird part is that there is no floppy disk turned on in the bios and also there is no floppy disk added in the VM of the node
[09:30] <admcleod_> PCdude: weird. well, maybe that can be ignored - it looks like other people have had the first issue too
[09:30] <PCdude> what u mean "other people", is this a know issue?
[09:31] <admcleod_> PCdude: it looks like it, i googled the error and i see other people have reported it recently
[09:32] <PCdude> admcleod_:  I have tried different fora and sended a bug report to JUJU, so I think u are looking at my post :) maybe u can share the link?
[09:33] <admcleod_> PCdude: e.g. http://askubuntu.com/questions/808372/ubuntu-server-16-04-openstack-mitaka-installation-juju-error/813395
[09:34] <admcleod_> PCdude: perhaps try the suggestions at the bottom of that link? let us know if that helps
[09:35] <PCdude> that is not me, but thanks for the link, I am gonna try that, I will let u know admcleod_
[09:42] <admcleod_> magicaltrout: you at the new job yet? or are you still on earth
[09:42] <admcleod_> PCdude: im hopeful..:)
[09:44] <magicaltrout> admcleod_: hehe
[09:44] <magicaltrout> i'm on the next ship out of here
[09:45] <magicaltrout> although today i'm working on my presentation for MesosCon on Wednesday
[09:45] <magicaltrout> learning MAAS in a hurry
[09:45] <admcleod_> colorado?
[09:46] <magicaltrout> Amsterdam
[09:46] <magicaltrout> Amsterdam on Wednesday, Bluefin for a Pentaho thing on Thursday, back for a week, then Pasadena for Juju Summit & working the following week @ JPL
[09:47] <admcleod_> oh yeah cool
[09:47] <PCdude> magicaltrout:  , where are u from?
[09:47] <magicaltrout> Good question PCdude
[09:47] <admcleod_> ill be at pasadena - ill bring some cheese chocolate
[09:47] <magicaltrout> I can tell you I live outside London currently
[09:47] <magicaltrout> admcleod_: i look forward to not bumping into you then
[09:48] <PCdude> magicaltrout: ah ok, cool! I live a little to the east of u then :)
[09:48] <magicaltrout> where you based PCdude ?
[09:48] <PCdude> not amsterdam, but close
[09:49] <magicaltrout> been a few years since I was last in Holland, shame its a flying (no pun intended) visit
[09:49] <admcleod_> magicaltrout: aww :)
[09:50] <PCdude> how old are u magicaltrout ?
[09:51] <magicaltrout> well yesterday I thought I was 34
[09:51] <magicaltrout> the mrs had to correct me
[09:51] <admcleod_> magicaltrout: so you're not 34, you're a messy idiot?
[09:52] <admcleod_> :D
[09:52] <PCdude> haha, 21 here
[09:52] <magicaltrout> 21
[09:52] <magicaltrout> makes me feel old
[09:52] <PCdude> and admcleod_ how old are u?
[09:52] <PCdude> u are old magicaltrout ;)
[09:52] <admcleod_> 36 i think
[09:52] <magicaltrout> you'd never guess with his bald head
[09:52] <admcleod_> haha
[09:53] <PCdude> I think?! haha
[09:53] <admcleod_> yeah, i look about 50
[09:53] <admcleod_> i stopped counting aftr 30 because i felt like id clocked the game
[09:53] <admcleod_> now every year is just a step closer to death.
[09:53] <admcleod_> ;]
[09:53] <PCdude> woah, the best had yet to come :)
[09:53] <magicaltrout> every day
[09:53] <magicaltrout> not every year
[09:54] <admcleod_> you younuns and your days
[09:54] <admcleod_> younguns
[09:54] <PCdude> well, I tried both options of the link admcleod_ , no luck so far...
[09:55] <PCdude> stupid openstack
[09:55] <admcleod_> PCdude: ok - if you stay in openstack-charms then someone who can help should be along soon
[09:55] <magicaltrout> don't use it
[09:55] <magicaltrout> its not the law ;)
[09:55] <PCdude> admcleod_:  I will
[09:56] <PCdude> magicaltrout:  , yeah well the whole landscape idea sounded really good to me, and what are the alternatives?
[09:56] <magicaltrout> what you trying to acheive PCdude ?
[09:57] <PCdude> I really wanna build a private cloud, with several servers. storage node, network node, provisioning
[09:58] <PCdude> basically a private version of amazon aws
[09:58] <PCdude> I know its a big plan, but I do not care :)
[09:59] <magicaltrout> fair enough, go wild then! :)
[10:00] <PCdude> but yeah, are there other options than openstack
[10:00] <PCdude> ?
[10:00] <PCdude> and I am still a student, so I dont have 1000 dollars a month laying around
[10:01] <admcleod_> PCdude: can you pastebin your juju accounts.yaml? (without passwords)
[10:01] <PCdude> admcleod_:  , sure one moment
[10:01] <magicaltrout> well it still depends on what you're trying to do. Learn cloud computing? then use Openstack. Create a private cloud for development? Maybe there is a different way of doing stuff outside of a private cloud
[10:05] <PCdude> admcleod_:  http://pastebin.com/auGcqBiM
[10:06] <PCdude> with of course, the maas key and password included in the real file
[10:07] <PCdude> magicaltrout:  , learning for sure, development as in for programming projects? or as in development of a private cloud?
[10:09] <admcleod_> PCdude: so, i think thats missing some stuff ...
[10:09] <admcleod_> PCdude: and im not sure what conjur-up is supposed to add
[10:09] <PCdude> admcleod_:  ok, hit me, what should I add?
[10:10] <PCdude> admcleod_:  conjure-up is what is supposed to be used when installing openstack on 16.04 and higher
[10:10] <PCdude> before that, someone could issue "sudo openstack-install"
[10:10] <admcleod_> PCdude: i mean, i dont know if conjure-up should be adding this extra configuration that should be there or not
[10:10] <PCdude> conjure-up (according to some stackexchange users) should give more freedom
[10:11] <admcleod_> PCdude: i would say, just to check that the juju install is ok, try https://jujucharms.com/docs/stable/getting-started
[10:11] <PCdude> admcleod_:  uhm, good idea  I think
[10:12] <PCdude> admcleod_:  , I fucked up this VM now anyway, so I think I need to start over to avoid some weird errors, I tried to fix the python error myself, without any luck
[10:13] <admcleod_> PCdude: right ok so starting from scratch sounds like a good idea
[10:13] <admcleod_> PCdude: verify juju, and then maybe someone will have a response to the specific error
[10:13] <PCdude> admcleod_:  btw, a little offtopic, but do u know some simple program to make an unattended version of ubuntu 16.04 for install?
[10:14] <PCdude> its just for some simple stuff, so I dont need a whole server with puppet or FIA
[10:14] <admcleod_> PCdude: preseed?
[10:14] <admcleod_> PCdude: https://help.ubuntu.com/lts/installation-guide/example-preseed.txt < something like that?
[10:15] <PCdude> admcleod_:  I did find some old posts yesterday, but was not sure if that was still the way to go in 2016 with ubuntu 16.04
[10:17] <PCdude> admcleod_:  I will look into preseed
[10:18] <admcleod_> PCdude: that one is for xenial - it basically provides answers to the normal installation prompts
[10:18] <PCdude> admcleod_:  and how do I add it to the install?
[10:18] <PCdude> the iso I mean
[10:22] <admcleod_> PCdude: you would need to mount the iso as an fs, add the file, rewrite the iso..
[10:24] <magicaltrout> admcleod_: you'll know this, if I juju deploy onto maas, does it install onto the bare metal? or in a lxc container?
[10:24] <admcleod_> PCdude: perhaps its better to ask that in #ubuntu though, maybe there is a better way
[10:25] <PCdude> magicaltrout:  on bare metal
[10:25] <admcleod_> magicaltrout: if you just 'juju deploy ubuntu' itll deploy it to bare metal, if you 'juju deploy ubuntu --to lxc:machine#' then lxc
[10:25] <magicaltrout> cool I need the baremetal scenario just checkin
[10:25] <magicaltrout> g
[10:26] <PCdude> admcleod_:  yeah, will try that, I find a ton of options u have to go around this "problem" so maybe there are some simple GUI versions even I dont know
[12:43] <rock_> Hi.  I did juju deploy openstack on LXD using  https://github.com/openstack-charmers/openstack-on-lxd.   Bymistake I did  #juju logout --force. Now I am not able to see $juju status.
[12:45] <rock_> How can I login back? I tried #juju login. But it was asking username and password. We last password. It was not showing anything in accounts.yaml. How can I achieve my previous status?
[12:45] <rock_> please help me in this
[12:56] <rts-sander> juju logout --force by mistake?
[12:59] <rock_> rts-sander
[12:59] <rock_> rts-sander: Yes
[13:02] <rock_> rts-sander: do you know how to solve? please tell me
[13:25] <magicaltrout> cmars: ping
[13:25] <cmars> magicaltrout, hi
[13:26] <magicaltrout> hi cmars, I'm trying to ascertain the difference between your two nagios interfaces
[13:26] <magicaltrout> can you shed any light?
[13:26] <cmars> magicaltrout, local_monitors vs nrpe_external_master?
[13:26] <magicaltrout> yeah. if my charm wanted to run an nrpe script, which do I pick? :)
[13:28] <magicaltrout> my gut says local_monitors, but I'm just guessing ;)
[13:28] <cmars> magicaltrout, well, they're basically the same content-wise. the local-monitors interface is useful if you want to deploy nagios into the same model and relate the nrpe subordinate to it
[13:28] <magicaltrout> ah, now i see what you mean by external master
[13:29] <cmars> magicaltrout, so i typically use this to test our nagios integration, for internal deploys at work
[13:29] <cmars> magicaltrout, when we go to production, we use nrpe-external-master
[13:29] <magicaltrout> cool, now it makes sense :)
[13:30] <cmars> magicaltrout, i've also noticed a layer:nrpe written more recently, this might be useful as well. haven't tried it yet, but it looks interesting
[13:30] <cmars> i think it may take a different approach
[13:41] <stub> magicaltrout, cmars : I was putting together https://launchpad.net/nagios-layer so everyone could share the same boilerplate
[13:42] <cmars> stub, awesome!
[13:43] <jcastro_> marcoceppi: can you help out with this one? Kind of complex http://askubuntu.com/questions/817399/juju-charms-related-to-etsi-osm-mano-nfv-deployment/817449#817449
[13:52] <beisner> hi rock, so to recap:  you did a deploy with the lxd provider, and that worked ok.  then after a juju logoff, you're wondering how to re-auth so you can interact with the model again.  is that right?
[13:53] <beisner> hi rock_ - so you have a charm that you've authored, or are planning to author, and you're wondering how to get it into the charm store as a recommended (official) charm?  is that what you mean by certified?
[13:54] <magicaltrout> lazyPower: ping
[13:54] <lazyPower> magicaltrout pong
[13:54] <magicaltrout> ah hello there
[13:54] <magicaltrout> prepping for wednesday
[13:54] <magicaltrout> quick question
[13:54] <rock_> beisner : Yes.
[13:54] <magicaltrout> if is possible to use layer-docker without installing docker?
[13:55] <magicaltrout> I would like to provide docker.available
[13:57] <magicaltrout> i guess the actual question is, is there an interface instead? : )
[13:57] <beisner> hi rock_ - i'm not sure that is recoverable (or if so, how).  based on the output of `juju logout` without force, in an identical use case, i would believe that there is an autogenerated initial password that is expected to be changed by the user before logging out.  ex:  http://pastebin.ubuntu.com/23107425/
[13:58] <lazyPower> magicaltrout https://github.com/juju-solutions/layer-docker/blob/master/layer.yaml
[13:58] <lazyPower> in your inhereting layer, override skip-install to be true. you get docker.available without the delivery bits
[13:58] <magicaltrout> nice
[13:59] <magicaltrout> i can just put hte same config in my layer.yaml right?
[13:59] <lazyPower> magicaltrout https://github.com/juju-solutions/layer-basic#layer-configuration
[14:00] <lazyPower> err
[14:00] <lazyPower> https://github.com/juju-solutions/layer-basic#layer-options
[14:00] <lazyPower> magicaltrout ^
[14:00] <magicaltrout> ta
[14:02] <rts-sander> is there some kind of minimal example of a charm making a call to the juju API?
[14:03] <marcoceppi> charms don'
[14:03] <marcoceppi> rts-sander: charms don't usually make calls to the juju API
[14:03] <marcoceppi> rts-sander: outside of the hook tools
[14:03] <marcoceppi> rts-sander: what kind of call are you looking to make?
[14:03] <rts-sander> I want the charm to scale itself
[14:03] <rts-sander> so add-unit in this case
[14:03] <marcoceppi> rts-sander: ah, I see
[14:05] <andrey-mp> marcoceppi: hi, I've asked you about mysql charm for 16.04 and I see that it's not ready yet. But what is the way to install OpenStack to 16.04 now?
[14:05] <rock_> beisner: OK. But all container are in persistent state. I ran  #lxc list    . Can we manage all these containers with a newly bootstrapped controller?
[14:09] <shruthima> hi petevg/kevin , may i know ibm-http charm review process status ?
[14:12] <petevg> kwmonroe ^^ it looks like our notes on it are blank. Is that the one where we were missing some files from the ftp site?
[14:14] <magicaltrout> lazyPower: Unable to load tactics.docker.DockerWheelhouseTactic from /home/bugg/Projects/dcos-master
[14:14] <lazyPower> magicaltrout - are you running the latest charm-tools?
[14:14] <magicaltrout> dunno
[14:15] <magicaltrout> 2.1.2
[14:16] <rock_> andrey-mp: Hi. You can use  https://github.com/openstack-charmers/openstack-on-lxd. All in one deployment on VM.
[14:16] <lazyPower> marcoceppi - can you confirm/deny if the apt packaged tooling has the wheelhouse fix?
[14:18] <lazyPower> magicaltrout - give me 10 to do some investigation
[14:18] <magicaltrout> sure
[14:19] <andrey-mp> rock_: these bundles contain 'charm: cs:xenial/percona-cluster' for mysql )
[14:25] <rts-sander> I know juju-gui makes calls to the API but it's not easy to extract a minimal example from it
[14:25] <rts-sander> then there's the golang juju/juju/api package but it has minimal documentation and no examples
[14:25] <andrey-mp> rock_: thank you. it's useful.
[14:25] <lazyPower> magicaltrout - i've just built from layer-docker  in charmbox:latest (which is using 1.25.6 and tooling from apt) - so if you bump your version of charm-tools you should get a clean build. If that's not the case, i'll need the output of dpkg --list | grep charm  so we can poke around. An issue related to your build error was also filed here: https://github.com/juju-solutions/layer-docker/issues/67
[14:29] <shruthima> petevg: if anything is missing from our end on ibm-http charm please let us know.
[14:32] <lazyPower> magicaltrout - marco says "install the snap" alternatively, its also in the devel ppa. ppa:juju/devel
[14:33] <lazyPower> rather ppa:juju/stable (we have no idea where we put things)
[14:36] <petevg> shruthima: Sorry about the lack of comment on the PR. It looks like ibm-http is the one that was missing files. We couldn't find the resources mentioned in the README on the ftp site.
[14:36] <petevg> shruthima: I'm in a meeting now, but after I'm out, I'll drop a comment on the PR w/ the specifics.
[14:37] <shruthima> petevg: ok thanks
[14:37] <petevg> you're welcome!
[15:00] <magicaltrout> here's a good dcos reference implementation lazyPower : https://ibin.co/2tFN0mNz6mr5.png
[15:00] <lazyPower> magicaltrout - which charm is missing the icon?
[15:00] <magicaltrout> most of the code doesn't exist yet, but who cares ;)
[15:01] <magicaltrout> I borrowed you're docker-nginx charm and hacked it up to do dcos-nginx
[15:01] <lazyPower> right on
[15:01] <magicaltrout> so you have your dcos core services, logging and monitoring from logstash and nagios
[15:01] <lazyPower> hense the desire for docker.available :D
[15:01] <magicaltrout> then you can attach docker comntainers
[15:01] <lazyPower> i see, i see.
[15:01] <magicaltrout> yeah i didn't use that in the end =/
[15:02] <lazyPower> no worries, options are there :)
[15:02] <magicaltrout> I'd like to figure out soem dcos/docker compatible interface
[15:02] <magicaltrout> but that'll have to come later
[16:43] <lazyPower> magicaltrout - last of the refactorings are landing in layer-docker. Give your layers a rebuild and let me know if you encounter any new failures. We circled back and triaged #69/#71 this morning after the reported failures.
[16:43] <lazyPower> just waiting on this one: https://github.com/juju-solutions/layer-docker/pull/73
[18:04] <cmars> i got an error when trying to build the charm-tools snap: https://paste.ubuntu.com/23108417/
[18:05] <cmars> any ideas how to fix this?
[18:06] <cmars> reason i ask, is i'd like to add the term publishing tools to the snap, but ran into this when i went to build it
[18:12]  * lazyPower looks
[18:12] <lazyPower> that looks like its pretty new cmars
[18:12] <lazyPower> marcoceppi ^
[18:12] <lazyPower> pyyaml version mismatch that might have been fine last week, but i'm not positive. calling in the author, but we're in standup
[18:18] <cmars> lazyPower, marcoceppi thanks. i've opened a bug
[18:31] <marcoceppi> cmars: weird, I'll push out an update
[18:31] <cmars> marcoceppi, thanks!
[18:32] <marcoceppi> cmars: oh, you're trying to build it
[18:32] <cmars> marcoceppi, yeah, want to test out https://github.com/juju-solutions/charm-pkg/pull/1
[18:33] <marcoceppi> cmars: change master to 2.1 in the charm-tools target
[18:34] <marcoceppi> cmars: there seems to be no way to twiddle that without editing the file (which is lame)
[18:34] <cmars> marcoceppi, yeah, it'd be cool if you could interpolate vars in there...
[18:34] <marcoceppi> totally
[18:35] <marcoceppi> cmars: either way, try that
[18:35] <cmars> trying now..
[19:39] <cmars> marcoceppi, still getting the same error. are you able to build the snap?
[19:48] <marcoceppi> cmars: I was a fwe days ago ;)
[19:48] <marcoceppi> cmars: let me try again
[19:48] <cmars> marcoceppi, thanks
[20:07] <marcoceppi> cmars: I replciated, apparently something is installing 3.12 of PyYAML
[20:07] <marcoceppi> ugh
[20:08] <cmars> marcoceppi, ok, thanks for confirming
[20:08] <marcoceppi> cmars: I just can't replicate it with a regular venv
[20:11] <hatch> when a layer emits an 'event' how does that event get actually called? say 'nrpe.available' ?
[20:12] <lazyPower> hatch - thats dependent on how the charm author has intended to handle it. If its written for you, search for a @when('nrpe.available') state is being consumed. or @when_any or even a @when_not
[20:12] <marcoceppi> hatch: that's not an event, that's a state
[20:12] <marcoceppi> nrpe.available is now, and forever, set until something removes that state
[20:12] <lazyPower> if its an open ended event, meaning we're just saying that some base level function to provide nrpe has been performed (such as a package being installed and default configuration rendered) its now up to you as the next inheriting layer, to decide what that means in the context of your deployment.
[20:12] <hatch> I mean, when does the layers framework execute functions decorated with an @whrn?
[20:12] <lazyPower> or as marco said in so many fewer words
[20:13] <marcoceppi> hatch: it's an event loop
[20:13] <hatch> so what triggers the event?
[20:13] <hatch> config-changed?
[20:13] <marcoceppi> hatch: so at the end of each loop, reactive evaluates prev states with current states
[20:13] <marcoceppi> hatch: if there's a mismatch, it'll re-run the loop
[20:13] <hatch> or do these @when's have nothing at all to do with the hook system?
[20:13] <marcoceppi> hatch: so, nrpe.available is set in the nrpe interface layer, typically when the relations is completed
[20:13] <marcoceppi> hatch: nothing
[20:14] <hatch> ok and are the @when's executed every time per loop? or only when that state has changed?
[20:14] <hatch> does the framework have a diffing mechanism?
[20:15] <marcoceppi> hatch: everytime the when criteria matches
[20:15] <magicaltrout> hatch: data_changed() for variable diffing
[20:15] <marcoceppi> which is why you'll typically see one or more when and when_not statements around a method
[20:16] <hatch> marcoceppi: so in this loop, which executes every Nms it's going to call the functions decorated with @when's
[20:18] <marcoceppi> hatch: so long as all criteria is met, then yes
[20:18] <hatch> I see
[20:18] <marcoceppi> hooks are just probes to run the reactive framework which combines Juju hook with the set of states/flags set currently
[20:18] <hatch> whats the duration of this event loop?
[20:18] <marcoceppi> most reactive/*.py files don't respond to @hook because it doesn't matter that it's install or start
[20:19] <marcoceppi> hatch: as long as it takes
[20:19] <hatch> so, something that's listening on @when('nrpe.available') will also need a @when_not('nrpe.not-available') ?
[20:20] <hatch> or...
[20:20] <hatch> you know what I mean
[20:20] <marcoceppi> hatch: no, because nrpe.available is only set when it's available
[20:20] <hatch> but every loop of the event loop it's going to call that function
[20:20] <marcoceppi> hatch: however, you might want something like @when('nrpe.available') and @when_not('app.nrpe-configured)
[20:20] <marcoceppi> where app.nrpe-configured is named appropriately and is set after you do swhat you need to with nrpe
[20:21] <marcoceppi> the state declarations are really just to help easily map dependencies of what needs to happen before this method is executed
[20:21] <hatch> so how do you create singletons for events? if you only wanted to perform an action once when nrpe.available?
[20:21] <marcoceppi> hatch: my above example would do just that
[20:22] <hatch> ok so then @when's are really "gates"
[20:22] <marcoceppi> hatch: what's the name of the layer
[20:22] <marcoceppi> hatch: yes
[20:22] <marcoceppi> they're conditionals
[20:22] <hatch> I see
[20:22] <hatch> so you really have to think about how to create a singleton
[20:22] <marcoceppi> arbitrary names as well
[20:22] <hatch> because I can't think of a time when you'd want to spam something every time the loop happens
[20:23] <marcoceppi> hatch: http://paste.ubuntu.com/23108940/
[20:23] <marcoceppi> hatch: there are a few instances
[20:24] <marcoceppi> por ejemplo
[20:26] <hatch> marcoceppi: so that seems like the default action people would want to do
[20:26] <hatch> a 'once'
[20:26] <marcoceppi> sure, it's one of the many possibilities
[20:26] <marcoceppi> once, occasionally, everytime are a few other examples
[20:26] <hatch> ok, but when would you ever want anything to happen on every event loop?
[20:27] <hatch> that could be hundreds of times per second
[20:27] <marcoceppi> update-status ?
[20:27] <marcoceppi> well, not nessisiarly
[20:27] <marcoceppi> event loop runs every time there's a hook until there are no state changes
[20:27] <marcoceppi> could be one time, could be 100
[20:27] <marcoceppi> but it's not like a node.js event loop or nginx
[20:27] <hatch> ok so there IS a direct relation between hooks and events
[20:28] <hatch> events are _not_ executed until a hook is triggered
[20:28] <marcoceppi> I think we're overloading event
[20:28] <hatch> ergo, not a loop
[20:28] <marcoceppi> the reactive framework is executed on each hook run
[20:28] <marcoceppi> > hooks are just probes to run the reactive framework which combines Juju hook with the set of states/flags set currently
[20:28] <hatch> ok so let me put an example
[20:29] <hatch> I have foo.available , that's 'fired' when my foo service has successfully installed and configured itself - this is a purely remote action, there is no hook fired on my charm. How does it know to execute that foo.available event?
[20:30] <marcoceppi> stop thinking of states as events
[20:30] <marcoceppi> step 1 ^ ;)
[20:30] <hatch> ok they are states
[20:30] <marcoceppi> the only way a state can be set is during a hook
[20:30] <marcoceppi> well
[20:30] <marcoceppi> 99.99999999% of times a state is set during a hook
[20:31] <marcoceppi> technically you can set states outside of hooks, but no one does that I'm aware of
[20:31] <lazyPower> despite actions having access to states... thats the other use case i can think of
[20:31] <marcoceppi> actions are hooks
[20:31] <lazyPower> but thats also an anonymous hook context
[20:31] <hatch> ok so assuming that this remote install and configuarion step is performed when a relation-joined happens. I'd have to block the relation-joined hook from continuing probing the remote service to see if it's done
[20:31] <marcoceppi> hatch: the relation interface should be the one that does the probing
[20:31] <marcoceppi> and it should be the one to set nrpe.available once it's confirmed it
[20:32] <hatch> sure, but that is still blocking the relation-joined hook from finishing
[20:32] <marcoceppi> either you ahve all the data to complete configuration, or you don't
[20:32] <marcoceppi> why?
[20:32] <hatch> because it can't finish the hook until it knows that this remote service is setup so it can set 'available'
[20:32] <marcoceppi> just don't set a state and the hook will complete and the next will run
[20:32] <marcoceppi> let me back up, are you writing the nrpe interface layer or are you writing somethign that depends on it?
[20:33] <hatch> I was just using that as an example, let me simplify this to abstract applications....How does AppA know that AppB is done doing something?
[20:33] <hatch> assuming that AppA has to know when AppB is done before setting 'AppB.available'
[20:33] <marcoceppi> the interface tells AppA it's available
[20:34] <hatch> what's in ths interface?
[20:34] <marcoceppi> hatch: how about an example?
[20:34] <hatch> what is the interface doing to know this
[20:34] <hatch> is AppA blocking a relation hook to poll on AppB
[20:34] <marcoceppi> hatch: https://github.com/johnsca/juju-relation-mysql/blob/master/requires.py
[20:34] <marcoceppi> hatch: so you poll, and it fails, then you exit the hook or it succeeds and you set the state
[20:35] <marcoceppi> or you don't do either, and assert that a completion of relation data required to make the connection is an indication of health for the remote application
[20:36] <hatch> right this example you linked is an immediate "oh we connected, we're good" but that's not always the case
[20:36] <marcoceppi> and without a sane way in juju to assert health of an application, we have to work off the assumptions that when a relation has sent all required data to make the connection
[20:36] <hatch> sometimes available is more than 'relation-joined'
[20:36] <marcoceppi> hatch: yes, in this case, you sent me /all/ the data I need to make a connection
[20:36] <marcoceppi> short of actually logging in which we /could/ do, there's not much else to be done
[20:36] <hatch> and the only way to know that is to block a relation hook and poll the remote service
[20:36] <marcoceppi> the handshake is complete, and it's availalble because the data has been made available
[20:37] <marcoceppi> hatch: so poll the remote service
[20:37] <marcoceppi> it'll either: fail - not ready or it'll succeed, ready
[20:37] <marcoceppi> but if a service is sending over relation data and it's not ready, that's a problem
[20:37] <hatch> right
[20:37] <marcoceppi> that charm isn't of quality
[20:38] <marcoceppi> so sure, you can go above and beyond, but if you expect to have another go at validating that relationship, without proper event modelling of health in juju there's no event that will be tirggered again to re-evaluate that state
[20:38] <hatch> that's fine, I'm just trying to understand the relationship between hooks and states
[20:38] <marcoceppi> this is why we have relation-changed, used to update the relation wire and if we withold crucial information like, connection details, until the remote serivce is ready
[20:38] <hatch> and without a hook there is no state
[20:38] <marcoceppi> we can use that to key on it being "available"
[20:39] <marcoceppi> states are set and evaluated inside of a hook context
[20:39] <marcoceppi> but available might mean two diferent things here, available: connection details available and available: service is functioning
[20:39] <hatch> right
[20:39] <marcoceppi> the former is today, the latter, well, I'd like to have a discussion about at the charmer summit :)
[20:39] <hatch> and simply by decorating a function with a state value doesn't mean you're going to be called with that immediately
[20:40] <marcoceppi> and how to measure application health with juju
[20:40] <hatch> a hook has to be executed to trigger this change
[20:40] <marcoceppi> yes
[20:40] <marcoceppi> fundementally, all juju and charm things are boiled down to "a hook ran"
[20:40] <marcoceppi> it's our entry point into the system
[20:41] <hatch> and when a state is changed there is a loop which is triggered which is basically a while loop which checks "have any states changed since the last loop"
[20:41] <hatch> it's not a never-ending stack
[20:41] <marcoceppi> right
[20:41] <marcoceppi> maybe one day? but not currently in today's design
[20:42] <marcoceppi> since we do still fundementally rely on juju hooks to determine method execution
[20:42] <hatch> ok now this makes sense
[20:42] <marcoceppi> cool, we're very much still open to input on different ways of doing things
[20:43] <hatch> marcoceppi: the docs need to be updated then
[20:43] <marcoceppi> hatch: link me to the mistakes
[20:43] <hatch> "States are synthetic events that are defined by the layers author"
[20:43] <hatch> https://jujucharms.com/docs/stable/developer-layers
[20:43] <marcoceppi> "states are synthetic flags that are defined by the layers author and evaluated during hook execution" ?
[20:43] <hatch> sure
[20:43] <marcoceppi> would that shape that sentance better?
[20:44] <hatch> just to me an event is something that reacts to changes
[20:44] <marcoceppi> yeah, event is totally the wrong wording there
[20:44] <marcoceppi> I think some more pictures too, describing this might be helpful
[20:44] <marcoceppi> I'll update that for now, thanks for the feedback
[20:45] <BradCrittenden> marcoceppi: why is 'synthetic' necessary?  it seems to just add confusion.
[20:45] <marcoceppi> bac: : not sure, it's meant to convey they are arbitrary iirc
[20:46] <bac> marcoceppi: if only there was a word for 'arbitrary'.  :)
[20:46] <marcoceppi> would arbitrary be a better word there for describing what a state is?
[20:46] <bac> marcoceppi: i think so
[20:46] <marcoceppi> I mean, they are synthetic, much in the way we promulgate charms ;)
[20:46] <hatch> marcoceppi: fwiw layers make charms so much eaiser to understand
[20:46] <hatch> I'm just being picky because I like to know the internals of things :D
[20:47] <marcoceppi> hatch: it's good discord, the more [people poking reactive the better it'll become
[20:47] <hatch> marcoceppi: there is also ". Hook decorators so the code can react to Juju events."
[20:47] <hatch> on the same page
[20:47] <marcoceppi> well, hooks are juju events, what wording would make more sense for you?
[20:48] <hatch> Juju hooks
[20:48] <hatch> :)
[20:48] <hatch> no need to introduce extra terminology
[20:48] <marcoceppi> psh, w/e <3
[20:48] <hatch> lol
[20:49] <hatch> marcoceppi: it's also very important to point out that it will execute those 'callbacks' every time there is a hook run
[20:49] <hatch> and probably an example on how to prevent that
[20:49] <hatch> as I'm assuming a singleton is the primary usecase
[20:50] <hatch> marcoceppi: I guess it DOES have a sentence about it
[20:51] <hatch> just doesn't really say that it's going to happen all the time
[20:51] <hatch> it sort of eludes to it
[20:52] <hatch> but anyways...thanks for clearing up all my confusion :D
[20:52] <marcoceppi> hatch bac https://github.com/juju/docs/pull/1314
[20:53] <marcoceppi> cmars: I patched charm-tools to get around this
[20:53] <hatch> marcoceppi: thanks looks good
[20:54] <hatch> marcoceppi: this link you sent http://paste.ubuntu.com/23108940/ would be a really good example for implementing idempotency
[20:55] <hatch> ya know, with a real example though :D
[20:55] <marcoceppi> hatch: psh, "examples" ;)
[20:55] <marcoceppi> cmars: https://github.com/juju/charm-tools/pull/250
[20:56] <hatch> lol
[20:56] <hatch> marcoceppi: maybe there needs to be a @when_once() ?
[20:57] <hatch> it would really be a simple wrapper over a setstate
[20:57] <hatch> but would make it much easier to grok for those not familiar with the execution flow of a layered charm
[20:57] <marcoceppi> hatch: so that has some major implications (and discussion has been had around this)
[20:57] <marcoceppi> but what does once mean?
[20:58] <hatch> I'd say once it becomes truthy
[20:58] <hatch> but I'v eonly thought about it for....30m?
[20:58] <hatch> lol
[20:58] <marcoceppi> https://github.com/juju-solutions/charms.reactive/issues/22
[20:58] <marcoceppi> hatch: so we have an only_once wrapper but it's problematic
[20:58] <hatch> oh nice, I totally missed this issue somehow
[20:58] <marcoceppi> odds are you want it once until something else changes
[20:59] <marcoceppi> which the something else is rare
[21:00] <hatch> hmmm
[21:00] <hatch> interesting
[21:00] <marcoceppi> hatch: yeah, the definition of once in a distributed system varries by the person defining what once means
[21:01] <hatch> right, and accounting for failures, does that mean the 'once' is satisfied, or not
[21:01] <bac> marcoceppi: gotta be quick on those doc reviews!
[21:01] <hatch> this is a rabbit hole
[21:01] <hatch> :)
[21:02] <bac> marcoceppi: if you're poking at the documentation, could you look at https://github.com/juju/docs/issues/1313 ? I think the problem is the use of an absolute URL.
[21:06] <marcoceppi> bac: yeah, good find. I've submitted #1315
[21:07] <bac> great, thank you marcoceppi
[21:21] <kwmonroe> lazyPower: i'm befuddled.. when charmbox builds went to ci.containers, i sadly assumed i'd lose the status from https://hub.docker.com/r/jujusolutions/charmbox/builds/, but those builds are green now.  is that status page pulling results from ci.containers?
[21:21] <lazyPower> those greens were the last builds before we moved over as best i can tell
[21:22] <lazyPower> i'd need exact timestamps to tell you in more detail
[21:24] <bac> marcoceppi: what is the cause of: charmtools.build.tactics: Options set for undefined layer: apt
[21:24] <bac> seems to be environmental, as makyo doesn't get it building the same charm
[21:24] <marcoceppi> bac: you have set options for a layer you didn't include
[21:24] <bac> hmm
[21:24] <marcoceppi> bac: can I see you layer.yaml ?
[21:25] <bac> marcoceppi: https://github.com/juju/bundleservice-charm/pull/2
[21:27] <marcoceppi> bac: huh, that's weird. you have layer:apt right there
[21:27] <marcoceppi> bac: what does `charm version` say?
[21:27] <bac> charm 2.1.1-0ubuntu1
[21:27] <bac> charm-tools 2.1.4
[21:28] <marcoceppi> well that's bizzare
[21:28] <marcoceppi> let me try
[21:29] <bac> marcoceppi: https://pastebin.canonical.com/164230/ shows it getting the apt layer
[21:36] <cmars> marcoceppi, thanks!
[21:45] <marcoceppi> bac: can you run with -l DEBUG
[21:46] <x58> Is there a reason to use the apt layer over just the basic layer with packages: in layer.yaml?
[21:46] <bac> marcoceppi: sure
[21:46] <x58> In my case I just want to make sure that my package is installed...
[21:46] <marcoceppi> x58: there are reasons to use apt over basic
[21:47] <marcoceppi> x58: apt layer provides states like `apt.installed.<pkg>` that you can respond to
[21:47] <marcoceppi> where as basic: packages: is more for "I need these packages before hook code can even run"
[21:47] <marcoceppi> since that's executed during the bootstrap process
[21:47] <marcoceppi> well, the bootstrap of the reactive framework
[21:48] <x58> Ah, got it.
[21:48] <marcoceppi> apt layer is really a more flexible encapsulation of things you acn do with apt: custom repositories/keys, queuing packages dynamicaly, and loads of states
[21:49] <bac> marcoceppi: https://pastebin.canonical.com/164232/
[21:50] <bac> marcoceppi: i need to step out.  ping me here if you find something otherwise i'll keep poking at it later.
[21:52] <marcoceppi> cory_fu: I'm getting this error too ^^
[21:54] <marcoceppi> bac: it appears layer-apt doesn't include a layer.yaml in it
[21:54] <marcoceppi> so this error is "right" and is likely because Makyo has an older version of charm-tools where the checks fail? I'll open a patch for layer-apt
[21:57] <cory_fu> marcoceppi: That error message implies to me that the charm being built is trying to set layer options for the apt layer, and it doesn't define any.  I think it would be ok for it to not have a layer.yaml and the error is actually in the charm
[21:58] <marcoceppi> cory_fu: but layer-apt does support an option
[21:58] <marcoceppi> it's just not defined
[21:58] <marcoceppi> and it seems 2.1.4 of charm-tools starts checking that
[21:58] <cory_fu> Ah.  It should have failed prior to that anyway due to there being no schema to validate it against, but I guess it was lenient
[21:59] <marcoceppi> cory_fu: is this commit maybe the one that fixes that: https://github.com/juju/charm-tools/commit/f651e144fe24879a0470c8e49ab792a9321e6b4b ?
[22:00] <cory_fu> Doesn't seem like it
[22:01] <cory_fu> marcoceppi: https://github.com/juju/charm-tools/commit/134e860d3b717f821ade4765d95e0bf38ecc1e1e
[22:01] <cory_fu> That seems like it would have been in a previous version
[22:01] <marcoceppi> but that's from april 4th
[22:01] <marcoceppi> yeah
[22:01] <cory_fu> Well, it clearly was the intended behavior that it be validated
[22:02] <cory_fu> Perhaps the error message could be better
[22:02] <marcoceppi> hah
[22:06] <marcoceppi> stub: bac: this is what you'll need to address this: https://code.launchpad.net/~marcoceppi/layer-apt/+git/layer-apt/+merge/304308
[22:16] <bdx> I think I just found a bug in the pgsql interface
[22:18] <bdx> take this charm code for example, which requests two different databases using each their own interface -> https://gist.github.com/jamesbeedy/b02c701df4e34132ea622f78cb30df43
[22:20] <bdx> what seems to be happining here is when the second database is requested, a new password is generated for the user 'juju_feed', but this changes the password for the user globally
[22:22] <bdx> this is my application.yml file that is rendered with the configs cached in the kv from each respective database connection
[22:23] <bdx> http://paste.ubuntu.com/23109426/
[22:23]  * marcoceppi takes a look
[22:23] <bdx> whats interesting here, is that only the password generated for the second database works on both
[22:23] <bdx> :-(
[22:25] <bdx> logging into feeddb with feeddb password  -> http://paste.ubuntu.com/23109431/
[22:25] <marcoceppi> bac: this looks like a bug in the postgresql charm
[22:25] <marcoceppi> bdx: ^^
[22:25] <marcoceppi> I imagine it's not checking if the user it created already exists
[22:25] <marcoceppi> and it just recreating it with a new password :\
[22:25] <bdx> logging into feeddb with feedreportdb password -> http://paste.ubuntu.com/23109434/
[22:25] <bdx> totally
[22:26] <marcoceppi> bdx: stub is your best bet for working through a fix, but he's in APAC timezone
[22:26] <marcoceppi> bdx: let me see if I can get you a patched postgresql
[22:26] <bdx> marcoceppi: thanks
[22:31] <bdx> the charm *really* needs to create non-superusers that are owners of only their database
[22:31] <bdx> this would be HUGE
[22:32] <bdx> marcoceppi: I can just work with a temp modification to use the same user/password for both until this charm gets a little smarter
[22:33] <bdx> no need to spend cycles just for me
[22:33] <bdx> thanks though, you're such a gentleman
[22:35] <marcoceppi> bdx: well, either way, it'd be good to file a bug on this, stub is awesome about his charms
[22:36] <marcoceppi> bdx: https://bugs.launchpad.net/postgresql-charm
[22:37] <bdx> excellent, on it
[22:39] <x58> marcoceppi: is charm build broken with the apt layer at the moment? I can't see the pastebin from bac so I can't be sure if I am running into the same issue.
[22:39] <marcoceppi> x58: probably
[22:39] <marcoceppi> x58: you can patch the apt layer locally, or let me know the error so I can confirm
[22:39] <x58> AttributeError: 'NoneType' object has no attribute 'combine'
[22:40] <cholcombe> marcoceppi, now that my charm is promulgated how do i apply updates to that?  Does that go through review again?
[22:40] <marcoceppi> x58: that's something different
[22:40] <bac> x58: not what i see
[22:40] <x58> marcoceppi: http://paste.ofcode.org/zNTqD6xMCXFB5BucvsjAK6
[22:40] <lazyPower> cholcombe - yep, you should be able to push to the devel and unpublished channels
[22:40] <lazyPower> but stable becomes ours, and requires a review
[22:40] <cholcombe> lazyPower, i see
[22:40] <bac> marcoceppi: ah, so makyo must have a cached version of the apt layer?
[22:40] <lazyPower> by "ours" i mean, must be reviewed and curated.
[22:41] <marcoceppi> bdx: or an older version of charm-tools
[22:41] <marcoceppi> bac: ^^
[22:41] <cholcombe> lazyPower, did review.juju.solutions url change?
[22:41] <cholcombe> i'm getting 502
[22:41] <bac> marcoceppi: no, he has the same charm
[22:41] <marcoceppi> x58: can you run with -l DEBUG
[22:41] <marcoceppi> bac: charm-tools*
[22:41] <Makyo> marcoceppi: bac 2.1.2 for charmtools
[22:41] <marcoceppi> ?
[22:41] <marcoceppi> there we go
[22:41] <bac> ah
[22:41] <marcoceppi> Makyo: if you update it'll probably err for you
[22:41] <bac> sweet.  will play with it tomorrow
[22:41] <bac> Makyo: don't! it's a trap
[22:42] <x58> marcoceppi: http://paste.ofcode.org/CXjMC8QivjDMHR8RVGemVs
[22:42] <marcoceppi> x58: and finally, can you tell me the output of `charm version` ?
[22:42] <x58> charm 2.1.1-0ubuntu1
[22:42] <x58> charm-tools 2.1.2
[22:43] <marcoceppi> x58: we just released 2.1.2, it's in ppa:juju/stable ; let me see if this was a bug fixed in that release, I don't think it was though
[22:43] <marcoceppi> we just released 2.1.4**
[22:44] <x58> I'm following juju/devel ... is that wrong?
[22:45] <marcoceppi> x58: no, but you can add juju/stable in additon to devel. Devel version of charm-tools is, comically, out of date since 2.1 went stable
[22:45] <marcoceppi> I dont' see anything in 2.1 that would address this, is your SNMP layer somewhere I could poke it?
[22:46] <x58> Not yet. Still developing it. I will get it up on Gitlab in a minute. Give me a couple.
[22:48] <marcoceppi> x58: cool, thanks. I'll be helpful to poke it, hopefully I can patch charm-tools quickly if it is indeed a bug
[22:49] <x58> marcoceppi: https://gitlab.com/bertjwregeer/juju_snmpd/tree/master
[22:49] <x58> I don't think I did anything out of the ordinary...
[22:50] <marcoceppi> x58: yeah, I hit the error to on 2.1.4, <insert canned you should still upgrade message>, but I'll see if I can hunt down the reason for this error
[22:51] <marcoceppi> x58: is there a reason you ignore the readme?
[22:52] <x58> marcoceppi: I use a .rst README
[22:52] <x58> not .MD
[22:53] <x58> so I would end up with README.rst and README.md
[22:53] <x58> which caused issues when rendering on the charmstore.
[22:53] <marcoceppi> x58: that's a good reason, could you just delete README.md ?
[22:53] <marcoceppi> bleh
[22:53] <marcoceppi> of course
[22:53] <x58> No, because charm build would pull it back in from the basic layer.
[22:54] <marcoceppi> x58: I understand now, so that ignore line seems to be causing the problems, let me see why. I know we had a few fixes around ignore and exclude
[22:54] <x58> Nevermind the fact that .rst rendering on the charmstore is currently broken (yes, I have a bug open for it)
[22:54] <x58> marcoceppi: Works fine for: https://gitlab.com/bertjwregeer/juju_staticroutes
[22:54] <x58> Which doesn't have the layer:apt in it though (only the basic layer)
[22:55] <marcoceppi> x58: ingore is getting overhauled in charm-tools 2.2, fwiw.
[22:56] <marcoceppi> what you really want is exclude
[22:56] <x58> I used ignore because exclude is what I tried first but that didn't exclude.
[22:56] <marcoceppi> as in "exclude this file from the final charm" and ignore is more for "don't include this file from my layer"
[22:56] <x58> Also, the documentation is severely lacking in that area :-/
[22:56] <marcoceppi> x58: exclude doesn't exist (yet)
[22:56] <marcoceppi> which is why it didnt' work
[22:56] <x58> I saw exmaples using "exclude"
[22:57] <marcoceppi> also, yeah, that's my bad. I've nto been super strict on documentation
[22:57] <x58> That makes sense. lol.
[22:57] <marcoceppi> x58: you on xenial?
[22:57] <x58> Yes.
[22:57] <marcoceppi> x58: so, this https://github.com/juju/charm-tools/pull/235 is in master which will be in 2.2 of charm-tools
[22:58] <marcoceppi> and I think it address your problems with exclude, which was the right idea
[22:58] <marcoceppi> actually, I had that reversed
[22:58] <marcoceppi> ignore is the right key, it's just not really working well in 2.1
[22:59] <bdx> marcoceppi, bac: https://bugs.launchpad.net/postgresql-charm/+bug/1618248
[22:59] <x58> This is the second charm that I am writing, and documentation is all over the place. I like the reactive framework, but documentation is hit or miss, mostly miss.
[22:59] <x58> The charmhelpers stuff is also inadequately documented, and I've spent an awful lot of time looking at source code to try and reverse engineer why something works the way it does.
[23:00] <bdx> oh, you prob can't see that huh
[23:00] <marcoceppi> x58: even using https://pythonhosted.org/charmhelpers ?
[23:01] <x58> Yes.
[23:01] <marcoceppi> x58: I apprecaite the feedback, our documentation is definitely lacking in a lot of areas, I'm sure there are numerous examples but if you had time (after all this charm build stuff) to just highlight a few examples we're eager to fix
[23:01] <x58> Sure. I can put some stuff together.
[23:02] <marcoceppi> x58: so this is defininitely a bug, and I think it's because there's no layer.yaml in apt which is making the build tactic choke
[23:02] <marcoceppi> x58: I'll file a bug and see if I can get a patch up for review
[23:03] <x58> marcoceppi: Thanks. Is there a temporary fix I can use in the mean time to get this charm build completed?
[23:03] <x58> Should I remove the ignore?
[23:03] <marcoceppi> x58: comment out the ignore then manually remote the .md for now, sadly, is the quickest workaround
[23:03] <x58> It'll get me where I need to be for now.
[23:04] <x58> Which is a charm I can start testing ;-)
[23:04] <x58> I can worry about publishing later.
[23:04] <marcoceppi> x58: are you going to the charmer summit in Sept?
[23:04] <x58> Nope.
[23:09] <x58> I wish. I only write charms to get my work completed :P
[23:09] <x58> And they are probably not even that great... Just the bare minimum to support my requirements.
[23:18] <bdx> x58: thats how it all starts ;-)
[23:20] <x58> bdx: haha =)
[23:20] <marcoceppi> x58: here's the bug for your particular build issue https://github.com/juju/charm-tools/issues/251
[23:22] <x58> Awesome +1. Will watch it later.
[23:22] <x58> Not logged into Github on my work machine.