Re: AIP-21 - grouping google operators

+1 for providers Having google, azure, etc. right next to hooks, operators modules just does not fit in the context of this module level imo. Except for the kubernetes module all module names are more generic. Felix Sent from ProtonMail Mobile On Fri, Oct 4, 2019 at 21:05, Driesprong, Fokko w

Re: AIP-21 - grouping google operators

I agree with Jarek. Using the structure proposed by Kamil sounds really sensible to me. Tomek On Fri, 4 Oct 2019 at 21:27, Jarek Potiuk wrote: > Side comment: > > In the near future (AIP-26 ??) we can also adopt the structure reflected in > the current documentation restructuring by Kamil > > h

Re: AIP-21 - grouping google operators

Side comment: In the near future (AIP-26 ??) we can also adopt the structure reflected in the current documentation restructuring by Kamil https://airflow.readthedocs.io/en/latest/operators-and-hooks-ref.html# - Fundamentals

Re: AIP-21 - grouping google operators

I agree with Jarek's suggestion to add another module. Personally I don't like having too many on the airflow._ level, there are quite a few already. Also, I would also go for providers. Mostly because we have hook*s* and operator*s*. When there are a lot of {operators,hooks,sensors} it makes sens

Re: AIP-21 - grouping google operators

Not that I want to open Pandora's box :). But I think the longer name - the worse. Provider is quite nice and short. I agree with plural 'providers' (as we have hooks and operators). So for consistency it should be indeed plural. J. pt., 4 paź 2019, 18:48 użytkownik Chris Palmer napisał: > My

Re: AIP-21 - grouping google operators

My question about Oracle/MySql wasn't a serious one, but I forget sometimes that sarcasm doesn't come across well on email. I guess my objection is that I don't think that 'provider' adds anything of value. I'm not convinced that there needs to be a level between 'airflow' and 'google' but if goin

Re: AIP-21 - grouping google operators

Hello, We think that only cloud providers should be separated from others, because these services are integrated with each other. Very often, when you use one cloud provider, you use many services of a given provider. Using a single provider solution provides a uniform way of authorization, etc. A

Re: AIP-21 - grouping google operators

This seems unnecessary to me. Is everything going to be under some 'provider' or just certain sets of operators, and if so what differentiates when something should be under a provider or not? For example, are the mysql operators going to go under 'provider/oracle/'? Chris On Fri, Oct 4, 2019 at

Re: AIP-21 - grouping google operators

Agree with Ash. After doing the gcp move and seeing the result we agreed that 'provider' is better as additional prefix. If no-one objects (Lazy Consensus ) till Monday 3.20 CEST, we will update AIP-21 and move the gcp operators to *prov

Re: AIP-21 - grouping google operators

+1 for something under airflow.google - though I'm now wondering if airflow.provider.google is a "better" name, as airflow.google is a little bit non-descript. I'm not personally familiar with the detail of what product suite each product in Google is under, and I don't think our users should h

Re: AIP-21 - grouping google operators

I think gdrive should be a part of gsuite, as drive is a part of gsuite technically On Thu, Oct 3, 2019 at 9:01 AM Jarek Potiuk wrote: > As part of AIP-21 we are moving the operators to core. > > We have been discussing during the last few days how we should group the > operators from Google (we

Re: AIP-21 - grouping google operators

I am fine with it. Looks more logical. On Thu, Oct 3, 2019, 17:01 Jarek Potiuk wrote: > As part of AIP-21 we are moving the operators to core. > > We have been discussing during the last few days how we should group the > operators from Google (we included Google Composer team) and we came to th

AIP-21 - grouping google operators

As part of AIP-21 we are moving the operators to core. We have been discussing during the last few days how we should group the operators from Google (we included Google Composer team) and we came to the conclusion that we need to group the operators in sub-modules. We originally moved most of th