+1 and thanks for starting the Discuss thread Larry ! This is a pretty comprehensive list and captures a lot of items that are good candidates for 1.3.0 release, thanks for consolidating other items as well, like SSO integration with Azure AD and logout. I shifted back to finishing up these features and would love to have them in 1.3.0, they were part of KIP-10 SSO and Logout Flow.
About the timeline, I think mid-April looks good, given the last release was mid-December. Again, thanks for the tracking and gathering all the items. Best, Sandeep On Fri, Feb 15, 2019 at 11:57 AM larry mccay <lmc...@apache.org> wrote: > Bump.... > > > On Tue, Feb 12, 2019 at 3:51 PM larry mccay <lmc...@apache.org> wrote: > > > All - > > > > I'd like to officially start the planning for the 1.3.0 release of Apache > > Knox. > > > > After looking at the list of outstanding JIRAs with fixVersion of 1.3.0, > > existing KIPs and considering requirements for a more containerized and > > cloud oriented world, I have a like of general categories: > > > > * TLS Improvements > > - Configurable Keystore Location and Password > > - Configurable Truststore Location and Password > > - Mutual Auth SSL truststores and client certs keystores > > - Dynamic keystore/truststore loading > > * Must keep in mind the KnoxCLI for create-cert, export-cert > > > > * Management Improvements > > There have been a number of people asking about the following and they > are > > all encountering similar pain - whether it be from a containerization > > context, DevOps or management tool, perspective a number of these are > > painful today for Knox admins. > > - Eliminate needs to have access to the Knox machines > > - Bootstrap config for log locations, pids, env variable overrides, > etc > > - Remote access to public certs (for SSL and for various signature > > verification(knoxtoken, knoxsso, etc)) > > - UI for Alias Management > > - Surface logs in UI(maybe?) and API > > - Master Secret synchronization across instances > > - Service Discovery from new source/s > > - new Remote Config Monitor source/s > > - new Remote Alias Service for Vault > > > > * SSO > > Easing the configuration required to enable all of the participating > > applications for KnoxSSO across a deployment will be important in general > > but being able to more easily provision this for cloud deployments will > be > > key. > > - IDP Initiated Flow with Landing Page (Okta portal page) > > - challenge - particpating apps are configured for a single IDP > > - Landing Page is like Okta - with links to UIs - how do we deal > > with multiple topologies > > - KnoxSSOut - logout from landing page > > - Keycloak? > > - Add a standard integration pattern for SPs to register with KnoxSSO > > - like SAML? > > - Azure AD with OAuth/OpenID Connect > > - Internal hostnames vs external for cookie domain > > - IDP metadata file for SPs to pull KnoxSSO public cert and any other > > details from an endpoint > > > > * Performance > > Performance is an ongoing item but deployment scenarios for cloud and > > hybrid may introduce new strategies for things like load balancing in > front > > of and behind the Knox gateway. > > - LoadBalancing from dispatch > > - HA provider config? > > - service specific > > - Hive cookie - sticky sessions > > - Knox HA story requires sticky sessions > > - TLS Options > > - Sizing Guidelines > > - JVM tuning > > - number of instances based on anticipated load (services need to > > be taken into account) > > > > * KnoxShell > > As deployments move more and more to the cloud and/or hybrid > combinations, > > the need to SSH to a gateway machine becomes more and more awkward. If we > > can provide a powerful enough scripting experience for Data Worker/ETL > type > > roles, we will be able to limit the need to SSH. > > - Remote CLI classes > > - ETL Usecase Classes > > - Livy classes > > > > * KnoxCLI > > - return error codes rather than throwing exception and always > > returning zero > > > > Many of our 1.3.0 JIRAs fall into one or more of the above categories. > > There are also quite a few of dispatch related issues filed. > > > > I realize that is a rather large list and a mixed back of category and > > detail in places. > > > > I think that we need to write up a couple KIPs to encompass the work > above > > that we would like to tackle in 1.3.0 and then identify/file JIRAs to > > represent the work. > > We will need to carefully manage scope in order to get this done but > > articulating this roadmap with some new KIP pages will help 1.3.0 and > > future releases. > > Thoughts? > > > > As for timeline, I am thinking that mid-April may feel appropriate. > > Thoughts? > > > > thanks, > > > > --larry > > >
