*** jistr has quit IRC | 00:01 | |
*** jistr has joined #openstack-mistral | 00:02 | |
*** catintheroof has quit IRC | 01:10 | |
*** gongysh has joined #openstack-mistral | 01:16 | |
*** jamielennox is now known as jamielennox|away | 01:17 | |
*** bobh has joined #openstack-mistral | 01:32 | |
*** jamielennox|away is now known as jamielennox | 01:34 | |
*** bobh has quit IRC | 02:21 | |
*** bobh has joined #openstack-mistral | 02:23 | |
*** bobh has quit IRC | 02:29 | |
*** zhurong has joined #openstack-mistral | 03:28 | |
*** zhurong has quit IRC | 04:27 | |
*** apetrich has quit IRC | 04:43 | |
*** gongysh has quit IRC | 04:50 | |
*** apetrich has joined #openstack-mistral | 04:54 | |
*** zhurong has joined #openstack-mistral | 04:54 | |
*** gongysh has joined #openstack-mistral | 05:30 | |
*** jaosorior_away is now known as jaosorior | 05:44 | |
*** sharatss has joined #openstack-mistral | 05:59 | |
openstackgerrit | Renat Akhmerov proposed openstack/mistral-specs master: HA specification https://review.openstack.org/470928 | 06:17 |
---|---|---|
*** zhurong has quit IRC | 06:32 | |
*** zhurong has joined #openstack-mistral | 06:37 | |
*** jaosorior is now known as jaosorior_away | 06:41 | |
*** jrist has quit IRC | 06:50 | |
xavierhardy | Good morning everyone | 07:05 |
xavierhardy | What kind of service is the event-engine? Does it simply create executions according to the cron triggers? Or does it execute them? | 07:05 |
*** jrist has joined #openstack-mistral | 07:36 | |
*** jpich has joined #openstack-mistral | 07:37 | |
openstackgerrit | Vu Cong Tuan proposed openstack/mistral master: Replace oslo.messaging.get_transport with get_notification_transport https://review.openstack.org/471238 | 07:38 |
*** dtantsur|afk is now known as dtantsur | 07:38 | |
xavierhardy | https://review.openstack.org/#/c/471239/ | 07:43 |
xavierhardy | Backporting the Jinja2 environment fix | 07:43 |
xavierhardy | into the ocata release | 07:43 |
*** sharatss has quit IRC | 07:50 | |
*** tuan__ has joined #openstack-mistral | 07:58 | |
*** dtantsur is now known as dtantsur|bbl | 08:22 | |
*** sharatss has joined #openstack-mistral | 08:35 | |
*** zhurong has quit IRC | 08:35 | |
*** zhurong has joined #openstack-mistral | 08:40 | |
d0ugal | rakhmerov: Hey | 08:48 |
d0ugal | xavierhardy: yes, I think that is exactly what the event-engine does. | 08:49 |
xavierhardy | "simply create executions according to the cron triggers" ? | 08:50 |
d0ugal | yes | 08:50 |
xavierhardy | OK thanks | 08:50 |
*** jaosorior_away is now known as jaosorior | 08:53 | |
*** jaosorior has quit IRC | 09:04 | |
rakhmerov | d0ugal: hi, I'm here | 09:06 |
rakhmerov | what's up? | 09:06 |
rakhmerov | I saw your email | 09:06 |
d0ugal | rakhmerov: I am trying to remove the import of mistral.utils.openstack.keystone in tripleo-common | 09:07 |
d0ugal | rakhmerov: this is a problem: https://github.com/openstack/mistral/blob/master/mistral/utils/openstack/keystone.py#L28 | 09:07 |
rakhmerov | looking.. | 09:07 |
d0ugal | tripleo-common wont have access to Mistral's config, obviously :) | 09:07 |
d0ugal | any ideas? | 09:07 |
rakhmerov | you mean you want to switch to a similar thing in mistral-lib, right? | 09:09 |
d0ugal | rakhmerov: Yeah, well, we will need those keystone functions in mistral-extra for the OpenStack actions | 09:10 |
rakhmerov | sorry, I'm just trying to focus on this and fully understand what you're doing ) | 09:10 |
rakhmerov | yeah | 09:10 |
rakhmerov | ooh, gosh, yes | 09:11 |
d0ugal | rakhmerov: but to help remove mistral from requirements I was just going to copy the code to tripleo-common (so we don't need a mistral-extra release) | 09:11 |
rakhmerov | I thought you were fixing that dependency problem from the ML thread | 09:11 |
d0ugal | but then I hit the problem with the config, and I don't know how to sove that for tripleo-common (or mistral-extra) | 09:11 |
rakhmerov | ooh | 09:11 |
d0ugal | the code should be the same, but getting it into tripleo-common will be much faster than releasing a new project. then I'd remove it again later. | 09:12 |
d0ugal | basically, my goal is to unblock the requirements problem | 09:12 |
rakhmerov | yes, ok | 09:12 |
rakhmerov | hm.. let me see how this config is used | 09:12 |
d0ugal | after apetrich's patch (linked in the email) lands, we will only have this import left: https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/base.py#L22 | 09:13 |
rakhmerov | so, CONF is used mostly for getting keystone related properties | 09:14 |
d0ugal | yeah | 09:14 |
rakhmerov | except openstack_actions.os_actions_endpoint_type | 09:14 |
rakhmerov | which is 100% wrong | 09:14 |
d0ugal | lol | 09:14 |
rakhmerov | because keystone_utils should know anything about openstack actions | 09:14 |
rakhmerov | yes | 09:14 |
d0ugal | agreed | 09:15 |
rakhmerov | that deserves refactoring.. | 09:15 |
rakhmerov | what i'm just thinking is: could we just replace the usage of CONF somehow? | 09:15 |
rakhmerov | just by getting these props from tripleO somehow | 09:15 |
d0ugal | rakhmerov: Yeah, I guess we could have our own config and duplicate the details | 09:16 |
rakhmerov | and as far as openstack_actions.os_actions_endpoint_type, we could hardcode it to your what is suitable for tripleO | 09:16 |
rakhmerov | that's probably the only way I see now | 09:16 |
d0ugal | rakhmerov: actually, don't we have most of the details in the mistral context already? | 09:16 |
d0ugal | i.e.. username: https://github.com/openstack/mistral/blob/master/mistral/context.py#L140 | 09:16 |
d0ugal | and region name is there too | 09:17 |
rakhmerov | yeah, but not things like admin_user/admin_password | 09:17 |
d0ugal | True. | 09:17 |
d0ugal | Do we really need that if we have the token? | 09:17 |
d0ugal | hmm | 09:17 |
d0ugal | I do not know enough about KeyStone :) | 09:17 |
rakhmerov | actually, we talked to Nikolay a few days ago and my conclusion is that all that code related to keystone in Mistral is totally messed up | 09:18 |
rakhmerov | I'd like to get my hands into it and fix it.. | 09:18 |
rakhmerov | but I can't for now | 09:18 |
d0ugal | right | 09:18 |
rakhmerov | d0ugal: so I'd be rather for hacking it somehow for now | 09:18 |
rakhmerov | and get it to a proper shape later | 09:18 |
d0ugal | rakhmerov: sounds good. | 09:18 |
rakhmerov | yeah | 09:19 |
d0ugal | I shouldn't need to change anything in Mistral now anyway, this is really a tripleo issue | 09:19 |
rakhmerov | sorry if it's not what you expected ) | 09:19 |
d0ugal | but I wanted to check there wasn't an easier way | 09:19 |
rakhmerov | right | 09:19 |
d0ugal | I was -1 to importing this originally, but they didn't listen :P | 09:19 |
rakhmerov | I se | 09:19 |
rakhmerov | see | 09:19 |
d0ugal | okay, thanks for your input! | 09:20 |
rakhmerov | np | 09:20 |
rakhmerov | I really want to fix it. You probably noticed that most of our problems now are coming from that area: trusts, authentication, actions based on using keystone | 09:21 |
rakhmerov | it's a pain point for us | 09:21 |
rakhmerov | breton and others are reporting issues related to this very often | 09:21 |
rakhmerov | ok, I'll stop blablablabling for now.. We'll schedule to fix it | 09:22 |
*** zhurong has quit IRC | 09:33 | |
*** mgershen has quit IRC | 09:36 | |
d0ugal | :) | 09:52 |
d0ugal | I'd like to help at some point | 09:52 |
d0ugal | Sorry, got distracted. | 09:52 |
*** shardy has joined #openstack-mistral | 09:55 | |
*** mgershen has joined #openstack-mistral | 10:04 | |
*** dtantsur|bbl is now known as dtantsur | 10:05 | |
*** jamielennox is now known as jamielennox|away | 10:10 | |
rakhmerov | np | 10:13 |
*** jamielennox|away is now known as jamielennox | 10:16 | |
*** gongysh has quit IRC | 10:26 | |
*** jkilpatr has quit IRC | 10:41 | |
*** tuan__ has quit IRC | 10:54 | |
*** tuan_ has joined #openstack-mistral | 10:56 | |
*** sharatss has quit IRC | 10:56 | |
*** sharatss has joined #openstack-mistral | 10:59 | |
*** jkilpatr has joined #openstack-mistral | 10:59 | |
*** tuan_ has quit IRC | 11:01 | |
*** shardy is now known as shardy_afk | 11:21 | |
*** zhurong has joined #openstack-mistral | 11:30 | |
*** jaosorior has joined #openstack-mistral | 11:56 | |
*** shardy_afk is now known as shardy | 12:10 | |
*** zhurong has quit IRC | 12:12 | |
*** sharatss has quit IRC | 12:13 | |
*** sharatss has joined #openstack-mistral | 12:13 | |
*** tuan_ has joined #openstack-mistral | 12:15 | |
*** sharatss has quit IRC | 12:27 | |
*** hrybacki|afkish is now known as hrybacki | 12:33 | |
*** tuan_ has quit IRC | 12:40 | |
*** catintheroof has joined #openstack-mistral | 12:42 | |
*** tuan_ has joined #openstack-mistral | 12:43 | |
*** tuan_ has quit IRC | 12:48 | |
*** tuan__ has joined #openstack-mistral | 12:50 | |
*** apetrich has quit IRC | 12:52 | |
*** jrist has quit IRC | 13:07 | |
*** jrist has joined #openstack-mistral | 13:10 | |
*** apetrich has joined #openstack-mistral | 13:37 | |
fultonj | d0ugal: fyi, i opened a bug for the issue we were talking about yesterday https://bugs.launchpad.net/mistral/+bug/1696128 | 13:51 |
openstack | Launchpad bug 1696128 in Mistral "unable to access a mistral env inside a workflow" [Undecided,New] | 13:51 |
*** bobh has joined #openstack-mistral | 13:53 | |
openstackgerrit | Toure Dunnon proposed openstack/mistral master: [WIP] Workflow Error Analysis (do not merge!) https://review.openstack.org/455447 | 13:56 |
therve | fultonj, Using mistral.environments_get sounds a bit weird | 13:56 |
fultonj | therve: would you mind expanding on that? e.g. the method shouldn't exist or be used? | 13:57 |
therve | fultonj, I mean, I wouldn't expect you to need using that to access environments | 13:58 |
toure | rakhmerov ping | 13:58 |
therve | Unless you really want to manage them, but otherwise that's not how I would access them | 13:58 |
fultonj | therve: i had borrowed it from https://ask.openstack.org/en/question/105618/can-you-associate-a-mistral-workflow-execution-with-an-environment-via-the-cli/?answer=105837#post-id-105837 | 13:58 |
fultonj | i had the same problem as the poster to the question question | 13:58 |
fultonj | therve: ultimately i have variables from Heat I wish to access via Mistral | 13:59 |
therve | fultonj, The second answer seems more appropriate :) | 13:59 |
d0ugal | therve: yeah, but it answers a different question :) | 14:01 |
therve | d0ugal, Does it? | 14:01 |
therve | You should access environments that way AFAIU | 14:01 |
d0ugal | therve: it depends what you want to do really, there are two different "types" of environments. | 14:02 |
therve | d0ugal, Yeah, and both can be specified via the "env" in params | 14:02 |
therve | Well, not both at the same time for some reasons | 14:02 |
d0ugal | How would you specify an environment that was created before? | 14:03 |
therve | env: env_name | 14:03 |
d0ugal | hah, really | 14:05 |
d0ugal | that is a horrible interface | 14:05 |
therve | Heh | 14:05 |
d0ugal | and AFAIK, undocumented | 14:06 |
fultonj | previously, i had tried to access env variables with things like... | 14:07 |
fultonj | env().get('service_ips', {}) | 14:08 |
mattybrennan | we're using that currently (referencing by name) | 14:08 |
fultonj | using the same preexisting env but I got __env key errors | 14:08 |
mattybrennan | I don't really know why there would be an API endpoint for creating a preexisting environment if you can't associate it with an execution | 14:08 |
openstackgerrit | Michal Gershenzon proposed openstack/mistral-specs master: Create and run workflows within a namespace https://review.openstack.org/470996 | 14:08 |
fultonj | I had "env().get('service_ips', {})" working when heat kicked off the workflow | 14:09 |
fultonj | but I am just trying to run the same workflow via the CLI for debug purposes | 14:09 |
therve | d0ugal, Well, if only documented things were used... | 14:09 |
fultonj | thought i could just create an env like the one Heat uses | 14:10 |
therve | It's still better than using mistral.environments_get | 14:10 |
therve | Also it might work :) | 14:10 |
d0ugal | therve: indeed, just wondering how you found it | 14:10 |
therve | d0ugal, I read the source code, what do you think? :) | 14:10 |
fultonj | i'll document it if you help me find it :) | 14:10 |
d0ugal | therve: the action does work, in some ways it's a more natural way to access it IMO - less magic. | 14:10 |
d0ugal | but yeah, I never liked it. | 14:10 |
rakhmerov | toure: hi, I'm here but not really available till tomorro :( | 14:10 |
rakhmerov | you can write, I'll read when I have a chance | 14:11 |
toure | rakhmerov no worries, it can wait till tomorrow | 14:12 |
fultonj | mattybrennan: i see this solution worked for you. would you mind saying what versions you were using? | 14:20 |
fultonj | therve: w.r.t to the second answer (zane's), are you suggesting i update the workflow to take an argument, e.g. "input: \n - params", and then call it that way via the CLI? ' | 14:20 |
mattybrennan | we're using it on 4.0 | 14:21 |
fultonj | for me, `mistral --version` --> mistral 3.1.0 | 14:21 |
fultonj | thanks mattybrennan | 14:22 |
fultonj | i am bound by what TripleO will ship | 14:22 |
d0ugal | fultonj: are you not working on Ocata or Pike? | 14:24 |
fultonj | d0ugal: pike | 14:25 |
fultonj | d0ugal: i used tripleo-quickstart last week to build this env | 14:25 |
fultonj | d0ugal: is pike's undercloud supposed to ship mistral 4 ? | 14:28 |
d0ugal | fultonj: it should ship master, 5.0 beta | 14:29 |
d0ugal | fultonj: that is the CLI version | 14:30 |
fultonj | i had specified master-ci | 14:30 |
fultonj | d0ugal: i will see what just master produces | 14:31 |
d0ugal | fultonj: 3.1.0 is the version of python-mistralclient | 14:31 |
d0ugal | that is correct | 14:31 |
fultonj | ahhhh | 14:31 |
fultonj | rpm -qa | grep mistral --> ... openstack-mistral-engine-5.0.0-0 ... | 14:32 |
d0ugal | that is better :) | 14:32 |
fultonj | so not a version issue | 14:32 |
fultonj | given this... | 14:36 |
fultonj | MistralAction.environments.get failed: <class 'requests.exceptions.ConnectionError'>: HTTPConnectionPool(host='localhost', port=8989): Max retries exceeded with url: /v2/environments/test (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7927710> | 14:36 |
fultonj | might it occur because the enviornment scope is private? | 14:36 |
fultonj | I'd expect a 401 if so however | 14:37 |
mattybrennan | fultonj: sorry, in case it was unclear, I'm not using environments_get | 14:37 |
mattybrennan | we include the environment name when we trigger the execution | 14:37 |
fultonj | mattybrennan: would you mind sharing your example? | 14:38 |
mattybrennan | we're using a ruby client we haven't open-sourced yet, but if this helps: | 14:40 |
mattybrennan | def execute!(env: nil) | 14:40 |
mattybrennan | body = { workflow_id: @id } | 14:40 |
mattybrennan | body[:params] = { env: env } if env | 14:40 |
mattybrennan | resp = @server.post('executions', body.to_json, | 14:40 |
mattybrennan | json: true) | 14:40 |
mattybrennan | resp['id'] | 14:40 |
mattybrennan | end | 14:40 |
fultonj | mattybrennan: great, thanks. | 14:41 |
fultonj | i will try more CLI variations by passing it | 14:41 |
*** tuan__ has quit IRC | 14:48 | |
*** flaper87 has joined #openstack-mistral | 14:54 | |
flaper87 | hey folks, is it possible to re-run an execution? | 14:56 |
therve | fultonj, So yeah, it's about params, not input | 14:57 |
fultonj | https://docs.openstack.org/cli-reference/mistral.html#mistral-execution-update | 14:59 |
fultonj | therve: ^ so you're suggesting I pass my env directly each time as some quoted json? | 14:59 |
therve | fultonj, You can do that. Or directly pass the name of your stored environment | 15:00 |
fultonj | mistral execution-create $WORKFLOW '{"env_name": "test"}' | 15:00 |
fultonj | ? ^ | 15:01 |
fultonj | and don't use 'action: mistral.environments_get name="test"' | 15:01 |
* therve looks at the CLI | 15:01 | |
therve | fultonj, No that's input. And it's {"env": "test"} | 15:04 |
fultonj | mistral execution-create $WORKFLOW '' '{"env": "test"}' | 15:04 |
therve | fultonj, Yep | 15:04 |
fultonj | http://paste.openstack.org/raw/611522/ | 15:08 |
fultonj | http://sprunge.us/DiFS | 15:08 |
fultonj | therve: given that call to 'mistral execution-create', would you expect me to just be able to action: std.echo output=<% $.env %> | 15:09 |
therve | Let's see | 15:11 |
therve | fultonj, That's '__env' apparently | 15:12 |
fultonj | not in std.echo output=<% $.__env %> ? | 15:13 |
fultonj | ERROR (app) Lexical error: illegal character '_' at position 3 | 15:13 |
fultonj | i assume you mean in the execution call | 15:13 |
fultonj | same though | 15:13 |
fultonj | same error | 15:13 |
fultonj | YaqlEvaluationException: Can not evaluate YAQL expression | 15:14 |
fultonj | flaper87: you already tried this one? https://docs.openstack.org/cli-reference/mistral.html#mistral-execution-update | 15:16 |
flaper87 | fultonj: yeah, so, d0ugal helped me: What I needed was to re-run a task so, re-running the first task re-triggered everything | 15:18 |
flaper87 | openstack task execution rerun | 15:18 |
d0ugal | flaper87: that worked? good to know :) | 15:18 |
fultonj | ok | 15:18 |
flaper87 | d0ugal: it did | 15:18 |
flaper87 | mistral claims to be "running" something | 15:18 |
d0ugal | cool | 15:19 |
flaper87 | yeah, it's runing | 15:19 |
d0ugal | I think we should have a restart command at the execution level | 15:19 |
flaper87 | d0ugal: ++ | 15:21 |
*** chlong has joined #openstack-mistral | 15:29 | |
fultonj | therve: did you by chance try to run the same workflow? | 15:29 |
therve | fultonj, Yeah it doesn't work | 15:35 |
fultonj | thanks for verifying | 15:36 |
fultonj | i tried renmaing the env (my_env) no diff | 15:36 |
fultonj | i will update the bug that i had issues via the CLI too | 15:36 |
fultonj | therve: this all started when trying to get this working again https://review.openstack.org/#/c/467682/ | 15:37 |
fultonj | I have ^ working on one undercloud | 15:38 |
fultonj | i am trying to get it working again on another | 15:38 |
fultonj | but cannot access the IPs in the env | 15:38 |
fultonj | so I sent off trying to understand Mistral envs and ran into this | 15:38 |
* fultonj has to go for now | 15:40 | |
fultonj | thanks all for the ideas | 15:40 |
*** jaosorior is now known as jaosorior_away | 15:47 | |
*** bobh_ has joined #openstack-mistral | 15:51 | |
*** bobh has quit IRC | 15:54 | |
therve | fultonj, $.get('__env') should work | 16:03 |
therve | I can't make my devstack work for some reason :/ | 16:03 |
mgershen | therve, what happened? | 16:13 |
therve | mgershen, I don't know it's not configured right | 16:14 |
therve | It didn't get the rabbit url for some reasons | 16:14 |
therve | And setting it is not enough to make stuff happens | 16:14 |
mgershen | did you restart mistral services and api? Is it a new devstack, they changed a lot in the last few months. | 16:15 |
mgershen | sudo systemctl restart devstack@mistral-engine.service && sudo systemctl restart devstack@mistral-executor.service && sudo systemctl restart devstack@mistral-event-engine.service && sudo /etc/init.d/apache2 restart | 16:16 |
therve | Yeah | 16:17 |
therve | It doesn't look like iniset_rpc_backend is called in mistral devstack plugin | 16:18 |
therve | I wonder how it works | 16:18 |
mgershen | don't know much about it. | 16:20 |
therve | Oh, rabbit_userid :/ | 16:20 |
*** jamielennox is now known as jamielennox|away | 16:26 | |
*** jpich has quit IRC | 16:26 | |
*** clenimar_ has joined #openstack-mistral | 16:28 | |
*** clenimar_ has quit IRC | 16:28 | |
*** amoralej has joined #openstack-mistral | 16:59 | |
amoralej | hi mistral, oslo team has tagged new release new oslo.messaging 5.26.0 which seems to break mistral from master as happened with 5.25.0, am i coorect? | 17:00 |
amoralej | are you hitting issues in gate jobs? | 17:00 |
*** jamielennox|away is now known as jamielennox | 17:05 | |
*** dtantsur is now known as dtantsur|afk | 17:07 | |
fultonj | therve: thanks. that's one step further for me; no error this time i just got null | 17:28 |
fultonj | http://paste.openstack.org/show/611541/ | 17:29 |
mattybrennan | thrash: that oslo update sounds likely to be the culprit of the errors xavierhardy and I were discussing yesterday | 17:46 |
mattybrennan | oslo.messaging!=5.25.0,>=5.24.2 # Apache-2.0 | 17:46 |
mattybrennan | ^ from requirements.txt | 17:46 |
thrash | mattybrennan: ack | 17:52 |
fultonj | finally | 17:56 |
fultonj | mistral execution-create $WORKFLOW '' '{"env": "my_env"}' | 17:56 |
fultonj | action: std.echo output=<% $.get('__env') %> | 17:56 |
fultonj | produce my environment | 17:56 |
fultonj | thanks therve | 17:57 |
fultonj | this also works... | 17:58 |
fultonj | action: std.echo output=<% env() %> | 17:58 |
fultonj | ... and i'm in business... | 17:59 |
fultonj | std.echo output=<% env().get('service_ips', {}).get('ceph_mon_ctlplane_node_ip\ | 17:59 |
fultonj | s', []) %> | 17:59 |
thrash | fultonj: excellent! | 18:28 |
fultonj | thanks thrash | 18:28 |
*** clenimar has quit IRC | 18:29 | |
fultonj | http://blog.johnlikesopenstack.com/2017/06/accessing-mistral-environment-in-cli.html | 18:35 |
fultonj | hopefully google will serve up this example for the next person | 18:35 |
fultonj | you know what would be nice... | 18:45 |
fultonj | if i could access variables from more than one enviornment | 18:45 |
fultonj | in the same workflow | 18:45 |
*** thrash is now known as thrash|biab | 18:57 | |
therve | fultonj, That'd be nice! :) | 18:57 |
fultonj | therve: thanks for your help. | 18:58 |
fultonj | i was able to access my env as per the blog entry above | 18:58 |
fultonj | the reason I want to access to envs is because I want to borrow the SSH keys in TripleO to do a little ansible | 18:58 |
fultonj | tripleo validations has a keypair and will have to see if i can borrow their example | 18:59 |
fultonj | to make another keypair | 18:59 |
fultonj | two* envs | 19:00 |
*** jkilpatr has quit IRC | 19:03 | |
therve | fultonj, Do you need to store them in mistral? | 19:06 |
therve | Otherwise I would just manage a json and pass it directly | 19:07 |
fultonj | therve: i only need mistral to have them temporarily to pass them to another action | 19:08 |
fultonj | the mistral workflow is started as a heat resource | 19:08 |
fultonj | https://review.openstack.org/#/c/465066/6/extraconfig/ceph_ansible/ceph-base.yaml | 19:08 |
fultonj | the action is ansible-playbook which deals with the ansible inventory | 19:09 |
fultonj | https://review.openstack.org/#/c/469644/5/workbooks/ceph-ansible.yaml | 19:09 |
fultonj | these both work provided i do a hack... | 19:09 |
fultonj | that is to put the keys in the mistral enviornment in the mistral users home dir | 19:10 |
therve | fultonj, I need to step out a little bit, back in 1h or so. Don't hesitate to ping me tomorrow otherwise | 19:12 |
therve | I'm sure we can find something :) | 19:12 |
fultonj | therve: thanks, i appreicate it! | 19:12 |
*** Qiming has quit IRC | 19:13 | |
*** Qiming has joined #openstack-mistral | 19:17 | |
*** amoralej is now known as amoralej|off | 19:26 | |
*** harlowja has quit IRC | 19:29 | |
*** harlowja has joined #openstack-mistral | 19:50 | |
therve | fultonj, OK so | 20:04 |
therve | fultonj, Why can't those IPs be regular inputs? | 20:05 |
*** shardy has quit IRC | 20:05 | |
fultonj | i don't see why they couldn't if it would help somehow | 20:06 |
fultonj | therve: i thought it was kind of cool how gfidente got them https://review.openstack.org/#/c/467682/ | 20:06 |
fultonj | and added them to the env to be used | 20:07 |
fultonj | there were some comments in https://review.openstack.org/#/c/469644 that i had a long input list | 20:07 |
therve | Ah ok, yeah | 20:07 |
fultonj | but there's no real reason | 20:07 |
therve | fultonj, So those are not stored | 20:07 |
fultonj | therve: suppose they were regular inputs | 20:08 |
fultonj | what might the benefit be? | 20:08 |
therve | fultonj, You could add your ssh keys there, no? | 20:08 |
*** toure is now known as toure|biab | 20:09 | |
fultonj | so validations gets its public keys on the overcloud nodes and stores them in mistral | 20:10 |
fultonj | mistral environment-get ssh_keys | 20:10 |
therve | Ah :) | 20:10 |
therve | I see | 20:10 |
fultonj | i imagine i'll need to do what they did to get my own "ceph" keys on the overcloud nodes first | 20:11 |
fultonj | and perhaps heat could add them to the env that gfidenete created | 20:12 |
therve | I don't really know the purpose of the validation keys | 20:12 |
fultonj | then once i have working keys that mistral can access, i'd pass them through | 20:13 |
therve | Maybe they are meant to be a generic purpose access to the nodes | 20:13 |
fultonj | if so no need to create a second pair | 20:13 |
fultonj | i wanted to try using theirs as a next step | 20:13 |
fultonj | in my review and get feedback | 20:13 |
therve | So making mistral.environments_get is a good goal though | 20:16 |
therve | There is no reason for it to not be work, there is just a bug maybe | 20:16 |
fultonj | therve: yeah, that would make it easy to grab they keys from the other env | 20:17 |
fultonj | not have to worry about heat wrapping them up when it calls this worfklow | 20:17 |
fultonj | the way heat grabbed the IPs | 20:17 |
fultonj | my current experience with mistral.enviroinments_get is https://bugs.launchpad.net/mistral/+bug/1696128/comments/3 | 20:19 |
openstack | Launchpad bug 1696128 in Mistral "unable to access a mistral env using mistral.environments_get" [Undecided,New] | 20:19 |
therve | fultonj, If you rely on validation, you may be able to use the node_admin_extra_ssh_keys parameter | 20:19 |
therve | fultonj, Or call the tripleo.validations.get_pubkey action in your workflow | 20:20 |
fultonj | i wonder if there is a get_private key | 20:21 |
fultonj | public key is on the nodes and working | 20:21 |
fultonj | just need to pass ansible the private key | 20:21 |
fultonj | therve: are you reading validations source? | 20:21 |
therve | fultonj, Yeah I'm looking at the workbook | 20:22 |
therve | But yeah you need the private key, I'm dumb | 20:22 |
*** rbrady has quit IRC | 20:22 | |
fultonj | not at all! | 20:22 |
*** rbrady has joined #openstack-mistral | 20:23 | |
fultonj | which workbook? | 20:23 |
fultonj | https://github.com/openstack/tripleo-validations/tree/master/validations | 20:23 |
*** dtantsur|afk has quit IRC | 20:23 | |
therve | fultonj, https://github.com/openstack/tripleo-common/blob/master/workbooks/validations.yaml#L200 | 20:23 |
therve | Which uses https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/validations.py#L26 | 20:24 |
therve | And the private key is only on the env, so you have get it there | 20:24 |
therve | So we get back to fix https://bugs.launchpad.net/mistral/+bug/1696128 :) | 20:25 |
openstack | Launchpad bug 1696128 in Mistral "unable to access a mistral env using mistral.environments_get" [Undecided,New] | 20:25 |
*** dtantsur has joined #openstack-mistral | 20:26 | |
fultonj | right | 20:26 |
therve | fultonj, Hum https://github.com/openstack/tripleo-common/blob/master/workbooks/plan_management.yaml#L85 | 20:31 |
fultonj | swift? | 20:32 |
therve | I mean it looks like it's already used in tripleo | 20:32 |
fultonj | so if i'm having trouble with it, why isn't the rest of TripleO? | 20:34 |
therve | Right | 20:34 |
*** jamielennox has quit IRC | 20:34 | |
fultonj | thus, the issue may not be a bug but something on my machine | 20:34 |
fultonj | MistralAction.environments.get failed: <class 'requests.exceptions.ConnectionError'>: HTTPConnectionPool(host='localhost', port=8989): Max retries exceeded with url: /v2/environments/my_env (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7c12ed0>: Failed to establish a new connection: [Errno 111] ECONNREFUSED',)) | 20:34 |
fultonj | mistral/engine.log ^ | 20:35 |
fultonj | as to why that method call failed | 20:35 |
fultonj | so the plan is... | 20:36 |
therve | Hum | 20:36 |
therve | fultonj, http://logs.openstack.org/09/471409/1/check-tripleo/gate-tripleo-ci-centos-7-ovb-ha-oooq/dcd59a5/logs/undercloud/var/log/mistral/engine.log.txt.gz#_2017-06-06_17_42_41_227 | 20:36 |
fultonj | if i can get that method working, then i'll call it in my wokrflow | 20:36 |
therve | It happens in CI as well | 20:36 |
therve | But we expect it to fail, so it doesn't raise an issue | 20:37 |
*** jkilpatr has joined #openstack-mistral | 20:38 | |
fultonj | we exect it to fail? | 20:38 |
*** jamielennox has joined #openstack-mistral | 20:38 | |
fultonj | on-success: notify_zaqar | 20:38 |
fultonj | it seems we're prepared for it to fail | 20:38 |
therve | Yeah, it expects a 404 as a failure, and continue if that's the case | 20:39 |
fultonj | but not 100% of the time | 20:39 |
therve | If it succeeds, it send a message to zaqar with a FAILED | 20:39 |
therve | IE we wait for a 404, but we get a econnrefused and treat it as the same failure | 20:41 |
therve | So the bug is present here, just not an issue | 20:41 |
therve | Yet | 20:41 |
fultonj | it's not an issue as the workflow can manage it | 20:42 |
fultonj | but one could argue that the bug exists regardless | 20:43 |
therve | Yep | 20:44 |
fultonj | so does validations ever get its private key? | 20:45 |
fultonj | if so, how? | 20:45 |
therve | Well it doesn't call the action in the workflow directly | 20:45 |
therve | See https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/validations.py#L106 | 20:46 |
therve | It calls an action that in turns call the env API | 20:46 |
therve | But not applicable to your case | 20:46 |
fultonj | so their action is customized | 20:49 |
fultonj | https://review.openstack.org/#/c/470021/ | 20:49 |
fultonj | ^ the playbook action has updated over time for things that make sense for ansible | 20:50 |
fultonj | ssh keys are soemthing any ansbile would need and this mistral integration with ansible would benefit from a similar call. | 20:51 |
fultonj | i wonder... | 20:51 |
therve | Aren't those actions to run ansible on the undercloud? | 20:52 |
fultonj | therve: yes | 20:52 |
fultonj | i don't think it's too much of a stretch | 20:53 |
therve | Well that call needs to be fixed | 20:54 |
therve | Not sure you need it for the ansible stuff | 20:54 |
fultonj | ansible-playbook --private-key ... with https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/validations.py#L106-L108 | 20:54 |
fultonj | any user of these actions regardless of tripleo may find an environment with those vars helpful | 20:55 |
therve | fultonj, Isn't the default taking the key for /root/.ssh anyway? | 20:56 |
fultonj | therve: but your point aside from this... is that there's a bug 1696128 | 20:56 |
openstack | bug 1696128 in Mistral "unable to access a mistral env using mistral.environments_get" [Undecided,New] https://launchpad.net/bugs/1696128 | 20:56 |
therve | It possible it works by default | 20:56 |
therve | fultonj, Right | 20:56 |
fultonj | i could drop this suggestion intot the review | 20:56 |
fultonj | rbrady: ^ | 20:56 |
fultonj | therve: mistral is running as the mistral user with these actions | 20:57 |
fultonj | the mistral user has no /home/mistral | 20:57 |
therve | Ah, ok | 20:57 |
fultonj | today i make it work by doing... | 20:57 |
fultonj | mkdir /home/mistral | 20:57 |
fultonj | cp /home/stack/.ssh/... /home/mistral ... | 20:57 |
fultonj | but i want to replayce that ^ | 20:57 |
therve | Yeah | 20:59 |
therve | Well I'm not sure how https://review.openstack.org/#/c/470021/ is supposed to work if they haven't solved that issue | 20:59 |
fultonj | right, unless you're doing something on your system outside of mistral | 21:06 |
fultonj | flaper87: i know you're also a user of https://review.openstack.org/#/c/470021/ how do you deal with the mistral user's SSH keys? | 21:06 |
fultonj | flaper87: is on the review so he may comment as i basically dropped the same question and example you shared, therve, into that review | 21:07 |
* therve nods | 21:08 | |
fultonj | therve: the other alternative is to extend the command with the new option and have it either pull it from the env, as we've been discussing, or take it as an argument and if it's taken as an argument, then the user must get it; perhaps via the solution to bug 1696128 | 21:09 |
openstack | bug 1696128 in Mistral "unable to access a mistral env using mistral.environments_get" [Undecided,New] https://launchpad.net/bugs/1696128 | 21:09 |
openstackgerrit | Thomas Herve proposed openstack/mistral master: Setup devstack with ini_rpc_backend https://review.openstack.org/471484 | 21:10 |
therve | Meanwhile I found my issue | 21:10 |
therve | oslo.messaging 5.26 is breaking mistral | 21:10 |
therve | fultonj, And now it works for me locally :) | 21:17 |
fultonj | therve: really? | 21:17 |
therve | Yeah | 21:17 |
fultonj | you don't have https://launchpad.net/bugs/1696128 | 21:17 |
openstack | Launchpad bug 1696128 in Mistral "unable to access a mistral env using mistral.environments_get" [Undecided,New] | 21:17 |
fultonj | provided you use devstack | 21:18 |
fultonj | with https://review.openstack.org/471484 | 21:18 |
therve | Nope it works on devstack (tm) | 21:18 |
fultonj | lol | 21:19 |
therve | Well that patch is something else | 21:19 |
fultonj | ok | 21:19 |
therve | fultonj, Do you use a "master" undercloud? | 21:19 |
fultonj | i have master-ci presently | 21:19 |
fultonj | getting master is no big deal | 21:19 |
fultonj | i can rebuild | 21:19 |
therve | No I don't think it makes a big difference | 21:19 |
fultonj | if oslo.messaging 5.26 is the cause, is a newer version out without that bug? | 21:20 |
fultonj | i may be oversimplifying | 21:20 |
therve | I don't think so. But the messaging problem is something else | 21:22 |
therve | I can't fathom it being your issue | 21:23 |
therve | Alright, off for now! | 21:26 |
fultonj | so why do i have the bug and you don't? | 21:26 |
fultonj | oh, ok | 21:27 |
therve | Yeah that part is to be determined! | 21:27 |
fultonj | thanks a lot therve see you later | 21:27 |
therve | Maybe the way the undercloud is deployed | 21:27 |
therve | Thanks, ttyl | 21:27 |
*** thrash|biab is now known as thrash | 21:50 | |
*** bobh_ has quit IRC | 22:08 | |
*** catintheroof has quit IRC | 22:41 | |
*** jkilpatr has quit IRC | 23:42 | |
*** jkilpatr has joined #openstack-mistral | 23:47 | |
*** jkilpatr has quit IRC | 23:50 | |
*** jkilpatr has joined #openstack-mistral | 23:53 | |
*** jkilpatr has quit IRC | 23:57 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!