update roadmap for 2022

[localvar]

No description provided.

[xxx7xxxx]

I have some improvements in my backup list, @localvar could decide whether to add (part of) them into the roadmap:

1. Eliminate global components(such as logger) in order to get a better experience of unit testing, even we need a global/simple unit testing framework for Easegress itself.
2. API layer uses standard json(generated by protobuf), and CLI could produce/consume both yaml and json like kubectl.
3. Make json schema failure messages more readable(current ones are not indexed).
4. Support updating config for system controller.
5. Clarify the location of config and status of static config (fix httpserver httppipeline status not show error #441 (comment)).

[jxd134]

I have some improvements in my backup list, @localvar could decide whether to add (part of) them into the roadmap:

1. Eliminate global components(such as logger) in order to get a better experience of unit testing, even we need a global/simple unit testing framework for Easegress itself.

2. API layer uses standard json(generated by protobuf), and CLI could produce/consume both yaml and json like kubectl.

3. Make json schema failure messages more readable(current ones are not indexed).

4. Support updating config for system controller.

5. Clarify the location of config and status of static config ([#441 (comment)](https://github.com/megaease/easegress/pull/441#issuecomment-1001953374)).

I strongly agree with the second/third point.
In addition, we need to create multiple types of http filters, such as session sticky filter.

[localvar]

I have some improvements in my backup list, @localvar could decide whether to add (part of) them into the roadmap:

1. Eliminate global components(such as logger) in order to get a better experience of unit testing, even we need a global/simple unit testing framework for Easegress itself.
   ...
   (fix httpserver httppipeline status not show error #441 (comment))).

We have logger.InitNop to create a nop logger for the unit test, so, do we still need the 1st one?

[suchen-sci]

we also have logger.InitMock to print log to stdout for the unit test to debug...

[xxx7xxxx]

We have logger.InitNop to create a nop logger for the unit test, so, do we still need the 1st one?

IMHO, yes. My deep opinion is actually we need to make logger modularized and automatical environment perception, for example:

func (rl *RateLimiter) Init() {
    // ...
    if x {
        // It prints `[filter/RateLimiter/ratelimiter-001]: BUG: duration is invalid` to stderr and file stdout.log.
        // But in unit testing, it prints the same message to the stderr only.
        rl.Log().Bugf("duration is invalid")
        return
    }

    // It prints `[filter/RateLimiter/ratelimiter-001]: initialization completed`.
    // The printing endpoint chosen are the same above.
    rl.Log().Infof("initialization completed")
}

And object/supervisor/cluster and so on got different prefixes for their own modules/scopes, I know it seems a little complex for Golang stuff. But as Easegress codebase inflates, the modularized logger should be the road ahead.

[localvar]

updated according to comments.

For "API layer uses standard json(generated by protobuf)", I think it has been covered by "Protobuf models generating".
And I didn't include "Clarify the location of config and status of static config" in the roadmap, because I think it is not user awarable change.

[xxx7xxxx]

How about adding modularized logger which is not the completely same as the better unit testings?

[localvar]

added.

How about adding modularized logger which is not the completely same as the better unit testings?

[zhao-kun]

Do we need to add some enterprise features to the roadmap?

For example:

• I think we could figure out some tools (or methodology) to help users operate the cluster of the Easegress (eg: [question] backup and recovery #452 ), so this could be added to the backlogs?
• A suit of ansible script help user to rapidly set up the Easegress cluster on bare metals
  etc...

A general mTLS support? The #467 is dedicated to the EaseMesh, we could figure out a more general mTLS support?

Continue refining cookbooks and manuals should be a long term goal