<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 10, 2016 at 11:52 AM, Max Rydahl Andersen <span dir="ltr"><<a href="mailto:manderse@redhat.com" target="_blank">manderse@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u> <div> <div style="font-family:sans-serif"><span class="gmail-"><div style="white-space:normal"> <p dir="auto"></p></div> <div style="white-space:pre-wrap"><blockquote style="border-left:2px solid rgb(119,119,119);color:rgb(119,119,119);margin:0px 0px 5px;padding-left:5px"><div dir="auto">My current thinking is is that we deploy this PR against latest-master </div><div dir="auto">of everything else. eg. a PR for 'core' would deploy against last </div><div dir="auto">deployed api and db. Similarly the PR for core would deploy with the </div><div dir="auto">last good UI and db etc ; but each time, the entire stack is brought </div><div dir="auto">up as an app, and exposed under its own set of hostnames.[1] </div></blockquote></div> </span><div style="white-space:normal"> <p dir="auto">sounds reasonable.</p> <p dir="auto"></p></div><span class="gmail-"> <div style="white-space:pre-wrap"><blockquote style="border-left:2px solid rgb(119,119,119);color:rgb(119,119,119);margin:0px 0px 5px;padding-left:5px"><div dir="auto">Since the PR can come from different services, we would need to map </div><div dir="auto">that via the hostname for clarity eg: core-pr25.<qdn> or ui-pr40.<qdn> e </div><div dir="auto">tc </div></blockquote></div> </span><div style="white-space:normal"> <p dir="auto">+1</p> <p dir="auto"></p></div><span class="gmail-"> <div style="white-space:pre-wrap"><blockquote style="border-left:2px solid rgb(119,119,119);color:rgb(119,119,119);margin:0px 0px 5px;padding-left:5px"><div dir="auto">Two primary concerns at this point are : </div><div dir="auto">1) it will almost always be a blank db. </div><div dir="auto">2) it will be had to have a api change be visible in sync with a </div><div dir="auto">proposed UI PR. </div><div dir="auto"> </div><div dir="auto">for (1) the easy route is to do a db dump from demo.db and load that </div><div dir="auto">into the db brought up for the instance. However, given that this </div><div dir="auto">brings with it the risk of exposing otherwise-private or privileged </div><div dir="auto">info, we should never really do that. The middle ground between </div><div dir="auto">no-data and all-the-data is to have a test dataset. Is this something </div><div dir="auto">we can do ? if so, we can workout the mechanics of storing it and </div><div dir="auto">loading/validating it. </div></blockquote></div> </span><div style="white-space:normal"> <p dir="auto">I would say we would <em>have</em> to be able to load the system with test data.<br> Any system I worked on that had it became so much better by it.</p></div></div></div></blockquote><div>There is always the fun part of keeping test data in sync with reality... but if we get our examples testable, <a href="https://github.com/almighty/almighty-core/pull/195#issuecomment-244894637">https://github.com/almighty/almighty-core/pull/195#issuecomment-244894637</a>, we might be able to use that to seed the database with a dataset controlled/tested by Core... ?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"> <p dir="auto"></p></div><span class="gmail-"> <div style="white-space:pre-wrap"><blockquote style="border-left:2px solid rgb(119,119,119);color:rgb(119,119,119);margin:0px 0px 5px;padding-left:5px"><div dir="auto">Given the present dataset live at demo.a.i, generating this test data </div><div dir="auto">might just be a case of dumping the present dataset into sql and </div><div dir="auto">checking it into the git repos. </div></blockquote></div> </span><div style="white-space:normal"> <p dir="auto">Yes, keep it simple.</p> <p dir="auto"></p></div><span class="gmail-"> <div style="white-space:pre-wrap"><blockquote style="border-left:2px solid rgb(119,119,119);color:rgb(119,119,119);margin:0px 0px 5px;padding-left:5px"><div dir="auto">for (2) the solution will likely be in finding a way to parse and </div><div dir="auto">establish the cross services PR relationship via the github comments. </div><div dir="auto">However, given the complexity in that, and given that the actual CD </div><div dir="auto">pipeline for the service as a while will need to be atomic - I propose </div><div dir="auto">that the PR test stages also be atomic. If a UI function needs core </div><div dir="auto">functionality, it should be built, tested and deployed via core first </div><div dir="auto">then exercised via the UI. </div></blockquote></div> </span><div style="white-space:normal"> <p dir="auto">I think that is what we would have to do for now.</p> <p dir="auto">I wonder if the way to handle the cross-cutting PR's is to instead of having Core and UI<br> in separate repos is to have them together and then split repos based on micro service vertical slices<br> rather than horizontal slices ? </p> <p dir="auto">its also one of the tenants of <a href="http://12factor.net" target="_blank">12factor.net</a> (<a href="https://12factor.net/codebase" style="color:rgb(57,131,196)" target="_blank">https://12factor.net/codebase</a><wbr>) that I think makes a lot of sense<br> for our kind of app(s).</p></div></div></div></blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"> <p dir="auto">With this much less magic needed IMO. WDYT ?</p></div></div></div></blockquote><div><br></div><div>A single UI is definitely less magical... There is a lot of cordination/composition required to handle a ms ui.</div><div><br></div><div>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... </div><div><br></div><div>-aslak-</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto"> </p> <p dir="auto">/max<br> <a href="http://about.me/maxandersen" style="color:rgb(57,131,196)" target="_blank">http://about.me/maxandersen</a></p> </div> </div> </div> <br>______________________________<wbr>_________________<br> almighty-public mailing list<br> <a href="mailto:almighty-public@redhat.com">almighty-public@redhat.com</a><br> <a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/almighty-<wbr>public</a><br> <br></blockquote></div><br></div></div>