ReleaseOperations/Projects/AutomaticProvisioning/Meetings/2014-01-29: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "== Followup on Action Items == * look at provisioning tools / cloud stacks -- jake/dustin * continue with JAMF --jake * moving things out of GPO and into puppet or MDT (diffic...")
 
No edit summary
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
== Followup on Action Items ==
Meeting started by dustin at 17:30:12 UTC. The full logs are available at http://people.v.igoro.us/~dustin/meetbot/taskcluster/2014/taskcluster.2014-01-29-17.30.log.html
* look at provisioning tools / cloud stacks -- jake/dustin
* continue with JAMF --jake
* moving things out of GPO and into puppet or MDT (difficult with Win8 - registration of default browsers is domain-only) --Q
* continue with puppet on windows, with different focus (puppet doesn't run on prod instances) --mark
* plan for VLAN changes, but no implementation this quarter --adam


== Round Table ==
 
* Can machines keep their existing hostnames through re-images (and fqdn/IP when not changing VLANs)? If so, how should we name them?  $hardwaretype$number? $assetag?
 
** Or, asking another way: how much identity do we want to assign to hardware, and how much to instances?
= Meeting summary =
 
* followup  (dustin, 17:31:46)
** installing an eval of openstack - https://bugzilla.mozilla.org/show_bug.cgi?id=963165  (dustin, 17:32:21)
** no time to look  (dustin, 17:33:13)
** installing an eval of cloudstack - https://bugzilla.mozilla.org/show_bug.cgi?id=963161  (dustin, 17:33:17)
** might be starting today, now that pices are in place  (dustin, 17:34:07)
** no updates on windows, VLAN changes  (dustin, 17:36:26)
 
* system identity  (dustin, 17:36:48)
** Can machines keep their existing hostnames through re-images (and fqdn/IP when not changing VLANs)? If so, how should we name them?  $hardwaretype$number? $assetag? (dustin, 17:47:14)
** need some feedback from API consumers as to how well this would work - are instances expected to have static IPs as they do in AWS?  (dustin, 17:49:39)
 
* monitoring for dynamic hosts  (dustin, 17:50:07)
** ACTION: dividehex look into monitoring support in stack suites (e.g., identifying bad hardware)  (dustin, 17:56:48)
** would be great to get as much info on hardware status as possible from the stack suite  (dustin, 17:59:37)
** we may also want to build a way to tie job failures to hardware and alert (and possibly disable provisioning of the hardware automatically) over a particular threshold  (dustin, 18:00:06)
** ACTION: Q to pull some related ideas out of his shadowy past in video rendering  (dustin, 18:02:14)
 
Meeting ended at 18:02:26 UTC.
 
Action Items
------------
* dividehex look into monitoring support in stack suites (e.g., identifying bad hardware)
* Q to pull some related ideas out of his shadowy past in video rendering
 
Action Items, by person
-----------------------
* dividehex
** dividehex look into monitoring support in stack suites (e.g., identifying bad hardware)
* Q
** Q to pull some related ideas out of his shadowy past in video rendering
 
People Present (lines said)
---------------------------
* dustin (68)
* dividehex (10)
* adam (10)
* Q (9)
* meetbot (3)

Latest revision as of 19:21, 29 January 2014

Meeting started by dustin at 17:30:12 UTC. The full logs are available at http://people.v.igoro.us/~dustin/meetbot/taskcluster/2014/taskcluster.2014-01-29-17.30.log.html


Meeting summary

  • system identity (dustin, 17:36:48)
    • Can machines keep their existing hostnames through re-images (and fqdn/IP when not changing VLANs)? If so, how should we name them? $hardwaretype$number? $assetag? (dustin, 17:47:14)
    • need some feedback from API consumers as to how well this would work - are instances expected to have static IPs as they do in AWS? (dustin, 17:49:39)
  • monitoring for dynamic hosts (dustin, 17:50:07)
    • ACTION: dividehex look into monitoring support in stack suites (e.g., identifying bad hardware) (dustin, 17:56:48)
    • would be great to get as much info on hardware status as possible from the stack suite (dustin, 17:59:37)
    • we may also want to build a way to tie job failures to hardware and alert (and possibly disable provisioning of the hardware automatically) over a particular threshold (dustin, 18:00:06)
    • ACTION: Q to pull some related ideas out of his shadowy past in video rendering (dustin, 18:02:14)

Meeting ended at 18:02:26 UTC.

Action Items


  • dividehex look into monitoring support in stack suites (e.g., identifying bad hardware)
  • Q to pull some related ideas out of his shadowy past in video rendering

Action Items, by person


  • dividehex
    • dividehex look into monitoring support in stack suites (e.g., identifying bad hardware)
  • Q
    • Q to pull some related ideas out of his shadowy past in video rendering

People Present (lines said)


  • dustin (68)
  • dividehex (10)
  • adam (10)
  • Q (9)
  • meetbot (3)