[Platformone] [EXT] Re: Account for Dirty Dev
Kevin O'Donnell
kodonnel at redhat.com
Tue Jan 7 15:38:30 UTC 2020
Tim,
This should all be automated.
I will be on site tomorrow, let's discuss.
Thanks,
KEVIN O'DONNELL
ARCHITECT MANAGER
Red Hat Red Hat NA Public Sector Consulting <https://www.redhat.com/>
kodonnell at redhat.com <kodonnell at redhat.com%20M:240-605-4654> M: 240-605-4654
<https://red.ht/sig>
On Tue, Jan 7, 2020 at 10:11 AM Miller, Timothy J. <tmiller at mitre.org>
wrote:
> 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
> >
> >
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/platformone/attachments/20200107/81958b1f/attachment.htm>
More information about the platformONE
mailing list