I'm updating the WBS on the move to SSF for the BMR stuff. This is the preliminary WBS. What I'm looking for is twofold: 1) Items I'm forgetting 2) Time estimates (assuming 1w = 1 person, 1 week, 1d = 1 person, 1 work day, 1h = 1 person, 1 hour). For instance, I know some of the moves are going to involve moving machines to new racks as we compress. == Craig
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I will list out things I think need to be altered below: section 1.1 Identifying components moving from 221. I would make this at least 2d, as there will need to be multiple people involved and it will take a lot longer than we think. section 1.2: decommissioning anything will take at least 4d that is if you include the disassemble and preparation for excess, especially for a cluster. just removing disks and doing paperwork and the cable reclamation is a couple people for a couple days. the default 4d times for each major subsystem/cluster in the BMR is probably reasonable as where we save time on one we will most likely burn somewhere else. If we are moving full racks at a time, the clusters may be a little quicker, but if we aren't the unracking/reracking time is going to add at least 1-2d of work per cluster. As for compression, I think currently the only machines that fall into that category are the core servers, and I was really hoping to have most of that taken care of before we move. Rick Craig Stacey wrote:
I'm updating the WBS on the move to SSF for the BMR stuff. This is the preliminary WBS. What I'm looking for is twofold:
1) Items I'm forgetting 2) Time estimates (assuming 1w = 1 person, 1 week, 1d = 1 person, 1 work day, 1h = 1 person, 1 hour).
For instance, I know some of the moves are going to involve moving machines to new racks as we compress. == Craig
----------------------------------------------------------------------
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ+JnPdavihOKkCCERAid9AJ4uU2oAaPYPzKjQJ/dUv5pu7G0J2wCgkMeL sPbQb5SVlqoY+xHnkRe4p9w= =XKmN -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm figuring on re-racking just about anything in the northwest corner of the BMR before moving, so those will take extra time. I'm incorporating your thoughts into this WBS and making up numbers for the rest, since yours is the only feedback I got. I'll send out a new one tonight -- I be presenting this as a preliminary WBS at a meeting tomorrow with the move manager. == Craig On Apr 29, 2009, at 1:17 PM, Rick Bradshaw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I will list out things I think need to be altered below:
section 1.1 Identifying components moving from 221. I would make this at least 2d, as there will need to be multiple people involved and it will take a lot longer than we think.
section 1.2: decommissioning anything will take at least 4d that is if you include the disassemble and preparation for excess, especially for a cluster. just removing disks and doing paperwork and the cable reclamation is a couple people for a couple days.
the default 4d times for each major subsystem/cluster in the BMR is probably reasonable as where we save time on one we will most likely burn somewhere else. If we are moving full racks at a time, the clusters may be a little quicker, but if we aren't the unracking/reracking time is going to add at least 1-2d of work per cluster.
As for compression, I think currently the only machines that fall into that category are the core servers, and I was really hoping to have most of that taken care of before we move.
Rick
Craig Stacey wrote:
I'm updating the WBS on the move to SSF for the BMR stuff. This is the preliminary WBS. What I'm looking for is twofold:
1) Items I'm forgetting 2) Time estimates (assuming 1w = 1 person, 1 week, 1d = 1 person, 1 work day, 1h = 1 person, 1 hour).
For instance, I know some of the moves are going to involve moving machines to new racks as we compress. == Craig
----------------------------------------------------------------------
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJ+JnPdavihOKkCCERAid9AJ4uU2oAaPYPzKjQJ/dUv5pu7G0J2wCgkMeL sPbQb5SVlqoY+xHnkRe4p9w= =XKmN -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkn/UEgACgkQbVNGA3HOzQsL1wCeJyfPHcUB6iRk0rKdBhLQS3wP K9cAn1jIZBHkc+ZN20rhetWcL4LJjtf4 =IVDt -----END PGP SIGNATURE-----
Dont you need a network brought up before machines can move? lw On May 4, 2009, at 3:30 PM, Craig Stacey wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm figuring on re-racking just about anything in the northwest corner of the BMR before moving, so those will take extra time.
I'm incorporating your thoughts into this WBS and making up numbers for the rest, since yours is the only feedback I got.
I'll send out a new one tonight -- I be presenting this as a preliminary WBS at a meeting tomorrow with the move manager. == Craig
On Apr 29, 2009, at 1:17 PM, Rick Bradshaw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I will list out things I think need to be altered below:
section 1.1 Identifying components moving from 221. I would make this at least 2d, as there will need to be multiple people involved and it will take a lot longer than we think.
section 1.2: decommissioning anything will take at least 4d that is if you include the disassemble and preparation for excess, especially for a cluster. just removing disks and doing paperwork and the cable reclamation is a couple people for a couple days.
the default 4d times for each major subsystem/cluster in the BMR is probably reasonable as where we save time on one we will most likely burn somewhere else. If we are moving full racks at a time, the clusters may be a little quicker, but if we aren't the unracking/reracking time is going to add at least 1-2d of work per cluster.
As for compression, I think currently the only machines that fall into that category are the core servers, and I was really hoping to have most of that taken care of before we move.
Rick
Craig Stacey wrote:
I'm updating the WBS on the move to SSF for the BMR stuff. This is the preliminary WBS. What I'm looking for is twofold:
1) Items I'm forgetting 2) Time estimates (assuming 1w = 1 person, 1 week, 1d = 1 person, 1 work day, 1h = 1 person, 1 hour).
For instance, I know some of the moves are going to involve moving machines to new racks as we compress. == Craig
----------------------------------------------------------------------
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJ+JnPdavihOKkCCERAid9AJ4uU2oAaPYPzKjQJ/dUv5pu7G0J2wCgkMeL sPbQb5SVlqoY+xHnkRe4p9w= =XKmN -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkn/UEgACgkQbVNGA3HOzQsL1wCeJyfPHcUB6iRk0rKdBhLQS3wP K9cAn1jIZBHkc+ZN20rhetWcL4LJjtf4 =IVDt -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't have any dependencies in place yet. I'll make that part of the dependencies, though the network can be in the process of being brought up while machines are being prepped for move here, depending on acceptable downtimes. How long should we allow from access to the SSF before we can assume there'll be a network? 2 days? == Craig On May 4, 2009, at 3:38 PM, Linda Winkler wrote:
Dont you need a network brought up before machines can move? lw On May 4, 2009, at 3:30 PM, Craig Stacey wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm figuring on re-racking just about anything in the northwest corner of the BMR before moving, so those will take extra time.
I'm incorporating your thoughts into this WBS and making up numbers for the rest, since yours is the only feedback I got.
I'll send out a new one tonight -- I be presenting this as a preliminary WBS at a meeting tomorrow with the move manager. == Craig
On Apr 29, 2009, at 1:17 PM, Rick Bradshaw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I will list out things I think need to be altered below:
section 1.1 Identifying components moving from 221. I would make this at least 2d, as there will need to be multiple people involved and it will take a lot longer than we think.
section 1.2: decommissioning anything will take at least 4d that is if you include the disassemble and preparation for excess, especially for a cluster. just removing disks and doing paperwork and the cable reclamation is a couple people for a couple days.
the default 4d times for each major subsystem/cluster in the BMR is probably reasonable as where we save time on one we will most likely burn somewhere else. If we are moving full racks at a time, the clusters may be a little quicker, but if we aren't the unracking/reracking time is going to add at least 1-2d of work per cluster.
As for compression, I think currently the only machines that fall into that category are the core servers, and I was really hoping to have most of that taken care of before we move.
Rick
Craig Stacey wrote:
I'm updating the WBS on the move to SSF for the BMR stuff. This is the preliminary WBS. What I'm looking for is twofold:
1) Items I'm forgetting 2) Time estimates (assuming 1w = 1 person, 1 week, 1d = 1 person, 1 work day, 1h = 1 person, 1 hour).
For instance, I know some of the moves are going to involve moving machines to new racks as we compress. == Craig
----------------------------------------------------------------------
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJ+JnPdavihOKkCCERAid9AJ4uU2oAaPYPzKjQJ/dUv5pu7G0J2wCgkMeL sPbQb5SVlqoY+xHnkRe4p9w= =XKmN -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkn/UEgACgkQbVNGA3HOzQsL1wCeJyfPHcUB6iRk0rKdBhLQS3wP K9cAn1jIZBHkc+ZN20rhetWcL4LJjtf4 =IVDt -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkn/WUMACgkQbVNGA3HOzQtU1gCgp2/lk8PaNSmlUtnZXrn3bREI 6eAAnjEYq7uFgggrz160hP10DBFIZ2Rr =qkVm -----END PGP SIGNATURE-----
I will comment on this tomorrow. I need to chew it up a bit and figure out what needs to go when. Depending on if I get funding for the new router, this may be an easy move. -corby On May 4, 2009, at 4:08 PM, Craig Stacey wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I don't have any dependencies in place yet. I'll make that part of the dependencies, though the network can be in the process of being brought up while machines are being prepped for move here, depending on acceptable downtimes.
How long should we allow from access to the SSF before we can assume there'll be a network? 2 days? == Craig
On May 4, 2009, at 3:38 PM, Linda Winkler wrote:
Dont you need a network brought up before machines can move? lw On May 4, 2009, at 3:30 PM, Craig Stacey wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm figuring on re-racking just about anything in the northwest corner of the BMR before moving, so those will take extra time.
I'm incorporating your thoughts into this WBS and making up numbers for the rest, since yours is the only feedback I got.
I'll send out a new one tonight -- I be presenting this as a preliminary WBS at a meeting tomorrow with the move manager. == Craig
On Apr 29, 2009, at 1:17 PM, Rick Bradshaw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I will list out things I think need to be altered below:
section 1.1 Identifying components moving from 221. I would make this at least 2d, as there will need to be multiple people involved and it will take a lot longer than we think.
section 1.2: decommissioning anything will take at least 4d that is if you include the disassemble and preparation for excess, especially for a cluster. just removing disks and doing paperwork and the cable reclamation is a couple people for a couple days.
the default 4d times for each major subsystem/cluster in the BMR is probably reasonable as where we save time on one we will most likely burn somewhere else. If we are moving full racks at a time, the clusters may be a little quicker, but if we aren't the unracking/reracking time is going to add at least 1-2d of work per cluster.
As for compression, I think currently the only machines that fall into that category are the core servers, and I was really hoping to have most of that taken care of before we move.
Rick
Craig Stacey wrote:
I'm updating the WBS on the move to SSF for the BMR stuff. This is the preliminary WBS. What I'm looking for is twofold:
1) Items I'm forgetting 2) Time estimates (assuming 1w = 1 person, 1 week, 1d = 1 person, 1 work day, 1h = 1 person, 1 hour).
For instance, I know some of the moves are going to involve moving machines to new racks as we compress. == Craig
----------------------------------------------------------------------
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJ+JnPdavihOKkCCERAid9AJ4uU2oAaPYPzKjQJ/dUv5pu7G0J2wCgkMeL sPbQb5SVlqoY+xHnkRe4p9w= =XKmN -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkn/UEgACgkQbVNGA3HOzQsL1wCeJyfPHcUB6iRk0rKdBhLQS3wP K9cAn1jIZBHkc+ZN20rhetWcL4LJjtf4 =IVDt -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkn/WUMACgkQbVNGA3HOzQtU1gCgp2/lk8PaNSmlUtnZXrn3bREI 6eAAnjEYq7uFgggrz160hP10DBFIZ2Rr =qkVm -----END PGP SIGNATURE-----
participants (4)
-
Craig Stacey -
Linda Winkler -
Rick Bradshaw -
Schmitz Corby