19:00:40 <mriedem> #startmeeting operators_ops_tools_monitoring
19:00:42 <openstack> Meeting started Wed May 18 19:00:40 2016 UTC and is due to finish in 60 minutes.  The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:45 <openstack> The meeting name has been set to 'operators_ops_tools_monitoring'
19:01:01 <mriedem> RaginBajin can't make it today so i'm running this show
19:01:03 <mriedem> is anyone around?
19:01:07 <rockyg> o/
19:02:26 <rockyg> slow/light day?
19:02:30 <mriedem> well i guess i'll get started
19:02:36 <mriedem> #link agenda https://etherpad.openstack.org/p/osops-irc-meeting-20160518
19:02:52 <mriedem> #topic Follow-up on Action Items from last meeting
19:03:03 <mriedem> * Review any additions to the Informal Meetup feedback etherpad
19:03:11 <mriedem> i don't know what that is
19:03:15 <mriedem> or where it is
19:03:31 <rockyg> me either at the moment.
19:03:41 <mriedem> #link https://etherpad.openstack.org/p/AUS-ops-informal-meetup
19:03:49 <mriedem> #link https://etherpad.openstack.org/p/osops-informal-meetup-feedback
19:03:58 <rockyg> And I don't know if the infra logstash filters were on that or they were this past week.
19:04:23 <mriedem> there is nothing in that feedback etherpad
19:05:56 <mriedem> ok, moving on
19:06:08 <rockyg> true.
19:06:09 <mriedem> * Review any follow-ups provided by emails sent to operators list regarding feedback for Nova blueprints
19:06:17 <mriedem> i don't remember seeing much about this
19:06:28 <mriedem> markus_z was going through old nova wishlist bugs this week and scrubbing those
19:06:50 <mriedem> sounded like some were already implemented or had blueprints up
19:06:56 <mriedem> coincidentally
19:07:15 <rockyg> cool.
19:07:40 <rockyg> I don't recall seeing anything else on the ops ml about this.
19:08:09 <mriedem> moving onto new business
19:08:09 <rockyg> maybe an info line on the wishlist scrub?
19:08:22 <mriedem> #info markus_z was going through old nova wishlist bugs this week and scrubbing those
19:08:32 <mriedem> #topic Additional Participation
19:08:34 <rockyg> thanks
19:08:41 <mriedem> #help How can we get more operators to even participate in email conversations let alone the group?
19:08:50 <mriedem> given the attendance at this meeting....idk
19:08:53 <mriedem> but i'm not ops
19:09:26 <mriedem> in nova we really just pick on a few known ops people that hangout in nova and know the code base enough to hack on it and be dangerous
19:09:34 <mriedem> so we run things by them if we don't get traffic in the ML
19:09:55 <rockyg> Ah.  That's good info...
19:10:30 <mriedem> moving on from this topic i guess
19:10:48 <rockyg> I think volunteering folks for a session, like the guy who posted the logstash stuff, and advertising his presence might help
19:11:51 <mriedem> which leads me to something the nova team wanted to bring up for ops attention
19:11:58 <mriedem> #link disabling deprecated APIs by config?: http://lists.openstack.org/pipermail/openstack-operators/2016-May/010482.html
19:12:06 <rockyg> Yeah.  I was just reading that on the dev ML
19:12:14 <mriedem> sdague and i just wanted to bring that up, but it's in the ML
19:12:21 <mriedem> there is some reply already from devs
19:12:52 <mriedem> basically nova is going to be deprecating a bunch of proxy APIs and nova-network specific APIs with a microversion, mearning if you request those APIs >= that microversion you get a 404
19:13:00 <mriedem> this to ween people off of them
19:13:08 <rockyg> I think either the original email and a link to the thread (already here) posted to the ops list, or a summary of the thread posted to the ops list will get their attention
19:13:39 <keekz> mriedem: interesting proposal. i like the idea, +1 from me :)
19:13:40 <mriedem> the question is would ops like the ability to kill these APIs regardless of the microversion
19:13:55 <keekz> re: "[Openstack-operators] disabling deprecated APIs by config?"
19:14:02 <rockyg> plus the config opt to get the 404 at deprecation rather than at eol or not
19:14:06 <sdague> rockyg: it was posted to the ops list
19:14:06 <mriedem> so people don't start writing new things against them just to find out later when they get to a more current microversion that they are busted
19:14:45 <rockyg> sdague, oh.  I get ops in digest form.  Haven't seen it yet.  But haven't read my digest yet, either.
19:14:55 <mriedem> rockyg: to be clear, you wouldn't get the 404 by default until you're requesting the microversion or higher, i.e. 2.27
19:15:00 <mriedem> so those using v2.1 wouldn't see this
19:15:30 <mriedem> the kill switch idea is to force those APIs to break regardless of microversion
19:15:38 <mriedem> basically, these deprecated APIs don't work in this cloud, period
19:15:39 <rockyg> mriedem, right.  But, the option to get the 404 would be settable, say in the test cloud or staging cloud
19:15:41 <mriedem> well, on this API endpoint
19:15:48 <mriedem> yes
19:15:50 <mriedem> per endpoint
19:16:01 <mriedem> sdague laid out the example uses in the thread
19:16:12 <mriedem> anyway, this is just an FYI to get feedback
19:16:31 <mriedem> it's going to be a separate spec from the API deprecation work which is going to happen regardless of the kill switch config ability
19:16:51 <rockyg> There should be some traffic on the ops ml, unless they all agree with the approach ;-)  Then, silence.
19:17:23 <sdague> yeh it was cross posted to get feedback there as well
19:17:25 <rockyg> Separate is best.
19:17:25 <mriedem> well, see "how to get better participation here" above :)
19:17:42 <mriedem> anywho
19:17:44 <mriedem> that's all i have
19:17:49 <rockyg> sdague, will you either write a spec or a BP that you can post for ops comment?
19:17:52 <mriedem> anyone else have anything for this meeting?
19:18:07 <sdague> rockyg: right now the email is the proposal
19:18:27 <sdague> once it fleshes out to concensus, there will be a spec in Nova for this add
19:18:49 <rockyg> Excellent.  That way there is a second chance for comments.
19:19:34 <sdague> sure, but comments late are worth less than comments early
19:19:37 <mriedem> but if no one cares to reply to the thread
19:19:47 <mriedem> there is like 0 chance they'll know about the spec and comment on it there
19:20:08 <sdague> comments late are only useful for details, comments early get to shape broad direction
19:20:09 <mriedem> i.e. we don't get much ops input on specs to begin with
19:20:09 <rockyg> Ops tend to want to see concrete so they can see exactly how it may affect them
19:20:22 <sdague> rockyg: please read the email
19:20:22 <mriedem> rockyg: and by then it's too late most of hte time
19:20:23 <mriedem> *the
19:20:35 <mriedem> anyway
19:20:42 <mriedem> yes, read the email, everyone and anyone
19:20:45 <mriedem> anything else here?
19:20:58 <sdague> nope
19:21:00 <rockyg> sdague, got through the first three on the thread.  It seems straightforward.  And you've got one comment here already.
19:21:22 <mriedem> alright, ending the meeting
19:21:24 <mriedem> thanks
19:21:29 <mriedem> #endmeeting