02:31:47 <ekcs> #startmeeting congressteammeeting
02:31:48 <openstack> Meeting started Fri Mar 30 02:31:47 2018 UTC and is due to finish in 60 minutes.  The chair is ekcs. Information about MeetBot at http://wiki.debian.org/MeetBot.
02:31:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
02:31:52 <openstack> The meeting name has been set to 'congressteammeeting'
02:32:23 <ekcs> hi all. topics here as usual. https://etherpad.openstack.org/p/congress-meeting-topics
02:32:27 <ramineni_> ekcs: hi
02:32:35 <ekcs> feel free to add/comment = )
02:32:38 <ekcs> hi ramineni_ !
02:36:59 <ekcs> ok let’s get started then.
02:37:02 <ekcs> #topic rocky priority follow-up
02:37:25 <ekcs> here’s the rocky planning etherpad. https://etherpad.openstack.org/p/congress-rocky-brainstorm
02:37:45 <ekcs> I did some follow up research on the TODO items.
02:37:54 <ekcs> anything we want to discuss more?
02:38:15 <ramineni_> ekcs:regarding error logging
02:38:22 <ekcs> yup
02:38:47 <ramineni_> ekcs: what do you intend to do? change it to info?
02:38:56 <ramineni_> and where?
02:39:07 <ramineni_> can u show me example, where you want to change
02:39:31 <ekcs> ok
02:42:15 <ekcs> There are many examples, but here’s a simple one: http://git.openstack.org/cgit/openstack/congress/tree/congress/api/datasource_model.py#n65
02:42:46 <ekcs> I’m not sure exactly what to do with it, just that ERROR appears to be inappropriate.
02:43:27 <ramineni_> ekcs: but needs to be notifed to operator , that the name he entered is wrong , and need to change it or something
02:43:43 <ramineni_> if its info , it is more like success case
02:44:10 <ramineni_> Error - Any error which is fatal to the operation, but not the service or application (can't open a required file, missing data, etc.). These errors will force user (administrator, or direct user) intervention. These are usually reserved (in my apps) for incorrect connection strings, missing services, etc.
02:44:20 <ramineni_> ref from : https://stackoverflow.com/questions/2031163/when-to-use-the-different-log-levels
02:45:21 <ekcs> ok I think we have some confusion because we’re thinking about different classes of operators.
02:45:53 <ekcs> there are the operators who maintain the openstack infrastructure and run the serivces (nova, neutron, congress, etc.)
02:46:02 <ekcs> let’s call those operators.
02:46:13 <ramineni_> yes
02:47:10 <ekcs> and then there are operators who interact with the services through API but don’t manage the the hosts the services are on and are not responsible for the healthy running of the services. let’s call these admins
02:48:50 <ekcs> my understanding is that the LOG is typically used by the deployer/operator who manage the unix servers running the services, not by the admins who interact with the service over API.
02:49:23 <ramineni_> ekcs: hmm, not sure
02:50:10 <ekcs> so when an admin uses API to get data source info, say the admin uses the wrong data source name, then the feedback is HTTP error returned or CLI message.
02:50:43 <ekcs> and there’s no need to put ERROR in LOG, which is for something the deployer/operator needs to pay attention to.
02:51:52 <ramineni_> ekcs: what if someone uses API through some other applcation , not direct or something, that doesnt need logs
02:51:52 <ekcs> same thing with any automated agent making API call to congress, every request will have HTTP code returned so any failure due to user error will be noted.
02:51:54 <ramineni_> ?
02:52:40 <ramineni_> ekcs: not sure Eric, info level logging doesnt sound right to me as well
02:52:43 <ekcs> whoever uses API will need to check the return code. that’s standard practice right? We certainly can’t expect a typical API user to have access to logs
02:53:28 <ekcs> LOGS are either files or journals on the unix server accessible typically only by superusers on the unix server.
02:53:47 <ekcs> I don’t know if info is the right one either. all I tihnk I know is error is not the right one.
02:54:01 <ekcs> maybe audit-level can be used.
02:54:02 <ramineni_> ekcs: ok
02:54:46 <ekcs> does it make sense to you error isn’t right?
02:57:14 <ramineni_> ekcs: hmm , not sure actually , if you are sure, not used by admins .. then should be fine i guess
02:57:54 <ekcs> got it.
02:58:52 <ekcs> do you have any contact with operators (even if only for test deployments) who can give opinion on what should go in LOG and at what levels?
02:59:17 <ramineni_> ekcs: ill check and let you know
03:00:12 <ekcs> ok thanks!
03:00:27 <ekcs> should we table this discussion for now then?
03:00:35 <ramineni_> ekcs: yes
03:01:07 <ekcs> ok let’s move on then if nothing else on those TODO follow ups?
03:02:30 <ramineni_> ekcs: i have gone through your comments , so internal URL not useful and direct invoke of api we cn try right
03:02:42 <ramineni_> ekcs: if i got it right
03:03:34 <ekcs> right from what I could gather, publicURL is standard and should always be available.
03:04:23 <ramineni_> ekcs: got it
03:04:29 <ekcs> there may still be cases when people prefer to use internalURL,
03:04:47 <ekcs> but seems to be much less important if it’s a preference rather than a must.
03:06:02 <ramineni_> ekcs: ok
03:07:31 <ekcs> ok then.
03:07:46 <ekcs> #topic updated backlog
03:08:10 <ekcs> I have updated the backlog here based on discussions. https://etherpad.openstack.org/p/congress-task-priority
03:08:16 <ekcs> anything we want to discuss?
03:08:48 <ramineni_> ekcs: this also , you are working on it right , monasca minimal tempest test
03:08:48 <ramineni_> or need some help
03:08:49 <ekcs> priorities are definitely subjective and we can move up or down.
03:09:54 <ekcs> Yea I plan to do it. I didn’t put my name on it yet just in case someone else shows up before I get to it and wants to do it.
03:10:04 <ekcs> because it should be a simple task.
03:10:12 <ramineni_> ekcs: ok
03:10:21 <ramineni_> ekcs: regarding this patch https://review.openstack.org/#/c/557147/
03:10:25 <ramineni_> i didnt get your comment
03:11:28 <ekcs> So I followed the link on the goal page down to here: https://docs.openstack.org/oslo.config/latest/reference/mutable.html#making-options-mutable-safe
03:11:52 <ramineni_> ekcs: we want to make any other congress cnfig options mutable also
03:12:08 <ramineni_> ?
03:12:13 <ekcs> I don’t think we need to.
03:12:39 <ekcs> All I was saying is that from the deployer perspective it’s a bit complex because they don’t know which options are mutable and which are not.
03:13:09 <ramineni_> ekcs: may be documentation and help on config options should capture that
03:13:14 <ramineni_> ?
03:13:44 <ekcs> yea that’d be fine. like i said in comment i didn’t think it needs to stop the patch.
03:14:08 <ekcs> a more serious issue is that there may be some options which if changed can actually cause congress to behave badly.
03:14:24 <ekcs> ideally we should tell operators not to change anything except logging level.
03:15:59 <ramineni_> ekcs: ok
03:16:05 <ekcs> I did a quick code search and I didn’t find any obvious problems. but it’s hard to know for user.
03:17:05 <ekcs> for example if part of congress code stores the value on first use (therefore doesn’t get updated option value), but another part of congress gets directly from cfg (therefore gets updated value), then there may be some unexpected behavior because of the conflict.
03:17:39 <ekcs> but I didn’t find any obvious example.
03:17:40 <ramineni_> ekcs: how is that possible
03:18:30 <ramineni_> ekcs: as i understand , we need to send SIGHUP signal for application to reload the config
03:18:43 <ramineni_> once the config is changed
03:21:02 <ekcs> right. but the service doesnt completely restart.
03:21:22 <ekcs> so for example if you changed bind_host or port, ask congress to reload conf file.
03:21:35 <ekcs> then congress probbaly isn’t going to actually change the port it’s bound to.
03:22:07 <ekcs> and if some part of congress code accesses cfg.CONF.bind_port to determine which port congress is bound to, then it would get the wrong value.
03:22:11 <ramineni_> ekcs: right, they are not safely mutable config options
03:22:16 <ramineni_> and shouldnt be mitable
03:22:18 <ramineni_> mutable
03:22:21 <ekcs> right.
03:22:48 <ekcs> maybe I’m misunderstanding how this all works.
03:22:54 <ramineni_> for debug , shouldnt be an issue
03:23:36 <ekcs> I see I misunderstood how it all worked. based on the congress patch I thought it made all the options reload.
03:23:45 <ekcs> but it’s only the options specifically marked as mutable.
03:23:57 <ekcs> now I get it lol. sorry about the confusion.
03:24:06 <ramineni_> ekcs: yes,
03:24:30 <ekcs> haha great. glad you helped me figure it out =p
03:24:58 <ramineni_> ekcs: :)
03:24:59 <ekcs> I have another topic I forgot earlier.
03:25:29 <ekcs> on the generic push driver stuff, does that interface seem to be something that would work well for monasca push too?
03:25:49 <ekcs> from my discussion with monasca ptl it seems that way.
03:26:00 <ekcs> but I know NEC already has a PoC
03:26:03 <ramineni_> ekcs: existing monasca notification format is not linear
03:26:27 <ramineni_> ekcs: internal tables are required,
03:26:31 <ekcs> got it.
03:26:44 <ramineni_> but if monasca makes the format configurable , we can use it with generic push
03:26:54 <ekcs> I see.
03:27:16 <ramineni_> ekcs: right now, its hard coded in monasca :(
03:27:18 <ekcs> if you get a chance later could you point me to the doc/code that shows monasca webhook notification format?
03:27:37 <ramineni_> ekcs: sure , ill mail you
03:28:01 <ekcs> they said they want to do configurable format through template. but who knows when that’d get done.
03:28:04 <ekcs> ok thank you.
03:28:27 <ekcs> well last minute or so. anything else to discuss or bring up for later?
03:28:28 <ramineni_> ekcs: that is the problem , that is the reason we changed in congress to support existing format
03:29:11 <ramineni_> ekcs: no, ill mail you on the details of format , we can close now
03:29:43 <ekcs> oh also is the PoC code available anywhere? i’d love to see how the updates are handled. and it’d be even better if I can work it into generic driver if possible.
03:29:47 <ekcs> ok
03:30:16 <ramineni_> ekcs: not yet , will make it soon
03:30:26 <ekcs> ok great.
03:30:37 <ekcs> well have a great friday and weekend. talk later then!
03:31:04 <ramineni_> ekcs: you too.. bye :)
03:31:08 <ekcs> bye
03:31:15 <ekcs> #endmeeting