Platform-2018-08-21 (Sprint: 153)

[skabashnyuk]

Features related to Authentication and security in Theia IDE

• Make loader page URL configurable within property | Make loader page URL configurable within property #10611 | 5sp
• Make public/private signing keys pair per-workspace and synch with workspace runtime (renew pair on each workspace restart) | Make public/private signing keys pair per-workspace and synch with workspace runtime (renew pair on each workspace restart) #10074 | 13sp
• ~~~Inject a jwtproxy container into each Pod instead of creating a separated Pod for it | Inject a jwtproxy container into each Pod instead of creating a separated Pod for it #10404 | 13sp~~~
• Rework JwtProxyConfigBuilder to use Objects instead of formatting string config template | Rework JwtProxyConfigBuilder to use Objects instead of formatting string config template #10402 | 5sp

Features related to ws.next

• Build a container to run the plugin registry and document how to use it to serve theia and the 2 plugins needed to run the scenario | Initial Plugin registry #9868 8sp
• Move the plugin registry files (YAML file, instructions, script etc) from eclipse/che to eclipse/che-plugin-registry | Move the Plugin Registry to its own repository #10615 8sp

New Features

Technical debts and bugs

• Migrate to mockito/mockito-testng | Migrate to mockito/mockito-testng #10617 8sp
• Enable DELETE /api/user api method | Enable DELETE /api/user api method #10620 8sp

Finalize issues started in the previous sprint.

Unplanned

• Read workspace permission allows to use/delete projects as well Read workspace permission allows to use/delete projects as well #10536
• Move the Plugin Registry to its own repository Move the Plugin Registry to its own repository #10615
• [Walking Skeleton] Setup a CI for the Plugin Registry [Walking Skeleton] Setup a CI for the Plugin Registry #10651
• Factory and stack features are not supported in Workspace.Next Factory and stack features are not supported in Workspace.Next #10368
• Add an ability to configure if a secure server should supports authentication with a cookie or not Add an ability to configure if a secure server should supports authentication with a cookie or not #10725
• Add an ability to configure a JwtProxy image Add an ability to configure a jwtproxy image #10733
• Add a "Plugin Registry API" to retrieve the list of plugins Add a "Plugin Registry API" to retrieve the list of plugins #10745
• Restore and actualize README.md file in che-jwproxy repo Restore and actualize README.md file che-jwtproxy#7
• Document "Authentication and security in Theia IDE" feature Document "Authentication and security in Theia IDE" feature #10762
• Add type of the object to the index file of che-plugin-registry Add type of the object to the index file of che-plugin-registry #10781

Sprint Analysis

Availability

Name	Available
Sergii Kabashniuk	15d
Max Shaposhnik	15d
Michail Kuznyetsov	15 d
Sergii Leshchenko	12 d

Metrics

	Planned	Result
Budget	68	47

Retrospective Comments

• Action item @skabashnyuk find a way to publish videos on official Eclipse Che account.
• Action item @sleshchenko evaluate Zandhub to use in platform team scrum process.
• Action item @mshaposhnik talk with @vkuznyetsov about the stability of Selenium tests.

[garagatyi]

@skabashnyuk you took issue #10404 into the sprint.
It's not clear to me how you want to overcome issues described in my comment #10404 (comment)
For example our current mysql stack would be broken with this change.
Do you think those points are not valid and user's won't suffer because of that?

[garagatyi]

After discussing with @sleshchenko I figured out that my previous message is not clear enough.
So here I'll try to explain it in a better way.
If we decide to run workspaces of multiple users at the same namespace than we would have to forbid usage of services by users. We also use it on a mysql stack.
If we forbid services then a lot of apps and mysql stack would be broken.
I'm not aware whether we have a requirement to run different users' workspaces in the same namespace but creation of proper isolation seems a very hard task. Kubernetes already has isolation with namespaces but we are considering creating an alternative implementation. So I'm wondering how much we would benefit by doing that instead of just using separate namespaces.
Apart from that walking skeleton already has service discovery in place and it works over kubernetes services. We would have to rework it too if we want to forbid creation of services in a workspaces because of their insecure nature.

[skabashnyuk]

@garagatyi @sleshchenko you are right. There is a lot of small details that we need to take into account. I think we can postpone #10404 until we have time to discuss it with @l0rd and @ibuziuk .

[garagatyi]

👍