[13:36] <icezimm> hi guys, I'm trying to install openstack using autopilot and when juju is going to install landscape server, I'm with a lot of messages like this 'machine-0: 2015-12-14 13:25:12 WARNING juju.state allwatcher.go:355 getting a private address for unit "landscape-server/0" failed: "private no address"', for private and public address.. if someone could point me on the direction of fixing this, I do really appreciate, thank you :)
[13:38] <icezimm> sorry about using guys, hello everybody :)
[13:39] <lazypower> icezimm: which version of Juju? 1.25 i assume?
[13:48] <jamespage> gnuoy`, I think logging options could push down into the base layer
[13:48] <jamespage> they are common across principle and subordinate charms I think
[13:49] <gnuoy`> ack
[13:54] <icezimm> lazypower: exactly, 1.25.0-wily-amd64
[13:58] <lazypower> icezimm: interesting, when you provision a node with maas/juju - do you see the same error output that it's unable to find the public/private addressing of the unit? or is it only that one node in maas?
[14:04] <icezimm> lazypower: don't know exactly, I'm really new to this… I'm following the instructions here: http://www.ubuntu.com/download/cloud/install-openstack-with-autopilot
[14:04] <lazypower> icezimm: try destroying the juju environment `juju destroy-environment maas` and then stand it backup with `juju bootstrap` and try `juju deploy ubuntu`
[14:05] <lazypower> icezimm: once you've done juju deploy ubuntu, tail the logs while the unit provisions - `juju debug-log`
[14:05] <lazypower> icezimm: i'm also making the assumption you've got nothing else in the environment, so you're free to nuke whats there and start from scratch
[14:06] <icezimm> lazypower: I have this config.yaml and running the command on install.sh https://gist.github.com/fernandes/e055827d8ef8c9715a54
[14:06] <icezimm> sure, I'm using these machines as tests… can nuke without any problem
[14:07] <icezimm> ERROR cannot read environment info: environment "maas" not found
[14:08] <icezimm> ~/.cloud-install/juju/environments/ is empty
[14:09] <icezimm> export JUJU_HOME=~/.cloud-install/juju
[14:09] <icezimm> and now its bootstrapping
[14:16] <icezimm> after bootstrap
[14:16] <icezimm> Bootstrap agent installed
[14:16] <icezimm> WARNING expected one instance, got 2
[14:16] <icezimm> Waiting for API to become available
[14:16] <icezimm> Bootstrap complete
[14:16] <icezimm> just this warning, but bootstrap ok
[14:17] <lazypower> icezimm: so far so good
[14:17] <icezimm> I'm watching the juju/all-machines.log
[14:18] <icezimm> lazypower: https://gist.github.com/fernandes/e055827d8ef8c9715a54#file-all-machines-log
[14:18] <icezimm> in case can help debugging something
[14:19] <icezimm> but juju status show as agent started...
[14:20] <icezimm> juju debug-log is the same as ssh logging on all machine and concatenate juju/all-machines.log ?
[14:20] <lazypower> yep
[14:20] <icezimm> good to know :)
[14:20] <lazypower> you can also pass filters to juju debug-log with -i and -x so you can target specific machines
[14:20] <icezimm> Added charm "cs:wily/ubuntu-1" to the environment.
[14:20] <icezimm> great!
[14:20] <icezimm> heheh
[14:21] <icezimm> seems juju deploy ubuntu acquired a new machine from my maas ppol
[14:21] <icezimm> *pool
[14:33] <jamespage> gnuoy`, https://code.launchpad.net/~james-page/charm-helpers/mitaka/+merge/280449
[14:35] <gnuoy`> jamespage, +1
[14:52] <icezimm> lazypower: ubuntu seems it was deployed
[14:52] <lazypower> icezimm: no errors in the log? Also, did maas chose the same node? :)
[14:53] <lazypower> *same node as you were trying to provision for landscape
[14:53] <icezimm> hummm actually no
[14:53] <icezimm> sudo openstack-install --openstack-release liberty --edit-placement --headless --debug --series wily -c config.yaml was booting machine 1
[14:53] <icezimm> bootstrapping juju
[14:53] <icezimm> and then deploying services as containers
[14:54] <icezimm> now juju deploy ubuntu got a new bare metal machine and installed on it
[14:54] <icezimm> not as a container
[15:04] <Prabakaran> Hi kwmonroe, Good Morning... How to have a check for the value getting from the config.yaml file in the decorated pattern. Like i am facing a scenario wherein i will have to get EULA value from the user as True or False. If EULA value which I am getting it from config.yaml file is true i will have to install IBM java SDK else it will uninstall the product. So I have used something like that, it was not working. Can you please suggest
[15:04] <Prabakaran> this?
[15:04] <Prabakaran> javasdk_license_accepted=`config-get accept-ibm-javasdk-license` @when 'java.connected' 'java.installed' '$javasdk_license_accepted== 'False'
[15:04] <Prabakaran> javasdk_license_accepted=`config-get accept-ibm-javasdk-license` @when 'java.connected' 'java.installed' '$javasdk_license_accepted== 'False'
[15:05] <mbruzek> Hello Prabakaran.  The decorator does not work on configuration options.  cory_fu correct me if I am wrong.
[15:06] <mbruzek> Prabakaran: What I have done is create a method that will be called on "config-changed" such as:
[15:06] <mbruzek> @hook('config-changed')
[15:06] <mbruzek> def config():
[15:07] <mbruzek> Prabakaran: Then you can check the configuration for accept-ibm-javasdk-license and set a state that your charm could react to.
[15:08] <mbruzek>     accepted = hook.config().get('accept-ibm-javasdk-license')
[15:08] <mbruzek>    
[15:08] <mbruzek> Now if accepted is true you can set_state("license.accepted')
[15:08] <mbruzek> And other methods could use:
[15:08] <mbruzek> @when('license.accepted')
[15:09] <mbruzek> but kwmonroe may have more experience with this so I defer to him
[15:09] <mbruzek> Prabakaran: Does that make sense?  Do you have any questions?
[15:11] <Prabakaran> mbruzek , @when('license.accepted') here how to get this license.accepted value from config.yaml file?
[15:11] <mbruzek> Prabakaran: Are you using python or bash?
[15:12] <Prabakaran> here i think we have to change ...accepted = hook.config().get('accept-ibm-javasdk-license')
[15:12] <Prabakaran> bash
[15:12] <mbruzek> Prabakaran: Oh OK. I gave you an example in bash
[15:12] <mbruzek> I mean python
[15:13] <mbruzek> OK so you already listed how to get the value from the config.
[15:13] <mbruzek> javasdk_license_accepted=`config-get accept-ibm-javasdk-license`
[15:13] <Prabakaran> s
[15:14] <mbruzek> I don't think you can not use that variable in a @when clause though,  cory_fu would know for sure.
[15:14] <mbruzek> Prabakaran: so you would need to create a hook for config-changed, read the value and then you can set a reactive state when the value is true or set a different state when false.
[15:15] <mbruzek> Prabakaran: then your methods could react to that state
[15:16] <mbruzek> if [ $javasdk_license_accepted == "True" ]; then
[15:16] <mbruzek>   set_state 'license.accepted'
[15:16] <mbruzek> else:
[15:16] <mbruzek>   set_state 'license.not.accepted'
[15:16] <mbruzek> fi
[15:16] <mbruzek> Something like that.  I have not tested that code.
[15:17] <mbruzek> after you set the state then you can use that state in a @when or @when_not clause
[15:17] <Prabakaran> k let test this
[15:17] <Prabakaran> k thanks...
[15:17] <mbruzek> Prabakaran: but do that confg-get in the "config-changed" hook
[15:17] <Prabakaran> let me test it and come back
[15:17] <mbruzek> OK
[15:17] <lazypower> mbruzek: no your suggestions are correct. ou cannot use a @when decorator with config, you would  instead check on the hook contest for config-changed, and set/remote a state depending on the value of the config option.
[15:17] <lazypower> *context
[15:20] <Prabakaran> before i have implemented something like that.. but while testing when i set EULA value to true it was installing but again i set EULA value to false it was not uninstalling...http://paste.ubuntu.com/14005951/
[15:20] <Prabakaran> i think i should not have a check for EULA in this http://paste.ubuntu.com/14005951/
[15:21] <lazypower> Prabakaran: you need to have a decorated method to uninstall when the value is false
[15:21] <lazypower> Prabakaran: @when_not('license.accepted') def uninstall_ibm_jdk(): # uninstall the jdk
 is it in python? or bash?
[15:22] <Prabakaran> because i am writing in bash
[15:22] <lazypower> Prabakaran: the example i just gave was python, but its very similar for bash
[15:23] <marcoceppi> aisrael: siege, cassandra-stress, monogdb, pts, mysql-benchmark - am I missing any?
[15:23] <mbruzek> Prabakaran: you still need to check configuration parameters in config-changed that is the ONLY hook that is run when configuration changes.
[15:24] <mbruzek> kwmonroe: feel free to chime in here with some JDK knowledge
[15:26] <Prabakaran> k <lazypower> and <mbruzek> .. Thank you so much for this suggessions and explainations..let me implement and test my charm and come back to you if i have any doubts
[15:26] <mbruzek> Prabakaran: happy to help
[15:26] <Prabakaran> lol
[15:26] <mbruzek> Prabakaran: I understand the reactive stuff is new, but it is very powerful
[15:27] <mbruzek> Prabakaran: I have written charms much faster and they are much smaller because I only react to the states that this layer needs
[15:27] <mbruzek> Prabakaran: I hope you find the same benefit
[15:28] <Prabakaran> i want to read more about this ..can i have any links for the same?
[15:29] <Prabakaran> i googled i have got some links but if u feel something good that can be shared to me ..
[15:34] <icezimm> lazypower: was supposed to deploy on a container? or should I try to deploy openstack?
[15:34] <Prabakaran> I am back again with one question .. using charm build command i have generated deployable charm which contains config changed hook in python.. can u please help me in writing code to have a check for EULA ..http://paste.ubuntu.com/14006238/
[15:35] <lazypower> icezimm: i would deploy landscape to a physical unit, and use that to stand up openstack w/ autopilot
[15:35] <lazypower> icezimm: but admittedly, i have no experience with our openstack installer you were using
[15:36] <lazypower> icezimm: disclaimer - i work in the eco, and i haven't touched every nook and cranny of the openstack suite we have :)
[15:37] <icezimm> lazypower: eco you mean? heheh
[15:37] <icezimm> no problem, thanks for the help, not I know (at least) juju is being bootstrapped correctly
[15:40] <lazypower> icezimm: ah, im a juju charmer, and i work in the broader ecosystem. I've got some experience with openstack - but mostly i look at workload charms. App Container focused charms as it were.
[15:41] <icezimm> hummm interesting hehehe
[15:41] <icezimm> so a juju question hehehe
[15:41] <icezimm> landscape exists only for trusty
[15:41] <icezimm> no way to run on wily?
[15:41] <icezimm> I mean, deploy
[15:41] <marcoceppi> icezimm: there is a way, but it's not the prettiest
[15:42] <icezimm> cool
[15:42] <icezimm> because I'm asking openstack installer to use series wily
[15:42] <marcoceppi> icezimm: you need to download the charm to your machine, and use deploy local:
[15:42] <marcoceppi> icezimm: ah, from the openstack installer I don't know/think so
[15:42] <icezimm> and I think it's trying to deploy landscape-server to wily
[15:45] <icezimm> let me force series trusty
[15:52] <cory_fu> mbruzek: Sorry I'm late to the discussion, but I think what you suggested was correct.
[15:53] <cory_fu> kjackal: So, you were asking about https://github.com/juju-solutions/charms.reactive/blob/master/charms/reactive/relations.py#L498 and why remove_state calls set_state...
[15:53] <cory_fu> kwmonroe, admcleod1: ^ in case you're interested
[15:54] <cory_fu> kjackal: So, the answer is that it's because a state can be set for multiple conversations.  You'll notice that there's a "conversations" list in the state value.  That holds all the conversations that the state applies to, not just this one.  So remove_state removes the current conversation from the list, and either updates the state with the new, shorter list, or removes it if it was the only one in the list to start with
[15:55] <cory_fu> So, that really should be "update_state"
[15:55] <cory_fu> But set and update are the same thing in this case.
[15:56] <kjackal> let me digest this
[15:57] <gnuoy`> jamespage, two new layers as discussed http://paste.ubuntu.com/14006647/
[16:00] <kjackal> cory_fu: So in my case the fact the state in not removed is because it was added actually two times, while it gets removed once?
[16:00] <cory_fu> kjackal: Correct.  Which is what the fix in https://github.com/juju-solutions/charms.reactive/pull/41 is intended to rectify
[16:00] <cory_fu> kjackal: The "conversations" list was originally a set() object but then I found out that doesn't serialize properly.  :/
[16:01] <kjackal> I see, that makes sense, because i see the state value increasing instead of decreasing
[16:01] <kjackal> cool
[16:52] <lazypower> cory_fu: i filed a bug against what i pinged about re: charms.reactive all_states here: https://github.com/juju-solutions/charms.reactive/issues/42
[17:19] <jamespage> gnuoy`, took a run through those layers - did a few tweaks and tidied a bit
[17:19] <jamespage> specifically
[17:19] <jamespage> base_charm -> charm
[17:19] <jamespage> dropped tox and test-requirements from higher layer charms
[17:19] <jamespage> added metadata.yaml to openstack-api layer so inheriting charms don't have todo interfaces for db, messaging and identity.
[17:19] <jamespage> pushed all that back to the repos...
[17:22] <beisner> jamespage, mp for review @ https://code.launchpad.net/~1chb1n/charm-helpers/os-amulet-test-mitaka/+merge/280480
[17:35] <cfx> mbruzek: ha, looks like I'm not the only one irrationally resistant to layers (but I'm coming around)
[18:32] <bdx> marcoceppi, coreycb: hey whats going on? I am trying to add a wheel to the wheelhouse and have it install alongside the other default wheels in the wheelhouse on bootstrap of the charm.
[18:33] <bdx> marcoceppi, coreycb: Is this an reccomended best practice for installing python packages inside the context of the charm?
[18:35] <bdx> marcoceppi, coreycb: I also see the charmhelpers function from charmhelpers.contrib.python.packages import pip_install
[18:36] <cory_fu> lazypower: Replied to your ticket.  I can't reproduce.  :(
[18:36] <bdx> marcoceppi, coreycb: I have had no luck using either method.........might you bestow upon me the knowledge needed to make this happen?
[18:37] <marcoceppi> bdx: what version of charm-tools do you have? `charm version` ?
[18:37] <bdx> charm-tools 1.10.1
[18:39] <bdx> marcoceppi:^
[18:39] <marcoceppi> bdx: how are you adding the wheel?
[18:40] <bdx> marcoceppi: git clone https://github.com/locustio/locust.git, cd locust, python setup.py sdist
[18:40] <marcoceppi> bdx: okay, normally wheelhouses are included by defining them in a wheelhouse.txt file
[18:41] <bdx> marcoceppi: cp dist/locustio-0.7.3.tar.gz charmdir/wheelhouse/
[18:41] <bdx> ok
[18:41] <marcoceppi> cory_fu: would have better guidance, not sure if that works, but I suppose it should
[18:43] <bdx> marcoceppi: Is there yet a standardized "best" way to install python packages from pip?
[18:44] <bdx> cory_fu, coreycb:^
[18:44] <cory_fu> bdx, marcoceppi: Yeah, I would recommend adding the requirement line to wheelhouse.txt (you can point it at a git URL just fine) and let the build process manage it for you.  You *could* manually put the file into the wheelhouse but you'd want to make sure it was not platform specific.  We don't actually use wheels because of this, and instead just include source .tar.gz files
[18:44] <marcoceppi> bdx: define them in the wheelhouse.txt https://github.com/juju-solutions/reactive-base-layer/blob/master/wheelhouse.txt
[18:45] <cory_fu> And to use a git URL, the format is: -e git+https://github.com/locustio/locust.git#egg=locust
[18:45] <cory_fu> (The -e, git+, and #egg=<foo> are all important)
[18:46] <cory_fu> You can also include @branch or @sha right before the #egg to use a specific branch or commit
[18:46] <bdx> cory_fu: awesome....it seems some pip packages (locust) have a requirement on python-dev ..... how would this be handled, if at all using wheelhouse?
[18:47] <bdx> python packages*
[18:48] <bdx> errrrr^, how are system level level deps handled* ?
[18:48] <cory_fu> bdx: Currently, it installs pip with all the recommended packages, so it pulls in python3-dev as well.  There was some discussion about making that a layer option so that charms that don't use Python libs with compiled bits could install faster
[18:48] <lazypower> cory_fu: ugh :\
[18:49] <cory_fu> bdx: What other system-level deps do you mean?
[18:49] <bdx> lazypower, cory_fu, marcoceppi: locust for example only supports python2.7
[18:50] <bdx> and requires python-dev as a system level deb
[18:50] <bdx> dep
[18:50] <cory_fu> lazypower: TBH, I don't see how that could possibly happen.  all_states doesn't modify anything at all, it just calls get_states and makes an assertion about the result.  :/
[18:50] <marcoceppi> bdx: is locust required for your hooks to run?
[18:50] <marcoceppi> or is it part of the software you're installing?
[18:51] <bdx> marcoceppi: it is the primary software pkg I am *trying* to get installed
[18:51] <cory_fu> Yeah, what marcoceppi is getting at is that the wheelhouse is only intended for *charm* deps.  i.e., libraries that are required for your charm code to run, not the the thing it's deploying
[18:51] <cory_fu> bdx: You shouldn't use the wheelhouse for that, then.
[18:51] <lazypower> ^
[18:51] <marcoceppi> bdx: in your install decorator, just do subprocess.check_call(['pip', 'install', 'whatever']) Or, git clone/installing
[18:52] <bdx> lazypower, cory_fu, marcoceppi: ok, thats what I was thinking....but it needs python2
[18:52] <bdx> *python2.7*
[18:52] <cory_fu> bdx: I'd recommend using charmhelpers.fetch.apt_install
[18:52] <marcoceppi> bdx: yes, pip is python2, pip3 is python3, you can use the charmhelpers.fetch.apt_install to install python-dev
[18:53] <lazypower> marcoceppi: does that change w/ xenial?
[18:53] <bdx> cory_fu, marcoceppi: got it, but then I can't install the python2 pkg
[18:53] <bdx> no matter what
[18:53] <lazypower> as in, will pip be python3 pip, or is it still py2 pip (which... is no longer a thing i hear?)
[18:53] <marcoceppi> lazypower: no idea
[18:53] <bdx> even if I ssh into the box and install from the box
[18:53] <cory_fu> apt_install(['python-dev', 'python-pip'])
[18:53] <cory_fu> subprocess.check_call(['pip2', 'install', 'locustio'])
[18:53] <marcoceppi> lazypower: python2 is still athing
[18:53] <lazypower> ok i'll mak eit a point to find out
[18:53] <marcoceppi> lazypower: it's just not installed by default
[18:54] <marcoceppi> there's a difference :)
[18:54] <lazypower> i was inferring from stubs comments about py2 deprecation on a system level that we're headed for heartache in xenial
[18:54] <cory_fu> lazypower, marcoceppi: You can always be explicit and use pip2
[18:54] <lazypower> i may have mis-read into it
[18:54] <marcoceppi> yesh
[18:55] <cory_fu> bdx: What do you mean you can't install the python2 package?
[18:55] <bdx> using from charmhelpers.contrib.python.packages import pip_install
[18:55] <bdx> or just in the terminal
[18:55] <bdx> when ssh'd into the box
[18:56] <bdx> cory_fu: although, I was running "pip install", not "pip2 install" ..... should "pip2" be the answer then?
[18:56] <cory_fu> bdx: I don't understand why you think that wouldn't work?
[18:56] <cory_fu> bdx: I'm pretty sure that even with python3 installed, "pip" is still the same as "pip2"
[18:56] <bdx> cory_fu: let me recreate, and grab you some hard data on this.
[18:57] <cory_fu> But being explicit isn't a bad thing, either
[19:06] <bdx> cory_fu, marcoceppi, lazypower: so whats up with "from charmhelpers.contrib.python.packages import pip_install" this only works for python3/pip3 pkgs?
[19:06] <marcoceppi> bdx: hooks run as python3, so probably
[19:08] <bdx> marcoceppi: how to you feel about modifying the pip_install function to take an optional bool arg for pip2?
[19:08] <marcoceppi> bdx: sounds fine
[19:09] <bdx> marcoceppi, cory_fu, lazypower: It doesn't look like pip2 is a thing .....
[19:10] <cory_fu> bdx: Your reality does not seem to be the same as mine: http://pastebin.ubuntu.com/14011024/  :)
[19:10] <bdx> crazy
[19:11] <cory_fu> Also, it looks like pip_install only uses subprocess if it's creating a venv, for some reason.  It should just always use subprocess: https://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/python/packages.py#L67
[19:11] <bdx> cory_fu: my bad...didn't have python-pip as a dep
[19:11] <cory_fu> bdx: That'll do it.  :)
[19:12] <bdx> marcoceppi, cory_fu, lazypower: I think I'm g2g now. Thank you all!!
[19:12] <cory_fu> bdx: Glad to help!
[20:19] <bdx> cory_fu, marcoceppi, lazypower: Is charmbenchmark the best way to get stdout from an action?
[20:20] <bdx> cory_fu, marcoceppi, lazypower: Also, if charmbenchmark is used, should it then be added to the wheelhouse?
[20:20] <marcoceppi> bdx: charmbenchmark is a depricated library
[20:20] <marcoceppi> bdx: charms.benchmark is the new library
[20:20] <marcoceppi> bdx: but it doesn't get stdout from an action, it uses action-get and action-set to send and recieve action data
[20:21] <marcoceppi> bdx: it's meant as an easy wrapper for benchmark actions
[20:21] <marcoceppi> bdx: charmhelpers.core.hookenv has an action_get, action_set, and action_fail method
[20:22] <bdx> marcoceppi: gotcha, I see that.... I'm trying to return a few values to the user after the action is ran, what is the way in which I should go about this?
[20:22] <marcoceppi> bdx: action_set('key', value)
[20:24] <bdx> marcoceppi: but action_set and action_get must be called from the action.....right?
[20:24] <marcoceppi> bdx: yes
[20:25] <bdx> marcoceppi: How can I return values to the user executing the action?
[20:25] <marcoceppi> action_set
[20:26] <marcoceppi> bdx: action_get is used to recieve the parameters a use has set for the action, action_set returns data to the user from that action
[20:26] <marcoceppi> both can only be run from an action
[20:26] <bdx> marcoceppi: e.g.  I want my users to run "juju action do locust/0 run-tests --params params.yaml"
[20:27] <bdx> marcoceppi: following that command, I want to return a ip:port to the user
[20:27] <marcoceppi> okay, you have to use action_set to send the data, eg: action_set('address', ip:port)
[20:28] <bdx> marcoceppi: I get that....where does that send the data?
[20:28] <marcoceppi> bdx: the user has to run juju action fetch <UUID>, the UUID will be presented when they do juju action do
[20:29] <bdx> marcoceppi: ok, awesome, thats what I was looking for! Thank you
[20:29] <marcoceppi> bdx: sure, np!
[21:12] <Icey> how can I handle sharing functionality between reactive handlers and action handlers without resorting to weird hacky things like messing with the load path?
[21:12] <lazypower> Icey: path :cop: approves of this question ^
[21:13] <marcoceppi> cory_fu: ^?
[21:13] <cory_fu> Icey: There is an open issue (https://github.com/juju-solutions/charms.reactive/issues/11) related to this.  Currently, there is no built-in support for actions in charm-build nor in reactive.
[21:14] <cory_fu> I think that we should do it, but charm authors will need to be aware that *all* handlers whose conditions match will be run.  So if you don't guard properly, you could have actions doing things like restarting your service because you assume "hook run means something changed"
[21:14] <lazypower> cory_fu; wait so build doesn't merge actions.yaml?
[21:14] <lazypower> good to know. i had not considered that when building out my layers
[21:14] <cory_fu> lazypower: No, it doesn't.  :(
[21:15] <cory_fu> At least, I'm pretty certain it doesn't
[21:15] <Icey> I generally think that the actions should NOT share functionality with Hooks, but that Hooks and Actions should both call helper functions to handle their shared functionality ;-)
[21:15] <lazypower> that'll change at some point i'm willing to bet
[21:15] <marcoceppi> lazypower: that's more a charm-tools issue, but it's imporant
[21:15] <lazypower> marcoceppi: oh i agree, and i said 'build' :)
[21:15]  * marcoceppi misread
[21:16] <cory_fu> lazypower: We need an ActionYAML that is a trivial subclass of YAMLTactic in: https://github.com/juju/charm-tools/blob/master/charmtools/build/tactics.py#L622
[21:16] <marcoceppi> lazypower cory_fu: https://github.com/juju/charm-tools/issues/82
[21:16] <cory_fu> But if we want to have proper reactive support, it will also need to build the hooks out
[21:16] <lazypower> cory_fu: is that a prompt for me to get un lazy and go contribute?
[21:16] <lazypower> i can see merging the actions yaml and including w/e is in actions/*
[21:17] <lazypower> i'm undecided on if actions in reactive is a good thing
[21:17] <lazypower> i'm already generating a script that matches the definition in actions.yaml, i dont know that generating them with decorators really saves me anything other than creating the file
[21:17] <lazypower> it actually limits me in what my action is written in if i'm mixing bash and python actions
[21:18] <Icey> lazypower I'd like actions to be a lot like old school hooks
[21:18] <Icey> you can have bash scripts
[21:18] <lazypower> or maybe not even a script at all, maybe i stuff in a binary that ships w/ whatever service and convert the flags to options that it passes to the binary
[21:18] <Icey> you can have an actions.py with links
[21:18] <lazypower> or maybe i'm just pulling stuff out of the air now
[21:18] <marcoceppi> I think actions in reactive is the right way forward, tbh
[21:18] <marcoceppi> but I am in the minority
[21:19] <lazypower> marcoceppi: to you, whats the benefit of actions in reactive?
[21:19] <marcoceppi> lazypower: I think for now, just having it merge the yaml is enough
[21:19] <lazypower> i'm asking more for my education
[21:19] <lazypower> as i've noodled this topic for about, 40 seconds.
[21:19] <lazypower> clearly i'm an authority
[21:20] <marcoceppi> lazypower: one place to manage my code, the model is all reactive, and I can more easily assert and manage states in actions
[21:20] <lazypower> hmm
[21:20] <lazypower> thats fair
[21:20] <marcoceppi> lazypower: however
[21:20] <lazypower> @when('backup.is_complete')
[21:20] <marcoceppi> I think there's a middle ground
[21:20] <lazypower> actually
[21:20] <lazypower> whats stopping you from doing that today?
[21:20] <lazypower> you can call charms.reactive set_state backup.is_complete and still handle it on your next update-status run
[21:20] <marcoceppi> lazypower: actions are not hooks
[21:21] <marcoceppi> oh, sure, but I also have to mung paths
[21:21] <marcoceppi> the source tree isn't as clean
[21:21] <lazypower> path :cop: disapproves of path munging
[21:22] <marcoceppi> lazypower: I think the way forward is, if actions/<action_name> exists, leave be, otherwise auto-generate stub and assume it's reactive
[21:22] <Icey> +1 to that marcoceppi
[21:23] <marcoceppi> lazypower Icey however, the second half of that is a bit more complicated to produce, since it requires changes to the reactive framework
[21:23] <lazypower> that makes sense
[21:24] <cory_fu> marcoceppi: Eh, not much.  Mostly just adding an @action decorator.  I don't think it needs anything else?
[21:24] <marcoceppi> cory_fu: okay, maybe it's not hard
[21:24] <lazypower> and yeah i'm 100% for getting the yaml merge first, hten tackling the reactive bits in tandem wl/ the generator(s)
[21:24]  * marcoceppi was just guessing
[21:24] <cory_fu> And you could probably use @hook in the meantime
[21:24] <Icey> can I access config inside of an action?
[21:24] <marcoceppi> Icey: you should be able to
[21:24] <lazypower> its an anonymous hook context, so sure
[21:24] <Icey> :)
[21:24] <marcoceppi> cory_fu: depends on how "hook name" is determined
[21:25] <cory_fu> marcoceppi: It uses $0
[21:25] <marcoceppi> oh, cool
[21:25] <cory_fu> Technically, it looks for $JUJU_HOOK_NAME and falls back to $0, but JUJU_HOOK_NAME is only set in debug-hooks
[21:25] <cory_fu> And presumably wouldn't be set for an action even during debug-hooks
[21:26] <marcoceppi> nope
[21:26] <cory_fu> So @hook should really Just Work, but we need to have an alias so that it's clear that it's intended for actions
[21:26]  * marcoceppi acks
[21:26] <marcoceppi> Maybe I'll take a stab at that over the holidays
[21:27] <cory_fu> marcoceppi: If you merge https://github.com/juju/charm-tools/pull/75 it should be pretty trivial
[21:29] <marcoceppi> cory_fu: merged, this also has conflicts now https://github.com/juju/charm-tools/pull/68
[21:29] <cory_fu> marcoceppi: Well, I guess it'd need a little refactoring; the DynamicHookBind class would need a prefix option that could be overridden to switch "hooks" for "actions"
[21:29] <marcoceppi> cory_fu: I'll be looking to release 1.11.0 this week
[21:29] <cory_fu> Nice
[21:29] <lazypower> marcoceppi: movin right along man! we've got a nice rel cadence going with c-tools
[21:30] <lazypower> hattip @ you and the contributors
[21:30] <marcoceppi> lazypower: the day releases slow down, is the day cory_fu stops making charm build better ;)
[21:31] <lazypower> cory_fu: i will bribe you with as much pizza as you can carry
[21:31] <lazypower> cory_fu: and scotch
[21:31] <cory_fu> marcoceppi: Resolved
[21:35] <cory_fu> marcoceppi: So yeah, if you want to take a stab at adding generated actions now, just look at how it's done now for StorageBind.  You'll need a new subclass of DynamicHookBind and a similar method in build/__init__.py:Builder.plan_{interfaces,storage,actions} (maybe those could be refactored)
[21:35] <marcoceppi> cool
[21:36] <cory_fu> As I said before, DynamicHookBind will need to override the dir prefix, and the HOOKS list for ActionsBind would just be ['{}']
[21:36] <cory_fu> (i.e., use the action name as the file name, no suffix)
[22:34] <cholcombe> i have a juju action parameter that needs to be any type.  Can i just use type: object for that?
[23:28] <marcoceppi> cholcombe: why not string?