Skip to content
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.

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

Add UDS support #2

Conversation

kang-makes
Copy link
Owner

Description:

Link to tracking Issue:

Testing:

Documentation:

Copy link

@sigilioso sigilioso left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

receiver/statsdreceiver/receiver_test.go Show resolved Hide resolved
receiver/statsdreceiver/transport/server_test.go Outdated Show resolved Hide resolved
receiver/statsdreceiver/transport/server_test.go Outdated Show resolved Hide resolved
Comment on lines 68 to 75
addr = &net.UnixAddr{
Net: "unixgram",
Name: "UDS",
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to include a comment explaining the hardcoded address value for unixgram address?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the beginning I agreed with you, but after checking the code, there are almost no if-else due to that difference

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw no way to check for the transport of PacketConn to not hardcode so I did it. I would like to know what upstream thinks about this.

Copy link

@paologallinaharbur paologallinaharbur Aug 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left my comment in the wrong conversation 🤦 it was meant to go below "Did you consider having two Server types udpServer and unixGramServer and creating one or the other depending on transport?"

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have the answer to that here: #2 (comment)

packetConn net.PacketConn
transport Transport
address string
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you consider having two Server types udpServer and unixGramServer and creating one or the other depending on transport?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because of the issue od addr being nil only when using a Unix socket I saw more difficult to have that part separated than having everything on the same file.

"testing"
)

func CreateTemporarySocket(t testing.TB, _ string) string {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we have the second argument if we ignore it?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't easier to have a fixed name if tempDir() is always changing?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or you can leverage createTemp https://pkg.go.dev/os#CreateTemp

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the signature has to be compatible with https://github.com/kang-makes/opentelemetry-collector-contrib/blob/receiver/statsdreceiver/add-uds-support-part-2/internal/common/testutil/testutil.go#L35

I also used t.TempDir() because the testing suite cleans all files after finishing tests so we can keep the house clean :)

Comment on lines 49 to 56
unixAddr, err := net.ResolveUnixAddr(s.transport, s.address)
if err != nil {
return err
}
s.Conn, err = net.DialUnix(s.transport, nil, unixAddr)
if err != nil {
return err
}
Copy link

@paologallinaharbur paologallinaharbur Aug 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would have two functions:

  • connectUDP (including two methods above)
  • connectUnixgram(including two methods below)

so that this one becomes more readable. Moreover I would wrap errors


// Returns true if the transport is unix socket based.
func (trans Transport) IsUnixTransport() bool {
switch trans {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT isn't the switch an overkill?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return trans == UnixGram maybe?

Copy link
Owner Author

@kang-makes kang-makes Aug 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are missing protocols that can appear like unix, unixgram... I kept the same structure for all functions.

var _ (Server) = (*packetServer)(nil)

// NewPacketServer creates a transport.Server using transports based on packets.
func NewPacketServer(transport Transport, address string) (Server, error) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is address still the right term?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. I had issues finding new wording that covers an IP address and a socket path... socket address sounds good to me but I am open to suggestions.

Comment on lines 80 to 94
var netErr net.Error
reporter.OnDebugf("%s Transport (%s) - ReadFrom error: %v", psrv.transport, psrv.packetConn.LocalAddr(), err)
if errors.As(err, &netErr) {
if netErr.Timeout() {
continue
}
}
return err

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would make senso to have handleError as we have handlePacket?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has exactly the same structure as the receiver had before my refactor. If you do not go commit by commit you'll see a whole new file but if you do you see that I did not make any change on that part.

Copy link

@paologallinaharbur paologallinaharbur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just nits, ignore what you do not agree with! 😄

@kang-makes kang-makes force-pushed the receiver/statsdreceiver/add-uds-support-part-2 branch 3 times, most recently from 03a724e to 107114b Compare August 3, 2023 13:34
@kang-makes kang-makes force-pushed the receiver/statsdreceiver/add-uds-support branch from 59faed9 to 7094a68 Compare August 21, 2023 10:52
@kang-makes kang-makes force-pushed the receiver/statsdreceiver/add-uds-support branch from 7094a68 to e4f8238 Compare August 22, 2023 09:40
@kang-makes kang-makes force-pushed the receiver/statsdreceiver/add-uds-support-part-2 branch from 107114b to 4ae630e Compare August 22, 2023 12:54
@kang-makes kang-makes force-pushed the receiver/statsdreceiver/add-uds-support-part-2 branch from 4ae630e to 116da7b Compare August 22, 2023 12:59
@kang-makes kang-makes force-pushed the receiver/statsdreceiver/add-uds-support branch from e4f8238 to 4fa23ed Compare September 7, 2023 13:46
@kang-makes kang-makes force-pushed the receiver/statsdreceiver/add-uds-support branch 4 times, most recently from c6f0e45 to 7b39dc2 Compare November 6, 2023 08:30
@kang-makes kang-makes force-pushed the receiver/statsdreceiver/add-uds-support branch from 7b39dc2 to 892ed4f Compare November 6, 2023 09:27
@kang-makes kang-makes force-pushed the receiver/statsdreceiver/add-uds-support branch 2 times, most recently from 7965808 to 51be5d3 Compare November 21, 2023 10:43
bogdandrutu pushed a commit to open-telemetry/opentelemetry-collector-contrib that referenced this pull request Dec 15, 2023
**Description:** 
This is the first step to adding UDS support to the StatsD receiver.

As I started to develop it, I saw that all tests were hardcoded to UDP
and using networking and there was no possibility to add a socket
communication.

PR started to get huge so I split it into two, one to refactor tests and
another one that adds UDS support:
 * Removed all unused references.
* Made a `Transport` helper that allows centralizing all supported
protocols and constants in its package.
* Removed all hardcoded UDP protocols and generalized testing so new
protocols are easy to add.

If you need a rationale about why the changes are like this, this is the
next PR I am going to submit after this one is merged:
kang-makes#2

That is the PR that is going to add UDS support properly.

**Link to tracking Issue:**
 - #21385

**Previous closed PR:**
 - #24832
cparkins pushed a commit to AmadeusITGroup/opentelemetry-collector-contrib that referenced this pull request Jan 10, 2024
…28896)

**Description:** 
This is the first step to adding UDS support to the StatsD receiver.

As I started to develop it, I saw that all tests were hardcoded to UDP
and using networking and there was no possibility to add a socket
communication.

PR started to get huge so I split it into two, one to refactor tests and
another one that adds UDS support:
 * Removed all unused references.
* Made a `Transport` helper that allows centralizing all supported
protocols and constants in its package.
* Removed all hardcoded UDP protocols and generalized testing so new
protocols are easy to add.

If you need a rationale about why the changes are like this, this is the
next PR I am going to submit after this one is merged:
kang-makes#2

That is the PR that is going to add UDS support properly.

**Link to tracking Issue:**
 - open-telemetry#21385

**Previous closed PR:**
 - open-telemetry#24832
@jcogilvie
Copy link

Any chance this can get PR'd upstream?

@kang-makes
Copy link
Owner Author

Hi @jcogilvie,

The PR is stale. At the time I wrote this, tests were coupled and had hardcoded responeses that needed a refactor before this one. Hence #1

The refactor for tests was asked upstream (open-telemetry#24832), it was rebased 3 times and completely ignored even after going to the collector meetings begging for this to be merged.

The collector moved in this year and the PR need a full refactor from scratch (again). I am done with this and I will not work on this anymore.

Closing.

@kang-makes kang-makes closed this Dec 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants