Hey Andrew, Yes, this is a really important question, and it's something that I believe that the Forge architecture supports out-of-the-box. Every interaction with the UI API (the Forge commands, per say) is stored in a request-scoped UIContext[1] object that is initialized when a command is invoked and destroyed when the command finishes executing. That means that you can execute multiple concurrent commands in a single Forge instance and they will not affect each other. When it comes to security, as a good practice, it is important to restrict the commands that the exposed REST service can execute. That's why in the Obsidian backend[2] we only expose a REST endpoint[3] consuming the Forge API to execute a limited number of commands (more specifically, the ones exposed by the obsidian-addon[4]) Last but not least, as the Forge Online app is just a PoC illustrating how Forge can work in a web environment, it does not impose restrictions to the supported commands, therefore it shouldn't be a web app to be used in production. PS: It would be nice to ping the Fabric8 team for this matter as they are already using Forge as their project generator solution for a long time now. I hope this helps. Looking forward to this list of requirements and happy to discuss about this anytime. [1] - https://github.com/forge/core/tree/master/ui#uicommand-execution-lifecycle [2] - https://github.com/obsidian-toaster/generator-backend [3] - https://github.com/obsidian-toaster/generator-backend/ blob/master/src/main/java/org/obsidiantoaster/generator/ rest/ObsidianResource.java [4] - https://github.com/obsidian-toaster/obsidian-addon Best Regards, *George Gastaldi* https://onename.com/gastaldi On Tue, Jan 31, 2017 at 9:27 PM, Andrew Lee Rubinger <alr(a)redhat.com&gt; wrote: > Hi, all: > > We have some requests coming down the pike from the Developer Group with > regards to running Forge as a Service (which is great!). > > Additionally, I'm suspecting this will soon be very important for us as > well, as we continue to build out what's currently known as the "Obsidian > Generator", using Forge as a backend. > > I'm hoping the Forge team will kindly advise as to our preparedness for > running Forge in a multitenant environment. Concerns may include resource > consumption (not running an instance-per-user), security, etc. Have we yet > broached this subject specifically in the prototypes I've seen thus far > using Forge Online? > > I've requested of the Developer Group a list of requirements they've > devised; will send those along here when I have them. In the meantime, > mind describing where we currently stand? > > S, > ALR > > -- > Red Hat Developer Group Architecture > @ALRubinger > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

> Hey Andrew, > > Yes, this is a really important question, and it's something that I > believe > that the Forge architecture supports out-of-the-box. Every interaction > with > the UI API (the Forge commands, per say) is stored in a request-scoped > UIContext[1] object that is initialized when a command is invoked and > destroyed when the command finishes executing. That means that you can > execute multiple concurrent commands in a single Forge instance and > they > will not affect each other. Excellent. > When it comes to security, as a good practice, it is important to > restrict > the commands that the exposed REST service can execute. > That's why in the Obsidian backend[2] we only expose a REST > endpoint[3] > consuming the Forge API to execute a limited number of commands (more > specifically, the ones exposed by the obsidian-addon[4]) > > Last but not least, as the Forge Online app is just a PoC illustrating > how > Forge can work in a web environment, it does not impose restrictions > to the > supported commands, therefore it shouldn't be a web app to be used in > production. Since we need something for production I would be curious to know what you feel are missing ?

> PS: It would be nice to ping the Fabric8 team for this matter as they > are > already using Forge as their project generator solution for a long > time now. In case you missed it - fabric8 team is now part of devtools and devtools are fabric8 :) We'll get James et.al. involved (they are in f2f meetings this week), but as I understood Fabric8 have a fork of the PoC adjusted to handle some more complex workflows they were exploring. Things they would like to get merged back as I understand it. Good, yes, that's right

That said - to outline the items we were discussing about forge as a SaaS: Main reason we need it in first place is that Forge is *massive*, takes up a lot of resources - even more than Eclipse Che; thus we are very interested in being able to run Forge without having one instance per user. I need some numbers here regarding the "a lot of resources - even more

In that we had some questions and concerns in addition to the ones above: A) can forge run without access to download updates etc. from maven and similar ? i.e. can we lock updates down and ensure it and its execution cannot be altered just because someone updated a plugin. (We discussed firewalling it completely to be sure :) No updates are downloaded automatically in Forge. There are commands to

others are not exposed to users nor in logs ?

C) Any expectations/ideas on how we would integrate obsidian generators with fabric8 ? Two options we considered: 1) call out to separate hosted obsidian-toaster and run the risk of exposing secrets on wire. 2) run obsidian-toaster or a copy of it inside fabric8 online so we don't expose any secrets.

Pete and others might have more, but above are the ones I wrote down while being on bluejeans to the conversations. > I hope this helps. Looking forward to this list of requirements and > happy > to discuss about this anytime. > > [1] - > https://github.com/forge/core/tree/master/ui#uicommand- execution-lifecycle > [2] - https://github.com/obsidian-toaster/generator-backend > [3] - > https://github.com/obsidian-toaster/generator-backend/ blob/master/src/main/java/org/obsidiantoaster/generator/ rest/ObsidianResource.java > [4] - https://github.com/obsidian-toaster/obsidian-addon > > Best Regards, > > *George Gastaldi* > > https://onename.com/gastaldi > > On Tue, Jan 31, 2017 at 9:27 PM, Andrew Lee Rubinger <alr(a)redhat.com&gt; > wrote: > >> Hi, all: >> >> We have some requests coming down the pike from the Developer Group >> with >> regards to running Forge as a Service (which is great!). >> >> Additionally, I'm suspecting this will soon be very important for us >> as >> well, as we continue to build out what's currently known as the >> "Obsidian >> Generator", using Forge as a backend. >> >> I'm hoping the Forge team will kindly advise as to our preparedness >> for >> running Forge in a multitenant environment. Concerns may include >> resource >> consumption (not running an instance-per-user), security, etc. Have >> we yet >> broached this subject specifically in the prototypes I've seen thus >> far >> using Forge Online? >> >> I've requested of the Developer Group a list of requirements they've >> devised; will send those along here when I have them. In the >> meantime, >> mind describing where we currently stand? >> >> S, >> ALR >> >> -- >> Red Hat Developer Group Architecture >> @ALRubinger >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev /max http://about.me/maxandersen _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

> Hey Andrew, > > Yes, this is a really important question, and it's something that I > believe > that the Forge architecture supports out-of-the-box. Every interaction > with > the UI API (the Forge commands, per say) is stored in a request-scoped > UIContext[1] object that is initialized when a command is invoked and > destroyed when the command finishes executing. That means that you can > execute multiple concurrent commands in a single Forge instance and > they > will not affect each other. Excellent.

> When it comes to security, as a good practice, it is important to > restrict > the commands that the exposed REST service can execute. > That's why in the Obsidian backend[2] we only expose a REST > endpoint[3] > consuming the Forge API to execute a limited number of commands (more > specifically, the ones exposed by the obsidian-addon[4])

> > Last but not least, as the Forge Online app is just a PoC illustrating > how > Forge can work in a web environment, it does not impose restrictions > to the > supported commands, therefore it shouldn't be a web app to be used in > production.

Since we need something for production I would be curious to know what you feel are missing ? > PS: It would be nice to ping the Fabric8 team for this matter as they > are > already using Forge as their project generator solution for a long > time now. In case you missed it - fabric8 team is now part of devtools and devtools are fabric8 :) We'll get James et.al. involved (they are in f2f meetings this week), but as I understood Fabric8 have a fork of the PoC adjusted to handle some more complex workflows they were exploring. Things they would like to get merged back as I understand it. That said - to outline the items we were discussing about forge as a SaaS: Main reason we need it in first place is that Forge is *massive*, takes up a lot of resources - even more than Eclipse Che; thus we are very interested in being able to run Forge without having one instance per user. In that we had some questions and concerns in addition to the ones above: A) can forge run without access to download updates etc. from maven and similar ? i.e. can we lock updates down and ensure it and its execution cannot be altered just because someone updated a plugin. (We discussed firewalling it completely to be sure :) B) Is there a way to ensure that secrets like GitHub auth keys and others are not exposed to users nor in logs ? C) Any expectations/ideas on how we would integrate obsidian generators with fabric8 ? Two options we considered: 1) call out to separate hosted obsidian-toaster and run the risk of exposing secrets on wire. 2) run obsidian-toaster or a copy of it inside fabric8 online so we don't expose any secrets. Pete and others might have more, but above are the ones I wrote down while being on bluejeans to the conversations. > I hope this helps. Looking forward to this list of requirements and > happy > to discuss about this anytime. > > [1] - > https://github.com/forge/core/tree/master/ui#uicommand- execution-lifecycle > [2] - https://github.com/obsidian-toaster/generator-backend > [3] - > https://github.com/obsidian-toaster/generator-backend/ blob/master/src/main/java/org/obsidiantoaster/generator/ rest/ObsidianResource.java > [4] - https://github.com/obsidian-toaster/obsidian-addon > > Best Regards, > > *George Gastaldi* > > https://onename.com/gastaldi > > On Tue, Jan 31, 2017 at 9:27 PM, Andrew Lee Rubinger <alr(a)redhat.com <javascript:;>> > wrote: > >> Hi, all: >> >> We have some requests coming down the pike from the Developer Group >> with >> regards to running Forge as a Service (which is great!). >> >> Additionally, I'm suspecting this will soon be very important for us >> as >> well, as we continue to build out what's currently known as the >> "Obsidian >> Generator", using Forge as a backend. >> >> I'm hoping the Forge team will kindly advise as to our preparedness >> for >> running Forge in a multitenant environment. Concerns may include >> resource >> consumption (not running an instance-per-user), security, etc. Have >> we yet >> broached this subject specifically in the prototypes I've seen thus >> far >> using Forge Online? >> >> I've requested of the Developer Group a list of requirements they've >> devised; will send those along here when I have them. In the >> meantime, >> mind describing where we currently stand? >> >> S, >> ALR >> >> -- >> Red Hat Developer Group Architecture >> @ALRubinger >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org <javascript:;> >> https://lists.jboss.org/mailman/listinfo/forge-dev >> > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <javascript:;> > https://lists.jboss.org/mailman/listinfo/forge-dev /max http://about.me/maxandersen _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org <javascript:;> https://lists.jboss.org/mailman/listinfo/forge-dev