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
> 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-pulp-2-master
- rhel-7-pulp-2-master
Patrick?
_
+1
On Thu, Nov 9, 2017 at 7:10 PM, Daniel Alley wrote:
> +1
>
> On Thu, Nov 9, 2017 at 3:27 PM, Jeff Ortel wrote:
>
>> +1
>>
>> On 11/09/2017 02:01 PM, Dennis Kliban wrote:
>> > Pulp 3 currently uses a resource's 'name' attribute to form a URI for
>> that resource. However, the name is
>> > usu
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
Thanks, for the education, Patrick. So sounds great to move over to
the "utilizing
the pulp-packaging* jobs in jenkins for nightlies going forward and turning
off the build-automation jobs." And have no particular understanding on
timing - so whatever works for you and helps with looking back on
hi
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 consider.
___
Pulp-dev ma
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
Some of the presenters had conflicts today so they sent videos. I've also
heard that presenters like recording to get their content right with a few
takes.
Aside from that, I'm going to streamline the presentation some so there is
less figiting between videos.
On Thu, Nov 9, 2017 at 2:53 PM, Brya
On Fri, Nov 10, 2017 at 11:59 AM, Patrick Creech wrote:
> 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.
> > > >
>
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
I need to understand the proposed change for builds, but I can do that
offline.
On Fri, Nov 10, 2017 at 11:35 AM, 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.
>>>
On Fri, Nov 10, 2017 at 11:35 AM, 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 enough. I also think that h
>
> 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 enough. I also think that hosting packages on one location helps to
prevent end-user confu
First, I appreciate this being a proposal and discussion before going this
route given it's implications for applications used to consuming Pulp
heavily. Secondly, I believe some of my questions and concerns have been
asked and addressed throughout the thread, but I do feel like it's reached
a poin
On Fri, Nov 10, 2017 at 10:43 AM, Patrick Creech wrote:
> 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
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
Following up on a recent discussion, here is some background on why
"repo_id" appears in the unit key for some content types.
The first step when we model a particular kind of content in Pulp, such as
a puppet module, is to establish what attributes can be used for unique
identification globally.
Thanks for all the discussion. See some inline responses.
On Fri, Nov 10, 2017 at 8:54 AM, Michael Hrivnak
wrote:
>
>
> On Wed, Nov 8, 2017 at 11:05 AM, Dennis Kliban wrote:
>
>> Please see my comments inline.
>>
>> On Tue, Nov 7, 2017 at 3:28 PM, Michael Hrivnak
>> wrote:
>>
>>>
>>>
>>> On Mo
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 forward and turning off the
> > b
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 forward and turning off the
> build-automation jobs
> starting monday.
>
We have any releases in
On Wed, Nov 8, 2017 at 11:05 AM, Dennis Kliban wrote:
> Please see my comments inline.
>
> On Tue, Nov 7, 2017 at 3:28 PM, Michael Hrivnak
> wrote:
>
>>
>>
>> On Mon, Nov 6, 2017 at 9:34 AM, Brian Bouterse
>> wrote:
>>
>>> Yes the REST API can be scoped to a base path. Pulp can also serve
>>> c
22 matches
Mail list logo
