Tuesday, 2017-06-06

*** jistr has quit IRC00:01
*** jistr has joined #openstack-mistral00:02
*** catintheroof has quit IRC01:10
*** gongysh has joined #openstack-mistral01:16
*** jamielennox is now known as jamielennox|away01:17
*** bobh has joined #openstack-mistral01:32
*** jamielennox|away is now known as jamielennox01:34
*** bobh has quit IRC02:21
*** bobh has joined #openstack-mistral02:23
*** bobh has quit IRC02:29
*** zhurong has joined #openstack-mistral03:28
*** zhurong has quit IRC04:27
*** apetrich has quit IRC04:43
*** gongysh has quit IRC04:50
*** apetrich has joined #openstack-mistral04:54
*** zhurong has joined #openstack-mistral04:54
*** gongysh has joined #openstack-mistral05:30
*** jaosorior_away is now known as jaosorior05:44
*** sharatss has joined #openstack-mistral05:59
openstackgerritRenat Akhmerov proposed openstack/mistral-specs master: HA specification  https://review.openstack.org/47092806:17
*** zhurong has quit IRC06:32
*** zhurong has joined #openstack-mistral06:37
*** jaosorior is now known as jaosorior_away06:41
*** jrist has quit IRC06:50
xavierhardyGood morning everyone07:05
xavierhardyWhat 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-mistral07:36
*** jpich has joined #openstack-mistral07:37
openstackgerritVu Cong Tuan proposed openstack/mistral master: Replace oslo.messaging.get_transport with get_notification_transport  https://review.openstack.org/47123807:38
*** dtantsur|afk is now known as dtantsur07:38
xavierhardyhttps://review.openstack.org/#/c/471239/07:43
xavierhardyBackporting the Jinja2 environment fix07:43
xavierhardyinto the ocata release07:43
*** sharatss has quit IRC07:50
*** tuan__ has joined #openstack-mistral07:58
*** dtantsur is now known as dtantsur|bbl08:22
*** sharatss has joined #openstack-mistral08:35
*** zhurong has quit IRC08:35
*** zhurong has joined #openstack-mistral08:40
d0ugalrakhmerov: Hey08:48
d0ugalxavierhardy: yes, I think that is exactly what the event-engine does.08:49
xavierhardy"simply create executions according to the cron triggers" ?08:50
d0ugalyes08:50
xavierhardyOK thanks08:50
*** jaosorior_away is now known as jaosorior08:53
*** jaosorior has quit IRC09:04
rakhmerovd0ugal: hi, I'm here09:06
rakhmerovwhat's up?09:06
rakhmerovI saw your email09:06
d0ugalrakhmerov: I am trying to remove the import of mistral.utils.openstack.keystone in tripleo-common09:07
d0ugalrakhmerov: this is a problem: https://github.com/openstack/mistral/blob/master/mistral/utils/openstack/keystone.py#L2809:07
rakhmerovlooking..09:07
d0ugaltripleo-common wont have access to Mistral's config, obviously :)09:07
d0ugalany ideas?09:07
rakhmerovyou mean you want to switch to a similar thing in mistral-lib, right?09:09
d0ugalrakhmerov: Yeah, well, we will need those keystone functions in mistral-extra for the OpenStack actions09:10
rakhmerovsorry, I'm just trying to focus on this and fully understand what you're doing )09:10
rakhmerovyeah09:10
rakhmerovooh, gosh, yes09:11
d0ugalrakhmerov: 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
rakhmerovI thought you were fixing that dependency problem from the ML thread09:11
d0ugalbut 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
rakhmerovooh09:11
d0ugalthe 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
d0ugalbasically, my goal is to unblock the requirements problem09:12
rakhmerovyes, ok09:12
rakhmerovhm.. let me see how this config is used09:12
d0ugalafter 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#L2209:13
rakhmerovso, CONF is used mostly for getting keystone related properties09:14
d0ugalyeah09:14
rakhmerovexcept openstack_actions.os_actions_endpoint_type09:14
rakhmerovwhich is 100% wrong09:14
d0ugallol09:14
rakhmerovbecause keystone_utils should know anything about openstack actions09:14
rakhmerovyes09:14
d0ugalagreed09:15
rakhmerovthat deserves refactoring..09:15
rakhmerovwhat i'm just thinking is: could we just replace the usage of CONF somehow?09:15
rakhmerovjust by getting these props from tripleO somehow09:15
d0ugalrakhmerov: Yeah, I guess we could have our own config and duplicate the details09:16
rakhmerovand as far as openstack_actions.os_actions_endpoint_type, we could hardcode it to your what is suitable for tripleO09:16
rakhmerovthat's probably the only way I see now09:16
d0ugalrakhmerov: actually, don't we have most of the details in the mistral context already?09:16
d0ugali.e.. username: https://github.com/openstack/mistral/blob/master/mistral/context.py#L14009:16
d0ugaland region name is there too09:17
rakhmerovyeah, but not things like admin_user/admin_password09:17
d0ugalTrue.09:17
d0ugalDo we really need that if we have the token?09:17
d0ugalhmm09:17
d0ugalI do not know enough about KeyStone :)09:17
rakhmerovactually, we talked to Nikolay a few days ago and my conclusion is that all that code related to keystone in Mistral is totally messed up09:18
rakhmerovI'd like to get my hands into it and fix it..09:18
rakhmerovbut I can't for now09:18
d0ugalright09:18
rakhmerovd0ugal: so I'd be rather for hacking it somehow for now09:18
rakhmerovand get it to a proper shape later09:18
d0ugalrakhmerov: sounds good.09:18
rakhmerovyeah09:19
d0ugalI shouldn't need to change anything in Mistral now anyway, this is really a tripleo issue09:19
rakhmerovsorry if it's not what you expected )09:19
d0ugalbut I wanted to check there wasn't an easier way09:19
rakhmerovright09:19
d0ugalI was -1 to importing this originally, but they didn't listen :P09:19
rakhmerovI se09:19
rakhmerovsee09:19
d0ugalokay, thanks for your input!09:20
rakhmerovnp09:20
rakhmerovI 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 keystone09:21
rakhmerovit's a pain point for us09:21
rakhmerovbreton and others are reporting issues related to this very often09:21
rakhmerovok, I'll stop blablablabling for now.. We'll schedule to fix it09:22
*** zhurong has quit IRC09:33
*** mgershen has quit IRC09:36
d0ugal:)09:52
d0ugalI'd like to help at some point09:52
d0ugalSorry, got distracted.09:52
*** shardy has joined #openstack-mistral09:55
*** mgershen has joined #openstack-mistral10:04
*** dtantsur|bbl is now known as dtantsur10:05
*** jamielennox is now known as jamielennox|away10:10
rakhmerovnp10:13
*** jamielennox|away is now known as jamielennox10:16
*** gongysh has quit IRC10:26
*** jkilpatr has quit IRC10:41
*** tuan__ has quit IRC10:54
*** tuan_ has joined #openstack-mistral10:56
*** sharatss has quit IRC10:56
*** sharatss has joined #openstack-mistral10:59
*** jkilpatr has joined #openstack-mistral10:59
*** tuan_ has quit IRC11:01
*** shardy is now known as shardy_afk11:21
*** zhurong has joined #openstack-mistral11:30
*** jaosorior has joined #openstack-mistral11:56
*** shardy_afk is now known as shardy12:10
*** zhurong has quit IRC12:12
*** sharatss has quit IRC12:13
*** sharatss has joined #openstack-mistral12:13
*** tuan_ has joined #openstack-mistral12:15
*** sharatss has quit IRC12:27
*** hrybacki|afkish is now known as hrybacki12:33
*** tuan_ has quit IRC12:40
*** catintheroof has joined #openstack-mistral12:42
*** tuan_ has joined #openstack-mistral12:43
*** tuan_ has quit IRC12:48
*** tuan__ has joined #openstack-mistral12:50
*** apetrich has quit IRC12:52
*** jrist has quit IRC13:07
*** jrist has joined #openstack-mistral13:10
*** apetrich has joined #openstack-mistral13:37
fultonjd0ugal: fyi, i opened a bug for the issue we were talking about yesterday https://bugs.launchpad.net/mistral/+bug/169612813:51
openstackLaunchpad bug 1696128 in Mistral "unable to access a mistral env inside a workflow" [Undecided,New]13:51
*** bobh has joined #openstack-mistral13:53
openstackgerritToure Dunnon proposed openstack/mistral master: [WIP] Workflow Error Analysis (do not merge!)  https://review.openstack.org/45544713:56
thervefultonj, Using mistral.environments_get sounds a bit weird13:56
fultonjtherve: would you mind expanding on that? e.g. the method shouldn't exist or be used?13:57
thervefultonj, I mean, I wouldn't expect you to need using that to access environments13:58
tourerakhmerov ping13:58
therveUnless you really want to manage them, but otherwise that's not how I would access them13:58
fultonjtherve: 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-10583713:58
fultonji had the same problem as the poster to the question question13:58
fultonjtherve: ultimately i have variables from Heat I wish to access via Mistral13:59
thervefultonj, The second answer seems more appropriate :)13:59
d0ugaltherve: yeah, but it answers a different question :)14:01
therved0ugal, Does it?14:01
therveYou should access environments that way AFAIU14:01
d0ugaltherve: it depends what you want to do really, there are two different "types" of environments.14:02
therved0ugal, Yeah, and both can be  specified via the "env" in params14:02
therveWell, not both at the same time for some reasons14:02
d0ugalHow would you specify an environment that was created before?14:03
therveenv: env_name14:03
d0ugalhah, really14:05
d0ugalthat is a horrible interface14:05
therveHeh14:05
d0ugaland AFAIK, undocumented14:06
fultonjpreviously, i had tried to access env variables with things like...14:07
fultonjenv().get('service_ips', {})14:08
mattybrennanwe're using that currently (referencing by name)14:08
fultonjusing the same preexisting env but I got __env key errors14:08
mattybrennanI don't really know why there would be an API endpoint for creating a preexisting environment if you can't associate it with an execution14:08
openstackgerritMichal Gershenzon proposed openstack/mistral-specs master: Create and run workflows within a namespace  https://review.openstack.org/47099614:08
fultonjI had "env().get('service_ips', {})" working when heat kicked off the workflow14:09
fultonjbut I am just trying to run the same workflow via the CLI for debug purposes14:09
therved0ugal, Well, if only documented things were used...14:09
fultonjthought i could just create an env like the one Heat uses14:10
therveIt's still better than using  mistral.environments_get14:10
therveAlso it might work :)14:10
d0ugaltherve: indeed, just wondering how you found it14:10
therved0ugal, I read the source code, what do you think? :)14:10
fultonji'll document it if you help me find it :)14:10
d0ugaltherve: the action does work, in some ways it's a more natural way to access it IMO - less magic.14:10
d0ugalbut yeah, I never liked it.14:10
rakhmerovtoure: hi, I'm here but not really available till tomorro :(14:10
rakhmerovyou can write, I'll read when I have a chance14:11
tourerakhmerov no worries, it can wait till tomorrow14:12
fultonjmattybrennan: i see this solution worked for you. would you mind saying what versions you were using?14:20
fultonjtherve: 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
mattybrennanwe're using it on 4.014:21
fultonjfor me, `mistral --version` --> mistral 3.1.014:21
fultonjthanks mattybrennan14:22
fultonji am bound by what TripleO will ship14:22
d0ugalfultonj: are you not working on Ocata or Pike?14:24
fultonjd0ugal: pike14:25
fultonjd0ugal: i used tripleo-quickstart last week to build this env14:25
fultonjd0ugal: is pike's undercloud supposed to ship mistral 4 ?14:28
d0ugalfultonj: it should ship master, 5.0 beta14:29
d0ugalfultonj: that is the CLI version14:30
fultonji had specified master-ci14:30
fultonjd0ugal: i will see what just master produces14:31
d0ugalfultonj: 3.1.0 is the version of python-mistralclient14:31
d0ugalthat is correct14:31
fultonjahhhh14:31
fultonjrpm -qa | grep mistral --> ... openstack-mistral-engine-5.0.0-0 ...14:32
d0ugalthat is better :)14:32
fultonjso not a version issue14:32
fultonjgiven this...14:36
fultonjMistralAction.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
fultonjmight it occur because the enviornment scope is private?14:36
fultonjI'd expect a 401 if so however14:37
mattybrennanfultonj: sorry, in case it was unclear, I'm not using environments_get14:37
mattybrennanwe include the environment name when we trigger the execution14:37
fultonjmattybrennan: would you mind sharing your example?14:38
mattybrennanwe'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 env14:40
mattybrennan      resp = @server.post('executions', body.to_json,14:40
mattybrennan                          json: true)14:40
mattybrennan      resp['id']14:40
mattybrennan    end14:40
fultonjmattybrennan: great, thanks.14:41
fultonji will try more CLI variations by passing it14:41
*** tuan__ has quit IRC14:48
*** flaper87 has joined #openstack-mistral14:54
flaper87hey folks, is it possible to re-run an execution?14:56
thervefultonj, So yeah, it's about params, not input14:57
fultonjhttps://docs.openstack.org/cli-reference/mistral.html#mistral-execution-update14:59
fultonjtherve: ^ so you're suggesting I pass my env directly each time as some quoted json?14:59
thervefultonj, You can do that. Or directly pass the name of your stored environment15:00
fultonjmistral execution-create $WORKFLOW '{"env_name": "test"}'15:00
fultonj? ^15:01
fultonjand don't use 'action: mistral.environments_get name="test"'15:01
* therve looks at the CLI15:01
thervefultonj, No that's input. And it's {"env": "test"}15:04
fultonjmistral execution-create $WORKFLOW '' '{"env": "test"}'15:04
thervefultonj, Yep15:04
fultonjhttp://paste.openstack.org/raw/611522/15:08
fultonjhttp://sprunge.us/DiFS15:08
fultonjtherve: given that call to 'mistral execution-create', would you expect me to just be able to action: std.echo output=<% $.env %>15:09
therveLet's see15:11
thervefultonj, That's '__env' apparently15:12
fultonjnot in std.echo output=<% $.__env %> ?15:13
fultonjERROR (app) Lexical error: illegal character '_' at position 315:13
fultonji assume you mean in the execution call15:13
fultonjsame though15:13
fultonjsame error15:13
fultonjYaqlEvaluationException: Can not evaluate YAQL expression15:14
fultonjflaper87: you already tried this one? https://docs.openstack.org/cli-reference/mistral.html#mistral-execution-update15:16
flaper87fultonj: yeah, so, d0ugal helped me: What I needed was to re-run a task so, re-running the first task re-triggered everything15:18
flaper87openstack task execution rerun15:18
d0ugalflaper87: that worked? good to know :)15:18
fultonjok15:18
flaper87d0ugal: it did15:18
flaper87mistral claims to be "running" something15:18
d0ugalcool15:19
flaper87yeah, it's runing15:19
d0ugalI think we should have a restart command at the execution level15:19
flaper87d0ugal: ++15:21
*** chlong has joined #openstack-mistral15:29
fultonjtherve: did you by chance try to run the same workflow?15:29
thervefultonj, Yeah it doesn't work15:35
fultonjthanks for verifying15:36
fultonji tried renmaing the env (my_env) no diff15:36
fultonji will update the bug that i had issues via the CLI too15:36
fultonjtherve: this all started when trying to get this working again https://review.openstack.org/#/c/467682/15:37
fultonjI have ^ working on one undercloud15:38
fultonji am trying to get it working again on another15:38
fultonjbut cannot access the IPs in the env15:38
fultonjso I sent off trying to understand Mistral envs and ran into this15:38
* fultonj has to go for now15:40
fultonjthanks all for the ideas15:40
*** jaosorior is now known as jaosorior_away15:47
*** bobh_ has joined #openstack-mistral15:51
*** bobh has quit IRC15:54
thervefultonj, $.get('__env') should work16:03
therveI can't make my devstack work for some reason :/16:03
mgershentherve, what happened?16:13
thervemgershen, I don't know it's not configured right16:14
therveIt didn't get the rabbit url for some reasons16:14
therveAnd setting it is not enough to make stuff happens16:14
mgershendid you restart mistral services and api? Is it a new devstack, they changed a lot in the last few months.16:15
mgershensudo 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 restart16:16
therveYeah16:17
therveIt doesn't look like iniset_rpc_backend is called in mistral devstack plugin16:18
therveI wonder how it works16:18
mgershendon't know much about it.16:20
therveOh, rabbit_userid :/16:20
*** jamielennox is now known as jamielennox|away16:26
*** jpich has quit IRC16:26
*** clenimar_ has joined #openstack-mistral16:28
*** clenimar_ has quit IRC16:28
*** amoralej has joined #openstack-mistral16:59
amoralejhi 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
amoralejare you hitting issues in gate jobs?17:00
*** jamielennox|away is now known as jamielennox17:05
*** dtantsur is now known as dtantsur|afk17:07
fultonjtherve: thanks. that's one step further for me; no error this time i just got null17:28
fultonjhttp://paste.openstack.org/show/611541/17:29
mattybrennanthrash: that oslo update sounds likely to be the culprit of the errors xavierhardy and I were discussing yesterday17:46
mattybrennanoslo.messaging!=5.25.0,>=5.24.2 # Apache-2.017:46
mattybrennan^ from requirements.txt17:46
thrashmattybrennan: ack17:52
fultonjfinally17:56
fultonjmistral execution-create $WORKFLOW '' '{"env": "my_env"}'17:56
fultonjaction: std.echo output=<% $.get('__env') %>17:56
fultonjproduce my environment17:56
fultonjthanks therve17:57
fultonjthis also works...17:58
fultonjaction: std.echo output=<% env() %>17:58
fultonj... and i'm in business...17:59
fultonjstd.echo output=<% env().get('service_ips', {}).get('ceph_mon_ctlplane_node_ip\17:59
fultonjs', []) %>17:59
thrashfultonj: excellent!18:28
fultonjthanks thrash18:28
*** clenimar has quit IRC18:29
fultonjhttp://blog.johnlikesopenstack.com/2017/06/accessing-mistral-environment-in-cli.html18:35
fultonjhopefully google will serve up this example for the next person18:35
fultonjyou know what would be nice...18:45
fultonjif i could access variables from more than one enviornment18:45
fultonjin the same workflow18:45
*** thrash is now known as thrash|biab18:57
thervefultonj, That'd be nice! :)18:57
fultonjtherve: thanks for your help.18:58
fultonji was able to access my env as per the blog entry above18:58
fultonjthe reason I want to access to envs is because I want to borrow the SSH keys in TripleO to do a little ansible18:58
fultonjtripleo validations has a keypair and will have to see if i can borrow their example18:59
fultonjto make another keypair18:59
fultonjtwo* envs19:00
*** jkilpatr has quit IRC19:03
thervefultonj, Do you need to store them in mistral?19:06
therveOtherwise I would just manage a json and pass it directly19:07
fultonjtherve: i only need mistral to have them temporarily to pass them to another action19:08
fultonjthe mistral workflow is started as a heat resource19:08
fultonjhttps://review.openstack.org/#/c/465066/6/extraconfig/ceph_ansible/ceph-base.yaml19:08
fultonjthe action is ansible-playbook which deals with the ansible inventory19:09
fultonjhttps://review.openstack.org/#/c/469644/5/workbooks/ceph-ansible.yaml19:09
fultonjthese both work provided i do a hack...19:09
fultonjthat is to put the keys in the mistral enviornment in the mistral users home dir19:10
thervefultonj, I need to step out a little bit, back in 1h or so. Don't hesitate to ping me tomorrow otherwise19:12
therveI'm sure we can find something :)19:12
fultonjtherve: thanks, i appreicate it!19:12
*** Qiming has quit IRC19:13
*** Qiming has joined #openstack-mistral19:17
*** amoralej is now known as amoralej|off19:26
*** harlowja has quit IRC19:29
*** harlowja has joined #openstack-mistral19:50
thervefultonj, OK so20:04
thervefultonj, Why can't those IPs be regular inputs?20:05
*** shardy has quit IRC20:05
fultonji don't see why they couldn't if it would help somehow20:06
fultonjtherve: i thought it was kind of cool how gfidente got them https://review.openstack.org/#/c/467682/20:06
fultonjand added them to the env to be used20:07
fultonjthere were some comments in https://review.openstack.org/#/c/469644 that i had a long input list20:07
therveAh ok, yeah20:07
fultonjbut there's no real reason20:07
thervefultonj, So those are not stored20:07
fultonjtherve: suppose they were regular inputs20:08
fultonjwhat might the benefit be?20:08
thervefultonj, You could add your ssh keys there, no?20:08
*** toure is now known as toure|biab20:09
fultonjso validations gets its public keys on the overcloud nodes and stores them in mistral20:10
fultonjmistral environment-get ssh_keys20:10
therveAh :)20:10
therveI see20:10
fultonji imagine i'll need to do what they did to get my own "ceph" keys on the overcloud nodes first20:11
fultonjand perhaps heat could add them to the env that gfidenete created20:12
therveI don't really know the purpose of the validation keys20:12
fultonjthen once i have working keys that mistral can access, i'd pass them through20:13
therveMaybe they are meant to be a generic purpose access to the nodes20:13
fultonjif so no need to create a second pair20:13
fultonji wanted to try using theirs as a next step20:13
fultonjin my review and get feedback20:13
therveSo making mistral.environments_get is a good goal though20:16
therveThere is no reason for it to not be work, there is just a bug maybe20:16
fultonjtherve: yeah, that would make it easy to grab they keys from the other env20:17
fultonjnot have to worry about heat wrapping them up when it calls this worfklow20:17
fultonjthe way heat grabbed the IPs20:17
fultonjmy current experience with mistral.enviroinments_get is https://bugs.launchpad.net/mistral/+bug/1696128/comments/320:19
openstackLaunchpad bug 1696128 in Mistral "unable to access a mistral env using mistral.environments_get" [Undecided,New]20:19
thervefultonj, If you rely on validation, you may be able to use the node_admin_extra_ssh_keys parameter20:19
thervefultonj, Or call the tripleo.validations.get_pubkey action in your workflow20:20
fultonji wonder if there is a get_private key20:21
fultonjpublic key is on the nodes and working20:21
fultonjjust need to pass ansible the private key20:21
fultonjtherve: are you reading validations source?20:21
thervefultonj, Yeah I'm looking at the workbook20:22
therveBut yeah you need the private key, I'm dumb20:22
*** rbrady has quit IRC20:22
fultonjnot at all!20:22
*** rbrady has joined #openstack-mistral20:23
fultonjwhich workbook?20:23
fultonjhttps://github.com/openstack/tripleo-validations/tree/master/validations20:23
*** dtantsur|afk has quit IRC20:23
thervefultonj, https://github.com/openstack/tripleo-common/blob/master/workbooks/validations.yaml#L20020:23
therveWhich uses https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/validations.py#L2620:24
therveAnd the private key is only on the env, so you have get it there20:24
therveSo we get back to fix https://bugs.launchpad.net/mistral/+bug/1696128 :)20:25
openstackLaunchpad bug 1696128 in Mistral "unable to access a mistral env using mistral.environments_get" [Undecided,New]20:25
*** dtantsur has joined #openstack-mistral20:26
fultonjright20:26
thervefultonj, Hum https://github.com/openstack/tripleo-common/blob/master/workbooks/plan_management.yaml#L8520:31
fultonjswift?20:32
therveI mean it looks like it's already used in tripleo20:32
fultonjso if i'm having trouble with it, why isn't the rest of TripleO?20:34
therveRight20:34
*** jamielennox has quit IRC20:34
fultonjthus, the issue may not be a bug but something on my machine20:34
fultonjMistralAction.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
fultonjmistral/engine.log ^20:35
fultonjas to why that method call failed20:35
fultonjso the plan is...20:36
therveHum20:36
thervefultonj, 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_22720:36
fultonjif i can get that method working, then i'll call it in my wokrflow20:36
therveIt happens in CI as well20:36
therveBut we expect it to fail, so it doesn't raise an issue20:37
*** jkilpatr has joined #openstack-mistral20:38
fultonjwe exect it to fail?20:38
*** jamielennox has joined #openstack-mistral20:38
fultonjon-success: notify_zaqar20:38
fultonjit seems we're prepared for it to fail20:38
therveYeah, it expects a 404 as a failure, and continue if that's the case20:39
fultonjbut not 100% of the time20:39
therveIf it succeeds, it send a message to zaqar with a FAILED20:39
therveIE we wait for a 404, but we get a econnrefused and treat it as the same failure20:41
therveSo the bug is present here, just not an issue20:41
therveYet20:41
fultonjit's not an issue as the workflow can manage it20:42
fultonjbut one could argue that the bug exists regardless20:43
therveYep20:44
fultonjso does validations ever get its private key?20:45
fultonjif so, how?20:45
therveWell it doesn't call the action in the workflow directly20:45
therveSee https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/validations.py#L10620:46
therveIt calls an action that in turns call the env API20:46
therveBut not applicable to your case20:46
fultonjso their action is customized20:49
fultonjhttps://review.openstack.org/#/c/470021/20:49
fultonj^ the playbook action has updated over time for things that make sense for ansible20:50
fultonjssh keys are soemthing any ansbile would need and this mistral integration with ansible would benefit from a similar call.20:51
fultonji wonder...20:51
therveAren't those actions to run ansible on the undercloud?20:52
fultonjtherve: yes20:52
fultonji don't think it's too much of a stretch20:53
therveWell that call needs to be fixed20:54
therveNot sure you need it for the ansible stuff20:54
fultonjansible-playbook --private-key ... with https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/validations.py#L106-L10820:54
fultonjany user of these actions regardless of tripleo may find an environment with those vars helpful20:55
thervefultonj, Isn't the default taking the key for /root/.ssh anyway?20:56
fultonjtherve: but your point aside from this... is that there's a bug 169612820:56
openstackbug 1696128 in Mistral "unable to access a mistral env using mistral.environments_get" [Undecided,New] https://launchpad.net/bugs/169612820:56
therveIt possible it works by default20:56
thervefultonj, Right20:56
fultonji could drop this suggestion intot the review20:56
fultonjrbrady: ^20:56
fultonjtherve: mistral is running as the mistral user with these actions20:57
fultonjthe mistral user has no /home/mistral20:57
therveAh, ok20:57
fultonjtoday i make it work by doing...20:57
fultonjmkdir /home/mistral20:57
fultonjcp /home/stack/.ssh/... /home/mistral ...20:57
fultonjbut i want to replayce that ^20:57
therveYeah20:59
therveWell I'm not sure how https://review.openstack.org/#/c/470021/ is supposed to work if they haven't solved that issue20:59
fultonjright, unless you're doing something on your system outside of mistral21:06
fultonjflaper87: 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
fultonjflaper87: is on the review so he may comment as i basically dropped the same question and example you shared, therve, into that review21:07
* therve nods21:08
fultonjtherve: 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 169612821:09
openstackbug 1696128 in Mistral "unable to access a mistral env using mistral.environments_get" [Undecided,New] https://launchpad.net/bugs/169612821:09
openstackgerritThomas Herve proposed openstack/mistral master: Setup devstack with ini_rpc_backend  https://review.openstack.org/47148421:10
therveMeanwhile I found my issue21:10
therveoslo.messaging 5.26 is breaking mistral21:10
thervefultonj, And now it works for me locally :)21:17
fultonjtherve: really?21:17
therveYeah21:17
fultonjyou don't have https://launchpad.net/bugs/169612821:17
openstackLaunchpad bug 1696128 in Mistral "unable to access a mistral env using mistral.environments_get" [Undecided,New]21:17
fultonjprovided you use devstack21:18
fultonjwith  https://review.openstack.org/47148421:18
therveNope it works on devstack (tm)21:18
fultonjlol21:19
therveWell that patch is something else21:19
fultonjok21:19
thervefultonj, Do you use a "master" undercloud?21:19
fultonji have master-ci presently21:19
fultonjgetting master is no big deal21:19
fultonji can rebuild21:19
therveNo I don't think it makes a big difference21:19
fultonjif oslo.messaging 5.26 is the cause, is a newer version out without that bug?21:20
fultonji may be oversimplifying21:20
therveI don't think so. But the messaging problem is something else21:22
therveI can't fathom it being your issue21:23
therveAlright, off for now!21:26
fultonjso why do i have the bug and you don't?21:26
fultonjoh, ok21:27
therveYeah that part is to be determined!21:27
fultonjthanks a lot therve see you later21:27
therveMaybe the way the undercloud is deployed21:27
therveThanks, ttyl21:27
*** thrash|biab is now known as thrash21:50
*** bobh_ has quit IRC22:08
*** catintheroof has quit IRC22:41
*** jkilpatr has quit IRC23:42
*** jkilpatr has joined #openstack-mistral23:47
*** jkilpatr has quit IRC23:50
*** jkilpatr has joined #openstack-mistral23:53
*** jkilpatr has quit IRC23:57

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!