On Tue, 2019-02-12 at 12:03 -0500, Neal Gompa wrote:
> On Tue, Feb 12, 2019 at 11:55 AM Brian Bouterse wrote:
> > This identifies that packaging Pulp into Fedora is valuable. Thank you for
> > that. I've got a few questions to help us
> > get there.
> >
> > What is the recommendation for where t
On Wed, 2018-12-05 at 09:34 -0500, Daniel Alley wrote:
> Perhaps, but it's not a -1 so much as a call for more experimentation and
> testing. I wouldn't feel comfortable saying
> Pulp is MySQL "compatible" if (if!) it was an order of magnitude slower than
> Pulp on Postgres, and we never found o
On Mon, 2018-11-19 at 17:08 -0500, Brian Bouterse wrote:
> When we switched from UUID to integers for the PK
> with databases other than PostgreSQL [0].
>
> With a goal of database agnosticism for Pulp3, if plugin writers plan to use
> bulk_create with any object inherited
> from one of ours, the
On Mon, 2018-11-05 at 14:58 -0500, David Davis wrote:
> I was looking at the release schedule page[0] and I saw that we define
> release terms like ‘beta’ and ‘release
> candidate’ but we don’t define what a ‘dev freeze’ means. I’d like to add the
> definition of ‘dev freeze' to our
> release sch
I wish I didn't have to write this, but we are where we are
unfortunately.
Back when we hit the 'need a new libsolv' issue, we ran into a little
problem with how libsolv's python bindings were generated between
fedora and el7. This boiled down to differences in how swig2 and swig3
generated the b
On Wed, 2018-10-03 at 16:28 -0400, Eric Helms wrote:
> Howdy,
>
> When switching a deployment over to use gunicorn, DEBUG = TRUE for serving
> static files stopped working. I endeavored to follow the production install
> method using collectstatic. This required
> setting STATIC_ROOT which appea
On Wed, 2018-07-11 at 18:33 +0200, Milan Kovacik wrote:
> Folks,
>
> We've merged a package dependency requirement update[1] to make it possible
> for the rich-dependencies work to be mergeable[2].
>
> This has broken the EL7 builds
So, often times we have needs to carry new/updated dependencie
On Thu, 2018-06-21 at 11:26 -0400, Jeremy Audet wrote:
> Base URLs should never change. That's an expectation that all web application
> clients everywhere should be able to rely on. "Cool URIs don't change." If
> anything, storing IDs is the worse practice,
> because that implies that the client
On Fri, 2018-06-22 at 14:38 -0400, Dennis Kliban wrote:
> I am working on building all of our Pulp 2 and Pulp 3 docs on Travis. The
> Pulp 2 docs will be built using cron jobs in Travis. Each cron job needs to
> be associated with a particular branch. This
> means that we need to have a branch fo
On Tue, 2018-06-19 at 11:06 -0400, Dennis Kliban wrote:
> On Tue, Jun 19, 2018 at 10:54 AM, Ina Panova wrote:
> > Just to highlight and check the overall understanding - there will be one
> > repository per Y pulp release which might contain multiple Z and Y plugin
> > version releases.
> > Cor
On Thu, 2018-05-24 at 17:41 -0400, Dennis Kliban wrote:
>
> Patrick, can we plan to do this next week?
Sure, let's plan for it to happen wednesday?
signature.asc
Description: This is a digitally signed message part
___
Pulp-dev mailing list
Pulp-dev
On Mon, 2018-05-21 at 19:51 -0400, Dennis Kliban wrote:
> We need to start planning the creation of a "2.17-dev" branch from the
> current master and merging "3.0-dev" into "master". We would then create new
> "2.Y-dev" branch after each "2.Y.0" release. All
> 3.0 work would then land on master.
I'm good with these dates from my end
On Fri, 2018-05-04 at 18:25 +0200, Ina Panova wrote:
> A Crane 3.2.0 is being planned with some features and recent fixes. Here [0]
> is a release schedule page which outlines some tentative dates, starting with
> a dev freeze on May 9, 2018.
>
> If this sc
On Mon, 2018-04-23 at 17:32 -0400, Brian Bouterse wrote:
>
>
> Whoever does the packaging needs to determine how/where they want to run them.
So, this is a sentiment I thought was addressed by Robin's e-mail, but I'll
explicitly re-iterate here:
The build teams role is not to be a black box th
On Mon, 2018-04-23 at 15:22 -0400, Brian Bouterse wrote:
> Travis CI runs a few OSes, but not RHEL and Fedora, or many others. Travis is
> good for ensuring that Pulp's main release asset (the pypi packages) are
> being tested continuously.
>
> Ensuring that Pulp runs on any given OS is a differ
On Mon, 2018-04-23 at 14:01 -0400, Robin Chan wrote:
> I feel like the Travis change is recent enough that I'm not exactly sure how
> they differ from the Jenkins jobs. Are we all clear on these terminology?
> Aren't there multiple jobs running at different
> times? I am not comfortable enough wi
Thanks Robin!
On Thu, 2018-04-19 at 16:34 -0400, Robin Chan wrote:
> Dennis, Eric, & Patrick,
>
> Thanks for this additional information around this motivation behind some of
> the differences between Pulp 2 and Pulp 3 release options. I'm glad to hear
> that Pulp 2 had some constraints that Pu
Pulp,
So, while working on the packaging work, I figured it be nice to start talking
about release process expectations around nightlies, beta, and GA.
Generally, what is pulp's release plan? What are the expectations here?
And also, more specifically,
Based on what we do for pulp 2, when wil
On Mon, 2018-03-26 at 16:56 -0400, Patrick Creech wrote:
> Head's up, the upgrade path still needs a little work from celery < 4 to
> celery > 4 on rhel.
>
> I will be working to resolve these issues asap
A fix has been vetted by QE, RC is unblocked. Will provide bui
Head's up, the upgrade path still needs a little work from celery < 4 to celery
> 4 on rhel.
I will be working to resolve these issues asap
signature.asc
Description: This is a digitally signed message part
___
Pulp-dev mailing list
Pulp-dev@redhat.com
On Mon, 2018-03-19 at 15:09 -0400, Brian Bouterse wrote:
> @pcreech let me know when the Beta is ready to announce. The announcements
> can go out whenever you say so.
>
Everythign is g2g from releng
signature.asc
Description: This is a digitally signed message part
On Wed, 2018-03-14 at 15:53 -0400, Brian Bouterse wrote:
> Here is one final feature that was added as a dev-freeze exception through
> discussion with rpm plugin devs and @pcreech:
> https://pulp.plan.io/issues/3444 It is merged, tested, and ready to go.
>
> @pcreech can you ack when pulp/pul
As part of the pulp-packaging transition plan, it was on the agenda to remove
the deps folder from pulp, and other release engineering items that are either
elseware (spec files) or obsolete (rel-eng
folder, dist_list.txt) from the various repos under pulp-packaging control.
This work was to be
On Tue, 2018-02-06 at 14:32 -0500, Jeremy Audet wrote:
> > Also it would verify that each issue has an associated commit because the
> > build machinery will fail if there are fewer commits.
>
> Does this mean that a single commit can't fix two issues? If so, this seems
> like a case of the tail
The release engineering team has some tooling that will help automate the
cherry-picking process,
but it will need some changes to the process outlined in the PUP-3.
The main thing is how would we want to associate a particular redmine item with
what release it
*should* land in (as opposed to wh
On Mon, 2018-01-08 at 09:08 -0600, Jeff Ortel wrote:
>
> Thoughts?
>
Sounds good from a releng pov for upstream, with the caveat of what to do about
EL5? We technically
still have client bits published for that distro.
signature.asc
Description: This is a digitally signed message part
On Mon, 2017-11-27 at 16:10 -0600, Jeff Ortel wrote:
> On 11/27/2017 12:19 PM, Jeff Ortel wrote:
> >
> >
> > On 11/17/2017 08:55 AM, Patrick Creech wrote:
> > > One of the things I like to think about in these types of situations is,
> > > "what is
With the release of 2.14.3, we can consider the *-dev branches dead going
forward, and can stop
merging forward our changes.
While everything surrounding cherrypicking hasn't been finalized yet, 2.15.0
will be branched
directly from 'master', and 2.15.1 will be the first release where we have to
One of the things I like to think about in these types of situations is, "what
is good rest api
design". Nesting resources under other resources is a necessary part of good
api design, and has
its place. To borrow some terms from domain driven development:
Collections of objects are called agg
Since there appears to be agreement from dev and qe, I'm adding a note to the
beta announcement for
2.14.3 with the expectation that 2.14.3 will be the last of the 2.14 line.
On Fri, 2017-11-10 at 14:15 -0500, Patrick Creech wrote:
> While it is typically standard practice to no longer r
With Fedora 27 being released today, I would like to propose dropping Fedora 24
at this time, with
dropping Fedora 25 shortly after 2.15.0 is released.
Fedora only supports Current and Current-1 releases, with Current-2 support
dropping one month after
the release of Current.
I will be workin
On Fri, 2017-11-10 at 16:09 -0500, Jeremy Audet wrote:
> > I'm assuming that with the Pulp 2 - Master UI tab, that there will be lots
> > of job here.
>
> I think the "Pulp 2 - master" UI tab will have four jobs, with names like:
> fedora-24-pulp-2-master
> fedora-25-pulp-2-master
> fedora-26-pul
On Fri, 2017-11-10 at 15:25 -0500, Robin Chan wrote:
> I'm assuming that with the Pulp 2 - Master UI tab, that there will be lots of
> job here. Will
> those jobs continue to have a 2.15 in the name and then we easily see where
> the next .y build was
> done? In otherwords, it is just the report
On Fri, 2017-11-10 at 15:08 -0500, Jeremy Audet wrote:
> Do you think it will be possible to push an emergency 2.14.4 build out the
> door if necessary? Or
> an emergency 2.13.z build? I love the idea of throwing away old processes
> that are weighing us
> down. But there are business needs to co
While it is typically standard practice to no longer release z streams for the
.y-1 release after we
release the .y, there are valid exceptions to this rule that we have observed a
few times in the
past. Therefore, I would like to make it explicit that we will not push
another 2.14 build after
On Fri, 2017-11-10 at 11:35 -0500, Jeremy Audet wrote:
> > > Hosting packages in just one place is simpler than hosting packages in
> > > multiple places.
> > > There's
> > > less room for error when the simpler thing is done.
> > >
> >
> > It shouldn't be too hard to set up.
>
>
> Fair enou
On Fri, 2017-11-10 at 10:49 -0500, Brian Bouterse wrote:
> >
> > >
> > >
> > > > From a deployment perspective, it's been a key use case to deploy crane
> > > > at the perimeter,
> > > > rsync published image files out to a file or CDN service, and run the
> > > > rest of Pulp on a
> > > > w
On Fri, 2017-11-10 at 10:26 -0500, Jeremy Audet wrote:
> On Thu, Nov 9, 2017 at 4:58 PM, Patrick Creech wrote:
> > As part of the ongoing release engineer changes, I would like to propose
> > utilizing the pulp-
> > packaging* jobs in jenkins for nightlies going forwar
As part of the ongoing release engineer changes, I would like to propose
utilizing the pulp-
packaging* jobs in jenkins for nightlies going forward and turning off the
build-automation jobs
starting monday.
I would also like to propose switching from having the next .y version in the
name for m
On Thu, 2017-11-02 at 17:19 -0400, Brian Bouterse wrote:
> I think Pulp probably has to be rooted at / on any given site so that it can
> host live APIs.
While this is possibly a safe assumption for the standalone basic use case, it
is not neccessarily for all use cases. Think of the web serve
The work for the below mentioned items have been completed. An e-mail was sent
out about how to access pulp-ci from your existing pulp_packaging checkout.
Feel free to reach out if you have any
quesitons
Thanks,
Patrick
On Mon, 2017-10-30 at 16:31 -0400, Patrick Creech wrote:
> This w
Pulp-dev,
pulp/pulp_packaging has been officially renamed to pulp/pulp-ci
If you have an existing pulp_packaging checkout that you want to work with the
new repo location you can do one of the following:
Use git remote commands to alter the url:
> git remote set-url pulp https://github.com/pul
This week, i'm looking to do the following:
1) Move the pulp-packaging[0] repo under pulp
2) renaming of pulp_packaging[1] to pulp-ci
For 1 to take place, I'll need to work with someone who has access to the pulp
organization on github to get this repo moved over.
For 2 to take place, I'll nee
Brian,
I don't mind picking this up as part of the release process, as I hope to
automate these annoucements in the future and having access will help with
that. I do ask that with 2.14.2 being imminent (a
matter of hours), would you be able to handle it one more time for 2.14.2 since
we don't
Pulp Packaging Redesign
Over the past few weeks I've been working at redesigning pulp's packaging
workflow and tooling with a goal of simplification and automation in mind.
I've taken inspiration from foreman and katello's
upstream, as well as an ansible based approach used in satellite's downs
Since I was one of the early voices against cherrypicking during the initial
vote, I figured I'd send this e-mail along with some points that have helped me
be in favor of cherry picking before voting
starts.
In taking over the release engineering process, I have gained some perspective
on our
I just took a look while doing the branch updates for the release engineering
process. After merging forward 2.13-dev -> 2.14-dev -> master (updating for
2.13.4), I went on master and cherry-picked
those two commit hashes. They did bring along new changes, and pushed them up
to master along wi
On Tue, 2017-08-01 at 11:38 -0400, Patrick Creech wrote:
> With the release of Pulp 2.14, pulp_docker is bumping it's major version to
> 3.0. pulp_docker already had a 3.0-dev branch from the future Pulp3 release.
> As a temporary solution we created a 3.0-dev-tmp branch for th
Below is the list of rm issues that are slated to be cherry-picked for
inclusion in 2.13.4. Please let me know if you are aware of other issues that
need to be addressed
2874
2903
2734
2927
Thanks,
Patrick
signature.asc
Description: This is a digitally signed message part
With the release of Pulp 2.14, pulp_docker is bumping it's major version to
3.0. pulp_docker already had a 3.0-dev branch from the future Pulp3 release.
As a temporary solution we created a 3.0-dev-tmp branch for the Pulp2 docker
work.
The permanent solution is to move the current 3.0-dev branc
. This will be done after
pulp 2.14 beta gets released
On Tue, 2017-07-18 at 14:37 -0400, Patrick Creech wrote:
> Due to the imminent release of 2.14.0, the following new -dev branches have
> been created:
>
> pulp:2.14-dev
> pulp_puppet: 2.14-dev
> pulp_rpm:2.14
Due to the imminent release of 2.14.0, the following new -dev branches have
been created:
pulp:2.14-dev
pulp_puppet: 2.14-dev
pulp_rpm:2.14-dev
pulp_docker: 2.5-dev
pulp_ostree: 1.3-dev
pulp_deb:1.5-dev
crane: 2.2-dev
- When merging new stories for these projects, continue
On Thu, 2017-06-29 at 18:48 -0400, Michael Hrivnak wrote:
>
> > I also want to make a similar point here about carrying a content
> > protection feature in Pulp and not relying on Apache exclusively for it. As
> > a developer I should be able to have the same content
> > protection features with
On Wed, 2017-06-21 at 12:41 -0400, Brian Bouterse wrote:
> tl;dr: Only use *args and **kwargs in a function signature if you can't be
> sure what will be passed in.
...
> If you see one of these in a PR or already committed, please change it.
> Please send thoughts, questions, or concerns about
On Fri, 2017-06-02 at 16:21 +0200, Ina Panova wrote:
> That's correct, we need not to forget to set the new branch as protected.
>
This can be included in the process for creating new .y releases to ensure it's
done at creation
time.
signature.asc
Description: This is a digitally signed message
On Thu, 2017-06-01 at 11:18 -0400, Bihan Zhang wrote:
> I've been documenting the plugin API semver strategy for 3.0 but I've noticed
> that the plugins
> were recently moved from plugin/pulp/plugin to platform/pulp/plugin
>
> My understanding was that we would have separate packages for plugin a
On Thu, 2017-05-25 at 10:30 -0400, Patrick Creech wrote:
> -1
I'm changing my vote to -0 to better reflect my initial intention of expressing
my dissent, but not
blocking the passage of this outright; as I do not believe I have enough
knowledge and experience in
this argument to do s
-1
I've come late to this topic, and wanted to wait till voting time to form an
opinion, so I apologize
if some of the reasons I'm voting -1 have already been discussed and brought up.
While trying to come up with a decision on this topic, I googled "git merge vs
cherry-pick". The
overwhelming
On Tue, 2017-04-18 at 14:42 -0400, Dennis Kliban wrote:
> Do we want to provide a tool for migrating from Pulp 2 to 3? If yes, then ...
Yes, indubitably (imo).
> Would the tool be able to migrate repository definitions and require the user
> to sync and upload
> content to restore /var/lib/pulp/
+0
On Tue, 2017-04-18 at 10:06 +0200, Tatiana Tereshchenko wrote:
> +0
>
> Tanya
>
> On Mon, Apr 17, 2017 at 11:43 PM, David Davis wrote:
> > +0
> >
> >
> > David
> >
> > On Mon, Apr 17, 2017 at 4:32 PM, Bihan Zhang wrote:
> > > +1
> > >
> > > On Mon, Apr 17, 2017 at 4:24 PM, Michael Hrivn
Due to the imminent release of 2.13.0, the following new -dev branches have
been created:
pulp: 2.13-dev
pulp_puppet: 2.13-dev
pulp_rpm: 2.13-dev
pulp_docker: 2.4-dev
crane: 2.1-dev
- When merging new stories for these projects, continue to be merge to master.
- When merging new bug fixes for t
After spending the majority of the day hunting down the fine details of this
plan, I'm in agreement
with Michael that it isn't the best option here. While it seemed interesting
on the surface, the
devil is in the details, as they say. And this just appears to be a little too
non-standard for u
I've been doing some preliminary research into a 'Have our cake and eat it too'
option.
While getting back up to speed on things pulp, I came across this comment on
the FPC ticket:
https://pagure.io/packaging-committee/issue/671#comment-146777
Buried towards the end of this comment, in the
Forwarding this along as well
Forwarded Message
From: notificati...@fedoraproject.org
To: pcre...@redhat.com
Subject: ape...@gmail.com filed a new bug RHBZ#1414000 'python2-pulp-common
uses conflicting nam...'
Date: Tue, 17 Jan 2017 14:21:12 + (UTC)
ape...@gmail.com filed a
On Thu, 2016-11-17 at 15:33 -0500, Brian Bouterse wrote:
> +1 to taking an action on this. The SET_NULL approach sounds fine with me for
> now. It is so
> simple. It does not help with the later log analysis though which I do think
> is useful, but maybe
> not something we need to facilitate with
On Fri, 2016-10-14 at 15:08 -0400, Sean Myers wrote:
> {a lot of stuff that is reasonable and I agree with}
Don't have much to add, just registering my +1
signature.asc
Description: This is a digitally signed message part
___
Pulp-dev mailing list
Pulp-
On Mon, 2016-10-17 at 11:14 -0400, Sean Myers wrote:
> I'd love it if we could stop writing docs in the ":param foo:" style. Instead,
> I think that we should use the sphinx extension "napoleon" to write docstrings
> that are *way* more human-readable (in my opinion, at least) while still
> generat
After some research into how to package for software collections, it does look
feesible to utilize
them for pulp 3. The main issue will be the fact that yes, we do have to
package some new
dependencies to utilize software collections instead. While that statement
initially appears loaded
with
On Wed, 2016-09-14 at 15:34 -0400, Sean Myers wrote:
> We've got a bunch of models, so we (wisely, I think) break them up
> into submodules in the platform app's models namespace so that they're
> easy to find.
>
> In my work on the 3.0 REST API, I'm mirroring this layout when defining
> the seria
During the course of the Task modeling work for Pulp 3, it was mentioned that
some discussion should
he had around the use of ISO8601 date fields to control task scheduling.
So to start this conversation, I pose two questions:
1) Should we do away with the use of ISO8601 date fields for schedul
On Tue, 2016-08-23 at 15:53 -0400, Brian Bouterse wrote:
> One related comment on this is my desire to avoid getters and setters.
>
> For example let's say my_field is the JSON field. I hope we can do this:
>
> my_model = TheModelClass()
> my_model.my_field = {'a': 1, 'b': 2} # this is setting w
While implementing the task models for Pulp 3.0, I came to the conclusion that
we still have a
requirement for implementing a database field strictly for object persistence.
The best solution
for this will be to utilize a custom field for this, that allows us to
serialize it to a json string
an
72 matches
Mail list logo
