14:00:19 <fifieldt> #startmeeting #operator-tags
14:00:19 <openstack> Meeting started Thu Jul  2 14:00:19 2015 UTC and is due to finish in 60 minutes.  The chair is fifieldt. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:22 <openstack> The meeting name has been set to '_operator_tags'
14:00:35 <fifieldt> hello all, and welcome to our second IRC meeting
14:00:55 <fifieldt> though we originally said we'd meet monthly, we didn't make it through our agenda two weeks ago
14:01:01 <fifieldt> so this meeting is a continuation of the previous one
14:01:10 <fifieldt> #info Agenda here: https://etherpad.openstack.org/p/ops-tags-June-2015
14:01:42 <fifieldt> we got through some announcements, roughly went through some reviews, but spend most of the time talking about fundamentals
14:01:54 <fifieldt> today, if it's OK with y'all, I'd like to start at item #4
14:02:03 <fifieldt> and have a brainstorm about new ideas
14:02:07 <fifieldt> work ok?
14:02:16 <maishsk> Which I think we still have not gotten nailed down - but if we go down that path - I dont think we will get anyway
14:02:21 <maishsk> so I would leave it for the end
14:02:30 <fifieldt> tehehe :)
14:02:30 <maishsk> Great
14:02:42 <fifieldt> might just be you and me here maish, jonproulx is away
14:02:45 <fifieldt> anyone else here?
14:03:00 <jamespage> o/
14:03:02 <berendt> <-- only passive
14:03:10 <maishsk> First one that I would like to start working on is ops:ha
14:03:14 <fifieldt> thanks jamespage, berendt
14:03:21 <fifieldt> sure, maishsk - can you tell us more?
14:03:43 <MarkBaker> fifieldt, o/
14:03:54 <fifieldt> thanks MarkBaker :)
14:03:55 <maishsk> Definition: is the project Highly available - and the documenation is present on how to achieve this.
14:04:25 <fifieldt> sounds promising :)
14:04:30 <fifieldt> though defining HA is always fun
14:04:40 <fifieldt> do you have any helpful examples at the moment?
14:04:41 <maishsk> and will be fun to get reviews…
14:04:43 <fifieldt> or just throwing it out there
14:05:28 <maishsk> #link http://docs.openstack.org/high-availability-guide/content/ch-intro.html
14:05:32 <berendt> can the HA guide team provide a definition?
14:05:37 <berendt> maishsk: thanks
14:06:12 <maishsk> #link Keystone for example - http://docs.openstack.org/high-availability-guide/content/s-keystone.html
14:06:43 <fifieldt> right, so it's possible to configure keystone to have multiple API endpoints, with a redundant backend
14:06:54 <fifieldt> and there's that handy doc
14:06:57 <fifieldt> so it gets a tick
14:07:02 <fifieldt> that seems useful for people to know
14:07:05 <maishsk> exactly.
14:07:27 <fifieldt> whereas if there is some new service that doesn't quite deal with having every part of it's API distributed, it wouldn't get a tick
14:08:04 <fifieldt> and there might be an in-between case where some particular (substantial) part of a service couldn't do it, whereas basically everything else was good
14:08:07 * med_ is late as usual
14:08:10 <fifieldt> eg I think nova's vncproxy was like that for a while
14:08:13 <fifieldt> thanks med_ :)
14:08:32 <fifieldt> is this matching the vision, maishsk? more to add?
14:08:54 <berendt> are there part of services that cannot by HA?
14:08:58 <Daviey> /win 23
14:09:00 <maishsk> Things that I do not yet know how to deal with - is for example - if cinder has multiple services - can they all be deployed in a redundant fashion - and if only some - then how that should reflect in the tag
14:09:38 <fifieldt> what about using a 'caveat' to say if there's a bit of it that doesn't quite do HA well?
14:09:48 <fifieldt> probably want to keep the "bits" pretty coarse-grained
14:10:02 <jamespage> it sound like there is some level of context to the tag ? a specific configuration for example
14:10:18 <maishsk> so I think we will have to iron that out in the review process?
14:10:23 <med_> what per se is getting tagged exactly? The service overall, specific parts of the service.
14:10:29 * med_ probably needs to read prior minutes
14:10:34 <maishsk> med_: Good question
14:10:44 <fifieldt> I think we basically have to stick with services overall
14:10:48 <med_> 'k
14:10:49 <fifieldt> so it's possible to line up tags :)
14:11:01 <berendt> I think overall
14:11:10 <fifieldt> and, going too fine grained just eats up people and becomes impossible to maintain
14:11:12 <med_> so the "ha" tag would definitely apply and definitely have to have some notes/caveats
14:11:13 <maishsk> jamespage: can you elaborate?
14:11:38 <med_> I can't speak for jamespage but you CAN deploy many services with/without HA
14:11:52 <med_> so the ha tag probably needs a reference to HOW you deploy with HA
14:11:55 <jamespage> maishsk, I was thinking of neutron specifically - not all plugins/drivers offer the same level of HA'edness
14:12:04 <fifieldt> that is a good point
14:12:05 <jamespage> but the same probably applies to cinder as well
14:12:07 <med_> or it leads you to doing a "hunt" for the right solution.
14:12:23 <jamespage> med_, hence the need to reference a configuration with the tag imho
14:12:30 <med_> agreed.
14:12:43 <maishsk> I agree to all of the above - but if it aint documented - in the official docs - it aint there - and therefore - no tag
14:12:56 <med_> so using neutron plugin:bizmummble is HA but using neutron plugin foxcreekjump is not HA
14:13:40 <fifieldt> I think jamespage might be suggesting we limit the number of plugins and configurations we care about
14:13:43 <fifieldt> right? :)
14:13:57 * maishsk agrees
14:14:07 <berendt> how to choose?
14:14:12 <jamespage> fifieldt, kinda - I think we need a mechanism to support documenting what we know is ha - not quite the same thing
14:14:13 <med_> so, then "ha"' implies that somewhere in the official (at somepoint in time docs, presumably the docs on the day the tag was applied) docs there is a documentation of HA
14:14:28 <jamespage> the limitation is really that no-one has verified that some alternative configuration is HA
14:14:29 <med_> ^ my comment back to maishk's
14:14:42 <berendt> med_: agreed
14:14:48 <fifieldt> right, this all sounds very reasonable
14:14:56 <med_> otherwise the tags get way too wishy-washy meaningless
14:14:57 <jamespage> but it sounds like that forms part of the benchmark for the tag anyway
14:15:14 <med_> the HA one at least has a (bad, out of date last I looked, broken) but existent guide
14:15:19 <med_> do other tags have guides?
14:15:25 <fifieldt> I think in general we're in favour of investigating this, so given we're 15 minutes in, it might be worth seeing other ideas people have and taking drtailed discussion to specs?
14:15:38 <med_> ie, "good for production" won't mean much unless we say What config in prod.
14:15:44 <fifieldt> s/specs/code review thing
14:16:26 <fifieldt> I figure we can have a more robust conversation when there's a document to poke holes in :)
14:16:30 <fifieldt> sound OK?
14:16:33 <jamespage> sure
14:16:41 <fifieldt> well, who's up next then :)
14:16:43 <berendt> there is a team improving the HA guide at the moment
14:16:47 <fifieldt> any ideas?
14:16:49 <berendt> #link https://blueprints.launchpad.net/openstack-manuals/+spec/improve-ha-guide
14:17:11 <berendt> #link http://specs.openstack.org/openstack/docs-specs/specs/liberty/ha-guide.html
14:17:17 <fifieldt> #agreed ops:ha tag seems worthwhile to investigate. details around config to be worked out
14:17:27 * med_ suspsects he may be on that team.... or was 6 mo. ago
14:17:37 <MarkBaker> I I wanted to dig into packaging tags - if there is a quality and/or distro element to them
14:18:06 <fifieldt> sure, since you and jamespage are here, it might be worth doing that
14:18:20 <fifieldt> please go ahead!
14:18:52 <MarkBaker> like med_ I may need to read previous minutes but is it agreed that there will be a packaged tag?
14:19:06 <fifieldt> ah, we did get around to discussing this last time
14:19:11 <fifieldt> there's actually a write up at https://review.openstack.org/#/c/186633
14:19:24 * jamespage reads fast
14:19:26 <fifieldt> which has had quite a bit of iteration :)
14:19:40 <fifieldt> ok, while those guys are reading, maybe we continue brainstorming and come back later?
14:19:46 <MarkBaker> .me reads
14:19:53 <fifieldt> lets give them 5 minutes
14:19:56 <fifieldt> so any new tag ideas?
14:19:57 <jamespage> fifieldt, ack
14:20:46 <berendt> no ideas at the moment
14:20:53 <fifieldt> med_, what info would you like to see to help you navigate the mysterious new openstack projects?
14:21:14 <med_> new ones? Mostly maturity, deployed-already-somewhere, stability
14:21:24 <med_> and I suspect that's a no, secret, notreally
14:21:27 <med_> for a new project
14:21:44 <med_> ie, I'm familiar with the not quite in the tent Monasca project
14:21:50 <med_> maturity=no
14:21:59 <med_> deployed-already=yes
14:22:04 <med_> stability=notsomuch
14:22:12 <med_> (and getting better every day)
14:22:27 <med_> Monasca is my "pet" too new to be in OpenStack project
14:22:38 <med_> there are lots of others I know even less about
14:22:43 <fifieldt> cool. I definitely think we want to get to the point where we can say stuff like that :) I think at the moment, it would be nice to break down a complex thing like maturity into component parts
14:22:56 <fifieldt> we can derive it a little from - is it in the install guide? is it packaged?
14:23:06 <fifieldt> has the puppet/chef/ansible stuff been updated for it?
14:23:16 <fifieldt> actually - on that last one, do you care?
14:23:29 <fifieldt> or is it a good indicator of maturity
14:23:30 <fifieldt> ?
14:23:55 <maishsk> fifieldt: If the information is useful - then yes.
14:23:57 <med_> btw, that pkg example is very helpful, thanks.
14:24:14 <berendt> i think puuppet/chef/ansible is a useful detail
14:24:21 <fifieldt> med_, you might also enjoy: https://review.openstack.org/#/q/project:stackforge/ops-tags-team+branch:master,n,z
14:24:24 <med_> stability in terms of functionality I care about
14:24:37 <med_> stability in terms of api I care about
14:25:01 <med_> and puppet/chef/ansible I care about (but feel some personal onus so if not done, should beat myself with a stick)
14:25:10 <jamespage> med_, hehe
14:25:15 <fifieldt> :D
14:25:21 <fifieldt> how about scale?
14:25:24 <med_> stability is more has the project settled enough to be remotely usable
14:25:30 <fifieldt> right
14:25:37 <med_> ie, Monasca is on there 3rd-4th different database backend
14:25:54 <med_> some see that as a challenge, others as opportunity, and operators as WTF?
14:26:15 <med_> scale's a very good ... tagtopic?
14:26:18 <med_> concept
14:26:28 <fifieldt> yeah, what do we do with it? :)
14:26:36 <maishsk> med_: and has the API been re-written/planned to be re-written once/twice/umpteenth times
14:26:39 <med_> ie, "works in devstack"TM doesn't quite imply "scale"
14:26:48 <med_> maishsk, yep.
14:26:49 <maishsk> +1
14:27:06 <fifieldt> "works in devstack" should so be a tag we should suggest the TC make :)
14:27:06 <jamespage> med_, I guess the trick with scale is quantifying that as well
14:27:28 <med_> so to evaluate for a "scale" tag is going to be a bit of a ... what jamespage said, ill defined atm
14:27:45 <fifieldt> ok, so, strawman - we use some user survey data, somehow
14:27:54 <maishsk> jamespage: can we use the User survey to collect those metrics? /cc fifieldt
14:28:01 <med_> so scale might mean 10, it might mean log==10 it might mean log(log) =10
14:28:09 <jamespage> maybe - not sure if has all of the required dimensions
14:28:14 <fifieldt> we have data on #TBs, # cores, #IP addresses
14:28:16 <med_> so use usersurvey to determine if deployed
14:28:24 <jamespage> that might work then
14:28:25 <med_> and how broadly
14:28:30 <med_> but doesn't really imply scale
14:28:47 <fifieldt> the problem we have is mapping different services in
14:28:59 <fifieldt> for nova, # cores might be scale, for swift # TBs or # objects
14:29:02 <med_> I don't think the user survey for example asks how many "neutron" nodes you have.
14:29:06 <fifieldt> yeah
14:29:12 * med_ needs to retake the survey to see exactly what it does ask
14:29:16 <fifieldt> so quite difficult to map in
14:29:18 <med_> I figured it asked about #compute nodes
14:29:37 <med_> not #of cinder nodes
14:29:38 <fifieldt> we'd probably need to go back and work out what a "large" cloud was, making a definition including all of these metrics
14:29:39 <jgbarah> Probably above a certain point, it doesn't matter too much, if the idea is "used enough"
14:29:42 <fifieldt> then count the number of those
14:29:44 <med_> not #of routers
14:29:58 <MarkBaker> most users I talk with measure scale in terms of compute nodes - that is mainly because that is how most distros charge
14:30:02 <med_> I think for 'deployed broadly' usersurvey is perfect
14:30:19 <jgbarah> OTOH, you don't need a single scale
14:30:36 <med_> agreed MarkBaker that's the first thing I think of but it is irrelevant if you are talking about many of the projects
14:30:36 <fifieldt> so, it's looking like as jgbarah says, we might be able to fake it using # of production deployment stats
14:30:49 <jgbarah> If you have quantitative info on different aspects, then those for whom nodes is important, can use that, but other could use some other parameter
14:30:53 <med_> "fake it" until we make it with something better...
14:31:03 <jamespage> I think multiple scale dimensions is an idea which would allow alignment with projects based on use case
14:31:20 <fifieldt> ok, so I'm thinking maybe this needs to be a change in the user survey presentation
14:31:24 <jgbarah> Thre could be the "standad" dimension, and then maybe some others...
14:31:25 <fifieldt> rather than a tag as such
14:31:44 <med_> yep
14:31:47 <fifieldt> so people can look at the specs of clouds that run monasca, for example
14:31:49 <med_> but it gets onerous
14:32:01 <jgbarah> In any case, tags could be delivered based on the "standard" dimension, if you want a "reference" tag set
14:32:16 <med_> i guess if we can use the value, we should ask. I hate makingrequesting that folks give away the farm, their baby, their design in a survey
14:32:34 <med_> so optional? tag/flag + optional qty?
14:32:41 <jgbarah> If you have rich metadata in json docs, you can compute different scales automatically, and one of them can be the "reference" scale
14:32:42 <med_> (in the survey)
14:33:17 <fifieldt> yeah, we've got a ton of data in a database from the user survey jgbarah, can likely pull some stuff up :)
14:33:33 <fifieldt> I might send out an email about user survey things
14:33:34 <jgbarah> ;-) Good idea.
14:33:38 <fifieldt> but we should probably get back to tags
14:33:49 <fifieldt> anyone want to continue the brainstorm?
14:34:35 * maishsk thinks that should give us a good start for now
14:34:44 <jamespage> fifieldt, reading the packaged spec, the thing that occurs to me is that it feels a little coarse from a distro perspective
14:34:55 <fifieldt> indeed - this is quite deliberate, jamespage
14:34:57 <jamespage> as its an aggregation over all distros
14:35:15 <jaypipes> jamespage: I brought that up last meeting...
14:35:42 <fifieldt> let me find the minutes, moment!
14:35:48 <jamespage> apologies for raking over old ground - but it feels importnat
14:35:54 <fifieldt> #link http://eavesdrop.openstack.org/meetings/ops_tags/2015/
14:35:59 <fifieldt> probably worth having a read
14:36:12 <fifieldt> but do go on if you want :)
14:37:04 <jamespage> fifieldt, sounds like I need to read the full context - so skip my comments for this time
14:37:13 <fifieldt> happy to revisit at any point :)
14:37:19 <fifieldt> basically we don't want to list exhaustive info for every distro+distro version for every project - because you've already got that in a smarter way with apt-cache search
14:37:31 <fifieldt> so have a read and get back to us :)
14:37:41 <fifieldt> anyway, maishsk, you seem ready to move on to the next agenda item
14:37:52 <fifieldt> which I know is dear to your heart
14:37:59 <fifieldt> so, let's cut the brainstorming for today
14:38:04 <fifieldt> maybe add in some more every meeting
14:38:09 <fifieldt> and move to a discussion of process
14:38:16 <fifieldt> #topic     We should start talking about process
14:38:25 <fifieldt> did you want to kick us off, maishsk?
14:38:53 <maishsk> So as a transparent process - I think that this group should define a few things
14:39:20 <maishsk> 1. Who approves tags (+2 power)
14:39:37 <maishsk> 2. How is that group of people defined.
14:40:43 <maishsk> Do we do this like all Openstack projects - is that even possible?
14:40:55 <fifieldt> cool, so just info so far:
14:40:56 <med_> not all openstack projects do it the same way tbh
14:41:05 <med_> (w/r/t +20
14:41:09 <med_> (w/r/t +2)
14:41:09 <fifieldt> current people with +2 rights on the repo are tim bell, subbu allamaraju, jon proulx and me
14:41:22 <fifieldt> that was just the initial set
14:41:30 <fifieldt> since I made the repo, and the other 3 are the user commitee
14:41:48 * maishsk is fine with that.
14:41:52 <fifieldt> I know the UC is interested in delegating more and doing less work themselves to some extent :)
14:42:30 <fifieldt> the other thing I'll point out is that approval at the moment is equivalent to "merged in the git repo"
14:42:36 <maishsk> If the group decides to expand - the process of how should be laid out
14:42:42 <fifieldt> nothing we do is displayed nicely anywhere or consumed at the moment
14:42:52 <fifieldt> strawman:
14:42:56 <maishsk> All things start small.
14:43:03 <fifieldt> people who do good things on the repo should be given rights?
14:43:10 <fifieldt> eg reviews
14:43:29 <fifieldt> hard when we are so small :)
14:43:32 <fifieldt> but *shrug*
14:43:48 <fifieldt> do you have ideas, maishsk?
14:44:26 <fifieldt> med_, anything interesting in the way your other projects do it?
14:44:32 <maishsk> I am more than willing to help out here.
14:44:58 <med_> fifieldt, no, they are very similar to what you just proposed: start somewhere, move forward.
14:45:13 <med_> in addition to the core reviewers of more traditional coding projects
14:45:26 <med_> (which may in fact start the same way and then people get proposed as added to core)
14:45:42 <fifieldt> so, if maishsk has reviewed every single patch and proposed a couple of his own, he's on the track to core? :)
14:45:44 <med_> cores look to other cores and non-cores to corify someone.
14:45:49 <med_> +1
14:45:59 <fifieldt> and that decision is made by the existing core team
14:46:00 <fifieldt> ?
14:46:01 <med_> ^ that's indeed a good point and how it works
14:46:17 <med_> fifieldt, that's my present understanding
14:46:30 <maishsk> One last thing which I forgot to mention - is ‘contesting’ (for a lack of a better word ATM) a tag.
14:46:33 <med_> jaypipes, ttx, jamespage could probably add more bg/info
14:46:42 <med_> that's a -1
14:46:44 <med_> or -2
14:46:51 <med_> and should have comments in the review
14:47:01 <fifieldt> cool, well, in the interests of time, does someone want to write the core reviewer stuff up and email it to the list for thinking?
14:47:10 <med_> or are you suggesting someone propose a tag value change? That would be a new mergeset
14:47:18 <fifieldt> contesting a tag is when someone thinks the value is wrong
14:47:44 <med_> so if someone thinks the value is wrong, should be a new review that goes out along with a ... reason for change
14:47:54 <fifieldt> eg we could have written nasty things about the HA-ability of monasca, when in fact it works
14:47:58 <maishsk> med_: that sounds like a plan
14:48:03 <fifieldt> monasca complains, and we respond
14:48:13 <fifieldt> I don't think we should necessarily say "submit a patch set" in every case :)
14:48:18 <med_> reason for change could be in the commit message. I'll need to read the proposed packages tags page again first to see if that reason also needs to go in a file.
14:48:38 <fifieldt> since it could be valuable people like driver makers, packagers, ...
14:48:43 <med_> fifieldt, ?
14:48:57 <med_> if those people can't make a changeset.... I'd question their openstackfulness.
14:49:13 <fifieldt> med_, of course it would be great if everyone did patches :)
14:49:18 <med_> I'm fine with someone proxxying their change.
14:49:21 <fifieldt> yes
14:49:23 <fifieldt> that's basically it
14:49:40 <fifieldt> all I'm saying is that we should prioritise the accuracy/responsiveness above the process :)
14:49:44 <med_> ie, if I hear from BRANDx that it works it really works and here's' how, I have no problem championing that to a changeset
14:49:55 <fifieldt> indeed
14:50:01 <med_> so WHERE/WHEN/HOW would they do that? In thi meeting?
14:50:06 <med_> in email to operators list?
14:50:20 <fifieldt> according to the wiki at the moment it's emailing the list
14:50:23 <med_> 'k
14:50:26 <fifieldt> or emailing me directly if it's uncomfortable :)
14:50:36 <fifieldt> then we could decide what to do from there
14:50:43 * med_ is always uncomfortable... but thought that was normal.
14:50:49 <med_> TMI
14:50:57 <fifieldt> :D
14:51:01 <fifieldt> so, we have 10 miuntes left
14:51:05 <fifieldt> where are we on process, maishsk?
14:51:09 <maishsk> med_: maybe you should get a new chair?
14:51:43 <maishsk> I think that we have covered the items on the agenda - pretty much.
14:51:50 <fifieldt> ok
14:52:02 <fifieldt> so, up next was something about our monthly meeting slot
14:52:05 <fifieldt> but I guess we fixed that
14:52:15 <fifieldt> which means we're basically in all other business
14:52:18 <fifieldt> so, the floor is open
14:52:21 <fifieldt> for anyone, for anything
14:52:27 <fifieldt> #topic AOB
14:53:11 <fifieldt> does anyone have anything further to add?
14:53:15 <fifieldt> request? discuss?
14:54:03 <med_> I just have homework.
14:54:10 <fifieldt> haha, brilliant :)
14:54:16 <med_> Did someone take the action to write up the how to become core in this project?
14:54:22 <med_> if not, I can write that email from scrollback.
14:54:23 <fifieldt> not yet!
14:54:27 <med_> taken
14:54:28 <fifieldt> that would be excellent
14:54:38 <fifieldt> #action med_  write up the how to become core in this project
14:54:41 <med_> by cob
14:54:43 <maishsk> :)
14:55:02 <fifieldt> cool, well, do tell your friends about us :)
14:55:08 <fifieldt> now, in terms of our next meeting
14:55:11 <med_> that too.
14:55:22 <fifieldt> we can either do it on 16th of July or 30th July
14:55:30 <fifieldt> preference?
14:55:52 <fifieldt> #action maishsk to investigate ops:ha
14:55:54 <fifieldt> forgot that one
14:55:58 <maishsk> ;)
14:56:07 <fifieldt> two weeks or one month people ?
14:56:29 <maishsk> I say keep it at 2 weeks - if there are no pressing topics
14:56:31 <med_> to make progress, I'd vote for 2 week
14:56:44 <med_> biweekly not semiweekly
14:56:48 <maishsk> cancel on the mailing list
14:56:57 <med_> +1 wfm
14:56:58 <fifieldt> ok, I will also be sure to add a topic for jamespage and MarkBaker to the agenda for a meeting on 16th july
14:57:04 <maishsk> aka -> What med_ said
14:57:08 <fifieldt> or they can add comments to the review
14:57:10 <fifieldt> prior to then
14:57:18 <fifieldt> so we can save valuable real-time-time :)
14:57:18 <MarkBaker> fifieldt, I can' make 16th, don;t know about jamespage
14:57:26 * med_ takes a 3 min break between irc meetings
14:57:29 <fifieldt> ok, well, please do spam the review link :)
14:57:35 <fifieldt> we'll work out a meeting time later
14:57:47 <fifieldt> since this one needs to wrap up before we fall asleep :)
14:57:52 <fifieldt> so thank you all very much for coming
14:58:02 <fifieldt> please take a look at the stuff under review, or propose your own ideas!
14:58:12 <fifieldt> and I look forward to seeing some of you in a couple weeks'
14:58:15 <fifieldt> #endmeeting