[almighty] Multitenancy

Thu Sep 29 23:57:57 UTC 2016

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

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