[almighty] Adhoc stack instance for PR code builds

[Aslak Knutsen]

On Sat, Sep 10, 2016 at 11:52 AM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

> My current thinking is is that we deploy this PR against latest-master
> of everything else. eg. a PR for 'core' would deploy against last
> deployed api and db. Similarly the PR for core would deploy with the
> last good UI and db etc ; but each time, the entire stack is brought
> up as an app, and exposed under its own set of hostnames.[1]
>
> sounds reasonable.
>
> Since the PR can come from different services, we would need to map
> that via the hostname for clarity eg: core-pr25.<qdn> or ui-pr40.<qdn> e
> tc
>
> +1
>
> Two primary concerns at this point are :
> 1) it will almost always be a blank db.
> 2) it will be had to have a api change be visible in sync with a
> proposed UI PR.
> for (1) the easy route is to do a db dump from demo.db and load that
> into the db brought up for the instance. However, given that this
> brings with it the risk of exposing otherwise-private or privileged
> info, we should never really do that. The middle ground between
> no-data and all-the-data is to have a test dataset. Is this something
> we can do ? if so, we can workout the mechanics of storing it and
> loading/validating it.
>
> I would say we would *have* to be able to load the system with test data.
> Any system I worked on that had it became so much better by it.
>
There is always the fun part of keeping test data in sync with reality...
but if we get our examples testable,
https://github.com/almighty/almighty-core/pull/195#issuecomment-244894637,
we might be able to use that to seed the database with a dataset
controlled/tested by Core... ?


> Given the present dataset live at demo.a.i, generating this test data
> might just be a case of dumping the present dataset into sql and
> checking it into the git repos.
>
> Yes, keep it simple.
>
> for (2) the solution will likely be in finding a way to parse and
> establish the cross services PR relationship via the github comments.
> However, given the complexity in that, and given that the actual CD
> pipeline for the service as a while will need to be atomic - I propose
> that the PR test stages also be atomic. If a UI function needs core
> functionality, it should be built, tested and deployed via core first
> then exercised via the UI.
>
> I think that is what we would have to do for now.
>
> I wonder if the way to handle the cross-cutting PR's is to instead of
> having Core and UI
> in separate repos is to have them together and then split repos based on
> micro service vertical slices
> rather than horizontal slices ?
>
> its also one of the tenants of 12factor.net (https://12factor.net/codebase)
> that I think makes a lot of sense
> for our kind of app(s).
>

Not sure that is what I take from that 12Factor section. It's simply
stating that a Deployment of 'the same' should only point to a single
repository at some time in it's life(sha). It doesn't define 'App' beyond;
if it doesn't, you have multiple apps and you are a distributed system.


> With this much less magic needed IMO. WDYT ?
>

A single UI is definitely less magical... There is a lot of
cordination/composition required to handle a ms ui.

I would recommend tumbling as short as possible down the MS rabbit whole
for the time being. Unless you're prepared to write infrastructure code for
the next 8 months...

-aslak-


> /max
> http://about.me/maxandersen
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160912/249af7f4/attachment.htm>