*** IlyaE has joined #murano | 00:01 | |
*** IlyaE has quit IRC | 00:05 | |
*** rakhmerov has joined #murano | 00:29 | |
*** rakhmerov has quit IRC | 00:33 | |
*** IlyaE has joined #murano | 00:42 | |
*** wirehead_ has joined #murano | 00:46 | |
*** wirehead_ has left #murano | 00:55 | |
*** IlyaE has quit IRC | 01:01 | |
*** rakhmerov has joined #murano | 01:29 | |
*** gokrokve_ has quit IRC | 01:30 | |
*** rakhmerov has quit IRC | 01:34 | |
*** gokrokve has joined #murano | 02:16 | |
*** rakhmerov has joined #murano | 02:30 | |
*** rakhmerov has quit IRC | 02:34 | |
*** gokrokve has quit IRC | 02:35 | |
*** rakhmerov has joined #murano | 02:41 | |
*** gokrokve has joined #murano | 03:05 | |
*** IlyaE has joined #murano | 03:55 | |
*** chandankumar_ has quit IRC | 05:28 | |
*** IlyaE has quit IRC | 06:32 | |
*** gokrokve has quit IRC | 06:37 | |
*** saju_m has joined #murano | 07:02 | |
*** IlyaE has joined #murano | 07:43 | |
*** IlyaE has quit IRC | 08:11 | |
*** asalkeld has quit IRC | 08:11 | |
*** openstackgerrit has quit IRC | 08:11 | |
*** tnurlygayanov has quit IRC | 08:11 | |
*** saju_m has quit IRC | 08:11 | |
*** igormarnat has quit IRC | 08:11 | |
*** bogdando has quit IRC | 08:11 | |
*** dteselkin_ has quit IRC | 08:11 | |
*** killer_prince has quit IRC | 08:11 | |
*** smurashov has quit IRC | 08:11 | |
*** sergmelikyan has quit IRC | 08:11 | |
*** tsufiev___ has quit IRC | 08:11 | |
*** katyafervent has quit IRC | 08:11 | |
*** ruhe has quit IRC | 08:11 | |
*** ogelbukh has quit IRC | 08:11 | |
*** akuznetsova has quit IRC | 08:11 | |
*** ativelkov has quit IRC | 08:11 | |
*** ekarlso has quit IRC | 08:11 | |
*** IgorYozhikov has quit IRC | 08:11 | |
*** asalkeld has joined #murano | 08:29 | |
*** tnurlygayanov has joined #murano | 08:29 | |
*** openstackgerrit has joined #murano | 09:01 | |
*** saju_m has joined #murano | 09:01 | |
*** ekarlso has joined #murano | 09:01 | |
*** bogdando has joined #murano | 09:01 | |
*** killer_prince has joined #murano | 09:01 | |
*** smurashov has joined #murano | 09:01 | |
*** sergmelikyan has joined #murano | 09:01 | |
*** ruhe has joined #murano | 09:01 | |
*** ogelbukh has joined #murano | 09:01 | |
*** IgorYozhikov has joined #murano | 09:01 | |
*** igormarnat has joined #murano | 09:01 | |
*** dteselkin_ has joined #murano | 09:01 | |
*** tsufiev___ has joined #murano | 09:01 | |
*** katyafervent has joined #murano | 09:01 | |
*** akuznetsova has joined #murano | 09:01 | |
*** ativelkov has joined #murano | 09:01 | |
*** ativelkov has quit IRC | 09:05 | |
*** saju_m has quit IRC | 09:19 | |
*** saju_m has joined #murano | 09:34 | |
openstackgerrit | Sergey Murashov proposed a change to stackforge/murano-tests: Add script which compares the requirements https://review.openstack.org/78146 | 09:35 |
---|---|---|
openstackgerrit | Sergey Murashov proposed a change to stackforge/murano-tests: Add script which compares the requirements https://review.openstack.org/78146 | 09:43 |
*** ativelkov has joined #murano | 09:59 | |
ruhe | smurashov: ping. why do you need a copy of a script which already existing in openstack-infra/config and is already used in murano jenkins jobs? | 10:00 |
tnurlygayanov | we have some modifications for this script ) | 10:01 |
tnurlygayanov | we have parameters 'allowed count of known errors' | 10:01 |
tnurlygayanov | this will allow to avoid extra alarm while we will not move all requirements to global requirements. | 10:02 |
ruhe | tnurlygayanov: we alreaday have check-requirements jobs right? you want to add something new and ignore error messages about real problems we have? | 10:03 |
ruhe | link https://git.openstack.org/cgit/openstack-infra/config/tree/modules/jenkins/files/slave_scripts/project-requirements-change.py | 10:04 |
openstackgerrit | Sergey Murashov proposed a change to stackforge/murano-tests: Add script which compares the requirements https://review.openstack.org/78146 | 10:05 |
tnurlygayanov | ruhe, yes | 10:06 |
ruhe | tnurlygayanov: it seems like a bad idea. i'd prefer to be alerted in each patch until we resolve all requirements issues | 10:07 |
tnurlygayanov | ruhe: we have check-requirements jobs. And these jobs fail all the time because we have some problems with global requirements now. | 10:07 |
tnurlygayanov | so | 10:07 |
tnurlygayanov | the idea is to have additional check which will test requirements with ignoring the known issues | 10:08 |
tnurlygayanov | to have the ability to detect real unknown problems | 10:08 |
ruhe | i wouldn't mind to have additional check | 10:08 |
tnurlygayanov | yes, and now we will have this check ) | 10:09 |
ruhe | oh, one moment | 10:10 |
ruhe | when do you think we will resolve all the requirements issues? | 10:11 |
ruhe | i guess very soon | 10:11 |
tnurlygayanov | I don't know. probably it will take about 1-2 months | 10:12 |
ruhe | tnurlygayanov: you had a bunch of patches yesterday to bring some of the requirements up to date. i thought that custom puka is the only one left | 10:17 |
tnurlygayanov | yes, we have this document https://docs.google.com/spreadsheet/pub?key=0Aiup6hoNUUUedGt3cnJIMHAxbTlHdlFDZGhxLS1yRXc&output=html | 10:19 |
tnurlygayanov | I don't know how we can fast fix the issue with custom puka | 10:20 |
tnurlygayanov | this is marked with red bold in this table | 10:20 |
ruhe | tnurlygayanov: sergmelikyan is working on that already | 10:21 |
tnurlygayanov | yes, but it is not done yet. | 10:23 |
tnurlygayanov | also we have bunch, deep, yaql and django-floppyforms | 10:24 |
tnurlygayanov | which is not presented in global requirements | 10:24 |
*** igormarnat has quit IRC | 10:30 | |
*** sergmelikyan has quit IRC | 10:31 | |
*** igormarnat has joined #murano | 10:31 | |
tnurlygayanov | Guys, I want to commit some packages (bunch and dee) to global requirements repo. You ok with this idea? | 10:32 |
*** dteselkin_ has quit IRC | 10:32 | |
*** IgorYozhikov has quit IRC | 10:32 | |
*** dteselkin has joined #murano | 10:32 | |
*** katyafervent is now known as katyafervent_awa | 10:33 | |
*** IgorYozhikov has joined #murano | 10:33 | |
tnurlygayanov | What about django-floppyforms ? | 10:36 |
tnurlygayanov | tsufiev___: do we plan to remove requirement django-floppyforms for murano-dashboard? | 10:36 |
*** gokrokve has joined #murano | 10:52 | |
*** gokrokve_ has joined #murano | 10:54 | |
*** gokrokve has quit IRC | 10:57 | |
*** katyafervent_awa is now known as katyafervent | 10:58 | |
*** gokrokve_ has quit IRC | 10:59 | |
tsufiev___ | tnurlygayanov: nope | 11:15 |
*** tsufiev___ is now known as tsufiev | 11:15 | |
tnurlygayanov | ok | 11:26 |
tnurlygayanov | looks like we should remove all external dependencies which are not presented in global requirements | 11:26 |
*** lazy_prince has joined #murano | 11:44 | |
*** gokrokve has joined #murano | 11:52 | |
*** killer_prince has quit IRC | 11:55 | |
*** lazy_prince is now known as killer_prince | 11:56 | |
*** gokrokve has quit IRC | 11:56 | |
*** IgorYozhikov has quit IRC | 11:56 | |
*** IgorYozhikov has joined #murano | 12:03 | |
*** chandan_kumar has joined #murano | 12:11 | |
*** rakhmerov has quit IRC | 12:36 | |
*** rakhmerov has joined #murano | 12:38 | |
*** rakhmerov has quit IRC | 12:42 | |
*** gokrokve has joined #murano | 12:52 | |
*** gokrokve has quit IRC | 12:56 | |
*** rakhmerov has joined #murano | 13:02 | |
*** rakhmerov has quit IRC | 13:06 | |
*** sergmelikyan has joined #murano | 13:15 | |
*** gokrokve has joined #murano | 13:52 | |
*** gokrokve has quit IRC | 13:57 | |
*** rakhmerov has joined #murano | 14:02 | |
*** rakhmerov has quit IRC | 14:07 | |
*** saju_m has quit IRC | 14:15 | |
*** gokrokve has joined #murano | 14:25 | |
*** IlyaE has joined #murano | 14:28 | |
*** gokrokve has quit IRC | 14:28 | |
*** gokrokve has joined #murano | 14:33 | |
*** rakhmerov has joined #murano | 14:42 | |
*** rakhmerov has quit IRC | 14:54 | |
*** rakhmero_ has joined #murano | 15:22 | |
*** rakhmero_ has quit IRC | 15:27 | |
*** rakhmerov has joined #murano | 15:29 | |
*** rakhmerov has quit IRC | 15:33 | |
*** rakhmerov has joined #murano | 15:39 | |
*** chandan_kumar has quit IRC | 15:51 | |
ativelkov | Hi folks! | 16:01 |
ativelkov | Anybody here for an eventhandling discussion? | 16:01 |
gokrokve | Hi | 16:02 |
*** stanlagun has joined #murano | 16:03 | |
gokrokve | I suggest to start the discussion | 16:05 |
ativelkov | Hi | 16:07 |
ativelkov | Should we do it here or may we move to some voice chat? | 16:07 |
ruhe | hi | 16:08 |
ativelkov | as it turns out that there are just a few people here | 16:08 |
stanlagun | hi | 16:08 |
gokrokve | this is fine. We will come to agreement faster :-) | 16:10 |
gokrokve | So. Let me again define what we want to have. | 16:10 |
gokrokve | 1) Applications can define different actions which can be triggered by some external event | 16:11 |
gokrokve | 2) There is no currently a mechanism to pass the event to Murano | 16:11 |
gokrokve | 3) The existing projects use: | 16:12 |
gokrokve | a) HTTP hooks to expose hook for an event | 16:12 |
gokrokve | b) MQ message or notification to trig an event | 16:12 |
gokrokve | c) potentially one can use API call to trig an event but I did not see this approach implemented in any OpenStack project | 16:13 |
gokrokve | 4) User will want to be able to enable or disable event handler | 16:14 |
gokrokve | 5) User will want to find information about existing event handlers exposed by application | 16:14 |
gokrokve | this is a brief definition of what is required. | 16:15 |
ruhe | gokrokve: for a healthy discussion it would be nice to have a list of core use-cases you would like to solve with your proposal | 16:15 |
gokrokve | There are some: | 16:16 |
gokrokve | 1) Autoscaling - scale up or scale down events triggered by Ceilometer and handled by Murano\Heat | 16:16 |
ativelkov | Could you please exaplain what do you mean by "existing projects"? | 16:17 |
gokrokve | 2) Periodic tasks for applications like backups, triggered by external scheduller -Mistral -> Murano handler | 16:17 |
sergmelikyan | ativelkov, and what difference between 3a and 3c | 16:17 |
gokrokve | "Existing projects" Heat, Ceilometer, Trove,.... | 16:17 |
sergmelikyan | Heat support WaitConditions through API Call (as it is done AWS) | 16:18 |
gokrokve | 3a) non authenticated HTTP hook which is simple GET or may be POST request handler. Uses some shared secred for security. | 16:18 |
gokrokve | 3c) a special API methods defined as a part of API specs, use keystone authentication and specific path in API tree | 16:19 |
ativelkov | So, these "hooks" are exposed not by the application definitions | 16:19 |
ativelkov | They are exposed by their particular instances | 16:19 |
ativelkov | I.e., the application definition define a "scaleUp" action | 16:20 |
gokrokve | ativelkov: Did i wrote application definitions expose something? | 16:20 |
ativelkov | no, you just wrote "application" | 16:20 |
ativelkov | but this may mean both definition and its instance | 16:21 |
ativelkov | so I wanted to clearly state the difference | 16:21 |
ativelkov | definitions define actions | 16:21 |
ativelkov | for a given instance it is possible to wire-up any action with a public URL or notification | 16:21 |
gokrokve | Yes. Application definition contains some information about actions it want to expose. | 16:22 |
ativelkov | yep, so, we've got the context | 16:22 |
ativelkov | afaik, stanlagun had some concerns about it. | 16:22 |
gokrokve | There is a reason why I want to have a specific DSL entiry for events, not just actions | 16:22 |
ativelkov | gokrokve: what do you mean? | 16:23 |
gokrokve | 1) event definition can be abstracted from actual implementation | 16:23 |
sergmelikyan | gokrokve, what the reason behind specific entity vs action + access definition? | 16:23 |
ativelkov | wait | 16:23 |
ativelkov | there is some terminology issue here | 16:23 |
gokrokve | 2) event handler definition can have text description which will be shown in UI | 16:23 |
ativelkov | "event" is something which happens externally | 16:24 |
ativelkov | DSL does not know anything about the events | 16:24 |
gokrokve | s/event/event handler | 16:24 |
ativelkov | It may just define "event handlers" | 16:24 |
ativelkov | yup, this is much better | 16:24 |
ativelkov | but "event handlers" are just action | 16:24 |
ativelkov | s | 16:24 |
gokrokve | ativelkov: Do not mix implementation and definition | 16:25 |
ativelkov | every event handler is an action, while not all the actions are event handlers | 16:25 |
gokrokve | yes, event handlers are actions | 16:25 |
gokrokve | thats clear | 16:25 |
stanlagun | there can be more than 1 handler for each event | 16:25 |
stanlagun | and event source cannot be aware of event handlers | 16:26 |
gokrokve | but there is a difference between event handler and actions in a sense that for user it has some special memaning | 16:26 |
gokrokve | stanlagun: yes. so we need to provide a way to describe even handlers to expose some meaningfull information for user and event source | 16:27 |
gokrokve | add an ability to find this handler, without preliminary knowledgr of application internals | 16:27 |
ativelkov | So, we speak about some addiional markup for workflow's actions which will: 1) indicate that the action is publicly available, 2) provide information of what this action does | 16:28 |
gokrokve | ativelkov: Yes, exactly | 16:28 |
ativelkov | And we will have an API returning this list of these actions with their descriptions | 16:28 |
gokrokve | Yes | 16:29 |
stanlagun | actions != event handlers | 16:29 |
ativelkov | yes | 16:29 |
ativelkov | I would agree | 16:29 |
ativelkov | event handlers are defined by the user | 16:29 |
ativelkov | user specifies the event source (URL or notfication type) | 16:29 |
ativelkov | in the UI for the deployed instance of application | 16:29 |
ativelkov | And then selects one or more actions to handle it | 16:29 |
sergmelikyan | and than maps to the actual actions? | 16:30 |
ativelkov | sergmelikyan: exactly | 16:30 |
gokrokve | ativelkov: event handlers are defined by application writer. They are actions in DSL. | 16:30 |
stanlagun | not neccessary | 16:30 |
gokrokve | ativelkov: I don't like an idea user maps something to actions | 16:30 |
stanlagun | This can be more complex. Applications may subscribe to event themselv. But external systems sygnal event conditions | 16:31 |
gokrokve | User do not know the implementation details. He should not know any action name | 16:31 |
ativelkov | well, user has to manually define the endpoint anyway | 16:31 |
stanlagun | User is cloud admin in this case | 16:31 |
gokrokve | No, | 16:31 |
gokrokve | Let me explain | 16:32 |
gokrokve | I think event handlers will be a part of DSL code and it will be an application writer responsibility to designe how application will interact with external world. | 16:32 |
gokrokve | For example I am creation DB application and I want to provide an abiliity to do backup on DB | 16:33 |
ativelkov | In this case you define an action is "public" | 16:33 |
gokrokve | As an Application writer I say in app definition: | 16:33 |
ativelkov | and set its desctipyion | 16:33 |
ativelkov | like this | 16:34 |
gokrokve | expose event handler "onBackup" | 16:34 |
ruhe | or in case of Savanna App publisher would like to run periodic MapReduce jobs | 16:34 |
gokrokve | descr "This is a handler for backup event. External system can trig a backup process to start on DB instance" | 16:34 |
ruhe | Which bring me to a question - how will the caller get the keystone token? | 16:35 |
gokrokve | So. This is application writer responsibility to architect app edfinition and expose meaningfull handlers for some particular events | 16:35 |
ativelkov | workflow: | 16:35 |
ativelkov | backup: | 16:35 |
ativelkov | Type: Public | 16:35 |
gokrokve | ruhe: use keystone trusts, use non authenticated HTTP hook with secret | 16:35 |
ativelkov | Description: This handles the database backup | 16:35 |
ativelkov | Body: | 16:35 |
ativelkov | ... | 16:35 |
ativelkov | hm.. IRC cuts-out tabs | 16:36 |
gokrokve | ativelkov: Yes. something like that | 16:36 |
sergmelikyan | ruhe - we can expose any event handler to anyone with a user-token, and only certain eventhandler with defined public endpoint to not authenticated ones | 16:36 |
gokrokve | I don't know how it shoould look like in YAML | 16:36 |
ativelkov | http://paste.openstack.org/show/72649/ | 16:36 |
ativelkov | But there is nothing about actual event here | 16:37 |
ativelkov | User still has to map it to the event source | 16:37 |
ativelkov | i.e. to the URL call or notification | 16:38 |
ativelkov | And what I say is that the user should be able to map a single event source to multiple actions | 16:39 |
sergmelikyan | ativelkov, do you mean cloud-user, not application writer? | 16:40 |
ativelkov | yes, the end-user | 16:40 |
ativelkov | because this will be done for a particular instance of application | 16:40 |
ativelkov | not for the definition | 16:40 |
stanlagun | What if one app whants to handle events happening in another app? | 16:41 |
gokrokve | ativelkov: For now I think it will be enough just to show hook URL in UI | 16:41 |
gokrokve | so user can go and copy&paste it to eny external event source | 16:42 |
gokrokve | these event source are not necessary OpenStack components | 16:42 |
gokrokve | but | 16:42 |
gokrokve | Also we ned to support the use case when app writer knows that there is an external system in his environment which will exist (like private cloud) | 16:43 |
gokrokve | and app writer will nedd to add an event handler link to this ext system via DSL | 16:43 |
gokrokve | he will have a special function to configure this external system | 16:44 |
gokrokve | So we need to provide a way to obtain thins event link in runtime in DSL | 16:44 |
gokrokve | to be able to express something like | 16:44 |
gokrokve | $.monitoring.addEventHook($.hookLink) | 16:45 |
ativelkov | This will not work | 16:46 |
ativelkov | as the link exists per application instance | 16:46 |
ativelkov | so this links will need to generated by the engine | 16:47 |
ativelkov | like $.generateEventLink(eventName) | 16:47 |
ativelkov | then this will generate a link like hostname/api/environemnet_id/application_id/event_name/some_secret_key | 16:49 |
*** openstackgerrit has quit IRC | 17:32 | |
*** rakhmerov has quit IRC | 17:58 | |
*** gokrokve has quit IRC | 18:22 | |
*** openstackgerrit has joined #murano | 18:26 | |
*** rakhmerov has joined #murano | 18:29 | |
*** IlyaE has quit IRC | 18:31 | |
*** rakhmerov has quit IRC | 18:31 | |
*** rakhmerov has joined #murano | 18:31 | |
*** rakhmerov has quit IRC | 18:36 | |
*** IlyaE has joined #murano | 18:48 | |
*** openstackgerrit has quit IRC | 19:02 | |
*** egorkamis has joined #murano | 19:07 | |
*** gokrokve has joined #murano | 19:23 | |
*** rakhmerov has joined #murano | 19:32 | |
*** rakhmerov has quit IRC | 19:34 | |
*** rakhmerov has joined #murano | 19:34 | |
*** egorkamis has quit IRC | 19:36 | |
*** rakhmerov has quit IRC | 19:38 | |
*** asalkeld has quit IRC | 19:44 | |
*** _dim_ has joined #murano | 19:52 | |
*** _dim_ has left #murano | 19:53 | |
*** asalkeld has joined #murano | 19:57 | |
*** rakhmerov has joined #murano | 20:34 | |
*** IlyaE has quit IRC | 20:36 | |
*** IlyaE has joined #murano | 20:38 | |
*** rakhmerov has quit IRC | 20:39 | |
*** gokrokve has quit IRC | 20:51 | |
*** mordashova has joined #murano | 21:34 | |
*** rakhmerov has joined #murano | 21:35 | |
*** rakhmerov has quit IRC | 21:39 | |
*** asalkeld has quit IRC | 21:58 | |
*** asalkeld has joined #murano | 22:10 | |
*** rakhmerov has joined #murano | 22:36 | |
*** rakhmerov has quit IRC | 22:40 | |
*** openstack has joined #murano | 23:03 | |
*** mordashova has quit IRC | 23:03 | |
*** rakhmerov has joined #murano | 23:37 | |
*** rakhmerov has quit IRC | 23:41 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!