[Pulp-dev] pulpcore 3.0.0b6 released
The following packages are now available on PyPI: pulpcore 3.0.0b6 [0] pulpcore-plugin 0.1.0b4 [1] pulp-file 0.0.1b4 [2] Comprehensive list of changes and bugfixes for beta 6 can be found here [3]. Breaking changes include: * Use querysets for add/remove_content methods [4] * Switch to using integer IDs instead of UUIDs [5] [0] https://pypi.org/project/pulpcore/3.0.0b6/ [1] https://pypi.org/project/pulpcore-plugin/0.1.0b4/ [2] https://pypi.org/project/pulp-file/0.0.1b4/ [3] https://bit.ly/2NI7Dse [4] https://github.com/pulp/pulp/pull/3548 [5] https://github.com/pulp/pulp/pull/3549 ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] proposed changes to Pulp 3 auto generated docs
I'm exploring the changes required to use IDs and hrefs on the PR here:
https://github.com/pulp/pulp/pull/3561#issuecomment-407888652
On Wed, Jul 25, 2018 at 4:24 PM, David Davis wrote:
> I know we don’t support things like accepting hrefs as references to
> resources but if I remember correctly we do return hrefs alongside ids in
> responses in Pulp 2. Is that not correct?
>
> David
>
>
> On Wed, Jul 25, 2018 at 4:17 PM Dennis Kliban wrote:
>
>> I don't think we support both hrefs and ids in Pulp 2. The Pulp 2 REST
>> API does not accept HREFs as references to resources. In Pulp 2's REST API
>> we do not even have resources that have relationships to other resources.
>> The relationships between resources are established by nesting them under
>> one another. e.g.: /pulp/api/v2/repositories// and
>> /pulp/api/v2/repositories//importers//. In Pulp 2,
>> if a user wanted to reference content units in a request, the API requires
>> writing a filter that uses Mongodb syntax.
>>
>> Pulp 3's REST API has a resources called Task that has a
>> 'created_resource' attribute. This resource is a reference to either a
>> repository version or a publication at this time. Pulp 3's REST API also
>> supports users specifying references to content units that should be added
>> or removed from a repository. These needs do not exist in Pulp 2's REST
>> API.
>>
>>
>> On Wed, Jul 25, 2018 at 3:55 PM, David Davis
>> wrote:
>>
>>> Correct me if I’m wrong but Pulp 2 supported @bizhang’s model of
>>> providing both hrefs and ids. Was that a source of problems or complaints
>>> by Pulp 2 users?
>>>
>>> David
>>>
>>>
>>> On Wed, Jul 25, 2018 at 3:08 PM Dennis Kliban
>>> wrote:
>>>
For everyone following along, the conversation has moved to Github - on
the PR[0] with the proposed changes.
[0] https://github.com/pulp/pulp/pull/3561
On Tue, Jul 24, 2018 at 11:15 AM, Bihan Zhang
wrote:
> @dkliban I've tried out your PR and left a question:
> https://github.com/pulp/pulp/pull/3561#issuecomment-407425172
>
> Won't it be problematic with the openapi definitions causing us to
>> have two schemas? Accepting the data in two forms is one thing, but using
>> openapi to describe it both ways is something I don't understand well.
>> Are
>> we going to ship and test two?
>>
>
> I don't think we'll be defining the data in two different ways in
> openapi. We need to pass a {repository identifier} to /sync/, openapi
> expects a string, what we do with that string is up to us. (In the
> following example the format is "uri" but this isn't actually used for
> validation at all, since it's not defined by the swagger specification
> [0],
> we can also clear out the format field, since format is only there to
> support documentation needs)
>
>- RepositorySyncURL:
>{
> - required:
> [
> - "repository"
> ],
> - type: "object",
> - properties:
> {
> - repository:
> {
> - title: "Repository",
> - description: "A URI of the repository to be
> synchronized.",
> - type: "string",
> - format: "uri"
> }
> }
> },
>
>
> I can see why some users would want to refer to things in the api
>> using ID not an href. I think about the case that when calling publish
>> and
>> referring to a RepositoryVersion with id=827561, num=3, and for
>> repository=1234. With an ID alternately accepted, you could call publish
>> and submit repo_version=827561 instead of
>> repo_version='repositories/1234/version/3/'.
>> I can see that benefit, but it comes with downsides. Saving/storing a
>> url I
>> know feels a little strange, but I do see several upsides...
>>
>
>> Doing it only with hrefs, ensures those benefits (nice recap btw)
>> will always be true. Having to submit the references using something like
>> 'repositories/1234/version/3/' will cause any client to store them that
>> way. I think that's a good thing because someone troubleshooting their
>> scripts or in katello's db will instead have
>> 'repositories/1234/version/3/',
>> which they can directly use with HTTP. I think this is valuable.
>> Otherwise
>> they would have repo version 827561, which now they have to do extra work
>> to start interacting with that object via HTTP. Storing urls removes the
>> "templating" step from the troubleshooter's responsibilities so we're
>> making their job easier. Spacewise, I don't think the clients benefit
>> hugely from storing 827561 instead of 'repositories/1234/version/3/',
>> but humans do.
>>
> Why don't we provide the ability to use both href and id as
> identifiers, and katello can choose the
Re: [Pulp-dev] proposed changes to Pulp 3 auto generated docs
I know we don’t support things like accepting hrefs as references to
resources but if I remember correctly we do return hrefs alongside ids in
responses in Pulp 2. Is that not correct?
David
On Wed, Jul 25, 2018 at 4:17 PM Dennis Kliban wrote:
> I don't think we support both hrefs and ids in Pulp 2. The Pulp 2 REST API
> does not accept HREFs as references to resources. In Pulp 2's REST API we
> do not even have resources that have relationships to other resources. The
> relationships between resources are established by nesting them under one
> another. e.g.: /pulp/api/v2/repositories// and
> /pulp/api/v2/repositories//importers//. In Pulp 2,
> if a user wanted to reference content units in a request, the API requires
> writing a filter that uses Mongodb syntax.
>
> Pulp 3's REST API has a resources called Task that has a
> 'created_resource' attribute. This resource is a reference to either a
> repository version or a publication at this time. Pulp 3's REST API also
> supports users specifying references to content units that should be added
> or removed from a repository. These needs do not exist in Pulp 2's REST
> API.
>
>
> On Wed, Jul 25, 2018 at 3:55 PM, David Davis
> wrote:
>
>> Correct me if I’m wrong but Pulp 2 supported @bizhang’s model of
>> providing both hrefs and ids. Was that a source of problems or complaints
>> by Pulp 2 users?
>>
>> David
>>
>>
>> On Wed, Jul 25, 2018 at 3:08 PM Dennis Kliban wrote:
>>
>>> For everyone following along, the conversation has moved to Github - on
>>> the PR[0] with the proposed changes.
>>>
>>> [0] https://github.com/pulp/pulp/pull/3561
>>>
>>> On Tue, Jul 24, 2018 at 11:15 AM, Bihan Zhang
>>> wrote:
>>>
@dkliban I've tried out your PR and left a question:
https://github.com/pulp/pulp/pull/3561#issuecomment-407425172
Won't it be problematic with the openapi definitions causing us to have
> two schemas? Accepting the data in two forms is one thing, but using
> openapi to describe it both ways is something I don't understand well. Are
> we going to ship and test two?
>
I don't think we'll be defining the data in two different ways in
openapi. We need to pass a {repository identifier} to /sync/, openapi
expects a string, what we do with that string is up to us. (In the
following example the format is "uri" but this isn't actually used for
validation at all, since it's not defined by the swagger specification [0],
we can also clear out the format field, since format is only there to
support documentation needs)
- RepositorySyncURL:
{
- required:
[
- "repository"
],
- type: "object",
- properties:
{
- repository:
{
- title: "Repository",
- description: "A URI of the repository to be
synchronized.",
- type: "string",
- format: "uri"
}
}
},
I can see why some users would want to refer to things in the api using
> ID not an href. I think about the case that when calling publish and
> referring to a RepositoryVersion with id=827561, num=3, and for
> repository=1234. With an ID alternately accepted, you could call publish
> and submit repo_version=827561 instead of
> repo_version='repositories/1234/version/3/'. I can see that benefit, but
> it
> comes with downsides. Saving/storing a url I know feels a little strange,
> but I do see several upsides...
>
> Doing it only with hrefs, ensures those benefits (nice recap btw) will
> always be true. Having to submit the references using something like
> 'repositories/1234/version/3/' will cause any client to store them that
> way. I think that's a good thing because someone troubleshooting their
> scripts or in katello's db will instead
> have 'repositories/1234/version/3/', which they can directly use with
> HTTP.
> I think this is valuable. Otherwise they would have repo version 827561,
> which now they have to do extra work to start interacting with that object
> via HTTP. Storing urls removes the "templating" step from the
> troubleshooter's responsibilities so we're making their job easier.
> Spacewise, I don't think the clients benefit hugely from storing 827561
> instead of 'repositories/1234/version/3/', but humans do.
>
Why don't we provide the ability to use both href and id as
identifiers, and katello can choose the route that is right for them based
on the points you bring up?
>
> I don't know much about the CLI, but if we want to enable a specific
> user experience, I think we can find a way to make that work. Overall I
> think users should be able to specify things in the most intuitive way
> possible, and I don't see
Re: [Pulp-dev] proposed changes to Pulp 3 auto generated docs
Correct me if I’m wrong but Pulp 2 supported @bizhang’s model of providing
both hrefs and ids. Was that a source of problems or complaints by Pulp 2
users?
David
On Wed, Jul 25, 2018 at 3:08 PM Dennis Kliban wrote:
> For everyone following along, the conversation has moved to Github - on
> the PR[0] with the proposed changes.
>
> [0] https://github.com/pulp/pulp/pull/3561
>
> On Tue, Jul 24, 2018 at 11:15 AM, Bihan Zhang wrote:
>
>> @dkliban I've tried out your PR and left a question:
>> https://github.com/pulp/pulp/pull/3561#issuecomment-407425172
>>
>> Won't it be problematic with the openapi definitions causing us to have
>>> two schemas? Accepting the data in two forms is one thing, but using
>>> openapi to describe it both ways is something I don't understand well. Are
>>> we going to ship and test two?
>>>
>>
>> I don't think we'll be defining the data in two different ways in
>> openapi. We need to pass a {repository identifier} to /sync/, openapi
>> expects a string, what we do with that string is up to us. (In the
>> following example the format is "uri" but this isn't actually used for
>> validation at all, since it's not defined by the swagger specification [0],
>> we can also clear out the format field, since format is only there to
>> support documentation needs)
>>
>>- RepositorySyncURL:
>>{
>> - required:
>> [
>> - "repository"
>> ],
>> - type: "object",
>> - properties:
>> {
>> - repository:
>> {
>> - title: "Repository",
>> - description: "A URI of the repository to be synchronized.",
>> - type: "string",
>> - format: "uri"
>> }
>> }
>> },
>>
>>
>> I can see why some users would want to refer to things in the api using
>>> ID not an href. I think about the case that when calling publish and
>>> referring to a RepositoryVersion with id=827561, num=3, and for
>>> repository=1234. With an ID alternately accepted, you could call publish
>>> and submit repo_version=827561 instead of
>>> repo_version='repositories/1234/version/3/'. I can see that benefit, but it
>>> comes with downsides. Saving/storing a url I know feels a little strange,
>>> but I do see several upsides...
>>>
>>
>>> Doing it only with hrefs, ensures those benefits (nice recap btw) will
>>> always be true. Having to submit the references using something like
>>> 'repositories/1234/version/3/' will cause any client to store them that
>>> way. I think that's a good thing because someone troubleshooting their
>>> scripts or in katello's db will instead
>>> have 'repositories/1234/version/3/', which they can directly use with HTTP.
>>> I think this is valuable. Otherwise they would have repo version 827561,
>>> which now they have to do extra work to start interacting with that object
>>> via HTTP. Storing urls removes the "templating" step from the
>>> troubleshooter's responsibilities so we're making their job easier.
>>> Spacewise, I don't think the clients benefit hugely from storing 827561
>>> instead of 'repositories/1234/version/3/', but humans do.
>>>
>> Why don't we provide the ability to use both href and id as identifiers,
>> and katello can choose the route that is right for them based on the points
>> you bring up?
>>
>>>
>>> I don't know much about the CLI, but if we want to enable a specific
>>> user experience, I think we can find a way to make that work. Overall I
>>> think users should be able to specify things in the most intuitive way
>>> possible, and I don't see how API data formats directly influence that. For
>>> example I think referring to a repository by it's name is the most natural;
>>> it's more natural than 1234 or repositories/1234.
>>>
>> +1 the CLI can resolve name to identifiers (either id or href), so I'm
>> not too concerned with that.
>>
>> [0]
>> https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types
>>
>> On Mon, Jul 23, 2018 at 9:51 PM, Dennis Kliban
>> wrote:
>>
>>> I've made a work in progress PR[0] that demonstrates the changes I was
>>> suggesting.
>>>
>>> [0] https://github.com/pulp/pulp/pull/3561
>>>
>>> On Mon, Jul 23, 2018 at 3:50 PM, Brian Bouterse
>>> wrote:
>>>
Having two ways to refer to objects in the API makes me nervous. I have
some questions/concerns/ideas. I'm also interested to see what dkliban's
bindings produce in terms of a resolution of the swagger issues.
Won't it be problematic with the openapi definitions causing us to have
two schemas? Accepting the data in two forms is one thing, but using
openapi to describe it both ways is something I don't understand well. Are
we going to ship and test two?
I can see why some users would want to refer to things in the api using
ID not an href. I think about the case that when calling publish and
referring to a RepositoryVersion with id=827561, num=3, and for
repository=1234. With
Re: [Pulp-dev] proposed changes to Pulp 3 auto generated docs
For everyone following along, the conversation has moved to Github - on the
PR[0] with the proposed changes.
[0] https://github.com/pulp/pulp/pull/3561
On Tue, Jul 24, 2018 at 11:15 AM, Bihan Zhang wrote:
> @dkliban I've tried out your PR and left a question: https://github.com/
> pulp/pulp/pull/3561#issuecomment-407425172
>
> Won't it be problematic with the openapi definitions causing us to have
>> two schemas? Accepting the data in two forms is one thing, but using
>> openapi to describe it both ways is something I don't understand well. Are
>> we going to ship and test two?
>>
>
> I don't think we'll be defining the data in two different ways in
> openapi. We need to pass a {repository identifier} to /sync/, openapi
> expects a string, what we do with that string is up to us. (In the
> following example the format is "uri" but this isn't actually used for
> validation at all, since it's not defined by the swagger specification [0],
> we can also clear out the format field, since format is only there to
> support documentation needs)
>
>- RepositorySyncURL:
>{
> - required:
> [
> - "repository"
> ],
> - type: "object",
> - properties:
> {
> - repository:
> {
> - title: "Repository",
> - description: "A URI of the repository to be synchronized.",
> - type: "string",
> - format: "uri"
> }
> }
> },
>
>
> I can see why some users would want to refer to things in the api using ID
>> not an href. I think about the case that when calling publish and referring
>> to a RepositoryVersion with id=827561, num=3, and for repository=1234. With
>> an ID alternately accepted, you could call publish and submit
>> repo_version=827561 instead of repo_version='repositories/1234/version/3/'.
>> I can see that benefit, but it comes with downsides. Saving/storing a url I
>> know feels a little strange, but I do see several upsides...
>>
>
>> Doing it only with hrefs, ensures those benefits (nice recap btw) will
>> always be true. Having to submit the references using something like
>> 'repositories/1234/version/3/' will cause any client to store them that
>> way. I think that's a good thing because someone troubleshooting their
>> scripts or in katello's db will instead have 'repositories/1234/version/3/',
>> which they can directly use with HTTP. I think this is valuable. Otherwise
>> they would have repo version 827561, which now they have to do extra work
>> to start interacting with that object via HTTP. Storing urls removes the
>> "templating" step from the troubleshooter's responsibilities so we're
>> making their job easier. Spacewise, I don't think the clients benefit
>> hugely from storing 827561 instead of 'repositories/1234/version/3/',
>> but humans do.
>>
> Why don't we provide the ability to use both href and id as identifiers,
> and katello can choose the route that is right for them based on the points
> you bring up?
>
>>
>> I don't know much about the CLI, but if we want to enable a specific user
>> experience, I think we can find a way to make that work. Overall I think
>> users should be able to specify things in the most intuitive way possible,
>> and I don't see how API data formats directly influence that. For example I
>> think referring to a repository by it's name is the most natural; it's more
>> natural than 1234 or repositories/1234.
>>
> +1 the CLI can resolve name to identifiers (either id or href), so I'm not
> too concerned with that.
>
> [0] https://github.com/OAI/OpenAPI-Specification/blob/
> master/versions/2.0.md#data-types
>
> On Mon, Jul 23, 2018 at 9:51 PM, Dennis Kliban wrote:
>
>> I've made a work in progress PR[0] that demonstrates the changes I was
>> suggesting.
>>
>> [0] https://github.com/pulp/pulp/pull/3561
>>
>> On Mon, Jul 23, 2018 at 3:50 PM, Brian Bouterse
>> wrote:
>>
>>> Having two ways to refer to objects in the API makes me nervous. I have
>>> some questions/concerns/ideas. I'm also interested to see what dkliban's
>>> bindings produce in terms of a resolution of the swagger issues.
>>>
>>> Won't it be problematic with the openapi definitions causing us to have
>>> two schemas? Accepting the data in two forms is one thing, but using
>>> openapi to describe it both ways is something I don't understand well. Are
>>> we going to ship and test two?
>>>
>>> I can see why some users would want to refer to things in the api using
>>> ID not an href. I think about the case that when calling publish and
>>> referring to a RepositoryVersion with id=827561, num=3, and for
>>> repository=1234. With an ID alternately accepted, you could call publish
>>> and submit repo_version=827561 instead of
>>> repo_version='repositories/1234/version/3/'.
>>> I can see that benefit, but it comes with downsides. Saving/storing a url I
>>> know feels a little strange, but I do see several upsides...
>>>
>>> Doing it only with hrefs, ensures
Re: [Pulp-dev] Proposal to change default logging to console in Pulp 3
Sorry, meant to include the issue: https://pulp.plan.io/issues/3883 On Wed, Jul 25, 2018 at 11:31 AM, Eric Helms wrote: > Thanks for the quick discussion. I went ahead and opened an issue and > accompanying PR for the work to make this change for y'all to consider. > > On Wed, Jul 25, 2018 at 10:59 AM, Daniel Alley wrote: > >> Not to say syslog is dead, it's especially useful for clustered installs >>> which need fancier logging like centralization or off-site replication, etc. >> >> >> And a lot of people who do use syslog are just telling journald to >> forward logs there, in which case, console logging is still a good default. >> >> On Wed, Jul 25, 2018 at 10:42 AM, Brian Bouterse >> wrote: >> >>> I think console logging is also probably the right logging default in >>> non containerized environments too. The majority of OSes Pulp will run on >>> will run systemd which has it's logging facilities reading from stdout and >>> stderr [0]. So for the majority of non-containerized userbase systemd is >>> their logging system not syslog. Not to say syslog is dead, it's especially >>> useful for clustered installs which need fancier logging like >>> centralization or off-site replication, etc. Those users can take the extra >>> step to configure logging to syslog if they apply a bit of extra config >>> after https://pulp.plan.io/issues/3879 is fixed. >>> >>> It also being the expected logging for containerized environments makes >>> me think we should switch Pulp3 to console logging as the default. What do >>> you think? >>> >>> [0]: https://www.freedesktop.org/software/systemd/man/systemd-jou >>> rnald.service.html#Description >>> >>> >>> On Wed, Jul 25, 2018 at 10:31 AM, Eric Helms wrote: >>> You actually can run with console logging today. There is a bug where if you are in an environment without syslog and enable console logging you will get errors, see https://pulp.plan.io/issues/3879 Since background running typically translates to systemd based, perhaps considering making logging type configurable as an environment variable or command line option to set it per service. For example, perhaps you want to run workers in the background but the main application server in your console? On Wed, Jul 25, 2018 at 9:17 AM, David Davis wrote: > I definitely think that we should support console logging (and it > looks like we currently don’t) but I’m a bit hesitant to make it the > default. I think right now a majority of non-dev users will be running > these services in the background. But I could see perhaps one day where > Pulp is mostly run in containers where console logging would be the better > default. > > David > > > On Wed, Jul 25, 2018 at 8:17 AM Eric Helms wrote: > >> Howdy, >> >> As I understand things, the default logging in Pulp 3 is set to >> syslog. I am proposing changing this to be console by default and >> optionally letting users configure syslog. I think these days console as >> a >> default makes general sense for running things in a simple terminal, or >> as >> a developer. Further, the natural way to log in a container based >> environment is to log to stdout. The use of syslog makes sense in a >> traditional systemd based deployment which can be configured by users as >> needed. >> >> >> - Eric >> ___ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> ___ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Proposal to change default logging to console in Pulp 3
> > Not to say syslog is dead, it's especially useful for clustered installs > which need fancier logging like centralization or off-site replication, etc. And a lot of people who do use syslog are just telling journald to forward logs there, in which case, console logging is still a good default. On Wed, Jul 25, 2018 at 10:42 AM, Brian Bouterse wrote: > I think console logging is also probably the right logging default in non > containerized environments too. The majority of OSes Pulp will run on will > run systemd which has it's logging facilities reading from stdout and > stderr [0]. So for the majority of non-containerized userbase systemd is > their logging system not syslog. Not to say syslog is dead, it's especially > useful for clustered installs which need fancier logging like > centralization or off-site replication, etc. Those users can take the extra > step to configure logging to syslog if they apply a bit of extra config > after https://pulp.plan.io/issues/3879 is fixed. > > It also being the expected logging for containerized environments makes me > think we should switch Pulp3 to console logging as the default. What do you > think? > > [0]: https://www.freedesktop.org/software/systemd/man/systemd- > journald.service.html#Description > > > On Wed, Jul 25, 2018 at 10:31 AM, Eric Helms wrote: > >> You actually can run with console logging today. There is a bug where if >> you are in an environment without syslog and enable console logging you >> will get errors, see https://pulp.plan.io/issues/3879 >> >> Since background running typically translates to systemd based, perhaps >> considering making logging type configurable as an environment variable or >> command line option to set it per service. For example, perhaps you want to >> run workers in the background but the main application server in your >> console? >> >> >> On Wed, Jul 25, 2018 at 9:17 AM, David Davis >> wrote: >> >>> I definitely think that we should support console logging (and it looks >>> like we currently don’t) but I’m a bit hesitant to make it the default. I >>> think right now a majority of non-dev users will be running these services >>> in the background. But I could see perhaps one day where Pulp is mostly run >>> in containers where console logging would be the better default. >>> >>> David >>> >>> >>> On Wed, Jul 25, 2018 at 8:17 AM Eric Helms wrote: >>> Howdy, As I understand things, the default logging in Pulp 3 is set to syslog. I am proposing changing this to be console by default and optionally letting users configure syslog. I think these days console as a default makes general sense for running things in a simple terminal, or as a developer. Further, the natural way to log in a container based environment is to log to stdout. The use of syslog makes sense in a traditional systemd based deployment which can be configured by users as needed. - Eric ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> >> ___ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > ___ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Proposal to change default logging to console in Pulp 3
I think console logging is also probably the right logging default in non containerized environments too. The majority of OSes Pulp will run on will run systemd which has it's logging facilities reading from stdout and stderr [0]. So for the majority of non-containerized userbase systemd is their logging system not syslog. Not to say syslog is dead, it's especially useful for clustered installs which need fancier logging like centralization or off-site replication, etc. Those users can take the extra step to configure logging to syslog if they apply a bit of extra config after https://pulp.plan.io/issues/3879 is fixed. It also being the expected logging for containerized environments makes me think we should switch Pulp3 to console logging as the default. What do you think? [0]: https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html#Description On Wed, Jul 25, 2018 at 10:31 AM, Eric Helms wrote: > You actually can run with console logging today. There is a bug where if > you are in an environment without syslog and enable console logging you > will get errors, see https://pulp.plan.io/issues/3879 > > Since background running typically translates to systemd based, perhaps > considering making logging type configurable as an environment variable or > command line option to set it per service. For example, perhaps you want to > run workers in the background but the main application server in your > console? > > > On Wed, Jul 25, 2018 at 9:17 AM, David Davis > wrote: > >> I definitely think that we should support console logging (and it looks >> like we currently don’t) but I’m a bit hesitant to make it the default. I >> think right now a majority of non-dev users will be running these services >> in the background. But I could see perhaps one day where Pulp is mostly run >> in containers where console logging would be the better default. >> >> David >> >> >> On Wed, Jul 25, 2018 at 8:17 AM Eric Helms wrote: >> >>> Howdy, >>> >>> As I understand things, the default logging in Pulp 3 is set to syslog. >>> I am proposing changing this to be console by default and optionally >>> letting users configure syslog. I think these days console as a default >>> makes general sense for running things in a simple terminal, or as a >>> developer. Further, the natural way to log in a container based environment >>> is to log to stdout. The use of syslog makes sense in a traditional systemd >>> based deployment which can be configured by users as needed. >>> >>> >>> - Eric >>> ___ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> > > ___ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
