08:00:49 <ifat_afek> #startmeeting vitrage
08:00:50 <openstack> Meeting started Wed Jun 20 08:00:49 2018 UTC and is due to finish in 60 minutes.  The chair is ifat_afek. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:00:54 <openstack> The meeting name has been set to 'vitrage'
08:00:58 <ifat_afek> Hi :-)
08:01:00 <e0ne> hi
08:01:04 <eyalb> \o/
08:01:48 <idankin> Hi
08:02:43 <najjar> hi \o/
08:02:52 <annarez> Hi :)
08:04:18 <ifat_afek> Agenda:
08:04:18 <ifat_afek> •	Status and updates
08:04:19 <ifat_afek> •	StoryBoard migration
08:04:20 <ifat_afek> •	Open discussion
08:04:31 <ifat_afek> #topic Status and updates
08:04:48 <ifat_afek> The Technical Committee published new guidelines for code reviews
08:04:53 <ifat_afek> #link https://docs.openstack.org/project-team-guide/review-the-openstack-way.html
08:05:04 <ifat_afek> I think that the main change is: don’t -1 and block the change for minor issues. It is better to approve with comments, and fix them later in a follow-up change.
08:05:29 <ifat_afek> Reminder: Berlin CFP is open! We can submit session proposals until July 17th, so start thinking about ideas.
08:05:36 <ifat_afek> #link https://www.openstack.org/summit/berlin-2018/call-for-presentations/
08:05:59 <ifat_afek> Another update is about Heat. In the self-healing forum in Vancouver I’ve had a discussion with Rico Lin, the Heat PTL, about integration Vitrage in Heat.
08:06:08 <ifat_afek> eyalb and I continued this discussion via mail, and we are thinking about implementing the following scenario:
08:06:16 <ifat_afek> Network failure -> monitored using an external monitor -> notify Vitrage -> trigger Mistral workflow for healing the Heat stack
08:06:31 <ifat_afek> We have demonstrated similar scenarios in the past, but the difference is that this time it will be managed by Heat: in the HOT template the user will specify the trigger and the Mistral healing workflow.
08:06:56 <annarez> Cool!
08:07:20 <ifat_afek> We are going to write a detailed desing in an etherpad and publish it, so you’ll be able to comment and add ideas. It should be done today or tomorrow
08:07:31 <ifat_afek> And we hope to finish this integration in Rocky
08:07:48 <eyalb> +2
08:08:20 <ifat_afek> That’s it for me. Anyone else wants to update?
08:08:49 <najjar> I'll update.
08:09:36 <najjar> regarding to Prometheus... the datasource is ready \o/
08:09:38 <najjar> but
08:10:42 <najjar> i'm working on vitrage ap to correctly get Prometheus alarms
08:11:21 <najjar> this requests some changes in api and adding another authentication method
08:11:28 <eyalb> we should configure the api-paste.ini for the path for post event to use a different auth plugin
08:11:31 <najjar> requires*
08:12:01 <najjar> eyalb okey
08:12:04 <eyalb> or even not to use authentication at all
08:12:16 <e0ne> najjar: is it backward-compatible change in the api?
08:12:23 <eyalb> yes
08:12:42 <e0ne> ok
08:13:19 <najjar> e0ne for now the answer is yes
08:13:23 <ifat_afek> e0ne: I think the main problem with the vitrage event post API is that it was written for test purposes for OPNFV Doctor project
08:13:35 <ifat_afek> And it was never used with real monitors
08:13:51 <ifat_afek> So now we are trying to make it work “for real”, and we hope not to change the API
08:13:54 <e0ne> :(
08:14:23 <najjar> e0ne does this has any affect in your side ?
08:14:38 <ifat_afek> Doctor project defined a “SB API” that should be used by an Inspector component (Vitrage in this case), and I implemented the API by their definitions
08:14:45 <e0ne> I'm working on upgrades stuff, so I worry about backward compatibility
08:14:50 <ifat_afek> But until you use something for real, you are not sure it’s ok
08:15:07 <ifat_afek> But this is API, no DB involved
08:15:13 <ifat_afek> So does it still affect you?
08:15:42 <e0ne> I hope, no
08:16:01 <eyalb> if the api will change we can use v2
08:16:12 <e0ne> it will be easier to answer when patch with api change will be in gerrit
08:16:20 <ifat_afek> Sure
08:16:31 <e0ne> eyalb: or microversion
08:16:40 <eyalb> yes
08:17:49 <ifat_afek> e0ne: regarding the upgrade - suppose you finish it and everything will be OK. Will there be a test that automatically breaks next time we do DB changes?
08:17:59 <ifat_afek> Just wondering :-)
08:18:28 <e0ne> ifat_afek: sure, db migrations are in progress
08:18:38 <e0ne> #link https://review.openstack.org/#/c/575150/
08:19:02 <e0ne> we're hitting with config-related issues now
08:19:30 <ifat_afek> I know, I’m just not familiar with the process. My question was will we know next time we do something wrong ;-) and I see that there are some tests in this change
08:19:30 <e0ne> it's mostly because vitrage uses oslo.config in a different way than other projects do :(
08:19:43 <ifat_afek> What’s different?
08:20:06 <e0ne> ifat_afek: in general, we should have db migrations tests
08:20:26 <ifat_afek> Ok, thanks
08:20:35 <e0ne> ifat_afek: backward incompatible api changes and config changes will handled by grenade job
08:20:46 <e0ne> #link https://review.openstack.org/575115
08:20:55 <e0ne> grenade job is almost ready
08:21:12 <ifat_afek> Sounds great
08:21:36 <e0ne> I need to add some tests into that, but I would like to do it step-by-step and implement tests in a follow-up patch
08:21:57 <ifat_afek> So what is the problem with oslo.config?
08:22:00 <e0ne> so, if anybody have time, please, review it
08:22:12 <e0ne> ifat_afek: not really problem, but..
08:22:41 <ifat_afek> Sure, I wasn’t sure if it’s ready for review. I will review it later today
08:22:54 <e0ne> we build  config object in vitrage.service.prepare_service method
08:23:14 <e0ne> and pass that instance into all service instances
08:23:36 <e0ne> that's why we need some dirty hacks in tests
08:24:05 <e0ne> for note: I'm not saying that it's bad. I'm saying that everybody follow other approach
08:24:19 <e0ne> #link https://docs.openstack.org/oslo.config/latest/reference/cfg.html#global-configopts
08:24:35 <e0ne> ^^ it's how we can deal with config
08:24:36 <ifat_afek> idan_hefetz is not here now, I think he knows it better than me. But can you please explain why is it causing problems?
08:25:23 <e0ne> current approach requires separate config options registration for tests and services
08:25:34 <e0ne> it leads to code dublication
08:25:48 <ifat_afek> We might need to make some changes to the way we hold config opts due to the “enable mutable configuration” community goal, but we didn’t look into it yet.
08:25:48 <e0ne> and we've got different code flow in tests and in the services
08:25:53 <ifat_afek> #link https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html
08:26:01 <e0ne> ifat_afek: ++++
08:26:35 <e0ne> but AFAIK for this once. we need to use oslo_config.cfg.CONF object everywhere,
08:26:46 <e0ne> also, it will simplify tests
08:27:31 <e0ne> because of oslo_config has config fixture for tests to override config options in very clean and easy way
08:27:39 <eyalb> I don't like using global objects
08:27:51 <e0ne> eyalb: nobody likes it
08:28:32 <e0ne> but honestly, config is always global. we can't have 2 different configuration for 1 service
08:29:43 <eyalb> I think its a bad practice to use it as a global variable but if everybody does it ...
08:29:52 <eyalb> we can change the code
08:30:34 <e0ne> I'm not saying that we need to change the code because of everybody does it
08:30:40 <e0ne> it's really bad idea
08:32:28 <e0ne> what I'm talking about that with a current approach, we've code a lot of code duplication, high coherence with config-related things and it's hard to support mutable configs
08:32:28 <eyalb> we also have a problem that there is a dependency of vitrage tempest in vitrage which causes problems and hacks when running the tempest
08:32:52 <e0ne> eyalb: what problem are you talking about?
08:33:44 <eyalb> there are imports of vitrage in vitrage tempest
08:33:51 <e0ne> :(
08:34:04 <eyalb> a major refactoring is needed there
08:35:16 <eyalb> but its doable :-)
08:35:26 <e0ne> why do we import vitrage from tempest plugin?
08:35:45 <ifat_afek> Because until few months ago it was one project and it was easy to do without noticing…
08:35:47 <eyalb> we use a lot of constants defined in vitrage
08:36:11 <eyalb> and also some graph methods from vitrage which is wrong of course
08:36:18 <e0ne> ifat_afek, eyalb: thanks, got it
08:36:37 <eyalb> we probably need to create some vitrage-lib with the common constants
08:37:31 <ifat_afek> e0ne: anyway, if you have a specific problem you need help with, let us know
08:37:46 <ifat_afek> Because refactoring might take time
08:37:53 <e0ne> ifat_afek: sure, I'll do
08:38:14 <ifat_afek> Let’s move on. Anyone else wants to update?
08:38:16 <e0ne> ifat_afek: I'm not a fan of refactoring, I just want to have upgrades working
08:39:21 <ifat_afek> Of course
08:39:31 <ifat_afek> And refactoring is not a bad idea… it just takes time
08:39:37 <e0ne> +1
08:40:45 <e0ne> I would like to finish db migrations in Rocky, so I'll try to implement everything with a current architecture
08:40:58 <ifat_afek> If you are blocked let us know of course
08:41:13 <e0ne> ok, will do
08:41:18 <ifat_afek> We’ll be very happy to have db migration in Rocky :-)
08:41:34 <Alon> We had an IRC session with e0ne @ Horizon channel. We talked about JS libraries, and the possible of using React to create a plugin
08:41:37 <e0ne> :)
08:42:20 <Alon> After I'll finish my commitments, I will start a POC to see if it can work
08:42:29 <e0ne> Alon: thanks
08:42:42 <Alon> Thanks e0ne for you support
08:42:54 <e0ne> but we've got more issues with vitrage-dashboard with 'vendor' directory
08:43:11 <e0ne> in a current state, it couldn't be packaged for debian
08:43:47 <e0ne> AFAIR, ubuntu reuses deb spesc from debian, so propably it won't be packaged in ubuntu too
08:43:57 <Alon> I don't know what does it mean, from the prespective of time and fix.
08:44:18 <Alon> I want to create a new project, in order to make this one obsolete
08:44:34 <Alon> All libraries there are too old:
08:44:56 <e0ne> Alon: we need to get rid of minified js and css files from our code
08:45:48 <e0ne> I strongly recommend to follow current horizon guidelines for static and xstatic things
08:46:15 <e0ne> it will help all community and vendors to support vitrage plugin
08:47:18 <eyalb> ok we will check it
08:47:29 <Alon> so, in that case we probably need to create xStatic of the dagreD3 library. Am I right ?
08:47:30 <eyalb> is there a an xststic for minified js ?
08:47:31 <e0ne> Alon: did you see my mail to openstack-dev?
08:47:39 <e0ne> #link  http://lists.openstack.org/pipermail/openstack-dev/2018-June/131580.html
08:48:03 <e0ne> Alon: for all libraries we use
08:48:09 <e0ne> eyalb: we don't need it
08:48:31 <e0ne> eyalb: we use django-compress to compress all static during deployment
08:48:53 <eyalb> ok
08:48:57 <Alon> e0ne: no. I will need to start with it in a week or two
08:49:19 <e0ne> Alon: ok, ping me if you need some help
08:49:38 <eyalb> we need to make a list of all libraries we use in vendor and check weather there is a Xstatic for it
08:49:49 <e0ne> +1
08:49:55 <eyalb> if not I guess we will need to create one
08:50:16 <e0ne> eyalb: there is only one lib from vendor that has xtatic package
08:50:37 <eyalb> do we need to pack to xstatic the css also ?
08:51:13 <e0ne> you need to create xstatic only for rrd-party libs
08:51:41 <e0ne> your own js/css/scss shouldn't be packed into xstatic
08:51:50 <eyalb> so where do we put them ?
08:52:05 <e0ne> eyalb: what do you mean?
08:52:47 <eyalb> Alon: we need to get rid of minified js and css files from our code
08:53:17 <eyalb> thats what you wrote
08:53:17 <Alon> only if css is in the vendor folder
08:53:20 <e0ne> here is a guideline https://docs.openstack.org/horizon/latest/contributor/contributing.html#javascript-and-css-libraries-using-xstatic
08:53:47 <e0ne> Alon, eyalb: please, don't put minifided css or js into the git
08:53:48 <eyalb> you mean css of the third party
08:54:12 <e0ne> we should use non-minified code as source of trust
08:54:54 <e0ne> minified static == binaries
08:55:15 <e0ne> we don't need to commit binaries when we've got sources
08:56:11 <ifat_afek> e0ne, Alon, eyalb: sorry to interrupt… we have 4 more minutes and I need to update regarding StoryBoard migration :-(
08:56:52 <e0ne> np. we can continue our discussion after the meeting in a project's channel
08:57:05 <ifat_afek> Sure, thanks
08:57:07 <ifat_afek> #topic StoryBoard migration
08:57:20 <ifat_afek> annarez and I evaluated StoryBoard and approved Vitrage migration from Launchpad.
08:57:32 <ifat_afek> The migration is scheduled for the coming Friday (June 22). On Sunday we will create the new boards and publish a how-to guide. Launchpad should be blocked for additions.
08:57:44 <ifat_afek> All Launchpad bugs will be automatically created in StoryBoard, but unfortunately the blueprints won’t be.
08:57:50 <e0ne> :(
08:57:51 <ifat_afek> I think we should create in StoryBoard stories for the blueprints that we are currently working on, and leave the backlog in Launchpad.
08:58:12 <ifat_afek> For now, you can have a look at the POC boards that we created for Vitrage in the test environment.
08:58:17 <ifat_afek> #link https://storyboard-dev.openstack.org/#!/board/51
08:58:23 <ifat_afek> #link https://storyboard-dev.openstack.org/#!/board/50
08:58:28 <ifat_afek> #link https://storyboard-dev.openstack.org/#!/worklist/227
08:58:32 <ifat_afek> #link https://storyboard-dev.openstack.org/#!/project/468
08:59:01 <ifat_afek> e0ne: is the sad imoji because of the blueprints or because of the entire StoryBoard migration?
08:59:06 <e0ne> yep
08:59:14 <ifat_afek> Yep what?
09:00:07 <ifat_afek> Got to end the meeting.. Bye and see you next week
09:00:20 <e0ne> I'm disappointed a bit that we can't do blueprints migration in an automatic way
09:00:47 <eyalb> bye
09:00:49 <ifat_afek> Me too, but anyway most of our blueprints are very short and the details are in gerrit
09:00:58 <ifat_afek> in vitrage-specs
09:01:00 <e0ne> ifat_afek: +1
09:02:04 <ifat_afek> Anyway, we are completely out of time… so we can discuss it in our channel later
09:02:40 <ifat_afek> #endmeeting