<div dir="ltr">oops, did not intend to skip list.. see below, comments inline<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 28, 2016 at 2:22 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u> <div> <div style="font-family:sans-serif"><div style="white-space:normal"> <p dir="auto">was it intentional your skipped the list ? (comments inline)</p><span class=""> <p dir="auto">On 28 Jul 2016, at 13:54, Aslak Knutsen wrote:</p> <p dir="auto"></p></span></div><span class=""> <div style="white-space:pre-wrap"><blockquote style="border-left:2px solid #777;color:#777;margin:0 0 5px;padding-left:5px"><div dir="auto">This brings us back to the original federated/distributed idea of using Git </div><div dir="auto">as a 'write-through' storage. </div><div dir="auto"> </div><div dir="auto">For things like the WorkItem Type definitions, </div><div dir="auto"> </div><div dir="auto">* Store changes from UI in the git repo </div><div dir="auto">* Expose the repo on some URL </div><div dir="auto"> </div><div dir="auto">That would allow anyone to clone that repo to anywhere and push back </div><div dir="auto">changes that are made. </div><div dir="auto"> </div><div dir="auto">The workflow of updating the definition of the WorkItems that rely on that </div><div dir="auto">definition is a different story tho. </div><div dir="auto"> </div><div dir="auto">* We can't assume the user will take on the responsibility of properly </div><div dir="auto">versioning the WorkItemTypes so that Core can recreate it. </div><div dir="auto"> </div><div dir="auto">The repo would need to be the latest v of them(?). A change to the repo </div><div dir="auto">would trigger core to create a new WorkItemType version to be created. </div></blockquote></div> </span><div style="white-space:normal"> <p dir="auto">But isn't the above just "another" storage - that it is git is great, but not really solving the issue here right ?</p></div></div></div></blockquote><div>The issue here as far as I can tell is the abillity to confgure certain things in the ALM outside of a UI.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"> <p dir="auto">The issue of committing lets say your .jenkinsfile into your projects git repo means that files lifecycle/scope is <br> that project, in that branch.</p></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"> <p dir="auto">For ALM where a project or lets call it a product might map to multiple projects do you expect to store issues, configuration, etc. into<br> the specific git repo storage for source code ? I've always seen it as a separate git repo.</p></div></div></div></blockquote><div><br></div><div>Yes, I mean ALM will expose a 'Project/Product' repository for ALM configuration. Completly unrelated to any other source code. Think more in the lines of how gh-pages work (except the specific branch thing), but for ALM configuration. A push to master will Load the data/configuration into the ALM, but it might need be activated (might require some additional API call to update existing workitems etc etc). But it's a Reposiotry on the same line as a Source Repo, so you can 'Plan' issues in the configuration, reference changes etc etc</div><div><br></div><div>The content would be JSON objects. You can write what ever tool chain your heart desires to manipulate them.</div><div>(Not that you couldn't just have a git repo with the REST API payloads and build what ever you want around that as well and run a script to invoke it, but..)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"> <p dir="auto">Which means you do get the benefit of easy sharing and being able to do updates outside of a graphical UI (assuming the format is actually also somewhat humanly readable).</p> <p dir="auto">But you don't get the benefit of having the config <em>inside</em> your source code.</p></div></div></div></blockquote><div><br></div><div>I think the reference to Source Control repo was just tyring to say 'in git/svn/hq', not litterally inside the repository where the source code is. You'll have 100 source repos with possible conflicting definitions so yea.. </div><div><br></div><div>(tho I guess we could technically take it one step further and allow 'any' repo to contain this type of information and have Build Pipelines for updating the ALM it self. It would allow the user to control it, but also shoot him self in the foot multiple times. :) <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"> <p dir="auto">/max</p> <p dir="auto"></p></div><div><div class="h5"> <div style="white-space:pre-wrap"><blockquote style="border-left:2px solid #777;color:#777;margin:0 0 5px;padding-left:5px"><div dir="auto"> </div><div dir="auto">-aslak- </div><div dir="auto"> </div><div dir="auto">On Thu, Jul 28, 2016 at 1:30 PM, Max Rydahl Andersen <<a href="mailto:manderse@redhat.com" target="_blank">manderse@redhat.com</a>> </div><div dir="auto">wrote: </div><div dir="auto"> </div><blockquote style="border-left:2px solid #777;color:#999;margin:0 0 5px;padding-left:5px;border-left-color:#999"><div dir="auto">On 28 Jul 2016, at 13:07, Pete Muir wrote: </div><div dir="auto"> </div><div dir="auto">The other thing to think about here is "infrastructure as code", </div><blockquote style="border-left:2px solid #777;color:#bbb;margin:0 0 5px;padding-left:5px;border-left-color:#bbb"><div dir="auto">particularly in relation to continuous delivery. </div><div dir="auto"> </div><div dir="auto">How would someone be able to store the ALM configuration in a source </div><div dir="auto">control repo, and make changes to the running instance using </div><div dir="auto">continuous delivery and at the same time support non-technical users </div><div dir="auto">in making changes (such as the UIs that Miroslav discussed). </div><div dir="auto"> </div></blockquote><div dir="auto"> </div><div dir="auto">Just to make sure we are talking about the same things here. </div><div dir="auto"> </div><div dir="auto">What ALM configuration are you thinking about specifically ? </div><div dir="auto"> </div><div dir="auto">I'm currently of the mindset that if you are going for the SCM based </div><div dir="auto">approach then you are on your own and thus non-technical users cannot make </div><div dir="auto">users via </div><div dir="auto">a controlled UI. What the ALM will then do is more about being a </div><div dir="auto">destination </div><div dir="auto">for the build to publish results to rather than be automagically </div><div dir="auto">configured. </div><div dir="auto"> </div><div dir="auto">This of course does not mean another project in the same ALM can't support </div><div dir="auto">a more UI driven approach. </div><div dir="auto"> </div><div dir="auto">I think this is definitely a scenario we should support, given our </div><blockquote style="border-left:2px solid #777;color:#bbb;margin:0 0 5px;padding-left:5px;border-left-color:#bbb"><div dir="auto">focus on supporting companies wanting to use CD/pipelines. </div><div dir="auto"> </div></blockquote><div dir="auto"> </div><div dir="auto">+1 </div><div dir="auto"> </div><div dir="auto">/max </div><div dir="auto"> </div><div dir="auto"> </div><div dir="auto"> </div><blockquote style="border-left:2px solid #777;color:#bbb;margin:0 0 5px;padding-left:5px;border-left-color:#bbb"><div dir="auto">On 27 July 2016 at 08:48, Konrad Kleine <<a href="mailto:kkleine@redhat.com" target="_blank">kkleine@redhat.com</a>> wrote: </div><div dir="auto"> </div><blockquote style="border-left:2px solid #777;color:#bbb;margin:0 0 5px;padding-left:5px;border-left-color:#bbb"><div dir="auto">Hi Miroslav, </div><div dir="auto"> </div><div dir="auto">thank you for sharing your thoughts on these three ways to customize an </div><div dir="auto">application: </div><div dir="auto"> </div><div dir="auto">1. Via dedicated UI forms, wizards and DSL </div><blockquote style="border-left:2px solid #777;color:#bbb;margin:0 0 5px;padding-left:5px;border-left-color:#bbb"><div dir="auto">2. Using configuration files </div><div dir="auto">3. Customizing it in application code </div><div dir="auto"> </div></blockquote><div dir="auto"> </div><div dir="auto"> </div><div dir="auto">I believe that 1. and 2. have a somewhat symbiotic effect. Let me try to </div><div dir="auto">explain what I mean by this: </div><div dir="auto"> </div><div dir="auto">I think there's the act of customizing and then there is storing of this </div><div dir="auto">customization. The later can be a configuration file format (e.g. JSON) </div><div dir="auto">with </div><div dir="auto">DSL inside. We use PostgreSQL as our database and this can store JSON as </div><div dir="auto">native objects. The pure act of customization on the other side can be </div><div dir="auto">either writing these JSON files by hand or manipulating them using a UI. </div><div dir="auto"> </div><div dir="auto">I may be naive but I think the benefit of having a configuration file </div><div dir="auto">format </div><div dir="auto">allows for customization right from the start. A UI can be added later </div><div dir="auto">(that </div><div dir="auto">is probably the naive part). </div><div dir="auto"> </div><div dir="auto">Regards, </div><div dir="auto">Konrad Kleine </div><div dir="auto"> </div><div dir="auto">Software Engineer </div><div dir="auto">Red Hat GmbH </div><div dir="auto">Werner-von-Siemens-Ring 15 </div><div dir="auto">85630 Grasbrunn, Germany </div><div dir="auto"> </div><div dir="auto"> </div><div dir="auto">On Tue, Jul 26, 2016 at 7:00 PM, Miroslav Hradilek <<a href="mailto:mhradile@redhat.com" target="_blank">mhradile@redhat.com</a>> </div><div dir="auto">wrote: </div><div dir="auto"> </div><blockquote style="border-left:2px solid #777;color:#bbb;margin:0 0 5px;padding-left:5px;border-left-color:#bbb"><div dir="auto"> </div><div dir="auto">Hello, </div><div dir="auto"> </div><div dir="auto">this is the first of my emails where I will be sharing my thoughts on </div><div dir="auto">some </div><div dir="auto">design decisions that, in my opinion, are worth considering when </div><div dir="auto">designing </div><div dir="auto">ALM architecture. </div><div dir="auto"> </div><div dir="auto"> </div><div dir="auto"># User Based Setup </div><div dir="auto"> </div><div dir="auto">So in most applications, and especially ones like ALM, there is a big </div><div dir="auto">need </div><div dir="auto">for customizing everything like objects, behavior etc. </div><div dir="auto"> </div><div dir="auto">It is mostly done in three ways: </div><div dir="auto"> </div><div dir="auto">1. Via dedicated UI forms, wizards and DSL </div><div dir="auto">2. Using configuration files </div><div dir="auto">3. Customizing it in application code </div><div dir="auto"> </div><div dir="auto"> </div><div dir="auto">I've personally had a chance to use all three ways throughout my life </div><div dir="auto">and </div><div dir="auto">I'm sure the readers are the same. All the methods have pros and cons. </div><div dir="auto">Some </div><div dir="auto">depend on licensing and their application depends on the skill set of </div><div dir="auto">the </div><div dir="auto">user. </div><div dir="auto"> </div><div dir="auto"># Approaches </div><div dir="auto"> </div><div dir="auto">1) UI etc </div><div dir="auto">This is by far the most consumable method for not very technically </div><div dir="auto">skilled </div><div dir="auto">people or people not willing to invest in learning the application. The </div><div dir="auto">sole </div><div dir="auto">configuration form is like reference documentation and configuration </div><div dir="auto">files </div><div dir="auto">combined. Even higher level of contextual configuration can be achieved </div><div dir="auto">by </div><div dir="auto">employing wizards which interact with the user until the configuration </div><div dir="auto">is </div><div dir="auto">finished. </div><div dir="auto"> </div><div dir="auto">The downside to this is that it requires the application developers to </div><div dir="auto">burn time to code often quite complex forms. Sometimes the expression of </div><div dir="auto">such form is quite limited and Domain Specific Language must be defined </div><div dir="auto">to </div><div dir="auto">overcome this lack of expression. Example being the languages describing </div><div dir="auto">mail filters, query languages etc. </div><div dir="auto"> </div><div dir="auto">After some time the user learns a lot about the application and these </div><div dir="auto">interfaces start to limit his/her efficiency. </div><div dir="auto"> </div><div dir="auto">2) Configuration files </div><div dir="auto">Somewhere in between. You do not have to be a coder to configure </div><div dir="auto">application this way. </div><div dir="auto"> </div><div dir="auto">What you have to do though, is to read quite a bit about the application </div><div dir="auto">and have a reference documentation at hand. This can be minimized by </div><div dir="auto">including the documentation inside template configuration files in form </div><div dir="auto">of </div><div dir="auto">comments. The expression is quite limited. Difficult data structures and </div><div dir="auto">Domain Specific Languages must be used to overcome this problem. </div><div dir="auto"> </div><div dir="auto">3) Hacking the code </div><div dir="auto">You need to be involved a lot in the application and you have to </div><div dir="auto">understand it's code in order to modify it. </div><div dir="auto"> </div><div dir="auto">The expression is virtually unlimited though with little effort on </div><div dir="auto">developers side. No config interpretation code and DSLs are necessary. </div><div dir="auto">This </div><div dir="auto">can be improved a lot by splitting the configuration part of the code </div><div dir="auto">from </div><div dir="auto">the system implementation structuring the code as a configuration file. </div><div dir="auto">If </div><div dir="auto">you include documentation in comments you have a nearly commented config </div><div dir="auto">file experience but you still require the user to be quite involved in </div><div dir="auto">the </div><div dir="auto">app and know at least basic data structures used in the language. </div><div dir="auto"> </div><div dir="auto">The biggest downside is that the app often (not necessarily) needs to be </div><div dir="auto">rebuilt to perform a change. Second most severe limitation is that </div><div dir="auto">closed </div><div dir="auto">source applications would be difficult if not impossible to configure </div><div dir="auto">this </div><div dir="auto">way. </div><div dir="auto"> </div><div dir="auto"># How to choose </div><div dir="auto"> </div><div dir="auto">There is one important consideration, sometimes overlooked when deciding </div><div dir="auto">which style of configuration to employ. Apart from time money and </div><div dir="auto">developers </div><div dir="auto">personal engagement. It is the TARGET AUDIENCE. </div><div dir="auto"> </div><div dir="auto">Who will be configuring which part in reality? How involved are they </div><div dir="auto">going </div><div dir="auto">to be in the application when in production? What are their use cases? </div><div dir="auto">Are </div><div dir="auto">there any security implications if I choose this over that? </div><div dir="auto"> </div><div dir="auto">These are some of the questions you should consider. And please do </div><div dir="auto">expand </div><div dir="auto">on this. I'm sure you will have some more options to consider. </div><div dir="auto"> </div><div dir="auto">-- </div><div dir="auto">Miroslav Hradilek </div><div dir="auto">Quality Assurance Engineer </div><div dir="auto">Base OS Quality Engineering </div><div dir="auto"> </div><div dir="auto">Red Hat Czech, s. r. o. </div><div dir="auto">Purkynova 99 </div><div dir="auto">612 45 Brno, Czech Republic </div><div dir="auto"> </div><div dir="auto">_______________________________________________ </div><div dir="auto">almighty-public mailing list </div><div dir="auto"><a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a> </div><div dir="auto"><a href="https://www.redhat.com/mailman/listinfo/almighty-public" style="color:#bbb" target="_blank">https://www.redhat.com/mailman/listinfo/almighty-public</a> </div><div dir="auto"> </div></blockquote><div dir="auto"> </div><div dir="auto"> </div><div dir="auto"> </div><div dir="auto">_______________________________________________ </div><div dir="auto">almighty-public mailing list </div><div dir="auto"><a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a> </div><div dir="auto"><a href="https://www.redhat.com/mailman/listinfo/almighty-public" style="color:#bbb" target="_blank">https://www.redhat.com/mailman/listinfo/almighty-public</a> </div><div dir="auto"> </div><div dir="auto"> </div></blockquote><div dir="auto">_______________________________________________ </div><div dir="auto">almighty-public mailing list </div><div dir="auto"><a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a> </div><div dir="auto"><a href="https://www.redhat.com/mailman/listinfo/almighty-public" style="color:#bbb" target="_blank">https://www.redhat.com/mailman/listinfo/almighty-public</a> </div><div dir="auto"> </div></blockquote><div dir="auto"> </div><div dir="auto"> </div><div dir="auto">/max </div><div dir="auto"><a href="http://about.me/maxandersen" style="color:#999" target="_blank">http://about.me/maxandersen</a> </div><div dir="auto"> </div><div dir="auto"> </div><div dir="auto">_______________________________________________ </div><div dir="auto">almighty-public mailing list </div><div dir="auto"><a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a> </div><div dir="auto"><a href="https://www.redhat.com/mailman/listinfo/almighty-public" style="color:#999" target="_blank">https://www.redhat.com/mailman/listinfo/almighty-public</a> </div><div dir="auto"> </div></blockquote></blockquote></div> </div></div><div style="white-space:normal"> <p dir="auto">/max<br> <a href="http://about.me/maxandersen" style="color:#3983c4" target="_blank">http://about.me/maxandersen</a></p> </div> </div> </div> </blockquote></div><br></div></div>