Re: [Pulp-dev] New pulpcore release (3.3.1?)
After our meeting today with Katello, we decided to release a 3.3.1 release this week with just https://pulp.plan.io/issues/6565 which is currently blocking them. There is a large backlog of fixes for 3.3 that probably cannot be cleanly picked onto the 3.3 branch. Moreover, we are coming up soon on our next monthly y-release (3.4). David On Wed, May 6, 2020 at 8:10 AM Brian Bouterse wrote: > When I look at the all_task_dispatched ticket I see a feature; the > TaskGroup not being in the plugin API I can see as a bug. If we release a > feature I think it would need to be 3.4.0. This is inconvenient I know, but > my concern is that if a feature gets released in Z stream even with good > intentions, we put the semver commitment and transitively the trust of our > users at risk. I agree completely that these changes must be released and > soon. > > What about dis-including all_task_dispatched from a 3.3.1? I > believe @daviddavis identified this gap and it was theoretical**. Katello > could workaround by polling any migration a bit longer even when it shows > completed. This would give many benefits: we can stay true to semver, > katello can use the workaround to poll linger, and a low-risk 3.3.1 would > be created without requiring everything to release for compatibility > reasons. What do others think about this approach? > > To unpack my mental model for this classification into feature versus bug, > I try to determine if there is a claim of usability already present. If > there is, then it's a bug; if there isn't then it's a feature. > > **: I don't mean this negatively. It's only an observation that it has not > been experienced in practice > > > > > > > On Tue, May 5, 2020 at 10:07 AM Tatiana Tereshchenko > wrote: > >> +1 for 3.3.1 >> >> Could those be included? >> 1. Adding TaskGroup to the plugin API >> https://github.com/pulp/pulpcore/pull/677 >> 2. Adding all_task_dispatched field to indicate that no more tasks will >> spawn https://github.com/pulp/pulpcore/pull/682 >> >> They may sound like features/improvements however, without both, task >> groups are close to unusable. >> Katello integrates with pulpcore 3.3 and migration plugin which uses task >> groups. >> Migration plugin can workaround the first problem by importing directly >> from the pulpcore. >> Without #2, there is no way to know whether all tasks have been >> dispatched or not, it means no way to know the overall state of the >> migration. >> >> To my knowledge, task groups are used by import/export (which is in tech >> preview) and by the migration plugin. So those PRs seem to me like a >> low-risk change. >> >> Any thoughts? >> >> Thanks, >> Tanya >> >> On Mon, May 4, 2020 at 8:41 PM David Davis wrote: >> >>> I think Katello would like a few of the bug fixes from the past couple >>> weeks. Would a 3.3.1 release make sense? Would anyone have time this week >>> to work on it? >>> >>> David >>> ___ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> ___ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] New pulpcore release (3.3.1?)
When I look at the all_task_dispatched ticket I see a feature; the TaskGroup not being in the plugin API I can see as a bug. If we release a feature I think it would need to be 3.4.0. This is inconvenient I know, but my concern is that if a feature gets released in Z stream even with good intentions, we put the semver commitment and transitively the trust of our users at risk. I agree completely that these changes must be released and soon. What about dis-including all_task_dispatched from a 3.3.1? I believe @daviddavis identified this gap and it was theoretical**. Katello could workaround by polling any migration a bit longer even when it shows completed. This would give many benefits: we can stay true to semver, katello can use the workaround to poll linger, and a low-risk 3.3.1 would be created without requiring everything to release for compatibility reasons. What do others think about this approach? To unpack my mental model for this classification into feature versus bug, I try to determine if there is a claim of usability already present. If there is, then it's a bug; if there isn't then it's a feature. **: I don't mean this negatively. It's only an observation that it has not been experienced in practice On Tue, May 5, 2020 at 10:07 AM Tatiana Tereshchenko wrote: > +1 for 3.3.1 > > Could those be included? > 1. Adding TaskGroup to the plugin API > https://github.com/pulp/pulpcore/pull/677 > 2. Adding all_task_dispatched field to indicate that no more tasks will > spawn https://github.com/pulp/pulpcore/pull/682 > > They may sound like features/improvements however, without both, task > groups are close to unusable. > Katello integrates with pulpcore 3.3 and migration plugin which uses task > groups. > Migration plugin can workaround the first problem by importing directly > from the pulpcore. > Without #2, there is no way to know whether all tasks have been dispatched > or not, it means no way to know the overall state of the migration. > > To my knowledge, task groups are used by import/export (which is in tech > preview) and by the migration plugin. So those PRs seem to me like a > low-risk change. > > Any thoughts? > > Thanks, > Tanya > > On Mon, May 4, 2020 at 8:41 PM David Davis wrote: > >> I think Katello would like a few of the bug fixes from the past couple >> weeks. Would a 3.3.1 release make sense? Would anyone have time this week >> to work on it? >> >> David >> ___ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > ___ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] New pulpcore release (3.3.1?)
+1 for 3.3.1 Could those be included? 1. Adding TaskGroup to the plugin API https://github.com/pulp/pulpcore/pull/677 2. Adding all_task_dispatched field to indicate that no more tasks will spawn https://github.com/pulp/pulpcore/pull/682 They may sound like features/improvements however, without both, task groups are close to unusable. Katello integrates with pulpcore 3.3 and migration plugin which uses task groups. Migration plugin can workaround the first problem by importing directly from the pulpcore. Without #2, there is no way to know whether all tasks have been dispatched or not, it means no way to know the overall state of the migration. To my knowledge, task groups are used by import/export (which is in tech preview) and by the migration plugin. So those PRs seem to me like a low-risk change. Any thoughts? Thanks, Tanya On Mon, May 4, 2020 at 8:41 PM David Davis wrote: > I think Katello would like a few of the bug fixes from the past couple > weeks. Would a 3.3.1 release make sense? Would anyone have time this week > to work on it? > > David > ___ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[Pulp-dev] New pulpcore release (3.3.1?)
I think Katello would like a few of the bug fixes from the past couple weeks. Would a 3.3.1 release make sense? Would anyone have time this week to work on it? David ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
