15:01:03 <rhochmuth> #startmeeting monasca
15:01:04 <openstack> Meeting started Wed Jul 13 15:01:03 2016 UTC and is due to finish in 60 minutes.  The chair is rhochmuth. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:06 <rhochmuth> o/
15:01:07 <openstack> The meeting name has been set to 'monasca'
15:01:13 <bklei> o/
15:01:14 <iurygregory> o/
15:01:16 <shinya_kwbt> o/
15:01:18 <koji> o/
15:01:27 <rhochmuth> agenda: https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:01:31 <witek> o/
15:01:39 <cbellucci> o/
15:01:40 <Fdaisuke> o/
15:01:42 <rhochmuth> Agenda for Wednesday July 13, 2016 (15:00 UTC)
15:01:42 <rhochmuth> 1. Discrepancy in devstack - some tarballs downloaded to /root, some to /opt/monasca_download_dir.
15:01:43 <rhochmuth> 2. Reviews:
15:01:43 <rhochmuth> 2.1 https://review.openstack.org/#/c/337901/
15:01:43 <rhochmuth> 2.2 https://review.openstack.org/#/c/327000/ - accept ?
15:01:43 <rhochmuth> 2.3 https://review.openstack.org/#/c/327481/ - accept ?
15:01:43 <rhochmuth> 2.4 https://review.openstack.org/#/c/333009/ - discuss constraint issue
15:01:43 <rhochmuth> 3. Mascot
15:01:44 <rhochmuth> 4. Mid-cycle: https://etherpad.openstack.org/p/monasca_newton_midcycle
15:01:44 <rbak> o/
15:02:07 <tomasztrebski> o/
15:02:14 <igorn> o/
15:02:27 <rhochmuth> hi everyone
15:02:55 <bklei> hola
15:02:57 <igorn> hi :)
15:02:58 <rhochmuth> looks liek the agenda is reasonably light today
15:03:04 <slogan_> morning
15:03:09 <slogan_> (or evening)
15:03:40 <rhochmuth> #topic Discrepancy in devstack
15:03:53 <ericksonsantos_> \o
15:04:11 <rhochmuth> did someone add that topic
15:04:24 <witek> tomasz i think
15:04:32 <tomasztrebski> I did, open question to understand why not all tarballs are downloaded into single location
15:04:35 <witek> when reviewing my change he spoted
15:04:51 <rhochmuth> probably just an oversight
15:05:07 <rhochmuth> i think monasca_download_dir is the correct location, from what i recall
15:05:08 <witek> should we take /root or designated dir?
15:05:20 <witek> ok
15:05:24 <rhochmuth> i think designated directory would be better
15:05:30 <rhochmuth> root sounds a little messy
15:05:41 <tomasztrebski> +1
15:06:12 <witek> I also introduced the variable which controlls if the tarballs should always be downloaded
15:06:13 <rhochmuth> #topic reviews
15:06:16 <rhochmuth> https://review.openstack.org/#/c/337901/
15:06:28 <bklei> that's me
15:06:34 <slogan_> witek: there is an OFFLINE variable in devstack too
15:07:11 <bklei> ^^ review ready for scrutiny/testing -- tomasz had some good comments -- and i'll add tempest tests
15:07:19 <bklei> thx for the review tomasz
15:07:30 <rhochmuth> ok, did you ever submit a bp?
15:07:36 <bklei> si
15:07:47 <rhochmuth> is that yes or no
15:07:58 <bklei> it's linked from the review -- https://blueprints.launchpad.net/monasca/+spec/dimensions-api
15:08:01 <bklei> yes :)
15:08:27 <rhochmuth> ok, i guess i'm a little out-of-sync
15:08:27 <tomasztrebski> bklei: always a pleasure ;-)
15:08:29 <bklei> i'm proposing to do dimension-values and dimension-names separately
15:08:41 <tomasztrebski> +1
15:08:48 <rhochmuth> ok, i'll try and get to looking at this one again
15:08:51 <bklei> it's a pretty big change all by itself -- across two dbs, two languages...
15:08:55 <bklei> thx
15:08:57 <rhochmuth> as well as get rbrandt to take a look
15:09:02 <bklei> perfect
15:09:27 <rhochmuth> https://review.openstack.org/#/c/327000/
15:09:48 <rhochmuth> monitoring for monasca-log-api
15:09:56 <rhochmuth> assuming that is tomasz and witek
15:10:09 <witek> i have added minor comment today
15:10:18 <tomasztrebski> guess, Witek spotted some issue, so will need to patch that, because looks like overlook from my side
15:10:20 <witek> looks good
15:10:31 <tomasztrebski> witek spotted that after I submitted it to agenda
15:11:07 <rhochmuth> well, i think it is mainly ready to go.
15:11:28 <rhochmuth> one question, shoudl we make the prefix "monasca.logs" plural
15:11:36 <rhochmuth> instead of monasca.log
15:12:04 <witek> I undersand monasca.log refers the monasca-log-api component
15:12:15 <rhochmuth> i see
15:12:21 <rhochmuth> sounds good
15:12:43 <tomasztrebski> well it is now, but if more metrics would come in place from area of log monitoring we could think on reusing that prefix
15:12:43 <rhochmuth> so, i'll look at the overall review again, i haven't in a while
15:12:52 <tomasztrebski> still either monasca.log or monasca.logs fits IMHO
15:13:09 <rhochmuth> also, will try and have tsv review again
15:13:21 <rhochmuth> not sure he is here right now
15:13:27 <tomasztrebski> the actual component is described by component dimension
15:13:43 <rhochmuth> tomasz: yep, i saw that
15:13:52 <rhochmuth> i think i'm good
15:14:15 <tomasztrebski> so, monasca.log stays, I need to patch the names according to Witek's comment and that should cut it
15:14:35 <witek> +2
15:14:54 <rhochmuth> we will be integrating the new log-api metrics into our distrobution really soon
15:15:31 <tomasztrebski> ok, so optimize is based in top of monitoring, so I will need to rebase that after, apart from it should be ready to go
15:15:38 <tomasztrebski> nice to hear ;-)
15:16:21 <rhochmuth> https://review.openstack.org/#/c/327481/
15:16:55 <rhochmuth> that is also tomasz and witek
15:17:07 <tomasztrebski> I already mentioned that change above
15:17:40 <rhochmuth> https://review.openstack.org/#/c/333009/
15:18:36 <tomasztrebski> that's me, but I just wanted to brought up the small issue with constraint that this feature will surely encounter
15:18:41 <tomasztrebski> pluggable notifications
15:18:53 <tomasztrebski> ok...let's say 'small'
15:20:07 <rhochmuth> i saw your comments, but haven't looked at code
15:21:03 <rhochmuth> yes, that is a problem
15:21:26 <tomasztrebski> well I can only tell you that since we (Fujitsu) joined monasca notification types were constrained in the database (by enum and now by seperate table + foreign key)
15:22:18 <tomasztrebski> so most likely this will end up as the change that affect database itself which will require some level of migration
15:22:21 <rhochmuth> i'm wondering why haneef hasn't encountered this problem already
15:22:48 <tomasztrebski> he's using the same notification types that were part of the enum thus were also inserted into notification_types table
15:22:50 <rhochmuth> if the type is constrained on specific values, then should the insert not been allowed
15:22:58 <tomasztrebski> I think that's the main reason
15:23:34 <rhochmuth> he wrote a plugins for slack and hipchat
15:23:47 <rhochmuth> but those types aren't defined in the mysql
15:23:51 <rhochmuth> am i confused?
15:23:54 <tomasztrebski> https://github.com/openstack/monasca-api/blob/master/devstack/files/schema/mon_mysql.sql#L274
15:24:19 <tomasztrebski> this is current content of that table, and no - those values aren't there
15:24:39 <rhochmuth> so, if the type isn't in that table, the insert shouldn't be allowed, right?
15:24:53 <tomasztrebski> as you can see validNotificationTypes (https://review.openstack.org/#/c/333009/12/devstack/files/monasca-api/api-config.yml) match the content of the table
15:25:43 <tomasztrebski> I don't think that it is possible
15:25:51 <rhochmuth> sure, but he theoretically tested his new plugins, which have new types associated with them
15:26:30 <rhochmuth> anyway, he must have added those types independently
15:26:59 <rhochmuth> so, in addition to adding the plugin
15:27:08 <rhochmuth> the schema needs to be modified
15:27:29 <rhochmuth> or, the schema is fine
15:27:43 <rhochmuth> but the new types need to be inserted
15:27:47 <rhochmuth> into that table
15:27:56 <tomasztrebski> I'll run some tests tommorow to make sure
15:27:58 <bklei> and hopefully if a migration is required, a script will be provided as part of the patch?
15:28:11 <rhochmuth> i don't think a migration is required
15:28:32 <rhochmuth> but, the new types need to be at least added to the table at some point
15:28:49 <rhochmuth> currently, they are hard-coded in the mysql that we use
15:28:53 <bklei> or even documentation of the correct columns/tables insert statement
15:29:11 <rhochmuth> possibly, they should be inserted when the api or notification starts-up
15:29:14 <bklei> something operators can copy/paste and not all figure it out
15:29:17 <rhochmuth> as another option
15:29:21 <rhochmuth> i'm just throwning out
15:29:46 <tomasztrebski> but if you keep schema and you keep configuration entry (validNotificationTypes), these are two places where something is defined, my concern here is that someone can remove entry from configuration
15:29:59 <rhochmuth> notification engine on start-up coudl check to see if all types are defined in the table
15:30:01 <tomasztrebski> it should follow with removing data from table
15:30:07 <shinya_kwbt> as You can see https://review.openstack.org/#/c/333009/12/monasca_api/v2/common/schemas/notifications_request_body_schema.py I think we should write notification type in config file.
15:30:21 <rhochmuth> tomasz: i agree, the configs need to be kept in-sync
15:30:30 <tomasztrebski> and if constraint is kept removing data for disabled notification types will be problamatic
15:31:54 <rhochmuth> if you disable a notification type in the api, it won't be allowed, and if the plugin disables it, then the plugin will just ignore i'm assuming
15:32:34 <tomasztrebski> ok, but what should happen with those notification methods that's type is the one you just disabled ?
15:32:55 <tomasztrebski> if still keeping schema and config in sync is in order
15:33:04 <shinya_kwbt> oh sorry tomasz already mentiond.
15:33:24 <rhochmuth> thinking off the top of my head, maybe it shouldn't be removed from the db
15:33:34 <rhochmuth> but, just ignore by notification engine
15:34:20 <rhochmuth> if notifications are defined that use a type that has been disable by the api and engine, i don't think it should be removed from the db, as that woudl result i'm assumin in a constraint violation
15:35:30 <rhochmuth> how about if we discuss further in the ticket
15:35:37 <tomasztrebski> ok
15:35:45 <rhochmuth> haneef isn't gettign all this
15:35:57 <rhochmuth> thanks for bringing this to our attention
15:36:18 <rhochmuth> i hadn't looked at the schema and assumed it was just a string
15:36:22 <rhochmuth> bad assumption on my part
15:36:36 <tomasztrebski> it used to be enum, that was kind of contraint on its own
15:36:47 <tomasztrebski> now it is the table, only constraint part did not change actually
15:37:30 <rhochmuth> #topic mascot
15:37:50 <rhochmuth> we have a request from openstack committee for a monasca mascot
15:38:30 <witek> :)
15:38:33 <iurygregory> nice :D
15:38:33 <Kamil_> cool
15:38:38 <rhochmuth> The idea is to create a family of logos for OpenStack projects that are unique, yet immediately identifiable as part of OpenStack. We’ll be using these logos to promote your project on the OpenStack website, at the Summit and in marketing materials.  We’re
15:38:39 <rhochmuth> asking project teams to choose a mascot to represent as their logo. Your team can select your own mascot, and then we’ll have an illustrator create the logo
15:38:40 <rhochmuth> for you (and we also plan to print some special collateral such as stickers for your team in Barcelona).
15:38:40 <rhochmuth> Your mascot can be anything from the natural world—an animal, fish, plant, or natural feature such as a mountain or waterfall. We ask that you don’t choose a mascot
15:38:40 <rhochmuth> that another company or project in the ecosystem is already using. To facilitate this, we suggest your team choose and prioritize a few mascot candidates by July 27.
15:38:40 <slogan_> Well, UC Santa Cruz already took the banana slug, so can't use that
15:39:12 <rhochmuth> we can put as a topic for nex weeks mid-cycle
15:39:32 <rhochmuth> currently, i have a dog, cat, monitor (lizard), and mammoth
15:40:00 <tomasztrebski> offtopic....just was looking for inspiration and found that -> https://cdn.meme.am/instances/500x/63908613.jpg
15:40:35 <iurygregory> need to be animal/something from nature i think
15:40:45 <bklei> eagle!
15:41:03 <rhochmuth> yo dawg
15:41:08 <Kamil_> an alpaca
15:41:13 <slogan_> heh
15:41:21 <rhochmuth> i thought an alpaca was a vegetable
15:41:42 <bklei> i've got it -- monasca is a mismash of different stuff -- okapi?
15:41:53 <slogan_> given it only needs to be unique in the ecosystem, banana slug is actually back on the table
15:42:03 <bklei> https://en.wikipedia.org/wiki/Okapi#/media/File:Okapi2.jpg
15:42:23 <slogan_> (sorry, I am still astonished a college would pick such a mascot)
15:42:49 <rhochmuth> slogan_: We are not going to use a banana slug
15:42:57 <bklei> +1 roland
15:42:58 <slogan_> lol
15:43:07 <iurygregory> o.o
15:43:32 <rhochmuth> ok, next topic
15:43:36 <tomasztrebski> http://i.telegraph.co.uk/multimedia/archive/03133/the-eye-of-sauron_3133429b.jpg
15:43:37 <rhochmuth> bring your ideas next week
15:43:40 <tomasztrebski> is that an option ?
15:43:43 <rhochmuth> sounds like we have some good ones
15:43:48 <tomasztrebski> kind of nice fit for monitoring
15:43:49 <tomasztrebski> :)
15:43:58 <rhochmuth> very cool
15:44:14 <bklei> like the analogy -- monasca==visibility into openstack
15:44:18 <rhochmuth> #topic Mid-cycle: https://etherpad.openstack.org/p/monasca_newton_midcycle
15:44:31 <rhochmuth> so, hopefully everyone remembers that next week is the mid-cycle
15:44:37 <rhochmuth> the link is above
15:45:13 <rhochmuth> if folks can start filling in with topics, that woudl be great
15:45:30 <rhochmuth> right now it is mostly open
15:45:54 <rhochmuth> i'lll start filling into
15:48:10 <rhochmuth> ok, just a reminder that CFP for openstack deadline is today
15:48:40 <slogan_> yep
15:48:45 <rhochmuth> so, we have a bit of time left
15:48:58 <rhochmuth> i'll just open it up
15:49:09 <slogan_> I can still add you as a speaker if you end up with only 2 talks
15:49:14 <slogan_> let me know by e-mail
15:49:33 <rhochmuth> slogan_: sure, i'll let you know later today, thx
15:49:56 <slogan_> we're now pushing packet trace data into monasca
15:50:09 <rhochmuth> wow
15:50:37 <bklei> slogan_ maybe a demo of that during next week's midcycle -- would like to see that?
15:50:48 <rhochmuth> yes, that is a great idea
15:50:50 <slogan_> I could certainly talk about what we've added
15:50:53 <rhochmuth> please add to agenda
15:50:56 <slogan_> ok
15:51:14 <rhochmuth> i was wondering about connections to other projects, like congress, vitrage, watcher
15:51:24 <slogan_> me too :-)
15:51:47 <rhochmuth> slogan_: ooops, sorry, broadview
15:52:04 <slogan_> would a discussion on the issues they may face with a firehose of obscure data be good for the midcycle
15:52:38 <slogan_> some of the stuff broadview pushes is really domain specific - seems like we have to play a role in ways beyod just dimensions
15:53:04 <slogan_> if they can effectively use the data
15:53:13 <slogan_> they kinda have to know what it means
15:53:15 <rhochmuth> that would be a good topic
15:54:13 <rhochmuth> cassandra update
15:54:18 <rhochmuth> that would be another good topic
15:54:46 <shinya_kwbt> it's me ?
15:54:48 <witek> +1
15:54:52 <bklei> good idea
15:55:16 <rhochmuth> shinya_kwbt: yes, that would be you, and whatver updates that fujitsu have
15:55:25 <rhochmuth> in the same area based on their investigations
15:55:30 <witek> i will speak with Matthias
15:55:36 <rhochmuth> thanks witek
15:56:02 <shinya_kwbt> I'm working to add support java implementation
15:56:17 <rhochmuth> i also have some general logistical topics related to the project to discuss
15:56:55 <rhochmuth> such as deployment documentation, and cleaning up repo readmes
15:57:06 <rhochmuth> so, i'll add them
15:57:52 <rhochmuth> so, i think for the first 1/2 hour to hour we can orhganize the topics and remainder of the agenda for th emid-cycle
15:58:04 <bklei> sounds good
15:58:29 <rhochmuth> so, unless anyone has anything else, i think this meeting is wrapping up
15:58:41 <rhochmuth> thanks everyone
15:58:52 <bklei> thx roland!
15:58:56 <witek> thank you Roland
15:59:02 <rhochmuth> see you next tuesday
15:59:03 <shinya_kwbt> thanks
15:59:05 <rhochmuth> and wednesday
15:59:10 <witek> see you
15:59:12 <koji> see you
15:59:32 <tomasztrebski> cya
15:59:47 <iurygregory> tomasztrebski, can you take a look at https://review.openstack.org/#/c/341214/2/docs/monasca-log-api-spec.md ? o/
16:00:14 <rhochmuth> #endmeeting