2016-11-22 Meeting notes

Previous meeting:  Nov 8, 2016

Date

22 Nov 2016

7am - 8am Seattle (UTC-8)

10am Washington D.C.

4pm Poland

11pm China

Meeting Link

https://www.uberconference.com/villagereach-isg

Optional dial in:
Dial in: 213-493-0531
PIN: 74762

Attendees

• Josh Zamor

• Elias Muluneh
• Brandon Bowersox-Johnson
• Chongsun Ahn (Unlicensed)
• Pengfei Cui (Deactivated)
• Sebastian Brudziński

Goals

• Review scenario's proposed design
• Get feedback on scenario's UI extension desires

Discussion items

Meetings Notes

• Design document was presented and discussed, Nick Reid wasn't able to attend this call so we'll look forward to him leading us on UI extension in a later call.

• The overall structure was understood.  There was questions on:

  Question	Response/Resources
  Complexity of utilizing this architecture, especially in deploying new services (also perhaps cost of ownership?)	It's not in question weather approaches to building extensible software can introduce complexity.  That always seems to be the case.  We all know why we need to be extensible so the approach is to manage complexity as much as possible.  To that end we do plan on providing examples as well as starting points along with documentation (here and read the docs).  It's something that's on-going though so maybe the committee needs to walk through some of this and identify gaps that they see.
  Why would an extension mechanism not already exist by the time an implementer needs to use them?	The Document presumes that not every extension mechanism would exist before an implementer would want to extend an existing concept (due to cost, difficulty forecasting, etc).  It covers therefore the process of the community adding the mechanisms.  It should be noted that anyone in an open source project can add an approved mechanism to any concept, and that the code stewards would always approve it.
  What happens to the original Requisition?  When the split requisitions are fulfilled are they aggregated back to the original?	The original requisition is never converted into an order.  In this analysis it's proposed that it ends in a status named "split".  The facility would see the two split requisitions, A1 and A2, that are filed on its behalf after that. As for fulfillment the scenario doesn't dive into much depth here yet (outstanding questions) and so I filled in that the two Order's from their respective Requisitions would end up as separate PoD's.  This makes sense to me as fulfillment would progress independently for each and so we can't presume to know which will be fulfilled and received in any order.  This is chalked in lightly though as the scenario would need to add more detail for us to tackle the fulfillment side of things.

There are two follow ons that are desired:

• show how extensions would be packaged, deployed, versioned, etc (git repos, dockerhub repos, jenkins jobs, etc)
  • Now as OLMIS-1407 - Getting issue details... STATUS
• have the UI discussion which needs to start with finding the right "line in the sand" for extending v. fork/replace.
  • Now as OLMIS-1405 - Getting issue details... STATUS
    
    

Action items