[Pulp-dev] Possible Pulp3 RC Blocker issues from backlog

[Austin Macdonald]

To be on the safe side, I'd like to highlight issues that *might* need to
be RC blockers. Please reply directly onto the issue, I'll update this
thread periodically if necessary.

REST API, backwards incompatible changes:

   - Add Task Names:
  - https://pulp.plan.io/issues/2889
  - IMO: We should make this an RC Blocker, because this will be an
  additional requirement for every task in every plugin.
   - Determine mutable fields
  - https://pulp.plan.io/issues/2635
  - IMO: someone (or a group) should take this as assigned and audit
  the mutability of fields. If we find one that needs to change,
it will be a
  backwards incompatible change to the REST API, so this should have the RC
  blocker tack.
   - Status API without db connection
  - https://pulp.plan.io/issues/2850
  - IMO: RC blocker or close. As it is the db connection field is not
  useful, and later removal would be backwards incompatible.
   - Add new field, Publication.created
  - https://pulp.plan.io/issues/2989
  - IMO: RC blocker or close, this would be a backwards incompatible
  change.
   - Asynchronous Distribution update/delete
  - https://pulp.plan.io/issues/3044
  - IMO: RC blocker or close, this would be a backwards incompatible
  change.

Packaging

   - Port dependencies to Python 3
  - https://pulp.plan.io/issues/2247
  - IMO: It seems like if this weren't done, we'd be having problems.
  Anyone mind if I close this one? If we do need to keep it open, should it
  be an RC blocker?
   - Plugins can declare PluginAPI version
  - https://pulp.plan.io/issues/2656
  - IMO: Are we happy with what we've got now? If we want to change it,
  now is the time.

Misc

   - pulp-manager migrate order
  - https://pulp.plan.io/issues/3062
  - IMO: RC Blocker. This is how users should migrate, so it should be
  correct before RC
   - jwt
  - https://pulp.plan.io/issues/3248
  - This was removed from Beta (MVP) but do we need this for RC/GA?
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Possible Pulp3 RC Blocker issues from backlog

[David Davis]

Thanks for digging through older issues to find potential RC blockers.

2889 - +1 to making it an RC blocker
2635 - +1 here as well
2850 - I spent some time working on this and didn’t get far. I think we
should just require the db to be running. I vote to close it out.
2989 - +1 to RC blocker
3044 - I guess we should revisit 3051 and decide on a design before the RC
which will determine if the distribution endpoints need to be async?
2247 - Agreed on closing. Seems like we open issues on an as-needed basis
2656 - Seems like this is done or am I missing something?
3062 - Will checking in migrations to source control not solve this problem?
3248 - I haven’t heard anyone asking for jwt so I would say we don’t need
it. We can just leave the issue open I think.

David


On Mon, Dec 3, 2018 at 2:41 PM Austin Macdonald  wrote:

> To be on the safe side, I'd like to highlight issues that *might* need to
> be RC blockers. Please reply directly onto the issue, I'll update this
> thread periodically if necessary.
>
> REST API, backwards incompatible changes:
>
>- Add Task Names:
>   - https://pulp.plan.io/issues/2889
>   - IMO: We should make this an RC Blocker, because this will be an
>   additional requirement for every task in every plugin.
>- Determine mutable fields
>   - https://pulp.plan.io/issues/2635
>   - IMO: someone (or a group) should take this as assigned and audit
>   the mutability of fields. If we find one that needs to change, it will 
> be a
>   backwards incompatible change to the REST API, so this should have the 
> RC
>   blocker tack.
>- Status API without db connection
>   - https://pulp.plan.io/issues/2850
>   - IMO: RC blocker or close. As it is the db connection field is not
>   useful, and later removal would be backwards incompatible.
>- Add new field, Publication.created
>   - https://pulp.plan.io/issues/2989
>   - IMO: RC blocker or close, this would be a backwards incompatible
>   change.
>- Asynchronous Distribution update/delete
>   - https://pulp.plan.io/issues/3044
>   - IMO: RC blocker or close, this would be a backwards incompatible
>   change.
>
> Packaging
>
>- Port dependencies to Python 3
>   - https://pulp.plan.io/issues/2247
>   - IMO: It seems like if this weren't done, we'd be having problems.
>   Anyone mind if I close this one? If we do need to keep it open, should 
> it
>   be an RC blocker?
>- Plugins can declare PluginAPI version
>   - https://pulp.plan.io/issues/2656
>   - IMO: Are we happy with what we've got now? If we want to change
>   it, now is the time.
>
> Misc
>
>- pulp-manager migrate order
>   - https://pulp.plan.io/issues/3062
>   - IMO: RC Blocker. This is how users should migrate, so it should
>   be correct before RC
>- jwt
>   - https://pulp.plan.io/issues/3248
>   - This was removed from Beta (MVP) but do we need this for RC/GA?
>
> ___
> 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] Possible Pulp3 RC Blocker issues from backlog

[Austin Macdonald]

For those with ambiguity, I added the RC blocker to force discussion and
[acceptance | closing].

Added RC Blocker:

   - Add task names: https://pulp.plan.io/issues/2889
   - Determine mutable fields: https://pulp.plan.io/issues/2635
   - pulp-manager migrate order: https://pulp.plan.io/issues/3062
  - @david - https://pulp.plan.io/issues/4067#note-5
   - Asynchronous Distribution update/delete:
   https://pulp.plan.io/issues/3044
   - Distribution base_path model validation:
   https://pulp.plan.io/issues/3051

Closed:

   - Viewable status endpoint w/out database running:
   https://pulp.plan.io/issues/2850
   - Port Dependencies to Python3: https://pulp.plan.io/issues/2247
   - Plugins can specify plugin API version:
   https://pulp.plan.io/issues/2656

No action:

   - jwt: https://pulp.plan.io/issues/3248
   - Add Publication.created (MODIFIED, david++):
   https://pulp.plan.io/issues/2989


On Mon, Dec 3, 2018 at 3:21 PM David Davis  wrote:

> Thanks for digging through older issues to find potential RC blockers.
>
> 2889 - +1 to making it an RC blocker
> 2635 - +1 here as well
> 2850 - I spent some time working on this and didn’t get far. I think we
> should just require the db to be running. I vote to close it out.
> 2989 - +1 to RC blocker
> 3044 - I guess we should revisit 3051 and decide on a design before the RC
> which will determine if the distribution endpoints need to be async?
> 2247 - Agreed on closing. Seems like we open issues on an as-needed basis
> 2656 - Seems like this is done or am I missing something?
> 3062 - Will checking in migrations to source control not solve this
> problem?
> 3248 - I haven’t heard anyone asking for jwt so I would say we don’t need
> it. We can just leave the issue open I think.
>
> David
>
>
> On Mon, Dec 3, 2018 at 2:41 PM Austin Macdonald  wrote:
>
>> To be on the safe side, I'd like to highlight issues that *might* need to
>> be RC blockers. Please reply directly onto the issue, I'll update this
>> thread periodically if necessary.
>>
>> REST API, backwards incompatible changes:
>>
>>- Add Task Names:
>>   - https://pulp.plan.io/issues/2889
>>   - IMO: We should make this an RC Blocker, because this will be an
>>   additional requirement for every task in every plugin.
>>- Determine mutable fields
>>   - https://pulp.plan.io/issues/2635
>>   - IMO: someone (or a group) should take this as assigned and audit
>>   the mutability of fields. If we find one that needs to change, it will 
>> be a
>>   backwards incompatible change to the REST API, so this should have the 
>> RC
>>   blocker tack.
>>- Status API without db connection
>>   - https://pulp.plan.io/issues/2850
>>   - IMO: RC blocker or close. As it is the db connection field is
>>   not useful, and later removal would be backwards incompatible.
>>- Add new field, Publication.created
>>   - https://pulp.plan.io/issues/2989
>>   - IMO: RC blocker or close, this would be a backwards incompatible
>>   change.
>>- Asynchronous Distribution update/delete
>>   - https://pulp.plan.io/issues/3044
>>   - IMO: RC blocker or close, this would be a backwards incompatible
>>   change.
>>
>> Packaging
>>
>>- Port dependencies to Python 3
>>   - https://pulp.plan.io/issues/2247
>>   - IMO: It seems like if this weren't done, we'd be having
>>   problems. Anyone mind if I close this one? If we do need to keep it 
>> open,
>>   should it be an RC blocker?
>>- Plugins can declare PluginAPI version
>>   - https://pulp.plan.io/issues/2656
>>   - IMO: Are we happy with what we've got now? If we want to change
>>   it, now is the time.
>>
>> Misc
>>
>>- pulp-manager migrate order
>>   - https://pulp.plan.io/issues/3062
>>   - IMO: RC Blocker. This is how users should migrate, so it should
>>   be correct before RC
>>- jwt
>>   - https://pulp.plan.io/issues/3248
>>   - This was removed from Beta (MVP) but do we need this for RC/GA?
>>
>> ___
>> 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] Possible Pulp3 RC Blocker issues from backlog

[David Davis]

Awesome, thanks!

David


On Wed, Dec 5, 2018 at 8:44 AM Austin Macdonald  wrote:

> For those with ambiguity, I added the RC blocker to force discussion and
> [acceptance | closing].
>
> Added RC Blocker:
>
>- Add task names: https://pulp.plan.io/issues/2889
>- Determine mutable fields: https://pulp.plan.io/issues/2635
>- pulp-manager migrate order: https://pulp.plan.io/issues/3062
>   - @david - https://pulp.plan.io/issues/4067#note-5
>- Asynchronous Distribution update/delete:
>https://pulp.plan.io/issues/3044
>- Distribution base_path model validation:
>https://pulp.plan.io/issues/3051
>
> Closed:
>
>- Viewable status endpoint w/out database running:
>https://pulp.plan.io/issues/2850
>- Port Dependencies to Python3: https://pulp.plan.io/issues/2247
>- Plugins can specify plugin API version:
>https://pulp.plan.io/issues/2656
>
> No action:
>
>- jwt: https://pulp.plan.io/issues/3248
>- Add Publication.created (MODIFIED, david++):
>https://pulp.plan.io/issues/2989
>
>
> On Mon, Dec 3, 2018 at 3:21 PM David Davis  wrote:
>
>> Thanks for digging through older issues to find potential RC blockers.
>>
>> 2889 - +1 to making it an RC blocker
>> 2635 - +1 here as well
>> 2850 - I spent some time working on this and didn’t get far. I think we
>> should just require the db to be running. I vote to close it out.
>> 2989 - +1 to RC blocker
>> 3044 - I guess we should revisit 3051 and decide on a design before the
>> RC which will determine if the distribution endpoints need to be async?
>> 2247 - Agreed on closing. Seems like we open issues on an as-needed basis
>> 2656 - Seems like this is done or am I missing something?
>> 3062 - Will checking in migrations to source control not solve this
>> problem?
>> 3248 - I haven’t heard anyone asking for jwt so I would say we don’t need
>> it. We can just leave the issue open I think.
>>
>> David
>>
>>
>> On Mon, Dec 3, 2018 at 2:41 PM Austin Macdonald 
>> wrote:
>>
>>> To be on the safe side, I'd like to highlight issues that *might* need
>>> to be RC blockers. Please reply directly onto the issue, I'll update this
>>> thread periodically if necessary.
>>>
>>> REST API, backwards incompatible changes:
>>>
>>>- Add Task Names:
>>>   - https://pulp.plan.io/issues/2889
>>>   - IMO: We should make this an RC Blocker, because this will be an
>>>   additional requirement for every task in every plugin.
>>>- Determine mutable fields
>>>   - https://pulp.plan.io/issues/2635
>>>   - IMO: someone (or a group) should take this as assigned and
>>>   audit the mutability of fields. If we find one that needs to change, 
>>> it
>>>   will be a backwards incompatible change to the REST API, so this 
>>> should
>>>   have the RC blocker tack.
>>>- Status API without db connection
>>>   - https://pulp.plan.io/issues/2850
>>>   - IMO: RC blocker or close. As it is the db connection field is
>>>   not useful, and later removal would be backwards incompatible.
>>>- Add new field, Publication.created
>>>   - https://pulp.plan.io/issues/2989
>>>   - IMO: RC blocker or close, this would be a backwards
>>>   incompatible change.
>>>- Asynchronous Distribution update/delete
>>>   - https://pulp.plan.io/issues/3044
>>>   - IMO: RC blocker or close, this would be a backwards
>>>   incompatible change.
>>>
>>> Packaging
>>>
>>>- Port dependencies to Python 3
>>>   - https://pulp.plan.io/issues/2247
>>>   - IMO: It seems like if this weren't done, we'd be having
>>>   problems. Anyone mind if I close this one? If we do need to keep it 
>>> open,
>>>   should it be an RC blocker?
>>>- Plugins can declare PluginAPI version
>>>   - https://pulp.plan.io/issues/2656
>>>   - IMO: Are we happy with what we've got now? If we want to change
>>>   it, now is the time.
>>>
>>> Misc
>>>
>>>- pulp-manager migrate order
>>>   - https://pulp.plan.io/issues/3062
>>>   - IMO: RC Blocker. This is how users should migrate, so it should
>>>   be correct before RC
>>>- jwt
>>>   - https://pulp.plan.io/issues/3248
>>>   - This was removed from Beta (MVP) but do we need this for RC/GA?
>>>
>>> ___
>>> 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] Possible Pulp3 RC Blocker issues from backlog

[Brian Bouterse]

I commented on the jwt one that I think it can be closed and why:
https://pulp.plan.io/issues/3248#note-6

On Wed, Dec 5, 2018 at 8:54 AM David Davis  wrote:

> Awesome, thanks!
>
> David
>
>
> On Wed, Dec 5, 2018 at 8:44 AM Austin Macdonald  wrote:
>
>> For those with ambiguity, I added the RC blocker to force discussion and
>> [acceptance | closing].
>>
>> Added RC Blocker:
>>
>>- Add task names: https://pulp.plan.io/issues/2889
>>- Determine mutable fields: https://pulp.plan.io/issues/2635
>>- pulp-manager migrate order: https://pulp.plan.io/issues/3062
>>   - @david - https://pulp.plan.io/issues/4067#note-5
>>- Asynchronous Distribution update/delete:
>>https://pulp.plan.io/issues/3044
>>- Distribution base_path model validation:
>>https://pulp.plan.io/issues/3051
>>
>> Closed:
>>
>>- Viewable status endpoint w/out database running:
>>https://pulp.plan.io/issues/2850
>>- Port Dependencies to Python3: https://pulp.plan.io/issues/2247
>>- Plugins can specify plugin API version:
>>https://pulp.plan.io/issues/2656
>>
>> No action:
>>
>>- jwt: https://pulp.plan.io/issues/3248
>>- Add Publication.created (MODIFIED, david++):
>>https://pulp.plan.io/issues/2989
>>
>>
>> On Mon, Dec 3, 2018 at 3:21 PM David Davis  wrote:
>>
>>> Thanks for digging through older issues to find potential RC blockers.
>>>
>>> 2889 - +1 to making it an RC blocker
>>> 2635 - +1 here as well
>>> 2850 - I spent some time working on this and didn’t get far. I think we
>>> should just require the db to be running. I vote to close it out.
>>> 2989 - +1 to RC blocker
>>> 3044 - I guess we should revisit 3051 and decide on a design before the
>>> RC which will determine if the distribution endpoints need to be async?
>>> 2247 - Agreed on closing. Seems like we open issues on an as-needed basis
>>> 2656 - Seems like this is done or am I missing something?
>>> 3062 - Will checking in migrations to source control not solve this
>>> problem?
>>> 3248 - I haven’t heard anyone asking for jwt so I would say we don’t
>>> need it. We can just leave the issue open I think.
>>>
>>> David
>>>
>>>
>>> On Mon, Dec 3, 2018 at 2:41 PM Austin Macdonald 
>>> wrote:
>>>
 To be on the safe side, I'd like to highlight issues that *might* need
 to be RC blockers. Please reply directly onto the issue, I'll update this
 thread periodically if necessary.

 REST API, backwards incompatible changes:

- Add Task Names:
   - https://pulp.plan.io/issues/2889
   - IMO: We should make this an RC Blocker, because this will be
   an additional requirement for every task in every plugin.
- Determine mutable fields
   - https://pulp.plan.io/issues/2635
   - IMO: someone (or a group) should take this as assigned and
   audit the mutability of fields. If we find one that needs to change, 
 it
   will be a backwards incompatible change to the REST API, so this 
 should
   have the RC blocker tack.
- Status API without db connection
   - https://pulp.plan.io/issues/2850
   - IMO: RC blocker or close. As it is the db connection field is
   not useful, and later removal would be backwards incompatible.
- Add new field, Publication.created
   - https://pulp.plan.io/issues/2989
   - IMO: RC blocker or close, this would be a backwards
   incompatible change.
- Asynchronous Distribution update/delete
   - https://pulp.plan.io/issues/3044
   - IMO: RC blocker or close, this would be a backwards
   incompatible change.

 Packaging

- Port dependencies to Python 3
   - https://pulp.plan.io/issues/2247
   - IMO: It seems like if this weren't done, we'd be having
   problems. Anyone mind if I close this one? If we do need to keep it 
 open,
   should it be an RC blocker?
- Plugins can declare PluginAPI version
   - https://pulp.plan.io/issues/2656
   - IMO: Are we happy with what we've got now? If we want to
   change it, now is the time.

 Misc

- pulp-manager migrate order
   - https://pulp.plan.io/issues/3062
   - IMO: RC Blocker. This is how users should migrate, so it
   should be correct before RC
- jwt
   - https://pulp.plan.io/issues/3248
   - This was removed from Beta (MVP) but do we need this for RC/GA?

 ___
 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] Possible Pulp3 RC Blocker issues from backlog

[Jeff Ortel]

Decisions look good to me.

On 12/5/18 11:36 AM, Brian Bouterse wrote:
I commented on the jwt one that I think it can be closed and why: 
https://pulp.plan.io/issues/3248#note-6


On Wed, Dec 5, 2018 at 8:54 AM David Davis > wrote:


Awesome, thanks!

David


On Wed, Dec 5, 2018 at 8:44 AM Austin Macdonald mailto:aus...@redhat.com>> wrote:

For those with ambiguity, I added the RC blocker to force
discussion and [acceptance | closing].

Added RC Blocker:

  * Add task names:https://pulp.plan.io/issues/2889

  * Determine mutable fields: https://pulp.plan.io/issues/2635
  * pulp-manager migrate order: https://pulp.plan.io/issues/3062
  o @david - https://pulp.plan.io/issues/4067#note-5
  * Asynchronous Distribution update/delete:
https://pulp.plan.io/issues/3044
  * Distribution base_path model validation:
https://pulp.plan.io/issues/3051

Closed:

  * Viewable status endpoint w/out database running:
https://pulp.plan.io/issues/2850
  * Port Dependencies to Python3: https://pulp.plan.io/issues/2247
  * Plugins can specify plugin API version:
https://pulp.plan.io/issues/2656

No action:

  * jwt: https://pulp.plan.io/issues/3248
  * Add Publication.created (MODIFIED, david++):
https://pulp.plan.io/issues/2989


On Mon, Dec 3, 2018 at 3:21 PM David Davis
mailto:davidda...@redhat.com>> wrote:

Thanks for digging through older issues to find potential
RC blockers.

2889 - +1 to making it an RC blocker
2635 - +1 here as well
2850 - I spent some time working on this and didn’t get
far. I think we should just require the db to be running.
I vote to close it out.
2989 - +1 to RC blocker
3044 - I guess we should revisit 3051 and decide on a
design before the RC which will determine if the
distribution endpoints need to be async?
2247 - Agreed on closing. Seems like we open issues on an
as-needed basis
2656 - Seems like this is done or am I missing something?
3062 - Will checking in migrations to source control not
solve this problem?
3248 - I haven’t heard anyone asking for jwt so I would
say we don’t need it. We can just leave the issue open I
think.

David


On Mon, Dec 3, 2018 at 2:41 PM Austin Macdonald
mailto:aus...@redhat.com>> wrote:

To be on the safe side, I'd like to highlight issues
that *might* need to be RC blockers. Please reply
directly onto the issue, I'll update this thread
periodically if necessary.

REST API, backwards incompatible changes:

  * Add Task Names:
  o https://pulp.plan.io/issues/2889
  o IMO: We should make this an RC Blocker,
because this will be an additional requirement
for every task in every plugin.
  * Determine mutable fields
  o https://pulp.plan.io/issues/2635
  o IMO: someone (or a group) should take this as
assigned and audit the mutability of fields.
If we find one that needs to change, it will
be a backwards incompatible change to the REST
API, so this should have the RC blocker tack.
  * Status API without db connection
  o https://pulp.plan.io/issues/2850
  o IMO: RC blocker or close. As it is the db
connection field is not useful, and later
removal would be backwards incompatible.
  * Add new field, Publication.created
  o https://pulp.plan.io/issues/2989
  o IMO: RC blocker or close, this would be a
backwards incompatible change.
  * Asynchronous Distribution update/delete
  o https://pulp.plan.io/issues/3044
  o IMO: RC blocker or close, this would be a
backwards incompatible change.

Packaging

  * Port dependencies to Python 3
  o https://pulp.plan.io/issues/2247
  o IMO: It seems like if this weren't done, we'd
be having problems. Anyone mind if I close
this one? If we do need to keep it open,
should it be an RC blocker?
  * Plugins can declare PluginAPI version