Re: [CFP] ApacheCon Asia about API/mrico service

2021-02-22 Thread Wesley Peng 

nice to know it. thanks.

On 23.02.2021 09:02, Ming Wen wrote:

hello, dev,
The ApacheCon Asia started CFP[1],
and everyone is welcome to submit topics related to Apache APISIX.
Both Mandarin and English are fine. Looking forward to it.

[1] acasia2021.jamhosted.net 

Thanks,
Ming Wen, Apache APISIX PMC Chair
Twitter: _WenMing

Re: [CFP] ApacheCon Asia about API/mrico service

2021-02-22 Thread Ming Wen 
Got it.

Thanks,
Ming Wen, Apache APISIX PMC Chair
Twitter: _WenMing


Sheng Wu  于2021年2月23日周二 上午9:06写道：

> Hi,
>
> It will start on Mar. 15th. You could access the page, but can't submit the
> CFP I think.
>
> Sheng Wu 吴晟
> Twitter, wusheng1108
>
>
> Ming Wen  于2021年2月23日周二 上午9:02写道：
>
> > hello, dev,
> > The ApacheCon Asia started CFP[1],
> > and everyone is welcome to submit topics related to Apache APISIX.
> > Both Mandarin and English are fine. Looking forward to it.
> >
> > [1] acasia2021.jamhosted.net 
> >
> > Thanks,
> > Ming Wen, Apache APISIX PMC Chair
> > Twitter: _WenMing
> >
>

Re: [CFP] ApacheCon Asia about API/mrico service

2021-02-22 Thread Sheng Wu 
Hi,

It will start on Mar. 15th. You could access the page, but can't submit the
CFP I think.

Sheng Wu 吴晟
Twitter, wusheng1108


Ming Wen  于2021年2月23日周二 上午9:02写道：

> hello, dev,
> The ApacheCon Asia started CFP[1],
> and everyone is welcome to submit topics related to Apache APISIX.
> Both Mandarin and English are fine. Looking forward to it.
>
> [1] acasia2021.jamhosted.net 
>
> Thanks,
> Ming Wen, Apache APISIX PMC Chair
> Twitter: _WenMing
>

[CFP] ApacheCon Asia about API/mrico service

2021-02-22 Thread Ming Wen 
hello, dev,
The ApacheCon Asia started CFP[1],
and everyone is welcome to submit topics related to Apache APISIX.
Both Mandarin and English are fine. Looking forward to it.

[1] acasia2021.jamhosted.net 

Thanks,
Ming Wen, Apache APISIX PMC Chair
Twitter: _WenMing

Re: [DISCUSS]Migration of docs from other projects to the website

2021-02-22 Thread Zhiyuan Ju 
Hi Zexuan,

Both put all i18n markdown files in a single repo and different repos are
ok to fetch, for now, I would prefer putting them in a single repo, here
are my reasons,

1. Easy to maintain for the community;
2. Will have more contributors in that single repo;

Best Regards!
@ Zhiyuan Ju 


Zexuan Luo  于2021年2月22日周一 上午11:12写道：

> So the multiple languages need to hold in a single repo? Or they can
> be fetched separately?
>
> Zhiyuan Ju  于2021年2月20日周六 下午2:29写道：
> >
> > Hi, folks,
> >
> > After searching and comparing those doc frameworks like
> > Hugo/Docsify/Docusaurus/KongHQ_Doc, I would prefer using Docusaurus[1] to
> > build our doc site.
> >
> > The Docusaurus:
> > - Supports multiple languages.
> > - Support for multiple versions.
> > - Support for Algolia site-wide text search.
> > - Relying only on front-end components such as React, not involving
> > languages such as Ruby and Golang.
> > - Clear component division for easy development and maintenance.
> > - Robust community from Facebook, clear project documentation, and a
> > configurable way to get started quickly, allowing developers to focus on
> > web business and maintainers to focus on documentation quality.
> >
> > We now have those projects:
> > - apisix
> > - apisix-ingress-controller
> > - apisix-dashboard
> > - apisix-docker
> > - apisix-helm-chart
> >
> > And we could follow those steps:
> > 1. Develop document specifications: directory structure, file
> > meta-information format, static resource storage location. For each
> > project, they will have a fixed URL like:
> > - https://apisix.apache.org/docs/apisix/2.3/en/getting-stared
> > - https://apisix.apache.org/docs/apisix-dashboard/2.4/en/getting-stared
> > 2. Automatic deployment: The documentation site actively fetches new
> > content from each project's docs directory and updates the documentation
> > site with the GitHub Action timer.
> > 3. Each project (apisix/apisix-dashboard/xxx) needs to adjust the
> contents
> > under the docs folder according to the specification.
> >
> > BTW, we have a contributor Jiahao Wang[2] to help us organize this
> > specification, and will update the infrastructure. Once the specification
> > gets done, we will put it in the apisix's website.
> >
> > [1] https://docusaurus.io/
> > [2] https://github.com/qier222
> >
> > Best Regards!
> > @ Zhiyuan Ju 
> >
> >
> > Sheng Wu  于2021年2月14日周日 下午5:51写道：
> >
> > > I want to share the plan we are doing in the SkyWalking.
> > > SkyWalking used to host doc in every repo, and we are going to keep
> this
> > > way.
> > > But also, at the same time, we know people want to read at the
> website, and
> > > good for search engine.
> > > So, our current ongoing plan to, generating docs on the website based
> on
> > > repo's commit IDs.
> > >
> > > A WIP PR is here,
> https://github.com/apache/skywalking-website/pull/215.
> > >
> > >
> > > Sheng Wu 吴晟
> > > Twitter, wusheng1108
> > >
> > >
> > > Zhiyuan Ju  于2021年2月14日周日 下午5:40写道：
> > >
> > > > Hi, Kishani,
> > > >
> > > > Thanks for your continuous contribution to the Apache APISIX Website
> > > first.
> > > >
> > > > I would prefer the first solution, that put all docs in the
> > > apisix-website
> > > > repository. Here are my concerns:
> > > >
> > > > 1. It's easier to maintain only one doc repository than multiples, no
> > > need
> > > > to sync (no matter manually or automatically) from other
> repositories;
> > > > 2. Yes, we could sync docs automatically from every project's
> repository
> > > of
> > > > course, but we have to set up then obey some Doc Writing rules, file
> > > > structure rules, and so on. Only in this way, we could have a
> universal
> > > > feeling to read docs in `apisix.apache.org`. It's not easy to obey
> those
> > > > rules in different repos.
> > > > 3. Every project should have some basic and needed docs, like FAQ,
> > > README,
> > > > but for more detailed docs, we could use the apisix-website repo to
> keep
> > > > them.
> > > >
> > > > I would vote +1 for the first solution.
> > > >
> > > > Best Regards!
> > > > @ Zhiyuan Ju 
> > > >
> > > >
> > > > kishani kandasamy  于2021年2月14日周日 下午3:26写道：
> > > >
> > > > > Hello community,
> > > > > The Apache Apisix website is  getting updated by contributors .This
> > > > > discussion  is for migrating  docs from other projects to the
> website.
> > > > >
> > > > > Here we have some options to do that.
> > > > >
> > > > > [1]. Move all docs to website, and remove all docs from origin
> repo;
> > > > > [2]. Use some tools to auto sync docs from other repos, then there
> > > should
> > > > > have a universal rule, or docs from different repo would not have a
> > > > uniform
> > > > > show style.
> > > > >
> > > > > Or there has some other ways?
> > > > >
> > > > > I would prefer the [1].
> > > > > What do you think? Any feedback is welcome. Thanks!
> > > > >
> > > > > Regards,
> > > > >

Re: [DISCUSS] Add consul_kv discovery module for apisix

2021-02-22 Thread 聂永 
Hi,

Yes, it support.

And, the discovery module does not matter upstream upper protocol.

> 2021年2月20日 17:04，大可  写道：
> 
> Excellent, what about support other protocols like gRPC?
> 
> 聂永  于2021年2月20日周六 下午4:25写道：
> 
>> Hi,
>> 
>> The PR is here: https://github.com/apache/apisix/pull/3615
>> 
>> And, all checks have passed now :))
>> 
>> 
>> 2021年2月20日 14:58，Li Yang mailto:yan...@apache.org>> 写道：
>> 
>> Hi,
>> 
>>My question is that from your example
>> "http://127.0.0.1:8500/v1/kv/upstreams/webpages/; seems to be the uri
>> we used to query a registered service.
>> 
>>Maybe we can split this long connection string to multiple
>> parts, such as consul_server, consul_prefix, service_name...
>> 
>> On Fri, Feb 19, 2021 at 2:12 PM 聂永 > niey...@staff.weibo.com>> wrote:
>> 
>> Hi,
>> 
>> I am back :)
>> 
>> As the `eureka` demo show:
>> 
>> ```bash
>> $ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY:
>> edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
>> {
>>  "uri": "/user/*",
>>  "upstream": {
>>  "service_name": "USER-SERVICE",
>>  "type": "roundrobin",
>>  "discovery_type": "eureka"
>>  }
>> }'
>> ```
>> 
>> So, we can use the `consul_kv` below:
>> 
>> ```bash
>> --- apisix_yaml
>> routes:
>> -
>> uri: /*
>> upstream:
>>   service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
>>   discovery_type: consul_kv
>>   type: roundrobin
>> ```
>> 
>> And, we don't need to import another `consul_url` or other variable, just
>> use `service_name` is ok for most service discovery ways.
>> 
>> 2021年2月8日 13:00，Li Yang mailto:yan...@apache.org>> 写道：
>> 
>> It sounds like a very useful feature for me.
>> 
>> My question is how will we configure routes after this feature?
>> 
>> Is this your planned way of configuring routes?
>> 
>> --- apisix_yaml
>> routes:
>> -
>> uri: /*
>> upstream:
>>   service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
>>   discovery_type: consul_kv
>>   type: roundrobin
>> 
>> The service_name variable name seems not accurate enough. Can we call
>> it consul_uri or something like this?
>> 
>> 
>> On Mon, Feb 8, 2021 at 11:23 AM Zexuan Luo > spacewan...@apache.org>> wrote:
>> 
>> *   doc
>>  *   english
>>  *   chinese
>> 
>> We can only provide the English version of doc.
>> 
>> Zexuan Luo mailto:spacewan...@apache.org>>
>> 于2021年2月8日周一 上午10:48写道：
>> 
>> If you need any help, please let us know.
>> 
>> 
>> 
>> 
>>