878361 - new product and new components for IT/Operations - "Infrastructure & Operations"

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: Administration, task)

Description

[Jake Maul [:jakem]]

Greetings!

We are finally ready to do this, more or less.

We'd like to make a product called "IT & Operations". This will ultimately handle much if not all of IT's bugs, but for starters we'd like to move over those things that WebOps are responsible for.

Initial components would be:

WebOps: Product Delivery
WebOps: Engagement
WebOps: Community Platform
WebOps: Socorro
WebOps: Bugzilla
WebOps: Source Control
WebOps: IT-Managed Tools
WebOps: Other

The "WebOps:" prefix is because there will eventually be other, non-webops components in here too, and it seems like it'll be cleaner and easier to maintain in the long run if we start out with appropriate prefixes.

I imagine their might be questions here, so let me know what info you need and I'll try to answer.


WebOps will be migrating from multiple components. We can provide a mapping... I'm interested to hear from you what's the ideal method for doing this. From my perspective I'd like to be able to somehow deprecate the old components so they don't get used anymore... perhaps even remove them altogether, if all the bugs are migrated out first. I don't know what's possible, or what's recommended.


I'm CC'ing some other interested parties in IT that will also be migrating at some point. They'll have separate components. Don't know if it's best to tackle this all at once, or if you'd rather do it in stages...


Please let me know what info or work you need out of me so we can make this happen. Thanks!

Comment 1

[Ravi Pina [:ravi]]

Yes, NetOps will also want to do this.  I have a list that I'll polish and can either add to this bug or open a new bug for it.  Please let me know what you prefer.  I have the same questions about how you advise a migration of this nature would work too so will defer to whatever is recommended here.

Comment 2

[:Atoll]

It would be useful to sync the prefixes ("WebOps", "NetOps", etc.) with the gpg directories ("netops", "relops", etc.), even if we have to rename some of the gpg directories to match.

Comment 3

[Dave Miller [:justdave]]

We've done these big reorgs before, within Firefox. We have scripts sitting around somewhere that will move components intact to a new product and new name, make the appropriate updates to the activity logs on all the bugs to show them being moved, make sure the milestones and versions from the old product that are in use exist in the new one, etc.

Comment 4

[:glob ✱]

(In reply to Jake Maul [:jakem] from comment #0)
> We are finally ready to do this, more or less.

\o/

> We'd like to make a product called "IT & Operations". This will ultimately
> handle much if not all of IT's bugs, but for starters we'd like to move over
> those things that WebOps are responsible for.

https://wiki.mozilla.org/BMO/Requesting_Changes#Products has the complete list of things we'll need.

> Initial components would be:
> 
> WebOps: Product Delivery
> WebOps: Engagement
> WebOps: Community Platform
> WebOps: Socorro
> WebOps: Bugzilla
> WebOps: Source Control
> WebOps: IT-Managed Tools
> WebOps: Other

> WebOps will be migrating from multiple components. We can provide a
> mapping... I'm interested to hear from you what's the ideal method for doing
> this. From my perspective I'd like to be able to somehow deprecate the old
> components so they don't get used anymore... perhaps even remove them
> altogether, if all the bugs are migrated out first. I don't know what's
> possible, or what's recommended.

as justdave mentioned, we have scripts which can move components between products (along with all associated bugs).  if the above list is a one-to-one mapping from existing components, please provide the mappings.

if this isn't a one-to-one mapping, we can also move bugs in bulk without triggering bugmail.

for any components which are completely new, we'll require descriptions etc for them (see https://wiki.mozilla.org/BMO/Requesting_Changes#Components).

> I'm CC'ing some other interested parties in IT that will also be migrating
> at some point. They'll have separate components. Don't know if it's best to
> tackle this all at once, or if you'd rather do it in stages...

i'd rather do it in stages (or at least on different bugs once the product is in place), as different groups probably have slightly different requirements.


we'll also need to update any custom enter_bug forms, as well as check the visibility of flags and custom fields.

as saved searches and bookmarks work on the product/component name and not the id, this change will break all existing saved searches, bookmarks, and most likely any dashboards or anything which integrates with bmo (eg, metrics). if required we can look at automatically fixing up saved searches as part of this work, however we obviously can't fix things hosted outside of our database :)

Comment 5

[Justin Dow [:jabba]]

I'd like in on this too. Currently Server Operations: Infrastructure is what I'd like moved over, simply as Infrastructure: Other, and in the future, I'd probably add more components, like Infrastructure: DNS, Infrastructure: Puppet, etc.

For now, just moving Server Operations: Infrastructure into the new product as Infrastructure: Other would be a good starting point to help this along.

Comment 6

[Jake Maul [:jakem]]

Okay, before this gets too crazy, let's keep the scope on this bug sufficiently narrow. Let's keep this bug about creating the new product, and any brand-new components. Migrations should be handled in separate, dependent bugs.

I'll comment again shortly with a proper summary based on the data in comment 4, and then this should become actionable. :)

Comment 7

[Jake Maul [:jakem]]

Here we go! Hopefully I've got everything here... we've had no major changes for so long that I'm not entirely certain what all customizations we actually have in place.

> The name of the product
Infrastructure & Operations

> The classification (group) you would like the product in
Other (I guess? It's not any kind of "software")

> A longer description, usually including a web link for more info on the product
Server and networking infrastructure, including web properties, CDN, DNS - https://mana.mozilla.org/wiki/display/IT/Home


> The initial list of components, with their info (see below)

WebOps: Product Delivery
    Any apps directly related to installing or updating key products - typically Bedrock, AUS, Bouncer, FTP, and associated CDN properties.
WebOps: Engagement
    Community Engagement projects, like Affiliates, Firefox Flicks, Mozilla Reps, etc.
WebOps: Community Platform
    SUMO, MDN, Input, and related projects.
WebOps: Socorro
    The Socorro crash-stats.mozilla.com app.
WebOps: Bugzilla
    Bugs specifically pertaining to operational issues on bugzilla.mozilla.org.
WebOps: Source Control
    Bugs pertaining to the operation of Mozilla's SVN, CVS, Hg, Git, or BZR systems.
WebOps: IT-Managed Tools
    Web Applications that are provided directly be Mozilla IT. Inventory, blog.m.o, wiki.m.o, etherpad.m.o, Sentry/errormill, Logstash/Bunker, etc.
NetOps: Projects
NetOps: Other
    Anything  that can't otherwise go in another component or be associated with an  office or data center.  Things like outages that aren't carrier related.
NetOps: DC Port Configurations
NetOps: DC Carrier
    Installs, upgrades, outages.
NetOps: DC Other
NetOps: Office Wireless
NetOps: Office Carrier
    Installs, upgrades, outages.
NetOps: Office Other
NetOps: Office ACL Requests

Default assignee on WebOps components should be [e-mail]
Default QA contact on WebOps components should be me ([e-mail])
Default assignee on NetOps components should be [e-mail]
Default QA contact on NetOps components should be Ravi ([e-mail])

These are all *new* components, not migrations... we'll do migrated components in separate bugs. :)

> The initial list of versions, with their info (see below)
None

> The initial list of target milestones, with their info (see below)
None

> The security group(s) bugs should be classified under when a user checks the security flag (if you don't know, we can help figure this out for you)
Need help on this. Definitely need to be able to set any of these 3:
Confidential Mozilla Corporation Bug
Infrastructure-related Bugs
Security-Sensitive Websites Bug 

> The number of votes needed to confirm a bug (UNCO --> NEW) (optional, disabled by default) 
Don't need this

Comment 8

[:glob ✱]

as this will require code changes to complete, i'll start work on adding the product as disabled, and enable it after the code push.

while that's going on, i have a few more questions:

the following flags are visible on mozilla.org bugs - i suspect some of these are relevant to IT, please indicate which ones you'd like:
bug flags:
- acl‑request
- cab‑review
- needs‑downtime
- needs‑treeclosure
- order-this
- pending‑upstream‑fix
- sec-review
- sec-bounty
- in-testsuite
attachment flags:
- review
- feedback
- approval-mozilla-*
- checked‑in

and the following custom fields are visible on mozilla.org bugs:
- blocking-*
- tracking-*
- status-*
- colo-sites
- office
- crash-signature
- due-date


the following custom bug_entry forms create bugs in the mozilla.org product:
- form.recoverkey : Server Operations: Desktop Issues
- form.presentation : Server Operations: Desktop Issues
- form.mozlist : Discussion Forums
- form.itrequest : Server Operations: Desktop Issues, Server Operations: RelEng, Server Operations: Web Operations, Server Operations: ACL Request, Server Operations

as you can see, the current itrequest form files into "Server Operations: Web Operations".  however there's also a webops specific form waiting for review on bug 840759.  in either case, it looks like the forms will need to be updated to request the product which is being pushed in order to select the correct component.  this isn't a blocker for this bug, but will need to be kept in mind when the existing components are moved.

Comment 9

[:glob ✱]

regarding groups, i suggest:

"Confidential Mozilla Corporation Bug" [mozilla-corporation-confidential]
"Infrastructure-related Bugs" [infra]
"Private Infrastructure Security Bug" [infrasec]
"Confidential Partner Data" [partner-confidential]
"Security-Sensitive Websites Bug" [websites-security]
"Security-Sensitive Webtools Bug" [webtools-security]

with moco-corp being the default group when someone files a bug and marks it as security sensitive.

Comment 10

[Justin Wood (:Callek)]

Allow me to ask to be sure, do all watched components get automatically moved to new product/component?

[bikeshed warning for following]

(In reply to Jake Maul [:jakem] from comment #7)
> WebOps: Source Control
>     Bugs pertaining to the operation of Mozilla's SVN, CVS, Hg, Git, or BZR
> systems.

I'll also note that while the internal webops team knows what this means at a glance, Bugzilla needs to be [should be] consumable quickly for outsiders who may need to file bugs here. And even I wouldn't have realized that "WebOps: Source Control" was appropriate.

I'd suggest something like "WebOps: Repository and Source Control Systems" or something similar. I'd also wonder if we want/need the Repository Account Requests component next to this in same product.

I'd also recommend at least a day or 2 warning posted to newsgroups about the bug bucket changes. So people are not taken by utter shock at it (If it was for anything other than IT, which has less outside interaction, I would recommend longer)

Lastly, I personally feel a WebOps::General, and/or a ::General (in new product) would be good, for people who can't determine what bucket certain bugs belong in.

Comment 11

[:glob ✱]

i'll need descriptions for all components (most of the netops ones are lacking).


(In reply to Justin Wood (:Callek) from comment #10)
> Allow me to ask to be sure, do all watched components get automatically
> moved to new product/component?

if a component is moved as a single unit, yes.
if bugs are selectively picked out of a component, or components are merged, no.

> I'd also recommend at least a day or 2 warning posted to newsgroups about the bug
> bucket changes.

i'd recommend a post to all@m.c :)

Comment 12

[Jake Maul [:jakem]]

(In reply to Byron Jones ‹:glob› from comment #8)
> the following flags are visible on mozilla.org bugs - i suspect some of
> these are relevant to IT, please indicate which ones you'd like:
> bug flags:
> - acl‑request
> - cab‑review
> - needs‑downtime
> - needs‑treeclosure
> - order-this
> - pending‑upstream‑fix
> - sec-review
> - sec-bounty
> - in-testsuite

Yep, we'll need all of these. Good catch!

> attachment flags:
> - review
> - feedback
> - approval-mozilla-*
> - checked‑in

Hmm.... definitely want the first 2, don't really know who or what uses the latter 2. I guess let's omit them for now, and we'll see if anyone screams.

> and the following custom fields are visible on mozilla.org bugs:
> - blocking-*
> - tracking-*
> - status-*
> - colo-sites
> - office
> - crash-signature
> - due-date

I don't think we need any of these.

> the following custom bug_entry forms create bugs in the mozilla.org product:
> - form.recoverkey : Server Operations: Desktop Issues
> - form.presentation : Server Operations: Desktop Issues
> - form.mozlist : Discussion Forums
> - form.itrequest : Server Operations: Desktop Issues, Server Operations:
> RelEng, Server Operations: Web Operations, Server Operations: ACL Request,
> Server Operations

The first 2 don't matter... in fact you might want to talk to Tim Fairfield about removing them. Desktop doesn't use Bugzilla anymore.

Discussion Forums aren't relevant here (at least, not yet), so that one doesn't bother me either.

For the itrequest one, when we submit bugs to actually move components, we'll change the form too. I don't think there are any changes needed here for *this* bug.

> this isn't a blocker for this bug, but will need to
> be kept in mind when the existing components are moved.

Precisely! :)


(In reply to Byron Jones ‹:glob› from comment #9)
> regarding groups, i suggest:
> 
> "Confidential Mozilla Corporation Bug" [mozilla-corporation-confidential]
> "Infrastructure-related Bugs" [infra]
> "Private Infrastructure Security Bug" [infrasec]
> "Confidential Partner Data" [partner-confidential]
> "Security-Sensitive Websites Bug" [websites-security]
> "Security-Sensitive Webtools Bug" [webtools-security]
> 
> with moco-corp being the default group when someone files a bug and marks it
> as security sensitive.

I like the looks of this. Let's go with it.


(In reply to Byron Jones ‹:glob› from comment #11)
> i'll need descriptions for all components (most of the netops ones are
> lacking).

Ravi can supply these. :)

Comment 13

[Amy Rich [:arr] [:arich]]

Let's keep checked‑in since people use it to denote when they've checked things into svn/hg/etc.

Comment 14

[:glob ✱]

this product is now open for entry.

Committing to: bzr+ssh://[e-mail]/bmo/4.2/
modified extensions/BMO/lib/Data.pm
Committed revision 8830.

none of the NetOps components have been created yet; waiting on descriptions.

Comment 15

[Ravi Pina [:ravi]]

NetOps: Projects
    NetOps projects

NetOps: Other
    Internal outage tracking and bugs without a more suitable component

NetOps: DC Port Configurations
    Data center port configurations

NetOps: DC Carrier
    Data center carrier installs, upgrades, outages, etc

NetOps: DC Other
    All other data center bugs not related to ACLs, port configurations, or carriers

NetOps: Office Wireless
    Office wireless

NetOps: Office Carrier
    Office carrier installs, upgrades, outages, etc

NetOps: Office Other
    All other office related bugs not related to ACLs, wireless, or carriers

NetOps: Office ACL Requests
    Office firewall flows and ACL requests

Comment 16

[:glob ✱]

i've created the netops components.

> NetOps: DC Other
>     All other data center bugs not related to ACLs, port configurations, or
> carriers

you have an office-acl-requests but not a dc-acl-requests, however the description for dc-other implies that there should be a separate component for dc-acl-requests.

ravi: do you want me to create a dc-acl-requests component, update the dc-other description, or leave as is?

Comment 17

[Ravi Pina [:ravi]]

mozilla.org::Server Opaerations:  ACL Requests was going to become Infrastructure & Operations:::Netops: DC ACL Requests.  mozilla.org::Server Opaerations: Netops would end up becoming Infrastructure & Operations: Netops.

Would it make sense to create those and then manually move things?

Comment 18

[:glob ✱]

(In reply to Ravi Pina [:ravi] from comment #17)
> mozilla.org::Server Opaerations:  ACL Requests was going to become
> Infrastructure & Operations:::Netops: DC ACL Requests.  mozilla.org::Server
> Opaerations: Netops would end up becoming Infrastructure & Operations:
> Netops.

ah, thanks for clarifying.

> Would it make sense to create those and then manually move things?

no, we can move the component at one fell swoop (this will be quicker, and won't result in a torrent of bugmail).


i believe there's nothing else to be done here; marking as fixed.

Comment 19

[Ravi Pina [:ravi]]

Bug 881491 was opened under NetOps and it didn't have a default QA contact.  It should be [e-mail] as noted in comment 7.  Can you verify this was defined for all of the NetOps ones, please?

Comment 20

[:glob ✱]

oops, sorry about that ravi -- i'd put you in as the default CC accidentally.
i've fixed the components and all the bugs filed while they were incorrectly configured.