New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[4.0] New binary and tree redesign #1986

Closed

TurboTurtle opened this issue Mar 23, 2020 · 0 comments

Assignees

Milestone

Member

TurboTurtle commented Mar 23, 2020

This issue to to track the new binary change(s) and the re-org of the project tree for 4.0.

The general approach is to have a new sos binary that is the entry point for subcommands like report, collect, clean, etc... This approach should allow for easy addition of new subcommands, much like how plugins today can be very easily added to report. The previous sosreport binary should still be present and accessible, though it is not immediately clear if it should just wrap sos report, or if it should maintain its existing hooks into report, and thus have limited access to the new functionality.

The text was updated successfully, but these errors were encountered:

TurboTurtle added this to the 4.0 milestone

TurboTurtle self-assigned this

This was referenced Mar 23, 2020

[4.0] Add soscleaner functionality into sos natively #1987

Closed

[4.0] Add sos-collector functionality to sos natively #1988

Closed

TurboTurtle added a commit to TurboTurtle/sos that referenced this issue


          [4.0] Re-organize tree for sos-4.0

26216ea

This is the beginning of the sos-4.0 design rework.

First, move the existing `sosreport` binary into a new top-level `bin`
dir. The future `sos` binary will also live here.

Second, create a `report` subdir within the `sos` module, and move the
relevant `sosreport` bits to that subdir. A following commit will update
all references like `from sos.plugins` to `from sos.report.plugins`.

Related: sosreport#1986

Signed-off-by: Jake Hunsaker <[email protected]>

TurboTurtle added a commit to TurboTurtle/sos that referenced this issue


          [4.0] Create new binary and define new entrypoints for subcommands

f4d8326

This is the first patch to add a new `sos` binary to act as the new
commandline interface for users.

It adds the basic `SoS()` and `SoSComponent()` classes that will be
built out and used going forward for new subcommand development. Actual
functionality will be added in coming patches, as this is mainly serving
as a checkpoint to avoid over-large commits affecting wide swathes of
changes at once.

Related: sosreport#1986

Signed-off-by: Jake Hunsaker <[email protected]>

TurboTurtle added a commit to TurboTurtle/sos that referenced this issue


          [binary] Have legacy sosreport binary redirect to sos

78898e8

We need to carry a `sosreport` binary for some time to allow for end
users and downstreams to adjust to the new binary. It was hoped
originally that the old `sosreport` binary could be maintained in place
and simply provide the older set of functionality.

This has proven to not be possible givent he overhaul of the options
handling that allows us to have multiple subcommands. So while we will
still ship an `sosreport` binary, and it will be locked to `report`
functionality, it is now a simple redirection script that also makes the
user aware of the new `sos` binary.

Closes: sosreport#1986

Signed-off-by: Jake Hunsaker <[email protected]>

TurboTurtle added a commit to TurboTurtle/sos that referenced this issue


          [binary] Have legacy sosreport binary redirect to sos

09bbbc2

We need to carry a `sosreport` binary for some time to allow for end
users and downstreams to adjust to the new binary. It was hoped
originally that the old `sosreport` binary could be maintained in place
and simply provide the older set of functionality.

This has proven to not be possible givent he overhaul of the options
handling that allows us to have multiple subcommands. So while we will
still ship an `sosreport` binary, and it will be locked to `report`
functionality, it is now a simple redirection script that also makes the
user aware of the new `sos` binary.

Closes: sosreport#1986

Signed-off-by: Jake Hunsaker <[email protected]>

TurboTurtle added a commit to TurboTurtle/sos that referenced this issue


          [binary] Have legacy sosreport binary redirect to sos

5d9eb07

We need to carry a `sosreport` binary for some time to allow for end
users and downstreams to adjust to the new binary. It was hoped
originally that the old `sosreport` binary could be maintained in place
and simply provide the older set of functionality.

This has proven to not be possible givent he overhaul of the options
handling that allows us to have multiple subcommands. So while we will
still ship an `sosreport` binary, and it will be locked to `report`
functionality, it is now a simple redirection script that also makes the
user aware of the new `sos` binary.

Closes: sosreport#1986

Signed-off-by: Jake Hunsaker <[email protected]>

TurboTurtle added a commit to TurboTurtle/sos that referenced this issue


          [4.0] Create new binary and define new entrypoints for subcommands

7bdd2bf

This is the first patch to add a new `sos` binary to act as the new
commandline interface for users.

It adds the basic `SoS()` and `SoSComponent()` classes that will be
built out and used going forward for new subcommand development. Actual
functionality will be added in coming patches, as this is mainly serving
as a checkpoint to avoid over-large commits affecting wide swathes of
changes at once.

Related: sosreport#1986

Signed-off-by: Jake Hunsaker <[email protected]>

TurboTurtle added a commit to TurboTurtle/sos that referenced this issue


          [binary] Have legacy sosreport binary redirect to sos

d346582

We need to carry a `sosreport` binary for some time to allow for end
users and downstreams to adjust to the new binary. It was hoped
originally that the old `sosreport` binary could be maintained in place
and simply provide the older set of functionality.

This has proven to not be possible givent he overhaul of the options
handling that allows us to have multiple subcommands. So while we will
still ship an `sosreport` binary, and it will be locked to `report`
functionality, it is now a simple redirection script that also makes the
user aware of the new `sos` binary.

Closes: sosreport#1986

Signed-off-by: Jake Hunsaker <[email protected]>

TurboTurtle added a commit to TurboTurtle/sos that referenced this issue


          [binary] Have legacy sosreport binary redirect to sos

c199842

We need to carry a `sosreport` binary for some time to allow for end
users and downstreams to adjust to the new binary. It was hoped
originally that the old `sosreport` binary could be maintained in place
and simply provide the older set of functionality.

This has proven to not be possible givent he overhaul of the options
handling that allows us to have multiple subcommands. So while we will
still ship an `sosreport` binary, and it will be locked to `report`
functionality, it is now a simple redirection script that also makes the
user aware of the new `sos` binary.

Closes: sosreport#1986

Signed-off-by: Jake Hunsaker <[email protected]>

TurboTurtle added a commit to TurboTurtle/sos that referenced this issue


          [binary] Have legacy sosreport binary redirect to sos

e525d63

We need to carry a `sosreport` binary for some time to allow for end
users and downstreams to adjust to the new binary. It was hoped
originally that the old `sosreport` binary could be maintained in place
and simply provide the older set of functionality.

This has proven to not be possible givent he overhaul of the options
handling that allows us to have multiple subcommands. So while we will
still ship an `sosreport` binary, and it will be locked to `report`
functionality, it is now a simple redirection script that also makes the
user aware of the new `sos` binary.

Closes: sosreport#1986

Signed-off-by: Jake Hunsaker <[email protected]>

TurboTurtle added a commit to TurboTurtle/sos that referenced this issue


          [4.0] Re-organize tree for sos-4.0

91354e6

This is the beginning of the sos-4.0 design rework.

First, move the existing `sosreport` binary into a new top-level `bin`
dir. The future `sos` binary will also live here.

Second, create a `report` subdir within the `sos` module, and move the
relevant `sosreport` bits to that subdir. A following commit will update
all references like `from sos.plugins` to `from sos.report.plugins`.

Related: sosreport#1986

Signed-off-by: Jake Hunsaker <[email protected]>

TurboTurtle added a commit to TurboTurtle/sos that referenced this issue


          [4.0] Create new binary and define new entrypoints for subcommands

32ec680

This is the first patch to add a new `sos` binary to act as the new
commandline interface for users.

It adds the basic `SoS()` and `SoSComponent()` classes that will be
built out and used going forward for new subcommand development. Actual
functionality will be added in coming patches, as this is mainly serving
as a checkpoint to avoid over-large commits affecting wide swathes of
changes at once.

Related: sosreport#1986

Signed-off-by: Jake Hunsaker <[email protected]>

TurboTurtle added a commit to TurboTurtle/sos that referenced this issue


          [binary] Have legacy sosreport binary redirect to sos

aa36123

We need to carry a `sosreport` binary for some time to allow for end
users and downstreams to adjust to the new binary. It was hoped
originally that the old `sosreport` binary could be maintained in place
and simply provide the older set of functionality.

This has proven to not be possible givent he overhaul of the options
handling that allows us to have multiple subcommands. So while we will
still ship an `sosreport` binary, and it will be locked to `report`
functionality, it is now a simple redirection script that also makes the
user aware of the new `sos` binary.

Closes: sosreport#1986

Signed-off-by: Jake Hunsaker <[email protected]>

TurboTurtle added a commit to TurboTurtle/sos that referenced this issue


          [4.0] Re-organize tree for sos-4.0

dfcabc6

This is the beginning of the sos-4.0 design rework.

First, move the existing `sosreport` binary into a new top-level `bin`
dir. The future `sos` binary will also live here.

Second, create a `report` subdir within the `sos` module, and move the
relevant `sosreport` bits to that subdir. A following commit will update
all references like `from sos.plugins` to `from sos.report.plugins`.

Related: sosreport#1986

Signed-off-by: Jake Hunsaker <[email protected]>

TurboTurtle added a commit to TurboTurtle/sos that referenced this issue


          [4.0] Create new binary and define new entrypoints for subcommands

31b3c4a

This is the first patch to add a new `sos` binary to act as the new
commandline interface for users.

It adds the basic `SoS()` and `SoSComponent()` classes that will be
built out and used going forward for new subcommand development. Actual
functionality will be added in coming patches, as this is mainly serving
as a checkpoint to avoid over-large commits affecting wide swathes of
changes at once.

Related: sosreport#1986

Signed-off-by: Jake Hunsaker <[email protected]>

TurboTurtle added a commit to TurboTurtle/sos that referenced this issue


          [binary] Have legacy sosreport binary redirect to sos

d29d7a7

We need to carry a `sosreport` binary for some time to allow for end
users and downstreams to adjust to the new binary. It was hoped
originally that the old `sosreport` binary could be maintained in place
and simply provide the older set of functionality.

This has proven to not be possible givent he overhaul of the options
handling that allows us to have multiple subcommands. So while we will
still ship an `sosreport` binary, and it will be locked to `report`
functionality, it is now a simple redirection script that also makes the
user aware of the new `sos` binary.

Closes: sosreport#1986

Signed-off-by: Jake Hunsaker <[email protected]>

TurboTurtle closed this as completed in

afb4211

TurboTurtle added a commit that referenced this issue


          [binary] Have legacy sosreport binary redirect to sos

2b58a44

We need to carry a `sosreport` binary for some time to allow for end
users and downstreams to adjust to the new binary. It was hoped
originally that the old `sosreport` binary could be maintained in place
and simply provide the older set of functionality.

This has proven to not be possible givent he overhaul of the options
handling that allows us to have multiple subcommands. So while we will
still ship an `sosreport` binary, and it will be locked to `report`
functionality, it is now a simple redirection script that also makes the
user aware of the new `sos` binary.

Closes: #1986
Resolves: #1993

Signed-off-by: Jake Hunsaker <[email protected]>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment