On Mon, May 11, 2020 at 4:46 PM Brian Bouterse wrote:
> On Mon, May 11, 2020 at 4:40 PM Grant Gainey wrote:
>
>> Hey folks,
>> I am making some additions to the import-export docs and went to build
>> them locally so I could review formatting. Since the last time I did this a
>> month ago, I'm
We've had some complicated use cases (which is good) for RBAC added to the
document starting @ L#21 https://hackmd.io/6rmwt_tgQTuFsfAJ4B2sXw Thanks to
@ttereshc for her writing in there since our last meeting.
Please read what's written there and add in the most complicated user
stories you've
On Mon, May 11, 2020 at 4:40 PM Grant Gainey wrote:
> Hey folks,
>
> I am making some additions to the import-export docs and went to build
> them locally so I could review formatting. Since the last time I did this a
> month ago, I'm running into a problem. docs/Makefile now assumes that "
>
Hey folks,
I am making some additions to the import-export docs and went to build them
locally so I could review formatting. Since the last time I did this a
month ago, I'm running into a problem. docs/Makefile now assumes that "
http://pulp/...; will resolve to something, which it certainly
Thank you for sharing this! Can a basic README be added showing a few
things a user could try after installing it from source? I also put a few
comments inline also.
On Mon, May 11, 2020 at 1:53 PM David Davis wrote:
> Adding pulp-list to hopefully get user feedback on this.
>
> David
>
>
> On
I think having the commands namespaced by the plugin name would be an
organized way to see what capabilities a given plugin is shipping. I
imagine for pulpcore's commands they could be namespaced under 'core' or
'pulpcore'.
Also +1 to 'pulp' command name.
On Mon, May 11, 2020 at 6:42 AM David
Adding pulp-list to hopefully get user feedback on this.
David
On Mon, May 11, 2020 at 6:54 AM Matthias Dellweg
wrote:
> A first draft of the architecture that should eventually govern the pulp
> cli has been completed [0].
> The feature set is naturally very limited, since we want to
Regards,
Ina Panova
Senior Software Engineer| Pulp| Red Hat Inc.
"Do not go where the path may lead,
go instead where there is no path and leave a trail."
On Fri, May 8, 2020 at 3:55 PM Brian Bouterse wrote:
>
>
> On Tue, May 5, 2020 at 10:48 AM David Davis wrote:
>
>> During
comments inline
On Mon, May 11, 2020 at 3:10 PM Brian Bouterse wrote:
>
> On Mon, May 11, 2020 at 3:21 AM Matthias Dellweg
> wrote:
>
>> What i like about this proposal is, that the yet unwritten rule, that one
>> signing service is really meant to sign with one specific key would be very
>>
On Mon, May 11, 2020 at 3:21 AM Matthias Dellweg
wrote:
> What i like about this proposal is, that the yet unwritten rule, that one
> signing service is really meant to sign with one specific key would be very
> explicit.
>
I agree
We could go one step further and provide the key ID as
Hi David, all
Just want to give my perspective on this issue [1]
I acknowledge that docs are an essential resource for Pulp users. As
someone who wrote tech docs for nine years, I get the importance of
findable docs. However, one thing that struck me was that the former
Documentation link on the
A first draft of the architecture that should eventually govern the pulp
cli has been completed [0].
The feature set is naturally very limited, since we want to autotemplate
most of this after getting good feedback about the architecture.
Questions we want to settle at this point are:
- Is the
In some places, the API in Pulp 3 is very different from Pulp 2 but where
it's possible and makes sense, I think we will want to do this. Perhaps
this is a good argument for having plugin name after the "pulp" command (eg
"pulp rpm ...", "pulp file ...").
David
On Thu, May 7, 2020 at 8:47 AM
+1 to 'pulp' command
+1 to first have plugin name
Regards,
Ina Panova
Senior Software Engineer| Pulp| Red Hat Inc.
"Do not go where the path may lead,
go instead where there is no path and leave a trail."
On Thu, May 7, 2020 at 2:28 PM Dennis Kliban wrote:
> On Thu, May 7, 2020
What i like about this proposal is, that the yet unwritten rule, that one
signing service is really meant to sign with one specific key would be very
explicit.
We could go one step further and provide the key ID as environment to the
script called (to make that part reusable / packageable).
Also
15 matches
Mail list logo
