15:00:46 <mfedosin> #startmeeting glare
15:00:46 <openstack> Meeting started Tue Apr 25 15:00:46 2017 UTC and is due to finish in 60 minutes.  The chair is mfedosin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:50 <openstack> The meeting name has been set to 'glare'
15:02:13 <mfedosin> #topic agenda
15:02:22 <mfedosin> #link https://etherpad.openstack.org/p/glare-meeting-agenda
15:03:11 <mfedosin> #topic Updates
15:03:28 <mfedosin> hello idanaroz :)
15:03:36 <idanaroz> hello :)
15:04:10 <mfedosin> so it's renews glare meeting
15:04:26 <mfedosin> it's weekly and it's 60 minutes long
15:04:46 <mfedosin> here we discuss all glare related topics
15:06:13 <mfedosin> I think we should talk about recent project changes and then go to future plans
15:07:05 <mfedosin> From glare's side there were no big updates, only bug fixes and other stabilizations
15:07:33 <idanaroz> cool. So what are our future goals ? Do we have any ideas for optimizations?
15:07:40 <mfedosin> one feature we have added was keycloak support
15:08:16 <mfedosin> we have several goals, for sure, but let's discuss them in next topics
15:08:51 <mfedosin> about ideas for optimizations, there are several, but they are not urgent
15:09:23 <mfedosin> another update is that we released python-glareclient 0.3
15:09:38 <mfedosin> and it was added to global requirements of OpenStack
15:09:56 <mfedosin> which means that other projects can start using it
15:10:42 <mfedosin> glare client got own shell 'glare' and keycloak authentication as well
15:11:21 <mfedosin> I know that keycloak is not related to openstack completely, but I think it's a good feature to have
15:11:59 <mfedosin> then, I created a docker image for glare
15:12:17 <mfedosin> #topic Docker image for glare
15:12:42 <mfedosin> #link https://github.com/Fedosin/docker-glare
15:12:49 <mfedosin> ^ it's a source code
15:13:10 <mfedosin> the image itself can be found on docker hub as mfedosin/openstack-glare
15:13:35 <mfedosin> idanaroz: you said that you'd tested it
15:13:55 <mfedosin> what's your opinion, how can we improve the image?
15:14:51 <mfedosin> my only one concern is that it always takes the code from master
15:15:16 <mfedosin> probably we should add the possibility to specify commit or branch
15:15:39 <idanaroz> it  worked currently i don't have idea how to improve it. But you made good points
15:15:57 <idanaroz> *worked successfully
15:17:02 <mfedosin> It is primarily intended to simplify developer's life
15:17:46 <mfedosin> because you know, bootstrapping devstack is not always convenient :)
15:18:40 <mfedosin> if we have docker container, then we can check some patch pretty quickly without deploying a vm
15:19:31 <mfedosin> okay, we are agree, that we need to add the ability to specify concrete commit or branch for docker container
15:20:12 <mfedosin> #action Implement the ability to specify concrete commit or branch for glare docker container
15:20:28 <mfedosin> okay, go next
15:20:46 <mfedosin> #topic Project rules
15:21:52 <mfedosin> I think that we can not be afraid to say that idanaroz will be next ptl
15:22:41 <mfedosin> and I suggest to make some agreements on how project will be administrated
15:23:08 <mfedosin> 1. Reviews:
15:23:47 <mfedosin> all people know that self-approve is bad :)
15:24:22 <mfedosin> but we have a lot of them
15:25:02 <mfedosin> of course it was before we have code reviewers from Nokia :)
15:25:41 <mfedosin> and I think that now we can stop this practice
15:26:23 <mfedosin> but the project really-really needs its code being reviewed
15:26:47 <mfedosin> idanaroz: can you spent some time during the day reviewing the patches?
15:27:08 <idanaroz> Yes, of course
15:27:45 <mfedosin> great! thank you
15:27:59 <mfedosin> it's your responsibility, btw ;)
15:28:14 <idanaroz> :)
15:28:39 <mfedosin> I think for now it's okay to have only one +2 to merge a patch
15:29:25 <mfedosin> When the community grows, we will be able to strengthen this demand
15:29:42 <mfedosin> 2. Commit messages
15:29:56 <mfedosin> they must follow common openstack rules
15:31:10 <mfedosin> i.e. it must have detailed description, a link to a bug in LP (if it's a bug fix), and a link to a blueprint (if it's a feature)
15:31:41 <mfedosin> 3. New lines of code must be covered by tests
15:31:57 <mfedosin> either functional or unit
15:33:04 <mfedosin> it's just common rules, but I believe they make sense
15:33:25 <mfedosin> idanaroz: do you have any objections or suggestions?
15:34:10 <idanaroz> i totally agree
15:34:36 <mfedosin> If my memory serves me correctly Renat suggested to create a wiki for glare
15:34:56 <mfedosin> probably we should do this and list all rules there
15:36:26 <mfedosin> idanaroz: can you take this on? if not I can do it
15:36:52 <idanaroz> Yes , I'll be glad to take this
15:37:22 <mfedosin> #action (idanaroz) create a wiki page for glare
15:37:43 <mfedosin> #topic unit tests
15:38:06 <mfedosin> recently I started implementing unit tests
15:38:28 <mfedosin> and this is pretty big initiative
15:39:01 <mfedosin> I've written tests for creation, updating and partially listing
15:39:22 <mfedosin> but I think I need help on that matter
15:39:58 <mfedosin> our goal to improve code coverage to 75%
15:40:26 <mfedosin> actually we have good good set of functional tests
15:41:08 <mfedosin> unfortunately we can emulate all scenarios using them
15:41:28 <mfedosin> like external storage failure
15:41:39 <mfedosin> *can't
15:42:29 <mfedosin> idanaroz: can you help me and take some part of unit tests implementation?
15:43:17 <idanaroz> Sure. I am planning to start with sorting Unit tests
15:43:46 <mfedosin> thank you!
15:44:09 <mfedosin> #action (idanaroz) help with unit tests
15:44:20 <mfedosin> #topic Documentation
15:44:55 <mfedosin> you know I wrote a couple of texts:
15:45:26 <mfedosin> #link https://review.openstack.org/#/c/457557/
15:45:34 <mfedosin> it's base architecture
15:46:08 <mfedosin> #link https://review.openstack.org/#/c/459295/2
15:46:20 <mfedosin> it's client
15:46:49 <mfedosin> I found several typos in architecture part, sou I'll update it soon
15:47:10 <mfedosin> thank you for reviewing the second one
15:48:53 <mfedosin> I do think that the next one will be a guide about how to implement new artifact types
15:49:43 <mfedosin> it's quiet big topic, so probably I'll split it in two documents
15:50:46 <mfedosin> basic stuff: creating custom fields, using validators, field properties and so on
15:51:31 <mfedosin> advanced stuff: using hook, implementing own validators, extending the framework
15:51:43 <mfedosin> so, it's an action for me
15:52:14 <mfedosin> #action (mfedosin) create a guide about how to implement new artifact types
15:52:28 <mfedosin> #topic Future plans
15:52:43 <mfedosin> for future plans we have two big initiatives
15:53:04 <mfedosin> sharing of artifacts and hard dependencies between them
15:53:44 <mfedosin> but afaiu they are postponed until June because of Nokia's cloudband release
15:54:14 <mfedosin> okay, that's all I wanted to discuss today
15:54:26 <mfedosin> #topic Open Discussions
15:55:04 <mfedosin> idanaroz: do you want to talk about anything else?
15:55:21 <mfedosin> maybe some quick questions?
15:56:01 <idanaroz> mm, no...
15:56:10 <mfedosin> all right
15:56:21 <mfedosin> so thank you for coming!
15:56:29 <idanaroz> Thank you !
15:56:36 <mfedosin> see you here next week :)
15:56:44 <idanaroz> see you :)
15:57:03 <mfedosin> #endmeeting