Page MenuHomePhabricator

Project Proposal: Label style projects for common operations tools
Closed, ResolvedPublic

Description

These are not really tasks or things would would exist in Bugzilla, but might in RT, however RT is not going to have the same overlap problems. It should be safe / sane to create some projects here to get things off to a sensible start. Mainly I'm looking to keep the dilution of the Operations group tasks to a minimum, and there is the problem of that being a private group and not really being friendly for non-ops to follow along and contribute.

So, for now I am thinking:

Diamond (example task here already T1145: Make minimalpuppetagent collector more robust to puppet failure events )
Graphite (example task here already T1075: Audit groups of metrics in Graphite that allocate a lot of disk space )
Icinga
HHVM (example task here already T760: WMF hhvm-dbg package is broken )
Puppet
Elasticsearch
Varnish
media-storage T1268: swift capacity planning
LDAP
Mail
Pybal

Type: label
Memberships: open
Permissions: public/all users

Event Timeline

chasemp created this task.Nov 7 2014, 3:30 PM
chasemp raised the priority of this task from to Needs Triage.
chasemp updated the task description. (Show Details)
chasemp changed Security from none to None.
chasemp updated the task description. (Show Details)
chasemp updated the task description. (Show Details)
chasemp added a project: acl*sre-team.
chasemp added a project: Phabricator.
chasemp updated the task description. (Show Details)
chasemp added a subscriber: chasemp.
Qgil triaged this task as Normal priority.Nov 7 2014, 3:34 PM
Qgil awarded a token.
Qgil added a subscriber: Qgil.
Dzahn added a subscriber: Dzahn.Nov 7 2014, 7:16 PM

I like this approach to do labels per project. Well, maybe for example observability could cover Icinga and Shinken and #watchmouse, but it's cool either way to somehow organize the operations tickets better than just everythin in "core-ops" or "ops-requests" like in the past in RT. in RT we had "tags" which were kind of like the labels here, but we didn't use them very much. i remember once we did to tag tickets as #hackathon when we wanted to look at them during a sprint/hackathon, but that's different from subject labels.

chasemp updated the task description. (Show Details)Nov 10 2014, 3:59 PM
chasemp updated the task description. (Show Details)Nov 13 2014, 4:33 PM
chasemp updated the task description. (Show Details)Nov 13 2014, 4:36 PM

works for me, as long as we keep it lightweight and obvious what's going on.
obviously the main flow is inbound requests from users and triaging of those for the on duty person, so the least confusing that is the better

Qgil added a comment.Nov 26 2014, 9:07 AM

What is left here?

fgiunchedi added a comment.EditedNov 27 2014, 12:20 PM
In T1147#787587, @Qgil wrote:

What is left here?

can we go for all lowercase (just labels) names please?

Qgil added a comment.Nov 27 2014, 1:24 PM

We agreed on Title Case by default for consistency, as much as we agreed on dashes instead of spaces...

https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Name

In T1147#791129, @Qgil wrote:

We agreed on Title Case by default for consistency, as much as we agreed on dashes instead of spaces...

fair enough, we should rename existing ones mentioned in this project then:

diamond, icinga, graphite, hhvm, puppet, swift, varnish

Qgil closed this task as Resolved.Dec 3 2014, 11:43 AM
Qgil claimed this task.

Fixed and resolving, because it seems that the rest is done as well. Otherwise please reopen or create a new task.

faidon added a subscriber: faidon.Dec 19 2014, 11:00 AM
faidon reopened this task as Open.Dec 22 2014, 10:08 AM
faidon added projects: ops-core, ops-requests.
faidon added subscribers: Jgreen, Manybubbles, Ottomata, demon.

We definitely need more and I'll reopen so we can discuss this here rather than the ops list. Most of these are trivial to do (and I have permissions to do them), but I'm seeking some form of consensus first :)

  • Debian packaging was raised on the list, with "Debian-packaging" or "Debs" (I prefer the latter but there's a couple of people on the list preferring the former)
  • We need tags for "mail", "LDAP" and something for databases/DBA work ("Databases"? "DBA"?)
  • We need a tag for the (Elastic)Search stuff, although I think this may be a "search" team tag with @Manybubbles and @chad for now? They may have one already for the CirrusSearch work and I'm still unsure whether we should have a different one for backend work.
  • Wikimedia-OTRS should probably be renamed to just "OTRS" and converted into a yellow tag. I think the Wikimedia- prefix is legacy from Bugzilla and I find it superfluous and inconsistent.
  • We need a separate (software) project for Pybal.

As for subteams:

  • We agreed on the list to split the operations aspects of fundraising (i.e. mostly @Jgreen's work) into a different project. I was thinking of "ops-fundraising" but Analytics did the same (for @Ottomata's work) already with "analytics-cluster" (previously named "analytics-refinery"). Something consistent would be nice, suggestions welcome :) I'm unsure whether these should be projects or teams, although I'm leaning towards the latter. These would be mutually exclusive to the project ops-core and possibly to the Operations team as well (with the exception of crossover work, obviously)
  • We also have a "Labs-Team" tag as an operations subteam, which should probably be renamed to just "Labs".

Finally, we're (still) thinking of deprecating ops-requests altogether, as well as tagging all of our tickets in different projects with our team tag Operations. Is there an easy way to do this without going through all of them (manually or programmatically) and mailing every subscriber in the process?

Qgil removed Qgil as the assignee of this task.Dec 22 2014, 10:39 AM
Qgil added a comment.EditedDec 22 2014, 10:41 AM

Finally, we're (still) thinking of deprecating ops-requests altogether, as well as tagging all of our tickets in different projects with our team tag Operations. Is there an easy way to do this without going through all of them (manually or programmatically) and mailing every subscriber in the process?

(Edited) Mmmm I don't think so, but you can warn the top users to "Ignore" notifications for project changes.

faidon added a subscriber: mark.Dec 22 2014, 12:09 PM
  • We need a tag for the (Elastic)Search stuff, although I think this may be a "search" team tag with @Manybubbles and @chad for now? They may have one already for the CirrusSearch work and I'm still unsure whether we should have a different one for backend work.

We've been using the CirrusSearch tag for CirrusSearch coding and deploy tasks but i have no objection to creating an Elasticsearch tag and using it for install/maintenance related stuff. There is also a Mediawiki-Search tag but that's more for user facing stuff. I blurs with the CirrusSearch tag to the point where I'm not sure when something should have one tag but not the other.

chasemp added a comment.EditedDec 22 2014, 4:44 PM

I like Debs :). With a relevant description generally shorter could be better. I am also partial in the label style project cases of arranging things so that I would search for Operations+Debs tags etc. Similar for mail or LDAP.

Side note related, Right now in order to see all operations related work we would have to search for things in 'Any' with all ops-* projects which with a saved search is pretty easy I think. Then tacking on more narrow categories like deb or elasticsearch to show all of that work across ops. Lots of ways to slice it though.

On this:

Debian packaging was raised on the list, with "Debian-packaging" or "Debs" (I prefer the latter but there's a couple of people on the list preferring the former)

I was thinking what about just "Packaging". That covers not only making packages for Debian but also tasks for getting them upstreamed, documentation, or general packaging cleanup for reprepro even.

Seems general enough to be useful but specific enough to find what we need. We could add a #Debs hashtag as well.

I created:

LDAP
Mail
Pybal

chasemp updated the task description. (Show Details)Dec 24 2014, 5:38 PM

I was thinking what about just "Packaging".

I hope that outside reporters won't file tasks about packaging MediaWiki tarball releases ("Wiki-Release-Team" project exists for that) there. A good project summary will help clarifying.

I created:
Mail

With its current short project description which has no reference to Ops I am afraid that some people might confuse it with the existing "MediaWiki-Email" project: https://phabricator.wikimedia.org/project/view/216/
Improving the project desc is very welcome if you want less irrelevant tasks in that basket. :)

demon added a comment.Dec 29 2014, 4:01 AM

I created:
Mail

With its current short project description which has no reference to Ops I am afraid that some people might confuse it with the existing "MediaWiki-Email" project: https://phabricator.wikimedia.org/project/view/216/
Improving the project desc is very welcome if you want less irrelevant tasks in that basket. :)

Which is why we should be flattening these projects already. </broken record>

https://phabricator.wikimedia.org/tag/mail/ is hell confusing, please delete or clarify within few days.

In general, it seems most such tags should be renamed and prefixed with Wikimedia-, given they're terribly generic.

faidon added a comment.EditedJan 4 2015, 11:43 PM

"Mail" is gone but with no comment here. What replaced it?

Isn't Wikimedia implied? This is the Wikimedia Phabricator, after all. I do buy the argument that some of these tags are ambiguous with regards to infrastructure and code but on the other hand, the lines aren't always very clear. I think that most of these are fine.

"Mail" is now https://phabricator.wikimedia.org/tag/mail_%5Bplaceholder%5D/ for the time being and we don't need to prefix everything with "Wikimedia". Also see T43.

chasemp added a comment.EditedJan 5 2015, 3:59 PM

"mail" as a tag is meant to be generic. It would be given context in conjunction with other tags (preferably not of the 'label' type to associate humans). mail+operations is one thing. mail+fundraising is another. The ability to see all mail related things by going to /tag/mail is intended. So far we have moved over hierarchy in tag form from bugzilla and rt, and (at least within the phabricator team) there has been some handwringing over how tags should be oriented in general. Should it always be foo+bar with distinct small bite tags that need to be collated to provide full context on a ticket, or should each tag be an island with parsable hierarchy embedded. I think we are realizing we need both cases. Tags (yellow) that provide a wide umbrella like "mail" or "ldap" are meant to do so across teams and even functional boundaries. If we end up with things from non-technical people being filed with the "mail" tag that dilute the usefulness then it is time to reassess and factor out into multiple tags. So mail being killed here I don't agree with.

Should we end up with operations-mail, mediawiki-mail, fundraising-mail? All of which would need the additional tag operations, mediawiki, fundraising almost certainly anyways. That makes much less sense than trying out the generic mail tag to me and seeing whether it is too broad in practice.

faidon added a comment.Jan 6 2015, 7:05 PM

Fully agreed with @chasemp on the generic names.

On an unrelated note, we also need a couple of new tags for HTTPS-related work: HTTPS as a simple (yellow) tag to tag all HTTPS-related issues (whether ops-related or not) and another one for an HTTPS-by-default milestone HTTPS-by-default. It could be argued that this can be a simple tag as well, a "release" tag or a "sprint"; personally I think release fits best, but I don't care all that much.

Nemo_bis removed a subscriber: Nemo_bis.Jan 6 2015, 10:06 PM

+1 to what Chase wrote. Projects with Yellow color and the tag symbol imply that a second component-style project is wanted for such tasks.

Mail should have a description pointing out that MediaWiki's internal emailing functions are in MediaWiki-Email and that mail rather refers to mail issues with Wikimedia servers.

For consistency, Graphite should also become yellow/tag style?

HTTPS brought up by Faidon: Could we tackle the needs of HTTPS in a separate task? Simply because it's messy already (T29946 and #wikimedia-ssl-related exist from Bugzilla) and I'd like to see it less messy / sort that out in a dedicated task.

Yes, please make Graphite a yellow-style tag. I'm fine with your suggestion regarding mail as well, go ahead and implement it.

HTTPS brought up by Faidon: Could we tackle the needs of HTTPS in a separate task? Simply because it's messy already (T29946 and #wikimedia-ssl-related exist from Bugzilla) and I'd like to see it less messy / sort that out in a dedicated task.

Done: T86063.

As for subteams:

  • We agreed on the list to split the operations aspects of fundraising (i.e. mostly @Jgreen's work) into a different project. I was thinking of "ops-fundraising" but Analytics did the same (for @Ottomata's work) already with "analytics-cluster" (previously named "analytics-refinery"). Something consistent would be nice, suggestions welcome :) I'm unsure whether these should be projects or teams, although I'm leaning towards the latter. These would be mutually exclusive to the project ops-core and possibly to the Operations team as well (with the exception of crossover work, obviously)

My vote is for ops-{whatever} or operations-{whatever} -- it's a little clearer when you consider other team's tags 'Fundraising Dash" and "Fundraising-Backlog" etc.

What is specifically left to do / discuss here to close this ticket? Can this be closed as resolved?
Ops-FR is covered in T89160...

A few of my suggestions/requests above haven't been implemented. We have no tags for DBA work yet — I pinged @Springle about it this on Monday, I'll re-ping. OTRS hasn't been done yet either. That's the only two that are left I think, I didn't check thoroughly if there are others…

scfc added a subscriber: scfc.Feb 12 2015, 6:58 PM
Krenair added a subscriber: Krenair.

I did OTRS

+1 to a DBA or Databases tag.

Although given our future includes various databases like MariaDB, Cassandra and Titan-er-some-graphdb, perhaps tags should be specific.

hashar updated the task description. (Show Details)Feb 12 2015, 11:02 PM
hashar removed a project: Jenkins.
chasemp closed this task as Resolved.Feb 17 2015, 5:28 PM
chasemp claimed this task.
chasemp added a project: DBA.

+1 to a DBA or Databases tag.
Although given our future includes various databases like MariaDB, Cassandra and Titan-er-some-graphdb, perhaps tags should be specific.

I created a #database tag for now. Feel free to rename it if you need or to make a new issue proposing more specific DB tags? My hope is for now this gets us going and we can close this lingerer of a task.

Steinsplitter moved this task from Incoming to Resolved on the OTRS board.Mar 19 2015, 10:27 AM
Restricted Application added projects: Discovery, Discovery-Search. · View Herald TranscriptMay 4 2016, 9:14 AM
Restricted Application added subscribers: TerraCodes, Matthewrbowker, Rjd0060, Steinsplitter. · View Herald Transcript