I've done cprofile and code analysis and I don't think we can make the
single-content branches as fast as 'master' currently is. I posted the
reasoning for this analysis here [0]. Per the previous discussion, since
this performance improvement actually slows things down, we should just
close these
Since no one is objecting, I'd like to see the PR[0] from @bmbouter
finished up and merged soon. I am updating the pass-through cache story[1]
to get it ready for implementation. I would like to remove all mention of
separate content app and streamer from the description.
[0] https://github.com/p
To rephrase the problem a little bit:
We need to bulk_create() a bunch of objects, and then after we do that we
want to immediately be able to relate them with other objects, which means
we need their PKs of the objects that were just created.
In the case of auto-increment integer PKs, we can't k
I commented on the jwt one that I think it can be closed and why:
https://pulp.plan.io/issues/3248#note-6
On Wed, Dec 5, 2018 at 8:54 AM David Davis wrote:
> Awesome, thanks!
>
> David
>
>
> On Wed, Dec 5, 2018 at 8:44 AM Austin Macdonald wrote:
>
>> For those with ambiguity, I added the RC blo
+1 to experimentation and also making sure that we understand the
performance implications of the decision. I'm replying to this earlier note
to restate my observations of the problem a bit more.
More ideas and thoughts are welcome. This is a decision with a lot of
aspects to consider.
On Tue, N
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
I see, yeah, I'm a bit vague; should be like the more detail is specified
by by a specific treat requirement, the fewer options should match.
If there's a unit requiring "module(nodejs)" and there are modules
providing multiple streams of the nodejs content in the (source) repository
--- "module(no
Awesome, thanks!
David
On Wed, Dec 5, 2018 at 8:44 AM Austin Macdonald wrote:
> For those with ambiguity, I added the RC blocker to force discussion and
> [acceptance | closing].
>
> Added RC Blocker:
>
>- Add task names: https://pulp.plan.io/issues/2889
>- Determine mutable fields: ht
I have a question.
Can you clarify the wording of "that particular module should be copied" in
the last 3 bullet use cases? Perhaps a use case? To me same wording implies
same behavior - or perhaps I'm not getting the distinction. Thanks!
On Wed, Dec 5, 2018 at 3:28 AM Milan Kovacik wrote:
>
>
For those with ambiguity, I added the RC blocker to force discussion and
[acceptance | closing].
Added RC Blocker:
- Add task names: https://pulp.plan.io/issues/2889
- Determine mutable fields: https://pulp.plan.io/issues/2635
- pulp-manager migrate order: https://pulp.plan.io/issues/306
Robin, I think you're right, we should include the folks.
--
milan
-- Forwarded message -
From: Robin Chan
Date: Wed, Dec 5, 2018 at 1:02 AM
Subject: Re: Pulp 2 depsolving module errata
To: Milan Kovacik
Cc: Daniel Alley , Kersom
Can we continue convo in pull-dev? Feel like t
11 matches
Mail list logo
