[Platformone] [EXT] Re: Account for Dirty Dev
Miller, Timothy J.
tmiller at mitre.org
Tue Jan 7 15:09:41 UTC 2020
Not what I'm saying; this has nothing to do with mission app data persistence.
A *dev toolchain* accrues project history. If you dump this data because the dev cluster was redeployed, we lose valuable history and can complicate future iterations.
For example, Sonarqube tracks code quality issues over time for a given project key. With each iteration, developers and security leads are evaluating findings, suppressing false positives, accepting some true positives, planning POA&Ms for others, and updating sonarqube's profile appropriately.
If you dump this data when re-dploying the dev environment, each dev team will have to do all of this work again.
-- T
> -----Original Message-----
> From: Kevin O'Donnell <kodonnel at redhat.com>
> Sent: Tuesday, January 07, 2020 8:30 AM
> To: Miller, Timothy J. <tmiller at mitre.org>
> Cc: Dino Arachchi <darachch at redhat.com>; Tim Gast <tg at braingu.com>;
> platformONE at redhat.com; Lastrilla, Jet <jlastrilla at mitre.org>
> Subject: Re: [Platformone] [EXT] Re: Account for Dirty Dev
>
> Tim,
>
> The application should be preserving application data, project history,
> individual toolchain elements, and history.
>
> As an example, when the application moves into Cloud1 how will the
> application preserve this information. The move into Cloud1 is no different
> than the move into an updated product (say OCP 3.11.5, or OCP 4.x) and or a
> new cloud provider or even on-prem.
>
> Thanks,
>
>
> KEVIN O'DONNELL
>
> ARCHITECT MANAGER
>
> Red Hat Red Hat NA Public Sector Consulting <https://www.redhat.com/>
>
> kodonnell at redhat.com <mailto:kodonnell at redhat.com%20M:240-605-
> 4654> M: 240-605-4654
>
> <https://red.ht/sig>
>
>
>
> On Tue, Jan 7, 2020 at 12:01 AM Miller, Timothy J. <tmiller at mitre.org
> <mailto:tmiller at mitre.org> > wrote:
>
>
> Unless you're preserving application data across redeploys, that's not
> an acceptable operating model. Project history is constantly accrued in the
> individual elements of the toolchain, and that history is important for analysis
> of application risk, projection of milestones, and team performance. If that's
> lost each time a feature is deployed, it will make it much harder to manage
> development projects.
>
> I'm also not sure I see any utility of a/b testing of the platform itself.
> The major workloads in the dev environment are builds and automated
> tests. What specific platform features require a/b test and evaluation? Is
> there a design record for this decision?
>
> -- T
>
> On 1/5/20, 13:41, "Kevin O'Donnell" <kodonnel at redhat.com
> <mailto:kodonnel at redhat.com> > wrote:
>
> Hello Tim,
>
>
> This is by design. We have freedom in AWS Gov. But we do not
> have the same freedom with the other target providers; CloudOne. We are
> setting up a blue / green deployment for the dev teams. up-prod-a / b, up-
> appdev-a / b. As enhancements are developed tested,
> staged and tested, feedback is received, with a green light we will
> fully redeploy to either a or b. The teams can test the apps in the new
> environment to provide feedback and make the decision to roll over to it or
> not.
>
>
> This also falls in line with the last email thread, on keys.
>
>
> "Correct. Re-enforcing the Day Two requirements. And also
> supporting that the pipelines and CI process can support CI/CD to only
> dev/staging. For prod or any environment were the keys have been
> swapped and are not included as private Git variables we can
> not support CD into prod/appdev if so deemed. "
>
>
> I am sure we can come up with some creative ways to reduce the
> total deployment time however it has not been top on our priority list.
>
>
> Thanks,
>
> KEVIN O'DONNELL
> ARCHITECT MANAGER
> Red Hat Red Hat NA Public Sector Consulting
> <https://www.redhat.com/>
>
> kodonnell at redhat.com <mailto:kodonnell at redhat.com>
> <mailto:kodonnell at redhat.com <mailto:kodonnell at redhat.com>
> %20M:240-605-4654> M: 240-605-4654
> <https://red.ht/sig>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sun, Jan 5, 2020 at 2:30 PM Miller, Timothy J. <tmiller at mitre.org
> <mailto:tmiller at mitre.org> > wrote:
>
>
> Color me confused--y'all have spent time writing and validating that
> the ansible roles are idempotent, so why do incremental changes to the
> plays require a build from scratch?
>
> And since 3.5h of the 5h build time is sync'ing Satellite repos, at
> what point will y'all checkpoint that data into an AMI or a resuable bucket?
>
> -- T
>
> On 12/23/19, 14:57, "platformone-bounces at redhat.com
> <mailto:platformone-bounces at redhat.com> on behalf of Dino Arachchi"
> <platformone-bounces at redhat.com <mailto:platformone-
> bounces at redhat.com> on behalf
> of darachch at redhat.com <mailto:darachch at redhat.com> >
> wrote:
>
> Tim,
>
>
> There were some security features that didn't get merged into
> the branch used to build the stack. This will require the same 4-5 hours as the
> last build due to the fully disconnected nature of the build process. We do
> have an open issue for connected environments
> that will cut down build time, but that feature is still in progress.
>
>
> Best Regards,
>
>
> DINO ARACHCHI
> SENIOR CONSULTANT
> darachch at redhat.com <mailto:darachch at redhat.com> M:
> 848-203-1809 <tel:848-203-1809>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Dec 23, 2019 at 2:49 PM Tim Gast <tg at braingu.com
> <mailto:tg at braingu.com> > wrote:
>
>
> Thanks for the update.
> What was the issue you found that would cause the entire stack
> to need a rebuild?
>
> Are we looking at another 5 hour build?
>
>
>
> Thanks,
> -Tim
>
>
>
> On Dec 23, 2019, at 2:47 PM, Dino Arachchi
> <darachch at redhat.com <mailto:darachch at redhat.com> > wrote:
>
> All,
>
>
> While provisionin the dev accounts, an issue was identified in the
> newly created up-appdev-a cluster. Code changes are being made now, after
> which the stack will be rebuilt. Once this is completed and verified, I will
> proceed with the creation of the new
> accounts. These tasks are estimated to be completed today, and
> an email will be sent out to confirm.
>
>
> Best Regards,
>
>
> DINO ARACHCHI
> SENIOR CONSULTANT
> darachch at redhat.com <mailto:darachch at redhat.com> M:
> 848-203-1809 <tel:848-203-1809>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Dec 23, 2019 at 1:46 PM Kevin O'Donnell
> <kodonnel at redhat.com <mailto:kodonnel at redhat.com> > wrote:
>
>
> Thanks Dino
>
>
>
> -Kevin
>
> On Mon, Dec 23, 2019 at 2:38 PM Tim Gast <tg at braingu.com
> <mailto:tg at braingu.com> > wrote:
>
>
> Thanks Dino.
>
> -Tim
>
>
>
> On Dec 23, 2019, at 1:37 PM, Dino Arachchi
> <darachch at redhat.com <mailto:darachch at redhat.com> > wrote:
>
>
>
>
>
>
>
>
>
> Hi Tim,
>
>
> I'm on PTO but am working on creating the dev accounts at the
> moment. The team should expect to receive credentials within the next
> couple hours.
>
>
> Best Regards,
>
>
> DINO ARACHCHI
> SENIOR CONSULTANT
> darachch at redhat.com <mailto:darachch at redhat.com> M:
> 848-203-1809 <tel:848-203-1809>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Dec 23, 2019 at 12:53 PM Tim Gast <tg at braingu.com
> <mailto:tg at braingu.com> > wrote:
>
>
> Hi Kevin,
>
>
> Any word on when to be looking for those dev accounts?
>
> Thanks,
> -Tim
>
>
>
> On Dec 21, 2019, at 10:22 AM, Kevin O'Donnell
> <kodonnel at redhat.com <mailto:kodonnel at redhat.com> > wrote:
>
> Build completed in 4 hours and 40 min. On Monday we will get
> the accounts created and also add some code into our build to automate the
> account creation process.
>
>
> Everyone enjoy your weekend.
>
>
> <image.png>
>
> KEVIN O'DONNELL
> ARCHITECT MANAGER
> Red Hat Red Hat NA Public Sector Consulting
> <https://www.redhat.com/>
>
> kodonnell at redhat.com <mailto:kodonnell at redhat.com>
> <mailto:kodonnell at redhat.com <mailto:kodonnell at redhat.com>
> %20M:240-605-4654> M: 240-605-4654
> <https://red.ht/sig>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Dec 20, 2019 at 9:19 PM Tim Gast <tg at braingu.com
> <mailto:tg at braingu.com> > wrote:
>
>
> Thanks for the update Kevin.
>
> -Tim
>
>
>
> On Dec 20, 2019, at 7:26 PM, Kevin O'Donnell
> <kodonnel at redhat.com <mailto:kodonnel at redhat.com> > wrote:
>
>
>
>
>
> Were about 3 hours in.
>
>
> <image.png>
>
>
> KEVIN O'DONNELL
> ARCHITECT MANAGER
> Red Hat Red Hat NA Public Sector Consulting
> <https://www.redhat.com/>
>
> kodonnell at redhat.com <mailto:kodonnell at redhat.com>
> <mailto:kodonnell at redhat.com <mailto:kodonnell at redhat.com>
> %20M:240-605-4654> M: 240-605-4654
> <https://red.ht/sig>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Dec 20, 2019 at 8:04 PM Kevin O'Donnell
> <kodonnel at redhat.com <mailto:kodonnel at redhat.com> > wrote:
>
>
> Hello Tim,
>
>
>
> The aws rbac changes impacted our deployment and it didn’t get
> the deployment running till 5pm est. I keep an eye on the job.
>
> On Fri, Dec 20, 2019 at 5:19 PM Tim Gast <tg at braingu.com
> <mailto:tg at braingu.com> > wrote:
>
>
> Hi.
> Checking in since it’s been a few hours in flight.
> Do we have a UP-DEV-A cluster and user access now?
>
>
> Thanks,
> -Tim
>
>
>
> On Dec 20, 2019, at 11:49 AM, Tim Gast <tg at braingu.com
> <mailto:tg at braingu.com> > wrote:
>
>
>
>
>
> Kevin, Mark, & Roc,
>
>
>
>
>
>
>
>
> Below is the request for dev accounts for UP-APPDEV-A.
> Can we please mirror what these folks have in the current UP-
> Prod-A cluster.
>
>
> Also, is it possible to provide an “elevated read” role for certain
> users (dcurrian) for discovery/troubleshooting?
>
>
> Please let me know when the environment is live and ready for
> the team to begin working with.
>
>
> Thanks,
> -Tim
>
>
> Begin forwarded message:
>
>
>
> From: "Curran, Daniel M" <Daniel.Curran at ManTech.com>
> Date: December 20, 2019 at 11:15:39 AM CST
> To: "tg at braingu.com <mailto:tg at braingu.com> "
> <tg at braingu.com <mailto:tg at braingu.com> >, "nino at braingu.com
> <mailto:nino at braingu.com> " <nino at braingu.com
> <mailto:nino at braingu.com> >
> Cc: "Buffaloe, Christopher"
> <Christopher.Buffaloe at ManTech.com>
> Subject: Account for Dirty Dev
>
>
>
>
>
> Hey Tim and Nino,
>
>
> Here's the account list for the Ginyu Force (CCAT) team
> dcurran
> rcepeda
> msison
> psoliz
> atorres
> dpalmer
> rho
> kmacias
> jandrichak
>
>
> Obviously we'll take all the privileges you're willing to give us but
> if we can keep our dev privileges from the unified-platform cluster and put
> us in a ginyu/ccat group so we can see each others projects that
> would be enough.
> It might also be advantageous to have one admin account
> (dcurran-adm or ccat-adm) or at least one with elevated read privileges for
> discovery purposes but I wouldn't call that a hard requirement.
>
>
> Thanks,
> Daniel
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> KEVIN O'DONNELL
> ARCHITECT MANAGER
> Red Hat Red Hat NA Public Sector Consulting
> <https://www.redhat.com/>
>
> kodonnell at redhat.com <mailto:kodonnell at redhat.com>
> <mailto:kodonnell at redhat.com <mailto:kodonnell at redhat.com>
> %20M:240-605-4654> M: 240-605-4654
> <https://red.ht/sig>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> KEVIN O'DONNELL
> ARCHITECT MANAGER
> Red Hat Red Hat NA Public Sector Consulting
> <https://www.redhat.com/>
>
> kodonnell at redhat.com <mailto:kodonnell at redhat.com>
> <mailto:kodonnell at redhat.com <mailto:kodonnell at redhat.com>
> %20M:240-605-4654> M: 240-605-4654
> <https://red.ht/sig>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> platformONE mailing list
> platformONE at redhat.com <mailto:platformONE at redhat.com>
> https://www.redhat.com/mailman/listinfo/platformone
>
>
>
>
>
>
More information about the platformONE
mailing list