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
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
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,
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
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
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
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
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
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.
> >
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
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
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
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
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
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
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
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
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 builds a
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
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
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
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
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
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
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 releas
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
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
>
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
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
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
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
> > > >
On Fri, 2017-11-10 at 10:26 -0500, Jeremy Audet wrote:
> On Thu, Nov 9, 2017 at 4:58 PM, Patrick Creech <pcre...@redhat.com> wrote:
> > As part of the ongoing release engineer changes, I would like to propose
> > utilizing the pulp-
> > packaging* jobs in jenkins
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
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
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
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
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
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
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 the Pul
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
. 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 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
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
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
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
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
51 matches
Mail list logo
