Friday, 2017-03-31

*** jamielennox is now known as jamielennox|away00:25
*** jamielennox|away is now known as jamielennox00:31
*** zhurong has joined #openstack-mistral00:31
*** gongysh has joined #openstack-mistral00:47
*** dprince has joined #openstack-mistral01:15
*** gongysh has quit IRC01:16
*** dprince has quit IRC01:26
*** thrash is now known as thrash|g0ne01:29
*** bobh has quit IRC02:31
*** bobh has joined #openstack-mistral03:04
*** bobh has quit IRC03:09
*** Qiming has quit IRC04:04
*** Qiming has joined #openstack-mistral04:06
*** zhurong has quit IRC04:09
*** zhurong has joined #openstack-mistral04:30
*** sharatss has joined #openstack-mistral05:29
*** zhurong has quit IRC05:41
*** jaosorior has joined #openstack-mistral05:56
*** zhurong has joined #openstack-mistral06:05
*** d0ugal has joined #openstack-mistral06:52
*** d0ugal has quit IRC06:54
*** d0ugal has joined #openstack-mistral06:58
*** d0ugal has joined #openstack-mistral06:58
openstackgerritSharat Sharma proposed openstack/mistral-dashboard master: Change the Next button to Validate  https://review.openstack.org/45206607:04
openstackgerritSharat Sharma proposed openstack/mistral-dashboard master: Change the Next button to Validate  https://review.openstack.org/45206607:06
*** jpich has joined #openstack-mistral07:14
*** d0ugal has quit IRC07:22
*** sharatss has quit IRC07:23
*** sharatss has joined #openstack-mistral07:23
*** Qiming has quit IRC07:26
*** d0ugal has joined #openstack-mistral07:26
*** d0ugal has joined #openstack-mistral07:26
*** Qiming has joined #openstack-mistral07:32
therved0ugal, rakhmerov https://bitbucket.org/zzzeek/sqlalchemy/issues/3950/11-regression-due-to-typedecorator-copy07:39
therve1.1.8 incoming07:39
d0ugaloh, cool07:40
openstackgerritDougal Matthews proposed openstack/mistral master: Workaround SQLAlchemy 1.1 issue  https://review.openstack.org/45198507:55
d0ugaloh, looks like there is larger CI issues today.08:10
*** tuan_ has joined #openstack-mistral08:10
tuan_morning folks08:19
d0ugaltuan_: hey08:20
tuan_yesterday i have had a talk with Dougal about refreshing expired token in mistral that should support multi VIM08:20
tuan_thanks dougal again for your time08:20
tuan_i would like to have more ideas about it08:21
d0ugaltuan_: I think rakhmerov said he wont be around todau08:21
d0ugaltoday08:21
tuan_okay08:21
tuan_but may be other guys have some ideas08:21
tuan_:D08:21
d0ugalOthers might be, but I think that is who you wanted to speak with :)08:21
d0ugalyup!08:22
d0ugalIf you don't have any luck, you could try the meeting on Monday.08:22
tuan_well, i would like to have as much as possible08:22
tuan_yep, i will definitely join it08:22
tuan_otherwise, i think the refreshing the expired token when calling clients in mistral is not supported08:23
tuan_this situation is what i told you yesterday08:24
tuan_therefore i would like to write a bug report for it08:24
tuan_how do you think about it08:26
*** shardy has joined #openstack-mistral08:26
*** shardy has quit IRC08:37
*** shardy has joined #openstack-mistral08:38
d0ugaltuan_: isn't the bug I sent you before good enough?09:33
d0ugalhttps://bugs.launchpad.net/mistral/+bug/159508409:33
openstackLaunchpad bug 1595084 in Mistral "Workflow execution lifespan is limited by auth token expire time" [High,Confirmed]09:33
*** tuan_ has quit IRC09:38
*** zhurong has quit IRC10:18
*** tuan_ has joined #openstack-mistral10:19
*** thrash|g0ne is now known as thrash10:26
*** zhurong has joined #openstack-mistral10:41
*** shardy is now known as shardy_lunch11:14
tuan_d0ugal: Hi Dougal, sorry for my late reply since i had something to do in urgent11:17
tuan_yep, this bug was about that11:18
tuan_however, shardy he proposed an algorithms in heat11:18
tuan_and now we want to implement his idea in mistral11:18
tuan_:)11:18
tuan_thannks and i am going to talk to him11:18
d0ugaltuan_: yup, doing something similar to Heat is a good starting point.11:20
tuan_well yup11:21
tuan_it is actually what i want to mention11:21
*** jkilpatr has joined #openstack-mistral11:21
tuan_however it is only using trust in keystone v311:21
tuan_what about backward compatibility11:21
tuan_or just let the previous releases deprecated11:22
tuan_then we just support some current verisons that support v311:22
tuan_i myself support for the solution of only supporting trust in keystone v311:23
tuan_if we want to make it general to support backward compatibility11:23
tuan_it is not an easy task11:23
d0ugaltuan_: I don't expect this feature to be backported.11:24
tuan_yup11:25
tuan_what about this11:25
tuan_now we are using mistral context to trigger other clients? like nova client, neutron client11:26
tuan_?11:26
d0ugal yes11:27
tuan_when mistral passes it11:27
tuan_for instance, nova client may realize that, the token for this user may expired11:28
tuan_then it fails11:28
tuan_what about we can query the keystone for this context11:28
tuan_and from that query, we can acquire a new token for this context11:29
tuan_and then continue11:29
d0ugalI guess that could work, it sounds a bit hacky11:29
d0ugalWhy not use trusts?11:29
thervetuan_, How do you acquire a new token?11:30
openstackgerritBrad P. Crochet proposed openstack/mistral-specs master: Adding securing sensitive data spec  https://review.openstack.org/45085311:30
tuan_what about it11:33
tuan_http://paste.openstack.org/show/605044/11:33
tuan_please add comments, ideas, i need to go out for another private problem :(11:33
therveI don't understand how that would work :)11:33
tuan_i will be back soo11:33
therveYour token is expired, you need the user password to get a new one11:33
tuan_yeap11:34
tuan_through the context11:34
tuan_keystone = keystoneclient.Client(**context)11:34
tuan_this line11:34
jaosoriorthat would be done automatically with keystone sessions11:35
bretonoh wow, yes, you should use keystone sessions11:35
breton*keystoneauth sessions11:35
jaosorioryep11:35
tuan_yup,11:35
thervejaosorior, How?11:35
therveSession will refresh the token automatically if you have the password11:36
therveNot on the mistral server side, AFAIU11:36
tuan_i need to run now :D, sorry, i will be back. Just continue11:36
jaosoriorbreton: you're probably better informed than me to answer that ^11:37
jaosorioror jamielennox ^^11:38
jaosorioranyway, therve, tuan_ maybe using trusts in the answer there?11:49
d0ugalI hear from everyone we should move to using trusts :)11:49
d0ugaltuan_: so, I guess, why not use them?11:49
thervejaosorior, Yeah it might, I'm just wondering about the counter argument :)11:50
therveIf there is something simpler, let's use that11:50
therved0ugal, So there is a reason11:50
therveThey don't work with federation11:50
therveDepending on what you need them for, service tokens may be a better idea11:50
jaosoriorI think this issue should be brought to the mailing list. Maybe the keystone folks will have good feedback about this.11:51
therveSure11:52
d0ugaltherve: I see, it is all so complicated :) How do people learn this stuff? Is there good docs I've not found?11:53
d0ugaljaosorior: +111:53
bretontherve: we are working on fixing them for federation11:53
bretontherve: they are already working on some mappings11:54
therved0ugal, Hum just being around that code for a while11:54
bretonwe discussed possible fixes at last meeting11:54
thervebreton, OK. What about your comment about sessions? Is my reasoning correct?11:55
bretontherve: i am not sure. I guess that there are credentials in **context. Instead of passing the credentials to keystoneclient, they should be used to consutruct auth plugin and auth session, and pass that to novaclient11:57
therveOK, but there is no magic that can recreate a token from an expired one :)11:58
*** zhurong has quit IRC11:59
*** shardy_lunch is now known as shardy12:03
*** dprince has joined #openstack-mistral12:08
bretontherve: that's right :)12:17
*** rook is now known as rook|tower12:31
*** catintheroof has joined #openstack-mistral12:36
*** chlong has joined #openstack-mistral12:40
tuan_therve: yeap13:02
tuan_i am back, and sorry not to be clear about that13:02
tuan_what i meant is actually the session13:02
tuan_trusts is one solution13:02
tuan_i just wanna know and find out more solution as much as possible13:02
thervetuan_, Where is the problem stated again?13:03
tuan_well, you mean the token expired?13:03
therveI mean there is a launchpad bug somewhere13:03
tuan_https://bugs.launchpad.net/mistral/+bug/159508413:04
openstackLaunchpad bug 1595084 in Mistral "Workflow execution lifespan is limited by auth token expire time" [High,Confirmed]13:04
tuan_it started last year13:04
tuan_but no concrete answer for that13:04
therveAs so trusts are used for cron triggers13:04
tuan_yeap13:04
therveSo for long workflows, service tokens may be a solution13:04
therveThat's what nova uses for live-migration IIRC13:05
thervehttps://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/use-service-tokens.html13:05
tuan_so to summary, in case the access token expired, we have one solution for service token13:06
tuan_another one is trust with cron job13:06
tuan_but for federation, trust is a good solution13:07
therveNo for federation trusts don't work currently13:08
*** tuan_ has quit IRC13:12
*** toure|gone is now known as toure13:13
tuanand also the solution for one keystone trusts another one13:15
tuantherve: could you update me about it13:15
*** tuan has joined #openstack-mistral13:15
thervetuan, Sorry update about what?13:15
tuanabout the federation13:20
tuani though that trusts is used for one keystone trusting another one13:21
tuan?13:21
therveone keystone user trusting another one13:26
*** sharatss has quit IRC13:27
tuanis it for federation?13:28
therveNo that's totally unrelated13:28
tuanahha, now i got it13:28
tuanokay, thanks guys13:28
tuani am now asking keystone guys for the service token usage13:29
tuani will update you guys later for it13:29
*** amoralej is now known as amoralej|lunch13:54
therved0ugal, I believe there is still an issue with the gate wrt py3.514:15
d0ugaltherve: damn :)14:15
therveAlso overall the gate is still broken :)14:15
d0ugaloh, I thought I just seen some pass14:16
d0ugalbut yeah, I just seen the message not to recheck14:16
d0ugaloops.14:16
*** jamielennox is now known as jamielennox|away14:16
*** bobh has joined #openstack-mistral14:20
*** amoralej|lunch is now known as amoralej14:36
tuanHi guys,14:45
tuanhope you are still there14:45
tuanafter discussing with keystone guys14:46
tuani myself think that obtaining the service token through keystone session by using keystoneauth1 library seems a way to go14:46
tuanif we go with this case14:48
tuanwe have to provide the auth_options for each service, e.g. nova, neutron, etc. into somewhere (may be a conf file and then load them to the oslo config)14:49
tuanthen mistral can use these auth_options to talk to each service if user token is expired14:50
tuanwhat do you guys think about it?14:50
*** jaosorior has quit IRC15:28
*** jpich has quit IRC16:16
*** toure is now known as toure|food16:21
*** shardy has quit IRC17:17
*** toure|food is now known as toure17:35
*** amoralej is now known as amoralej|off18:54
openstackgerritKupai József proposed openstack/mistral master: Limit the number of finished executions.  https://review.openstack.org/44668019:16
*** tuan has quit IRC19:25
*** Qiming has quit IRC20:12
*** Qiming has joined #openstack-mistral20:16
*** dprince has quit IRC20:36
*** Qiming has quit IRC21:01
*** Qiming has joined #openstack-mistral21:02
*** thrash is now known as thrash|g0ne21:24
*** fultonj has quit IRC21:40
*** bobh has quit IRC22:18
*** catintheroof has quit IRC22:36
*** bobh has joined #openstack-mistral23:29
*** bobh has quit IRC23:30
*** bobh has joined #openstack-mistral23:31
*** bobh has quit IRC23:36

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