[almighty] Multitenancy

Tue Sep 27 13:30:36 UTC 2016

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160927/d5f06edb/attachment.htm>