09:00:12 <ifat_afek> #startmeeting vitrage
09:00:13 <openstack> Meeting started Wed Nov 25 09:00:12 2015 UTC and is due to finish in 60 minutes.  The chair is ifat_afek. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:16 <openstack> The meeting name has been set to 'vitrage'
09:00:24 <ifat_afek> hi everyone :-)
09:00:40 <oetrog> hello
09:00:44 <lhartal> hi :-)
09:01:01 <alexey_weyl> Hello :)
09:01:08 <idan_hefetz> hi
09:01:17 <ohad> hi everyone
09:01:19 <emalin> good morning
09:01:29 <istolber> hi :)
09:01:53 <eyalb> hi
09:02:15 <nyakar> hihi
09:03:00 <^Gal^> hi
09:03:07 <amir_gur> hello
09:03:12 <ifat_afek> Let’s start. Our agenda today:
09:03:33 <ifat_afek> * Current status and progress from last week
09:03:42 <ifat_afek> * Review action items
09:03:50 <ifat_afek> * Next steps
09:03:58 <ifat_afek> * Open Discussion
09:04:08 <ifat_afek> #topic Current status and progress from last week
09:04:28 <ifat_afek> The blueprints are still in the process of being reviewed. We are hoping to get reviews from Doctor, Ceilometer and Monasca teams.
09:04:41 <elishar_> hi everyone
09:04:51 <armen_aghasaryan> hi
09:04:58 <ifat_afek> Regarding manage-ceilometer-alarms blueprint, we are currently in a discussion with Ceilometer guys, specifically with Ryota Mibu (Doctor PTL) and Gordon Chung (Ceilometer PTL).
09:05:02 <elishar_> hi armen - welcome
09:05:13 <aheller> Hi :)
09:05:15 <ifat_afek> The current AODH API does not allow us to trigger our custom deduced alarms. We are checking if it would be possible to add this capability to AODH.
09:05:42 <ifat_afek> We got a few comments from Roland Hochmuth (Monasca PTL). We need to write a blueprint for the integration with Monasca, so they can review it. Anyone can take it?
09:06:12 <nadav> hi again
09:06:47 <ifat_afek> #action ifat_afek need to add a blueprint for monasca
09:07:01 <ifat_afek> Regarding the workplan, here is a link to Mitaka release schedule:
09:07:10 <ifat_afek> #link https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
09:07:25 <ifat_afek> I set the series goal for some of the blueprints we are currently working on to be mitaka-2: get-topology-api, networkx-graph-driver, vitrage-resource-processor and vitrage-cli
09:07:47 <ifat_afek> lhartal, can you update about the meetings we had?
09:08:04 <lhartal> We  had a design meeting on our first use case – Show Topology
09:08:34 <lhartal> In the meeting we discussed the following blueprints, which are relevant to this use case: Vitrage Graph component, Vitrage Graph driver, get topology API, Vitrage API and Vitrage graph transformers
09:08:45 <lhartal> Additionally, we need to add a new blueprint – Nova Transformer
09:09:06 <lhartal> This blueprint explains the transformer mechanism with implementation of our first use case (Representation of nova.instances and nova.machines in the graph)
09:10:13 <alexey_weyl> liat: *component=processor
09:11:28 <lhartal> you right :)
09:11:34 <ifat_afek> ok, thanks. nadav, can you update regarding the progress you had with the synchronizer?
09:11:47 <nadav> sure:
09:12:02 <nadav> I have divided our work to stories which are to be prioritized and assigned to people in the following days. synchronizer blueprint design updated, awaiting approval
09:12:58 <nadav> we have had a meeting regarding the graph and the synchronizer modules interfacing and concluded that the synchronizer response - it would contain a dictinary which its data is to be determined per plugin
09:13:35 <lhartal> #action lhartal To add Nova Transformer blueprint
09:14:04 <nadav> and finally, regarding concurrency best practices - per a consultation with Julien from AODH will be implemented via multiple subprocesses for utilization of multiple cores via python-multiprocessing library. We might also use python threads, which are lighter but not multiple core , for blocking I/O operations
09:14:40 <ifat_afek> Thanks. Can you split the synchronizer blueprint to smaller blueprints, according to your work plan? also, please check what part of the synchronizer blueprint can be completed by mitaka-2.
09:15:10 <nadav> np. we have already started this process
09:15:40 <ifat_afek> thanks
09:15:42 <ifat_afek> #action nadav split the synchronizer blueprint and check what can be done for mitaka-2
09:15:51 <ifat_afek> aheller, can you update on the UI progress?
09:16:08 <alonh> sure...
09:16:50 <alonh> We pushed our first commit yesterday: So you can see it in the vitrage-dashboard
09:17:17 <ifat_afek> great!!
09:17:20 <alexey_weyl> Way the go :)
09:17:24 <alonh> It contains "Hello World" as a plugin of Horizon
09:17:33 <lhartal> good new :-)
09:18:33 <alonh> More than that, we talked about the design, and the solution of how we want to show it on the UI
09:18:33 <omer_etrog> now we need to add the vitrage service to the plugin
09:18:44 <alonh> and the Karma tests :)
09:19:34 <ifat_afek> Thanks. Do you know if your sunburst blueprint can be ready for mitaka-2?
09:19:40 <ifat_afek> january 21
09:20:37 <alonh> Quickly... I think yes, but we still have unknown issues like the d3 framework limitations, and the unknown design.
09:20:51 <alonh> So... I don't know for sure
09:21:36 <ifat_afek> ok, thanks
09:21:42 <ifat_afek> I’d like to check also the status of the other blueprints we have started working on.
09:21:51 <ifat_afek> eyalb, can you updated on get-topology-api and vitrage-cli?
09:21:59 <eyalb> yes sure
09:22:01 <alonh> last thing, We also dependent on the API from other team
09:22:16 <ifat_afek> of course
09:22:22 <eyalb> I continue working on the vitrage client
09:22:52 <eyalb> we decided on the type of response we will get that will describe a topology
09:23:07 <eyalb> it will be a json graph spec
09:23:25 <eyalb> #link http://jsongraphformat.info/
09:23:57 <eyalb> we will also add some filter options for get topology
09:24:18 <eyalb> so the client can get sub parts of the graph
09:24:42 <eyalb> I started updating the blueprints of the api and client
09:25:06 <eyalb> and started looking how to implement the api service
09:25:25 <eyalb> also I need to add tests for the client
09:26:07 <alonh> I'm not so sure about the graph. The topology can be describe as a tree
09:26:13 <eyalb> although I might wait for the server api and then I can do full functional tests
09:26:25 <eyalb> using tempestr
09:26:33 <eyalb> thats all :-)
09:26:49 <eyalb> we talked to noy and we cant
09:26:55 <elishar_> we will also need to see if there are cases, when the api response is known to be a tree, that we want to return a tree. we need to scope out the use cases and see if the ui can easily use a  graph instead of needing a tree.
09:26:57 <ifat_afek> eyalb; by server api do you mean the graph driver api?
09:27:23 <armen_aghasaryan> will the topology include later on horizontal relation defined by heat?
09:27:23 <alonh> When talking about storage, we can't. But when talking on topology (hosts, vms, etc...) we can
09:27:30 <eyalb> the vitrage-api service
09:28:12 <elishar_> armen_aghasaryan: you mean horizontal as in direct relationships between instances (vms)?
09:28:21 <armen_aghasaryan> yes
09:28:24 <eyalb> if we add a filter that asks for only hosts and vms then ask for a tree representation
09:30:02 <elishar_> armen_aghasaryan: I think that's a design decision we will make at a later stage, though my inclination is yes.
09:30:31 <eyalb> this can be another filter to add --tree or --graph
09:30:59 <armen_aghasaryan> indeed in this case, you dont have anymore a tree
09:33:15 <elishar_> indeed, it is clear we will need to support a general graph representation. However, some queries to the graph might yield a tree, and then the UI might have tree-oriented visualization techniques they can use
09:34:02 <eyalb> if a tree representation is not possible for the query then an http error response will be sent
09:34:11 <ifat_afek> sounds good
09:35:39 <ifat_afek> eyalb: I want to make sure I understood. you are currently working on the client, and only later will work on the api?
09:35:54 <eyalb> both
09:35:58 <ifat_afek> ok
09:36:17 <eyalb> since they talk to each other :-)
09:36:29 <ifat_afek> let's move on. . Idan, can you update on networkx-graph-driver?
09:36:43 <idan_hefetz> yea
09:37:14 <idan_hefetz> The blueprint defines the basic graph interface and includes an implementation for NetworkX.
09:37:39 <idan_hefetz> I had discussions with Liat and Alexey to make sure the interface is sufficient to support other blueprints.
09:37:55 <idan_hefetz> already have a prototype and I will soon send a patch, so we can begin using it.
09:38:27 <ifat_afek> great, thanks
09:38:29 <ifat_afek> alexey_weyl, can you update on vitrage-resource-processor?
09:38:47 <alexey_weyl> started to work on the Processor with Dany and Nofar.
09:39:44 <alexey_weyl> I need to talk with the Transformer, Synchronizer and GraphDriver people in order to to the integration with those parts
09:40:14 <alexey_weyl> In addition, I started to look how the vitrage should start and everything should run there
09:40:30 <alexey_weyl> So, in order to do this, we need to start our services
09:40:39 <alexey_weyl> for example, processor service
09:41:11 <alexey_weyl> the way to do this is to inherite from oslo.service
09:41:19 <alexey_weyl> and implimenet this class
09:41:39 <alexey_weyl> and as well to add a script in openstack which will call to this service and raise it up
09:41:57 <ifat_afek> ok, thanks. let's move on
09:42:05 <ifat_afek> #topic Review action items
09:42:17 <ifat_afek> let's review our action items from the previous meeting
09:42:38 <^Gal^> I have some updaes
09:42:49 <^Gal^> Regarding: https://blueprints.launchpad.net/horizon/+spec/ceilometer-alarm-management-page
09:42:59 <^Gal^> I've managed to contact the assignee: Sanjana from Hitachi.
09:43:05 <^Gal^> He says he'll commit his code very soon
09:43:43 <ifat_afek> great
09:43:54 <ifat_afek> thanks ^Gal^
09:44:01 <^Gal^> sure, np
09:44:15 <ifat_afek> other action items:
09:44:29 <ifat_afek> * lhartal document API in Vitrage wiki page
09:46:19 <lhartal> we already did the design but yet published it
09:46:44 <ifat_afek> ok, I think we already have an action item for next time about it
09:46:53 <ifat_afek> * ifat_afek finish the last blueprint
09:47:14 <ifat_afek> We did not yet write the blueprint with all of our use cases. Anyone wants to do it?
09:48:48 <elishar_> we need to have a blueprint for a set of initial use cases. With each batch of use cases we will need to have a corresponding blueprint.
09:48:58 <ifat_afek> I agree
09:49:03 <elishar_> however, we still have to decide which will be the first use cases we want to do
09:49:42 <elishar_> by "use case" I mean a deduced alarm/rca use case
09:50:40 <elishar_> I think we should wait until we see how we progress with the synchonizers before deciding on what it is
09:50:50 <ifat_afek> makes sense
09:50:58 <ifat_afek> so let's wait with this blueprint
09:51:09 <ifat_afek> next action item: nadav_yakar update synchronizer blueprint and gerrit
09:52:07 <nadav> done, waiting for review
09:52:15 <ifat_afek> great
09:52:21 <ifat_afek> * elisha_rosensweig decide on where to get the list alarms ui
09:53:32 <elishar_> so we had some email correspondence with ceilometer representatives about this issue. we're in the process of understanding the capabilities of AODH in this regard.
09:53:41 <ifat_afek> #action ifat_afek finish the discussions with AODH regarding our integration with them
09:54:04 <ifat_afek> next: nadav_yakar find a best practice for concurrency handling in openstack projects
09:54:31 <nadav> done, see my response on the beginning of the conversation
09:54:44 <ifat_afek> thanks. next: finish review of the blueprints
09:54:56 <ifat_afek> We did not finish the reviews, as we still hope we can get reviews from Doctor, Ceilometer and Monasca guys
09:55:06 <ifat_afek> #action finish review of the blueprints
09:55:21 <ifat_afek> last one: decide what information is part of the synchronizer events
09:56:19 <nadav> will be done per plugin once developed. Please see full comment on the beginning of the conversation for the full details
09:56:39 <ifat_afek> ok. next topic
09:56:45 <ifat_afek> #topic Next Steps
09:56:55 <ifat_afek> We need to start thinking about our tests. I will schedule a meeting with Marina and Eliran, so they can explain us what they know about the tempest tests.
09:57:07 <ifat_afek> #ifat_afek schedule a meeting regarding tempest
09:57:25 <ifat_afek> anything else?
09:57:44 <ifat_afek> #topic Open Discussion
09:58:34 <amir_gur> is it possible to write vitrage using python 3?
09:59:03 <eyalb> yes
09:59:09 <emalin> Does oslo support python3 ?
09:59:22 <eyalb> we need to make sure our code is compitable
09:59:44 <elishar_> from what i've read, it seems that using python3 is possible, but has problems due to dependencies within openstack whcih is currently in 2.x
09:59:49 <eyalb> you can check in the setup.cfg project
09:59:55 <ifat_afek> we are out of time. thanks everyone :-)
10:00:01 <ifat_afek> #endmeeting