[almighty] Multitenancy

[Andrew Lee Rubinger]

On Thu, Sep 29, 2016 at 7:57 PM, Aslak Knutsen <aslak at redhat.com> wrote:

> Eventual consistency and time-based historical audit is an interesting
> combination... This is what the state was 6 days ago, ish... ;)
>

Nah, they're not really at odds, I don't think.  If you timestamp a field,
that gets you what you need for historical audit at the time the record was
inserted/updated in the master DB (which may or not be propagated out to
all viewing).  So when you query for a point in time it's no more "ish"
than your view of the present time.

What's the requirement for historical audit in the first place?

S,
ALR


>
> -aslak-
>
> On Tue, Sep 27, 2016 at 7:04 AM, Andrew Lee Rubinger <alr at redhat.com>
> wrote:
>
>>
>>
>> On Tue, Sep 27, 2016 at 9:57 AM, Monica Granfield <mgranfie at redhat.com>
>> wrote:
>>
>>> Thanks all. Yes, persisted work! Great. Transactions... I know ACID is
>>> not a priority just putting it out there for consideration while creating
>>> the infrastructure...
>>>
>>
>> Totally.  And in our case I would actually argue that ACID is not only
>> not a priority, it's a poor design decision for work items.  Updates to
>> work items aren't, from what I can tell, mission critical enough to warrant
>> the resources and synchronization points involved.
>>
>> S,
>> ALR
>>
>>
>>>
>>> On Tue, Sep 27, 2016 at 9:30 AM, Andrew Lee Rubinger <alr at redhat.com>
>>> wrote:
>>>
>>>> I think we're intermingling concepts. :)
>>>>
>>>> To circle this back to multitenancy: yes, anytime a work item is
>>>> persisted/updated, it should be available to all users system-wide.
>>>>
>>>> Transactional integrity does not appear to be a requirement from PM, so
>>>> something eventually-consistent will do.  This means that we take an
>>>> optimistic approach to subsequent updates and prioritize performance over
>>>> ACID compliance.
>>>>
>>>> Whether that change is pushed to the UI or simply available at the next
>>>> request is out-of-scope for 6-months requirements from PM.
>>>>
>>>> S,
>>>> ALR
>>>>
>>>> On Tue, Sep 27, 2016 at 9:24 AM, Todd Mancini <tmancini at redhat.com>
>>>> wrote:
>>>>
>>>>> I think the only requirement for real-time update is Chat, and,
>>>>> technically, Chat is not part of the 6 month plan (although we are working
>>>>> on it).
>>>>>
>>>>> On Tue, Sep 27, 2016 at 9:21 AM, Monica Granfield <mgranfie at redhat.com
>>>>> > wrote:
>>>>>
>>>>>> How about user status, comments.. any transactions that you would
>>>>>> expect to be live or immediate,...Low Pri so long as we account for it,
>>>>>> sounds good to me.
>>>>>>
>>>>>> On Tue, Sep 27, 2016 at 9:04 AM, Todd Mancini <tmancini at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> My $0.02.
>>>>>>>
>>>>>>> 1. When we say 'status change', we need to be careful. If I have a
>>>>>>> WI open for full details and I change basically anything, nothing is
>>>>>>> persisted until I click Save. (This gives me the option to cancel.) But in
>>>>>>> other parts of the UI, say, moving a card on a Kanban board from 1 column
>>>>>>> to another -- that would be an immediate update. I'm not saying anyone is
>>>>>>> confused by this, but it never hurts to restate it. :)
>>>>>>> 2. All WIs have a Status as far as I know, so I don't think we need
>>>>>>> to talk about "WIs with a status", because that suggests that some do not.
>>>>>>> 3. Auto-updating UIs when someone/something changes something -- in
>>>>>>> general, sure, this is nice to have (say, via WebSockets). But I would call
>>>>>>> this out as low priority for our first release.
>>>>>>>
>>>>>>>    -Todd
>>>>>>>
>>>>>>> On Tue, Sep 27, 2016 at 8:41 AM, Monica Granfield <
>>>>>>> mgranfie at redhat.com> wrote:
>>>>>>>
>>>>>>>> Sure... if a WI has a status, and the status changes, will it
>>>>>>>> immediately persist and be updated anywhere that WI is viewed. In the past
>>>>>>>> I have run into scenarios about concurrency with objects based on how
>>>>>>>> multi-tenancy is structured. So just want to ask if all data is live or
>>>>>>>> will require updates to see current statuses, states or otherwise...?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Sep 26, 2016 at 7:08 PM, Andrew Lee Rubinger <
>>>>>>>> alr at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> On Sep 26, 2016 5:01 PM, "Monica Granfield" <mgranfie at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>> >
>>>>>>>>> > One scenario to ask about here... around keeping status in sync
>>>>>>>>> with multi-tenants.... Is this something that is good or has been thought
>>>>>>>>> about at all?..
>>>>>>>>>
>>>>>>>>> I am not sure I understand the question, Monica.  Could you
>>>>>>>>> elaborate?
>>>>>>>>>
>>>>>>>>> >
>>>>>>>>> > -Monica
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > On Mon, Sep 26, 2016 at 5:30 AM, Max Rydahl Andersen <
>>>>>>>>> manderse at redhat.com> wrote:
>>>>>>>>> >>
>>>>>>>>> >> On 23 Sep 2016, at 0:44, Andrew Lee Rubinger wrote:
>>>>>>>>> >>
>>>>>>>>> >>> I think the question is about more than a URL scheme.
>>>>>>>>> >>>
>>>>>>>>> >>> We've been considering "Project" as our top-level container
>>>>>>>>> entity, but
>>>>>>>>> >>> there really exists "system" above that.
>>>>>>>>> >>>
>>>>>>>>> >>> By that measure, we can contain in a system:
>>>>>>>>> >>>
>>>>>>>>> >>> * Users
>>>>>>>>> >>> * Projects
>>>>>>>>> >>>
>>>>>>>>> >>> ...and then map permissions between users and roles at the
>>>>>>>>> project level.
>>>>>>>>> >>>
>>>>>>>>> >>> How does "Organization" map into that?
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> Good points and I like the notion of "system".
>>>>>>>>> >>
>>>>>>>>> >> The way GitHub and I think VSO does it is that Organizations
>>>>>>>>> are owners/containers of projects and users can also be owners.
>>>>>>>>> >> Which is why they often share namespace, i.e. cannot have both
>>>>>>>>> a user and org called "maxandersen".
>>>>>>>>> >>
>>>>>>>>> >> /max
>>>>>>>>> >>
>>>>>>>>> >>>
>>>>>>>>> >>> S,
>>>>>>>>> >>> ALR
>>>>>>>>> >>>
>>>>>>>>> >>> On Thu, Sep 22, 2016 at 6:37 PM, Todd Mancini <
>>>>>>>>> tmancini at redhat.com> wrote:
>>>>>>>>> >>>
>>>>>>>>> >>>> It's not clear to me what URLs have to do with multi-tenancy.
>>>>>>>>> The VSTS
>>>>>>>>> >>>> approach (which is actually one "org" per FQDN, but with
>>>>>>>>> infinite
>>>>>>>>> >>>> projects per org) was chosen for technical reasons, not
>>>>>>>>> product
>>>>>>>>> >>>> management ones.
>>>>>>>>> >>>>
>>>>>>>>> >>>> So, do you have a technical preference?
>>>>>>>>> >>>>
>>>>>>>>> >>>> The GitHub model seems to work well. But since we also plan
>>>>>>>>> to handle
>>>>>>>>> >>>> enterprise SSO (via SAML, for example), the Gmail model also
>>>>>>>>> works well
>>>>>>>>> >>>> (as far as PM is concerned). I'm not married to particular
>>>>>>>>> URL schemes.
>>>>>>>>> >>>>
>>>>>>>>> >>>> Sent from my phone, so anticipate hilarious autocorrectsFrom:
>>>>>>>>> Max
>>>>>>>>> >>>> Rydahl Andersen
>>>>>>>>> >>>> Sent: ‎9/‎22/‎2016 6:24 PM
>>>>>>>>> >>>> To: Andrew Lee Rubinger
>>>>>>>>> >>>> Cc: ALMighty-public
>>>>>>>>> >>>> Subject: Re: [almighty] Multitenancy
>>>>>>>>> >>>> On 22 Sep 2016, at 21:08, Andrew Lee Rubinger wrote:
>>>>>>>>> >>>>
>>>>>>>>> >>>>> On Thu, Sep 22, 2016 at 3:07 PM, Baiju Muthukadan
>>>>>>>>> >>>>> <bmuthuka at redhat.com>
>>>>>>>>> >>>>> wrote:
>>>>>>>>> >>>>>
>>>>>>>>> >>>>>> Hi,
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> ALMighty architecture is going to support Multitenancy,
>>>>>>>>> right?
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>> To the bone, yes.
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>> what is unclear though is how the multi tenancy will work.
>>>>>>>>> >>>>
>>>>>>>>> >>>> i.e. is it like github/jira where one instance under one url
>>>>>>>>> has many
>>>>>>>>> >>>> projects with shared users/orgs
>>>>>>>>> >>>> or is it more like VSO where each domain has one project with
>>>>>>>>> users
>>>>>>>>> >>>> shared across many domains.
>>>>>>>>> >>>>
>>>>>>>>> >>>> Eagerly waiting for some of the "new project" PDD/UX stories
>>>>>>>>> to actually
>>>>>>>>> >>>> start getting that settled down.
>>>>>>>>> >>>>
>>>>>>>>> >>>> /max
>>>>>>>>> >>>>
>>>>>>>>> >>>>>
>>>>>>>>> >>>>>> Regards,
>>>>>>>>> >>>>>> Baiju M
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> _______________________________________________
>>>>>>>>> >>>>>> almighty-public mailing list
>>>>>>>>> >>>>>> almighty-public at redhat.com
>>>>>>>>> >>>>>> https://www.redhat.com/mailman/listinfo/almighty-public
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> --
>>>>>>>>> >>>>> Red Hat Developer Programs Architecture
>>>>>>>>> >>>>> @ALRubinger
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>>> _______________________________________________
>>>>>>>>> >>>>> almighty-public mailing list
>>>>>>>>> >>>>> almighty-public at redhat.com
>>>>>>>>> >>>>> https://www.redhat.com/mailman/listinfo/almighty-public
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>> /max
>>>>>>>>> >>>> http://about.me/maxandersen
>>>>>>>>> >>>>
>>>>>>>>> >>>> _______________________________________________
>>>>>>>>> >>>> almighty-public mailing list
>>>>>>>>> >>>> almighty-public at redhat.com
>>>>>>>>> >>>> https://www.redhat.com/mailman/listinfo/almighty-public
>>>>>>>>> >>>>
>>>>>>>>> >>>
>>>>>>>>> >>> --
>>>>>>>>> >>> Red Hat Developer Programs Architecture
>>>>>>>>> >>> @ALRubinger
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> /max
>>>>>>>>> >> http://about.me/maxandersen
>>>>>>>>> >>
>>>>>>>>> >> _______________________________________________
>>>>>>>>> >> almighty-public mailing list
>>>>>>>>> >> almighty-public at redhat.com
>>>>>>>>> >> https://www.redhat.com/mailman/listinfo/almighty-public
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> almighty-public mailing list
>>>>>>>> almighty-public at redhat.com
>>>>>>>> https://www.redhat.com/mailman/listinfo/almighty-public
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Red Hat Developer Programs Architecture
>>>> @ALRubinger
>>>>
>>>
>>>
>>
>>
>> --
>> Red Hat Developer Programs Architecture
>> @ALRubinger
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>>
>>
>


-- 
Red Hat Developer Programs Architecture
@ALRubinger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160930/8b74e5a6/attachment.htm>