On 9/23/20 7:18 AM, David Davis wrote:
I think the two main things for me are (1) it makes git history more
linear and (2) it cuts down on the number of commits. Both of these
make git history more readable.
The 'rebase and merge' option provides a nice balance of letting you
provide multipl
I discovered this issue with 3.6.2 (and prior) that prevents proper
operation: https://pulp.plan.io/issues/7450
Would it be possible to get a 3.6.3 i near term?
Justin
On 9/2/20 5:13 PM, Dennis Kliban wrote:
Pulpcore 3.6.1was released yesterday, but a bug with the OpenAPI
schema was discovere
On 7/28/20 11:44 AM, David Davis wrote:
Today we discussed this at triage. We're leaning towards changing the
default from 20 to 10 as it seems like 10 only incurs an extra 30%
penalty in time while seeming to fix the problem[0].
One question though is how we should treat existing data becaus
Is it normal for things added/fixed between 3.3 and 3.4 to not show up
in that version tracker?
The item i'm thinking about is https://pulp.plan.io/issues/6591
On 5/19/20 8:55 PM, Dennis Kliban wrote:
Pulpcore 3.4.0 is scheduled to be released on May 27th. There are
currently 3 issues that hav
I apparently replied instead of replied-list! Resending:
I don't have known concerns (more worry about what happens as more and
more people use pulp3 in the real world), but i do think after reading
the investigation in https://pulp.plan.io/issues/6589 that the resulting
RFE: https://pulp.pla
+1 to all of this!
On 4/8/20 12:35 PM, Brian Bouterse wrote:
Thanks for writing this up and sending! My only addition would be to
also remove the P1, P2, P3 tags entirely after setting all tagged
issues with 'katello' and setting their priorities based on the
previous P1/P2/P3 label.
Thank y
I much prefer this solution (A single RPM Repository type), and i think
just using 'location_href' for a rpm uniquness within a repo version
makes a lot of sense, overall +1.
Justin
On 3/23/20 4:27 PM, Daniel Alley wrote:
I think, as long as the metadata is correct, using just the
location_hr
just add some header after reading the cert (and
validating the path) and then pass it on to the reverse proxy with apache?
Thanks!
Justin
On 3/11/20 2:58 PM, Brian Bouterse wrote:
On Wed, Mar 11, 2020 at 2:34 PM Justin Sherrill <mailto:jsher...@redhat.com>> wrote:
We had di
We had discussed base64 encoding the cert in the webserver on the way in
and then letting cert guard decode it. While that's not ideal I think
it has some advantages over moving the full auth into the webserver.
What was your motivation for going with that approach over the base64
encoding ap
tarball
I would imagine that with pulp3 we would somewhat combine these two
approaches and take the pulp3 generated export file and add in a
metadata file of some sort.
Justin
On 2/19/20 2:28 PM, Dennis Kliban wrote:
Thank you for the details. More questions inline.
On Wed, Feb 19, 2020 a
users will probably
get a bunch of content they don't care about if they want to
export a single repo version. That said, if users do want to
export entire repos, we could add this feature later I think?
David
On Wed, Feb 19, 2020 at 10:30 AM Justin Sherrill
mailto:jsh
On 2/14/20 1:09 PM, David Davis wrote:
Grant and I met today to discuss importers and exporters[0] and we'd
like some feedback before we proceed with the design. To sum up this
feature briefly: users can export a repository version from one Pulp
instance and import it to another.
# Master/De
Distributions definitely do not need to be migrated (i see them more as
configuration similar to importers, than i do as something that can be
exported/imported).
Publications i think would be a nice to have, but can be re-generated on
the other side based on the repository version. While the
Both of these look good to me
Justin
On 1/27/20 2:44 PM, Tatiana Tereshchenko wrote:
I'm looking for feedback on the stories below. For both:
- is the logic correct or if anything is missing?
- where to store info (from a remote) which is needed later?
1. https://pulp.plan.io/issues/4458 As
ll!
Justin
On 1/17/20 8:30 AM, Justin Sherrill wrote:
There have been some design discussions going on around applicability
(https://hackmd.io/ydvHuzXNRA6T9eXx6cqy5A) in pulp3.
There are some big changes compared to pulp2, including:
* Package profile, module profile,and repository list
There have been some design discussions going on around applicability
(https://hackmd.io/ydvHuzXNRA6T9eXx6cqy5A) in pulp3.
There are some big changes compared to pulp2, including:
* Package profile, module profile,and repository list have to be
uploaded on every applicability computation
* C
A while back we had some discussion about pulp 3.1 (and somewhat beyond
pulp 3.1), and i wanted to bring attention to some items that may need
to be looked at in those time frames:
https://pulp.plan.io/issues/5613 (re-download corrupted files)
https://pulp.plan.io/issues/5200 (supporting mirro
On 8/20/19 12:17 PM, Brian Bouterse wrote:
Recently with pulp_ansible, users were interested in using pagination
with LimitOffsetPagination [0]. Pulp currently defaults to
PageNumberPagination. I looked at our current DRF defaults, and I
noticed two things.
1. We default to the not-as-common
On 6/20/19 8:02 AM, Dennis Kliban wrote:
On Wed, Jun 19, 2019 at 1:57 PM Dennis Kliban <mailto:dkli...@redhat.com>> wrote:
On Wed, Jun 19, 2019 at 11:34 AM Dennis Kliban mailto:dkli...@redhat.com>> wrote:
On Wed, Jun 19, 2019 at 11:20 AM Justin Sherrill
If a plugin provided multiple remotes, for example, what would that look
like?
in your example:
|-file_remote = fileremotes.remotes_file_file_create(remote_data)
+file_remote = fileremotes.create(remote_data) Lets say the file plugin
provided some other remote that still synced file content?
To me the API is the interface to pulp, not httpie and I do not think
you should corrupt the api to make it easier to use from httpie (I.e.
switch to using comma separated values when json provides a method for
specifying multiple values).
If you want to support both on the server I think that
On 4/4/19 2:35 PM, Daniel Alley wrote:
Content copy between repositories is critically important to Katello
integration and is something that we have not really addressed yet.
It also needs to be completed before the RPM plugin can begin work on
depsolving. The story that results from this d
On 3/1/19 2:45 PM, Robin Chan wrote:
Justin,
Would such a change make a significant difference in the effort,
complexity, or time to migrate existing (or support new) plugins in
Katello?
It would be a very small and simple change.
Robin
On Fri, Mar 1, 2019 at 2:00 PM Justin Sherrill
To me this makes a lot of sense, allows for plugin flexibility, and is
more consistent across plugins.
I feel like this will make differences between plugins more
understandable by reading the api docs, rather than scanning the
README's of the respective plugin and trying to work out what is d
On 2/22/19 12:07 PM, Brian Bouterse wrote:
On Fri, Feb 22, 2019 at 9:36 AM Justin Sherrill <mailto:jsher...@redhat.com>> wrote:
On 2/18/19 2:41 PM, Austin Macdonald wrote:
Originally, our upload story was as follows:
The user will upload a new file to Pulp vi
On 2/19/19 12:30 PM, Brian Bouterse wrote:
Overall +1, we should make a 1-shot uploader. It will need a bit of
code from plugin writers to make it work though.
I believe the "manual and generic" feature offerings we have now are
pretty good. I don't think we should take them away.
To descri
On 2/18/19 2:41 PM, Austin Macdonald wrote:
Originally, our upload story was as follows:
The user will upload a new file to Pulp via POST to /artifacts/
(provided by core)
The user will create a new plugin specific Content via POST to
/path/to/plugin/content/, referencing whatever artifacts th
On 2/19/19 6:38 AM, Ina Panova wrote:
+1 to facilitate the upload process.
At the conferences, there have been many users pointing out how
inconvenient current upload process is .
Is it so much more inconvenient because pulp3 doesn't have a cli?
Justin
Regards,
Ina Panova
Softw
Speaking for our Katello users, I don't know that its required for us to
do, but might be nice to have. I think we might want to have the option
to preserve or not, as alphabetically organized repositories are nice to
have even when the upstream repository isn't laid out in such a way.
I do s
To expand on this, we're starting integration now with pulp3 and file
repositories. I don't have a good estimation for how long it will take,
but my goal is ~2 months (so more likely 3 or 4 months). This should
give us a good estimation for how difficult it will be add future
content types a
h ssl protected content, but those are the only two types where
we provide workflows to the user (via subscription-manager).
My vote would be to make it generic, unless it is much more difficult to
do so.
Justin Sherrill
On 11/26/18 11:56 AM, Jeff Ortel wrote:
To support content protection usi
On 06/26/2018 11:30 AM, Milan Kovacik wrote:
Folks,
TL;DR should we support alternative solvers (configuration) during
recursive unit association?
I've been refactoring the current approach to RPM dependency solving
for e.g the recursive copy to be able to handle rich dependencies[1].
While
On 05/16/2018 01:02 PM, Brian Bouterse wrote:
A mini-team of @jortel, @ttereshc, @ipanova, @dkliban, and @bmbouter
met today to discuss Lazy use-cases for Pulp3. The "initial" use cases
would all be delivered together as the first implementation to be used
with Pulp 3.0. The ones for "later"
ulp core platform somehow.
Matthias
On Mon, 14 May 2018 11:31:52 -0400
Justin Sherrill wrote:
From my understanding of pulp 3, this would maybe involve the
ability to 'import' a publication. Would that make sense?
Justin
On 05/09/2018 08:22 AM, Bryan Kearney wrote:
One of the
From my understanding of pulp 3, this would maybe involve the ability
to 'import' a publication. Would that make sense?
Justin
On 05/09/2018 08:22 AM, Bryan Kearney wrote:
One of the themes I heard yesterday at the Red Hat Summit was around
having a pulp server mirror the upstream RPM repo m
HI All!
I noticed while testing out pulp 3, that artifacts are downloaded as:
$ ls -l
/var/lib/pulp/artifact/04/2c259d546331588e1dff83a46f62a27fb7cf3de4050924470d99fd8d2a046f
-rw---. 1 root root 4358144 May 2 15:42
/var/lib/pulp/artifact/04/2c259d546331588e1dff83a46f62a27fb7cf3de405092
On 04/30/2018 10:46 AM, Jeremy Audet wrote:
> +1. Exposing UUIDs is definitely preferable to using hrefs as ids.
"The app just looks at the relative path" -> what if pulp wants the
flexibility to change repositories end point (highly improbable but
you never know).
Is it better, though? U
though, hostname and port don’t matter. The app just
looks at the relative path. It looks like changing the deployment path
causes problems though.
It matters if you are a client and are fetching stored hrefs.
Justin
David
On Mon, Apr 30, 2018 at 9:58 AM, Justin Sherrill <mailto:js
e should add them back.
On Fri, Apr 27, 2018 at 12:26 PM, Justin Sherrill
mailto:jsher...@redhat.com>> wrote:
Hi All!
I started playing around with pulp 3 and generated bindings
via https://pulp.plan.io/issues/3580
<https://pulp.plan.io/issues/3580
Hi All!
I started playing around with pulp 3 and generated bindings via
https://pulp.plan.io/issues/3580 and it results somewhat in what you
would expect. Here's an example:
# @param id A UUID string identifying this repository.
# @param [Hash] opts the optional parameters
# @ret
On 03/08/2018 11:13 AM, Austin Macdonald wrote:
Motivation:
The name "importer" carries some inaccurate implications.
1) Importers should "import". Tasks like "sync" will do the actual
importing. The object only holds the configuration that happens to be
used by sync tasks.
2) Sync tasks on m
41 matches
Mail list logo
