All users were logged out of Bugzilla on October 13th, 2018

New HTTP edge build logic

RESOLVED FIXED

Status

P1
normal
RESOLVED FIXED
2 years ago
13 hours ago

People

(Reporter: whd, Assigned: whd)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [SvcOps])

(Assignee)

Description

2 years ago
1 point left on this. This work is based off our standard openresty build config. I started out by using dynamic modules, but after talking with ops switched to a statically compiled build.

Things that still need to be done: make sure adding a new luasandbox-core rpm to our depencendy repo doesn't conflict with the current redshift loading production tasks (using a very old hindsight), and adding a jenkins task (which becomes a question of versioning).
(Assignee)

Comment 1

2 years ago
https://github.com/mozilla-services/svcops/compare/new_telemetry?expand=1

This has been hooked into jenkins. For now, to get around the push load luasandbox-core compatibility issues, we're treating the various RPM dependencies of nginx-moz-ingest as stack-specific assets that get pulled in during the package build (
https://github.com/mozilla-services/svcops/compare/new_telemetry?expand=1#diff-d1a436c50d25000c9d1f9d76eadefce5R214) and are thus only available via the stack-specific repos.

The jenkins job, which has been hooked into the edge deploy pipeline:
 
https://deploy.mozaws.net/view/Pipeline-Edge/job/Pipeline-Edge-Package/

RPM version and release are based on the timestamp and hash of the HEAD commit of the repository as specified to the build job.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED

Updated

13 hours ago
Product: Cloud Services → Cloud Services Graveyard
You need to log in before you can comment on or make changes to this bug.