Prepare cncf.kubernetes release 1.0.2 #14477
Conversation
boring-cyborg
bot
added
provider:cncf-kubernetes
|
Following the question before - Why not also release other providers? There were some changes in other providers as well and we initially discussed releasing 'batches' of the providers every three weeks. Do you plan to have separate voting on this one and separate on the others? I'd love to understand the thinking here, why cncf.kubernetes is going to be released separately from the others. |
|
@potiuk Because the whole point of separating providers was so that each vote would be easier.
I do not remember this. Perhaps I was not in that meeting. By releasing one provider at a time as it is needed it makes the vote that much easier. And also: this is a bug fix, so is more urgent than "there are just new changes". |
|
FYI. I just run
It's just a matter of updating provider,yaml with new version + adding high-level changelog for all those (the detailed changelog will be generated automatically) and re-running Here are relevant snippets of the output when you run `generate provider-package-documentation. |
No, it's a matter of TESTING each of those packages too. Doing that properly is more work than just throwing some tarballs up for a vote. |
We've never tested either of those when we released airflow 1.10. Have anything changed in the procedure? |
|
You haven't been testing things before putting them up to a vote: 😱 I always do. |
When is the last time you tested google/jenkins/ssh operators when releasing any version of 1.10 ? I think, honestly it's totally over-the top here as we have never been testing the providers (and 1.10 equivalent of those). If you want to introduce it - feel free to start a discussion, but it has never been brought to any discussion nor even raised as a problem. Right now all the providers in questions are tested (in the CI):
This is even more than we've tested in Airflow 1.10 to be honest. I am not sure what is your proposal then ? Should someone (who?) actually run all the tests for all the providers we release? what is the idea you have in mind how it should be done? |
|
We haven't tested all of the providers in depth before precisely because releasing 13 at once (including the big three of azure, aws and gcp) is a lot of work, and those releases are less urgent. But by chosing to release one at a time, it is much more possible to test each release in detail. Essentially: what is the problem in releasing cncf.kubernetes on it's own right now? You are asking me to do about 3 days of work to test those (and yes, I/Astronomer did test these in detail for 2.0.0 release) - I personally am not willing to put my name down as release manager to a release I haven't tested. |
Nope . I am asking to release all others based on tests we alredy have in CI. As we've always did. I think you are complicating things too much. The release manager's responsbility is the mechanics of the relese only, not whether everything works: https://infra.apache.org/release-publishing.html. I am not asking any more than we've been doing before. |
|
And this is fantasticly surprising seeing this is a problem at all, especially we discussed all of this before and there are even meeting minutes from the dev call stating the process. I propose to proceed as we already agreed on those meetings and if there is a doubt about it, let's discuss it at the next meeting. |
|
I'll say it even clearer. You are asking me to do something I am not happy to do. If I release something, I have tested it until I am happy with it. |
So let me ask you this question: did you ever test Jenkins, ssh, operators when releasing it? Because I know you did several times. What is your counter-proposal then? Do you have one? I am also extremely not happy with not releasing providers as batches of them (as we previously all agreed to) either, until I hear a viable alternative solution of relasing the providers. |
|
Did I test them for 1.10x? Not always, no. Was I happy about it? Hell no. But now we have the means to do it better. If you really feel that strongly about releasing them all in a batch, okay, but it is going to take me longer. I'm not just going to cut the release and push it out. |
ashb
added
area:providers
and removed
provider:cncf-kubernetes
|
I can do it tomorrow, I have completely no problem with releasing them in batch with the tests that we already have. |
|
If you do not feel comfortable with that - feel free to work out how to do it in a better way with more testing. I am happy to follow what we agreed - before - release both providers and backports in regular (3 weeks intervals) - same way as I've done so far. In the meantime, if you want to start thinking on how to do it better - maybe this is the right time to start thinking of it. Other than following the process the way I designed it and release whatever passes all the test we already have, but certainly no capacity to think about and introduce more sophisticated testing around it. |
|
My 2 cents:
So I agree with the following principles (that you both stated separately) :
|
|
I do not believe we ever said we would only release providers in batches. I can't find any reference to such a decision in the (admittedly very terse) dev meeting notes, nor AIP-8. |
Yes. We agreed that we CAN release them separately if there is an actual need to deviate from a regular schedule by default and that we release all providers in batches due to efficiency and overhead for voting process. That's why in my first comment I asked what is justification for releasing it out-of-bands.
That was my first ask is no reason why cncf.kubernetes should be released separately rather than with the rest of the providers - but apparentlly discussion has deviated from that. So let me repeat again - is there any reason why cncf.kubernetes cannot be released a bit later together with other providers as we agreed before? Is there are critical problem there? If there is a critical problem - are we going also to release backport for that (when we are releasing providers - until end of March we are also releasing backports together with every batch of providers). |
See this is where I disagree. I see a batch release as MORE overhead. Releasing a single provider is much less work on everyone to vote on it. Releasing 13 at once encourages rubber-stamping the vote, or makes people not test it. |
Yep. We disagree here for sure. I think you should propose new process how to apply it for all providers, when to release them and how to test them. I am happy to cease my responsibilities there if there is another process in place - but not sooner than that. And until then regular batches should be the rule and out-of-band ones should be exception. Happy to discuss it at the next dev call. |
|
Just adding a reason again on why I had created a separate issue to release Kubernetes Provider: This issue was raised multiple times by our users: #13348, #13522 & #14287 and so I wanted to release this provider asap since the fix was already merged around 18 Feb (the last batch of providers were released on 8 Feb). |
Let's do it tomorrow then following the process we've already have - including releasing backports together with all providers (since this is a critical issue, it also affect 1.10 users). I have not seen an attempt to release backport package as well for that. |
|
Previously we discussed 3 weeks release schedule for providers. The last round of providers RCs was sent precisely 3 weeks ago. So this is simply the RIGHT TIME to release all of them. And this is what I planned to do tomorrow. I simply see no point in releasing cncf.kubernetes now since we are going to release all the other providers. That's why I was surprised why we JUST want to release the kubernetes one. If we start voting today on cncf.kubernetes alone and tomorrow on all the rest - in parallel on several different providers overlapping each other - THIS will be a mess and this is pretty much guarantee nobody tests anything anyway. Am I missing something? |
I had posted about it 8 days ago (#14287 (comment)) -- since it was just 10 days since all the providers were released. I don't mind either way now and we can discuss this in next Dev call -- but this was one of the times where we should have created an ad-hoc release straight-away. I added it as an item for our next call: https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Dev+Calls#AirflowDevCalls-Agendafornextweek: |
Agree. As I mentioned I've totally missed that one mention in the PR. Maybe that would have been justified back then. Let's talk about it at the call indeed. |
|
Closing as this is covered by #14487 |
3 participants
Related #14463
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.