diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f135d39b7d11..1ffd3abbd0f2 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -40,7 +40,7 @@ would like to implement a new feature then consider what kind of change it is: ## RFCs -Sometimes, major feature requests are "complex" or "substantial". In this case, GitHub Issues might not be the best tool to to present them because we will need a lot of going back and forth to reach a consensus. +Sometimes, major feature requests are "complex" or "substantial". In this case, GitHub Issues might not be the best tool to present them because we will need a lot of going back and forth to reach a consensus. So we ask that these feature request be put through a formal design process and have their specifications described in an "RFC" (request for comments) that will be validated by the team through a Pull Request Review. @@ -318,7 +318,7 @@ Please ensure to run `npm run lint` and `npm test` on the project root before su ## Template Guidelines The template engine used by yeoman is [EJS](http://ejs.co/), its syntax is fairly simple. -For simple code (few lines), logic can be embedded in the main file but if logic becomes more complex it's better to externalise the JS fragment to a sub template included by the first one and located in same folder. +For simple code (few lines), logic can be embedded in the main file but if logic becomes more complex it's better to externalize the JS fragment to a sub template included by the first one and located in the same folder. Sub templates should be named with the `ejs` extension because it's the default one, it enables editors to apply correct syntax highlighting and it enables us to use a very concise syntax: diff --git a/rfcs/1-jhipster-rfc-k8s-operator.md b/rfcs/1-jhipster-rfc-k8s-operator.md index cd37503d98df..354ea0b7f464 100644 --- a/rfcs/1-jhipster-rfc-k8s-operator.md +++ b/rfcs/1-jhipster-rfc-k8s-operator.md @@ -67,7 +67,7 @@ Things that the Operator will **NOT** do: [guide-level-explanation]: #guide-level-explanation -You can use the JHipster Kubernetes Operator to monitor and manage your JHipster MicroServices Applications running inside Kubernetes.In order to deploy your applications to Kubernetes you can use the `jhipster kubernetes` and `jhipster kubernetes-helm` generators to generate the Kubernetes Manifest required to run your containers in K8s. +You can use the JHipster Kubernetes Operator to monitor and manage your JHipster MicroServices Applications running inside Kubernetes. In order to deploy your applications to Kubernetes you can use the `jhipster kubernetes` and `jhipster kubernetes-helm` generators to generate the Kubernetes Manifest required to run your containers in K8s. ![JHipster Flow to K8s](https://github.com/salaboy/jhipster-operator/blob/master/imgs/jhipster-flow.png 'JHipster Flow to K8s') @@ -76,7 +76,7 @@ After deploying your applications to a Kubernetes environment you can deploy the Once the Operator is running you will be able to: 1. Interact with the Kubernetes API to get JHipster specific resources, such as Applications, MicroServices, Gateways and Registries and see the relationships between them. You will be able to describe each of the resources to obtain more details about the services that are related to the application -2. Automatically expose applications based on the healthyness of all the services belonging to that application, if a service is failing the application might be automatically hidden from the end users. This can be achieved by creating new Ingress or new Gateway Routes for Istio +2. Automatically expose applications based on the healthiness of all the services belonging to that application, if a service is failing the application might be automatically hidden from the end users. This can be achieved by creating new Ingress or new Gateway Routes for Istio 3. Manage multiple applications deployed in the same cluster 4. Control the applications topology and isolation with other Applications 5. Share infrastructure (Registry, SSO, maybe datastores) between different applications @@ -110,11 +110,11 @@ The Operator will expose a set of APIs to fine tune the default behaviour and al Because we are using CRDs we will be able to ask to the Kubernetes APIs about our JHipster Resources using for example the `kubectl` command. -An important aspect of the Operator is that it will not be in charge of deploying applications. Deployment should be done by standard tools such as HELM or the default Kubernetes APIs that we use after generatign the Kubernetes Manifests. The Operator responsability is to monitor and manage applications, not to deploy them. +An important aspect of the Operator is that it will not be in charge of deploying applications. Deployment should be done by standard tools such as HELM or the default Kubernetes APIs that we use after generating the Kubernetes Manifests. The Operator responsibility is to monitor and manage applications, not to deploy them. -The JHipster Kubernetes Operator can be built as a Spring Boot Starter meaning that it doesn't nesseraly needs to be it is own independent container it can be attached to an existing service if it is required. +The JHipster Kubernetes Operator can be built as a Spring Boot Starter meaning that it doesn't necessarily need to be its own independent container; it can be attached to an existing service if required. -The Operator will provide an excelent entry point for domain specific extensions and integrations with other platform wide services such as Istio, KNative, Jenkins X (Tekton Pipelines), etc. It will provide the entry point for a Developer Workflow on top of Kubernetes. +The Operator will provide an excellent entry point for domain specific extensions and integrations with other platform wide services such as Istio, KNative, Jenkins X (Tekton Pipelines), etc. It will provide the entry point for a Developer Workflow on top of Kubernetes. # Drawbacks @@ -129,7 +129,7 @@ A Kubernetes Operator only make sense if you are planning to run your applicatio [rationale-and-alternatives]: #rationale-and-alternatives -Building Kubernetes Operators is a long journey. In order to find some best practices we need to iterate and improve while we learn. We don't have all the answers right now, but having a concreate project will help us to improve it until it is useful for the entire community. +Building Kubernetes Operators is a long journey. In order to find some best practices we need to iterate and improve while we learn. We don't have all the answers right now, but having a concrete project will help us to improve it until it is useful for the entire community. # Prior art diff --git a/rfcs/2-jhipster-rfc-jhipster-control-center.md b/rfcs/2-jhipster-rfc-jhipster-control-center.md index 335c15e417c4..54227d93bab9 100644 --- a/rfcs/2-jhipster-rfc-jhipster-control-center.md +++ b/rfcs/2-jhipster-rfc-jhipster-control-center.md @@ -98,7 +98,7 @@ Implementation details will be left to the discretion of the **JHipster Control [drawbacks]: #drawbacks -- As JHipster is first and foremost a code generator, it could be argued that it is not the goal of the project to release non code generator products. Two date, several external products have been released as part of the JHipster organization: the JHipster Registry and JHipster Console and their release cadence has been low compared to the main generator. +- As JHipster is first and foremost a code generator, it could be argued that it is not the goal of the project to release non code generator products. To date, several external products have been released as part of the JHipster organization: the JHipster Registry and JHipster Console and their release cadence has been low compared to the main generator. - Impose the overhead of running another service in development and production ## Rationale and alternatives @@ -137,6 +137,6 @@ Some existing similar or related solutions : Possible future evolutions: - Provide a plugin mechanism to let organizations customize the **JHipster Control Center** with custom features without forking -- Seamlessly integrate with observablility tools such as ELK, Grafana and Zipkin +- Seamlessly integrate with observability tools such as ELK, Grafana and Zipkin - Plug into service mesh telemetry services such as those provided by Istio - Integrate with the [JHipster Kubernetes Operator](https://github.com/jhipster/jhipster-operator)