*** iceyao has joined #ara | 00:20 | |
*** iceyao has quit IRC | 00:25 | |
*** iceyao has joined #ara | 00:41 | |
*** iceyao has quit IRC | 00:46 | |
*** cuongnv has joined #ara | 00:48 | |
*** iceyao has joined #ara | 01:02 | |
*** iceyao has quit IRC | 01:06 | |
*** iceyao has joined #ara | 01:22 | |
*** cuongnv_ has joined #ara | 01:37 | |
*** cuongnv has quit IRC | 01:39 | |
*** iceyao has quit IRC | 02:02 | |
*** iceyao has joined #ara | 02:03 | |
*** cuongnv_ is now known as cuongnv | 02:12 | |
*** iceyao has quit IRC | 03:53 | |
*** iceyao has joined #ara | 04:15 | |
*** iceyao has quit IRC | 04:20 | |
*** iceyao has joined #ara | 04:33 | |
*** iceyao has quit IRC | 04:38 | |
*** iceyao has joined #ara | 04:42 | |
*** iceyao has quit IRC | 05:39 | |
*** iceyao has joined #ara | 05:58 | |
*** iceyao has quit IRC | 06:02 | |
*** iceyao has joined #ara | 06:09 | |
*** iceyao has quit IRC | 06:13 | |
*** sshnaidm has quit IRC | 06:16 | |
*** iceyao has joined #ara | 06:36 | |
*** iceyao has quit IRC | 06:41 | |
*** sshnaidm has joined #ara | 07:19 | |
*** iceyao has joined #ara | 08:40 | |
*** iceyao has quit IRC | 10:08 | |
*** cuongnv has quit IRC | 10:14 | |
*** iceyao has joined #ara | 10:19 | |
*** iceyao has quit IRC | 10:23 | |
*** iceyao has joined #ara | 10:46 | |
*** iceyao has quit IRC | 10:50 | |
*** iceyao has joined #ara | 11:22 | |
*** sshnaidm has quit IRC | 12:44 | |
*** tbielawa has joined #ara | 12:53 | |
*** sshnaidm has joined #ara | 13:49 | |
*** jparrill has joined #ara | 13:53 | |
dmsimard | sshnaidm: forgot you were here, let's move here instead | 14:48 |
---|---|---|
dmsimard | so, to roll back discussion | 14:49 |
dmsimard | I feel like https://review.openstack.org/#/c/479882/2/roles/collect-logs/library/ara_graphite.py should be a good addition to ara upstream | 14:49 |
dmsimard | but I feel like it's better suited to have a callback implementation instead of a module so the data is fed to graphite in real-time and not at the end of the playbook in bulk | 14:50 |
sshnaidm | dmsimard, it's better to have it configurable | 14:50 |
dmsimard | We've had this idea of drivers in ARA where ara could collect data from other places (i.e if upstream zuul publishes ansible tasks to mqtt, ara could pick up messages from there instead of from the callback) | 14:50 |
dmsimard | sshnaidm: ara is configurable :) | 14:51 |
sshnaidm | dmsimard, yeah :) I mean now there is requirement to publish only when playbook finished successfully | 14:51 |
dmsimard | sshnaidm: ah, hrm | 14:52 |
dmsimard | I guess one does not exclude the other | 14:52 |
sshnaidm | dmsimard, so we can use either callback or final "publish all" | 14:52 |
dmsimard | we can have it both as a module and as a callback | 14:52 |
sshnaidm | dmsimard, yeah | 14:52 |
sshnaidm | dmsimard, I'm more concerned about mapping task names to graphite paths | 14:53 |
dmsimard | sshnaidm: that can end up being in ansible.cfg | 14:53 |
sshnaidm | dmsimard, as part of ara config? | 14:53 |
dmsimard | sshnaidm: yeah, ara can be configured inside ansible.cfg under the [ara] block | 14:54 |
dmsimard | sshnaidm: and fyi ansible 2.4 is moving from inifile format to yaml format | 14:54 |
dmsimard | for ansible.cfg | 14:54 |
sshnaidm | oh, nice | 14:55 |
sshnaidm | dmsimard, do you know how you are going to implement these publishers or you have any example..? | 14:56 |
dmsimard | sshnaidm: It's mostly just an idea for the time being. In practice, the current implementation would become a driver (sql) and there would be a module for each additional driver (graphite/elasticsearch/etc) | 15:00 |
dmsimard | sshnaidm: https://github.com/openstack/ara/blob/master/ara/plugins/callbacks/log_ara.py would be made generic and publish to the appropriate driver instead of being hardcoded to sql | 15:01 |
dmsimard | sshnaidm: so that people not interested in the web UI could not even publish to a sql database if they don't want to | 15:01 |
dmsimard | sshnaidm: basically ara would really become an ansible indexer, if you will | 15:09 |
sshnaidm | dmsimard, ok.. so for now I leave it as is, or you want me to integrate this anywhere..? | 15:11 |
dmsimard | sshnaidm: If this is blocking you from moving forward, feel free to carry it for the time being but let's consider that we'll need to move it eventually | 15:29 |
dmsimard | sshnaidm: does it add any requirements that are not in the standard library ? | 15:29 |
sshnaidm | dmsimard, no, everything in std | 15:31 |
*** tbielawa is now known as tbielawa|lunch | 15:57 | |
dmsimard | sshnaidm: left some comments in your review | 15:59 |
dmsimard | sshnaidm: up to you if you want to move it to ara right now or wait until later -- if we merge it, it would only be available in trunk/master until we cut a release | 15:59 |
dmsimard | It'd land in 0.14 which would not be for a while still | 16:00 |
dmsimard | 0.14 is bound to be the version that lands ansible 2.4 compatibility | 16:00 |
*** tbielawa|lunch has quit IRC | 16:22 | |
*** jparrill has quit IRC | 16:53 | |
*** iceyao has quit IRC | 17:03 | |
*** iceyao has joined #ara | 17:30 | |
*** iceyao has quit IRC | 17:34 | |
*** tbielawa has joined #ara | 18:02 | |
*** tbielawa is now known as tbielawa|covfefe | 18:03 | |
*** tbielawa|covfefe is now known as tbielawa | 18:28 | |
*** iceyao has joined #ara | 18:35 | |
*** iceyao has quit IRC | 18:39 | |
*** iceyao has joined #ara | 19:02 | |
*** iceyao has quit IRC | 19:06 | |
*** tbielawa is now known as tbielawa|VMs | 19:08 | |
*** tbielawa|VMs is now known as tbielawa | 19:22 | |
*** tbielawa is now known as tbielawa|tour | 19:41 | |
*** openstackgerrit has joined #ara | 19:49 | |
openstackgerrit | Jesse Pretorius (odyssey4me) proposed openstack/ara master: [WIP] Add subunit output support https://review.openstack.org/480716 | 19:49 |
*** tbielawa|tour has quit IRC | 20:11 | |
*** tbielawa has joined #ara | 20:11 | |
*** tbielawa has quit IRC | 20:32 | |
*** jparrill has joined #ara | 20:34 | |
*** iceyao has joined #ara | 21:48 | |
*** iceyao has quit IRC | 21:53 | |
harlowja | dmsimard whatever came with that output recording/capturing stuffs? | 21:55 |
dmsimard | harlowja: it was released in 0.13.2 I think | 21:55 |
harlowja | the idea was i guess to do `ara playbook list` then run a followup playbook to record data directly for that other playbook right | 21:59 |
harlowja | pretty sure that was the idear | 21:59 |
harlowja | dmsimard ^ ? | 22:02 |
harlowja | if so , is there anyway for me to force/specify/pick the uuid that will be used for initial recording (ie the playbook that will do the work) so that i can ensure that i attach the stdout to the right playbook in the db (which afaik is based on a uuid) | 22:04 |
dmsimard | harlowja: Yeah the uuid is currently generated. You can retrieve it at runtime by registering the output of an ara_record or ara_read task under playbook_id. | 22:07 |
harlowja | or an initial `ara create play` that will give me a uuid that i can then use later for all recording and running | 22:07 |
harlowja | right dmsimard that assumes say that i have one ansible thing happening at the same time | 22:07 |
harlowja | so wondering how i would figure out the uuid in a multi-process-ara/ansible usage | 22:08 |
dmsimard | harlowja: you run concurrent ansible-playbook ? | 22:08 |
harlowja | in theory, yes | 22:08 |
dmsimard | harlowja: I still haven't addressed that but it is a known issue :/ | 22:08 |
dmsimard | https://storyboard.openstack.org/#!/story/2000853 | 22:09 |
harlowja | ie, 'deploy glance staging' and 'deploy nova <somewhere-else>' seems like they should be concurrent (or at least possible so) | 22:09 |
dmsimard | harlowja: the concurrent use case and the clash of metadata for ara_record/ara_read is something I want to fix.. in the meantime, let me try and think | 22:10 |
harlowja | even a simple `ara init playbook record` that could be used later would work | 22:10 |
harlowja | ^ command would output a uuid to use | 22:10 |
dmsimard | harlowja: yeah but it's kind of an ugly workaround to solving the real problem | 22:11 |
dmsimard | not going to implement something like that | 22:11 |
harlowja | ya, depends on how ugly u want this to be, lol | 22:12 |
harlowja | some kind of way to tag playbooks would work also, so that i can at least find the tag later (when running the followup playbook) | 22:13 |
dmsimard | harlowja: well I mean the current real problem is that concurrent runs can clash, if this would be resolved you could accurately retrieve the uuid | 22:13 |
dmsimard | and there'd be no need for workarounds | 22:14 |
dmsimard | there's maybe an easy fix.. let me look | 22:14 |
* harlowja run one playbook at a time, lol | 22:14 | |
harlowja | with a lock | 22:14 |
harlowja | lol | 22:14 |
dmsimard | harlowja: it sucks because ansible doesn't have something like a seed, a hash or whatever could uniquely represent a run | 22:16 |
harlowja | (though i don't want to do that, especially if u have better idears) | 22:16 |
harlowja | ya, i mean, a 'ara_tag: <tags>' would work to | 22:16 |
harlowja | though still a pita | 22:16 |
harlowja | where the tags would be said seed that i could later find | 22:16 |
harlowja | but ya, if ansible had something, that'd be nice, lol | 22:17 |
dmsimard | harlowja: hm, wait, maybe things don't clash against each others after all | 22:18 |
dmsimard | harlowja: yeah I think this could be a non-issue, maybe you could confirm | 22:18 |
dmsimard | harlowja: ansible generates a new tmpdir for each ansible run | 22:19 |
dmsimard | harlowja: and ara stores it's file in that tmpdir | 22:19 |
* harlowja puts ara stuff into a sqlite db | 22:19 | |
harlowja | (unless u mean a different file) | 22:20 |
dmsimard | harlowja: https://paste.fedoraproject.org/paste/nU2dWl62AlH~ArZwH8bnXQ/raw | 22:20 |
dmsimard | harlowja: regardless of database backend, the playbook uuid is persisted in an ansible tmpfile on the control host | 22:21 |
dmsimard | ex: | 22:21 |
dmsimard | $ cat ./ansible-local-2215499oovY/ara.json | 22:21 |
dmsimard | {"playbook": {"id": "3849c552-6bd7-4c04-95ee-107316fc4e1b"}} | 22:21 |
dmsimard | This is how ara_record and ara_read modules are able to refer back to the parent playbook | 22:21 |
harlowja | how would i find which ./ansible-local-$blah to use? | 22:22 |
dmsimard | harlowja: you don't, the modules know where to find it in the loaded in-memory context | 22:22 |
dmsimard | harlowja: do this: https://gist.githubusercontent.com/dmsimard/f04758bbc5d9c3e96703d506e85141a7/raw/5b0f2f7fb55221293a1d4b9cd9e5013bfcef589d/task.yml | 22:23 |
dmsimard | harlowja: you'll see there is a playbook_id key in the return output that you can use | 22:24 |
dmsimard | in that particular example it'd be record.playbook_id | 22:24 |
harlowja | hmmmm, intersting | 22:24 |
harlowja | ok that may work, will try | 22:25 |
dmsimard | harlowja: it's a bit complicated but basically the modules load the flask application context that the callback initially started in which the ansible tmpdir was created (with a known path inside that context) | 22:25 |
dmsimard | on Ansible's end, it's basically just a mktemp so it's random, but we have access to the path inside the context | 22:26 |
harlowja | doesn't that mean those tempdirs can never be deleted? | 22:27 |
dmsimard | (the flask application context is a super powerful feature I didn't know existed before) | 22:27 |
dmsimard | harlowja: they can be deleted, they're only useful during the actual playbook run is in progress | 22:27 |
harlowja | ah, k | 22:27 |
harlowja | gotcha | 22:27 |
dmsimard | harlowja: if you want to run ara_record on a playbook *after* it's finished, you *need* to pass a playbook id | 22:28 |
dmsimard | and that's the feature I implemented for you :P | 22:28 |
harlowja | yup, gonna see how i can plug it all together now, ha | 22:28 |
harlowja | right now our ansible stdout/stderr get shoved into a gist on our github, lol | 22:28 |
dmsimard | gotta do what you gotta do | 22:29 |
dmsimard | harlowja: but hey, no guarantee on this, however it *should* work | 22:29 |
harlowja | :-P | 22:29 |
dmsimard | concurrent runs is not something that is even tested right now | 22:29 |
harlowja | someones gotta do it, lol | 22:30 |
dmsimard | yeah, I can see it being a legit use case | 22:30 |
dmsimard | harlowja: tbh, it's not so much concurrent runs that's a problem | 22:30 |
dmsimard | harlowja: it's concurrent runs *from the same host* | 22:30 |
dmsimard | like, I know there are users with multiple "control hosts" and feed data to a central mysql database | 22:30 |
dmsimard | that works super fine | 22:31 |
dmsimard | there might be edge cases (I would venture so far as saying within ansible itself?) by running ansible concurrently as the same user on the same box | 22:31 |
harlowja | impassible, lol | 22:32 |
dmsimard | impossibru ? | 22:32 |
harlowja | lol | 22:32 |
harlowja | ya | 22:32 |
harlowja | that | 22:32 |
dmsimard | harlowja: your bot could launch ephemeral isolated containers to run ansible-playbook from or something :p | 22:33 |
harlowja | fml | 22:33 |
harlowja | lol | 22:33 |
dmsimard | harlowja: with cool technology | 22:33 |
dmsimard | harlowja: like k8s | 22:33 |
harlowja | :( | 22:35 |
harlowja | to much tech | 22:35 |
harlowja | don't need waffle-iron to deploy openstack | 22:35 |
harlowja | lol | 22:35 |
harlowja | waffle iron powered by k8s | 22:36 |
*** jparrill has quit IRC | 22:36 | |
harlowja | dmsimard what was the hack that http://logs.openstack.org/54/342354/21/check/gate-kolla-python35/99c1d4b/_zuul_ansible/ did, i forget | 22:49 |
harlowja | they basically patchd ansible (i forget?) | 22:50 |
*** iceyao has joined #ara | 22:50 | |
dmsimard | harlowja: oh basically they hijacked the whole command module | 22:52 |
*** klindgren_ has joined #ara | 22:52 | |
dmsimard | harlowja: and then run everything in there | 22:52 |
harlowja | klindgren_ hallo | 22:52 |
klindgren_ | o/ | 22:52 |
*** klindgren_ is now known as klindgren | 22:52 | |
harlowja | klindgren_ also at godaddy, was asking me some questions on wtf i was going to do for recording, lol | 22:52 |
dmsimard | harlowja: basically it's to (amongst other things) send data to a file so that the zuul console can read from it and people can stream it | 22:52 |
harlowja | and then i was starting to channel/proxy dmsimard and i dislike channeling people (i'm not into voodoo) | 22:53 |
dmsimard | harlowja: otherwise ansible doesn't output the result of a task until it's completed | 22:53 |
dmsimard | harlowja: so zuul hijacked the module in order to stream the output as it is available | 22:53 |
dmsimard | klindgren: hai | 22:53 |
dmsimard | harlowja: https://github.com/openstack-infra/zuul/blob/master/zuul/ansible/library/command.py | 22:54 |
dmsimard | https://github.com/openstack-infra/zuul/blob/master/zuul/ansible/library/command.py#L127-L157 | 22:54 |
*** iceyao has quit IRC | 22:54 | |
dmsimard | https://github.com/openstack-infra/zuul/blob/master/zuul/ansible/library/zuul_log.py | 22:55 |
dmsimard | and finally https://github.com/openstack-infra/zuul/blob/master/zuul/ansible/library/zuul_console.py#L158 | 22:55 |
harlowja | ya , man | 22:55 |
harlowja | are the ansible folks just gonna make stdout/stderr redirection easier, lol | 22:55 |
klindgren | So one thing I was trying to figure out with ara_record stuff. Is with ansible you can have 2 types of playbooks. A playbook of playbooks and a playbook of tasks. | 22:55 |
dmsimard | harlowja: it's not a matter of redirection, it's a matter of buffering the task output until it's completed | 22:56 |
* harlowja was telling klindgren we'd need something like https://gist.github.com/harlowja/994b761f15269db29a8527713bb3f679 on playbooks | 22:56 | |
dmsimard | harlowja: streaming the live output of a task when you're running one task against one host is easy, but if you're running one task against 10, 100, 1000 hosts ... | 22:56 |
klindgren | If we made the ara_record and output fetching stuff its own set of playbooks and then jsut executed those before and after our other ansible role stuff - would that be fine | 22:56 |
harlowja | the ara_record one + debug needs to happen from the main playbook that does all the work | 22:57 |
harlowja | (afaik) | 22:57 |
harlowja | cause that's the one i want to record stdout/stderr of | 22:57 |
klindgren | or does it need to run as a task in the main playbook doing all the work | 22:57 |
klindgren | Well what I dont understand from an internal ansible perspective is how is a playbook of playbooks actually treated. | 22:57 |
klindgren | because you can pass variables/host and stuff between them | 22:58 |
dmsimard | klindgren: so the fact that your one playbook ends up including a set of playbooks is not important from the perspective of ara, there will be one unique playbook run and it's the "main" playbook, so there will be one playbook UUID and one run recorded in ara | 22:58 |
dmsimard | klindgren: in ARA, one "ansible-playbook" command == one playbook uuid | 22:59 |
klindgren | kk | 22:59 |
dmsimard | klindgren: so, if you want to stash the playbook uuid for that particular playbook, you do it anywhere within that playbook, can be in any file, not necessarily in the "main" playbook file | 22:59 |
klindgren | thats what I was figuring/hoping so we can do a generic ara_record/ara_output thingy and include that on all our main runs, and it will work for everything. | 23:00 |
dmsimard | klindgren: what I did for ARA's integration tests when I added the feature for harlowja was fairly simple since the execution order is predictable | 23:00 |
dmsimard | 1) Save the output somewhere: https://github.com/openstack/ara/blob/master/run_tests.sh#L95-L96 | 23:01 |
dmsimard | 2) Get the playbook id I'm interested in https://github.com/openstack/ara/blob/master/run_tests.sh#L114 | 23:01 |
dmsimard | 3) Attach it to the playbook: https://github.com/openstack/ara/blob/master/run_tests.sh#L130 | 23:01 |
harlowja | 4) profit | 23:01 |
dmsimard | harlowja: nooooooo | 23:01 |
dmsimard | 4) ??? | 23:01 |
dmsimard | 5) profit | 23:01 |
harlowja | klindgren the issue that i was discussing earlier was https://github.com/openstack/ara/blob/master/run_tests.sh#L114 won't work, especially if we run at any kind of concurrency level | 23:02 |
harlowja | so that's where including https://gist.github.com/harlowja/994b761f15269db29a8527713bb3f679 somewhere in the 'main playbook' will dump it (so that it can be later found) | 23:03 |
dmsimard | klindgren: so, in your context, if you need a reliable way of retrieving the playbook uuid (step #2), you can use a "sort-of" dummy ara_record task and the registered return provides the playbook_id | 23:03 |
dmsimard | Once you have the playbook_id, you can do whatever you want with it, dump it to a file at a predictable location or something. | 23:03 |
dmsimard | and then do step #3 not much differently than in the example I provided | 23:03 |
harlowja | dmsimard did u ever poke the ansible-tower folks, from what i remember they are also capturing output somehow | 23:04 |
dmsimard | harlowja: they wrap around ansible-playbook with like pexpect | 23:04 |
harlowja | k | 23:04 |
dmsimard | basically you don't run the ansible-playbook command | 23:04 |
dmsimard | you run ansible-tower (or whatever it is) | 23:05 |
dmsimard | and in the background what it really does is run ansible-playbook and captures the output | 23:05 |
harlowja | ya, then i guess they shove it in there db and associate it however | 23:05 |
klindgren | so stupid question - can we generate a UUID and pass it to ara somehow? | 23:05 |
harlowja | nice try! | 23:05 |
harlowja | did u read the logs,l lol | 23:05 |
* harlowja not sure there are logs :-P | 23:06 | |
dmsimard | I ideally don't want to wrap ansible-playbook under an ara command, want to avoid requiring users to change their workflows | 23:06 |
dmsimard | harlowja: yeah eavesdrop | 23:06 |
harlowja | klindgren already asked, ha | 23:06 |
dmsimard | klindgren: no there's no way, it's generated when the run starts | 23:06 |
klindgren | read logs = pshaw - who does that these days | 23:06 |
klindgren | is this uuid generation something that ara is doing or is this something internally that ansible is doing and ara is just using it? | 23:07 |
dmsimard | klindgren: the UUID ends up being used all over the place, leaving an option to make it user-supplied worries me :) | 23:07 |
harlowja | https://github.com/openstack/ara/blob/master/ara/models.py#L32 :-P | 23:07 |
dmsimard | klindgren: it's something that ara does, ansible has no concept of uniquely identifying an ansible run | 23:07 |
dmsimard | harlowja: yeah, and you know what, there was this openstack-dev thread a while back where people were advising against using uuid as primary keys.. I TIL'd that day. I'll address that sometime. | 23:08 |
dmsimard | klindgren: is recovering and using the uuid the way I explained particularly bothersome ? | 23:09 |
klindgren | harlowja, so - when we run this stuff via daddy is a new tmpdir for each playbook run done? | 23:10 |
dmsimard | klindgren: yeah, that part is abstracted by ansible | 23:10 |
dmsimard | klindgren: https://paste.fedoraproject.org/paste/nU2dWl62AlH~ArZwH8bnXQ/raw | 23:10 |
*** iceyao has joined #ara | 23:11 | |
klindgren | dmsimard, its just: https://github.com/openstack/ara/blob/master/run_tests.sh#L95-L96 make it so where if we are doing like 4 parallel runs, all refrencing the same tee dir that they will start blowing each other up | 23:11 |
klindgren | I guess we could do a uuid per run ahead of time and try on our end to link our uuid run to a ara uuid | 23:12 |
dmsimard | klindgren: well I don't have context on how you're running things.. but surely you have some means of knowing which run this is referring to somehow | 23:12 |
dmsimard | and pipe the output to a file appropriate for that run | 23:12 |
dmsimard | or you could, I don't know, LOGFILE=$(mktemp) ansible-playbook |tee $LOGFILE ? | 23:13 |
klindgren | I think I have an idea - I will work with josh on it. | 23:14 |
dmsimard | klindgren: happy to hear about it when you got something going | 23:14 |
dmsimard | I have to head out before A) my gf divorces me B) I digest myself | 23:14 |
*** iceyao has quit IRC | 23:15 | |
*** iceyao has joined #ara | 23:31 | |
*** iceyao has quit IRC | 23:36 | |
*** iceyao has joined #ara | 23:52 | |
*** iceyao has quit IRC | 23:56 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!