-
Notifications
You must be signed in to change notification settings - Fork 316
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
Initial protobufs for events #6344
Conversation
Thanks for the pull request! Here is what will happen next:
Thank you for contributing! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good to me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Just some small thoughts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General format of the protobufs looks good. If proto3 is equally supported in rust then I'd like to switch to it; if not then we can deal.
f063765
to
6d1897c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
5e810e3
to
cbce5f4
Compare
22bc8ea
to
f3a4af4
Compare
2eb56d7
to
40f44cc
Compare
69ce79a
to
ad65d61
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not finished, but wanted to commit some of my feedback before leaving so you can see it earlier on Monday.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still not quite done; this is a lot of code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm finished with my initial review pass. Let me know when you're happy with everything and I can give it another look for approval.
278f33d
to
2e11c8f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two little tweaks; overall looks really great
Signed-off-by: Christopher Maier <cmaier@chef.io>
Signed-off-by: Christopher Maier <cmaier@chef.io>
Signed-off-by: Christopher Maier <cmaier@chef.io>
Signed-off-by: Christopher Maier <cmaier@chef.io>
Signed-off-by: Christopher Maier <cmaier@chef.io>
See #6555 instead. Signed-off-by: Christopher Maier <cmaier@chef.io>
Signed-off-by: Christopher Maier <cmaier@chef.io>
Signed-off-by: Christopher Maier <cmaier@chef.io>
Signed-off-by: Christopher Maier <cmaier@chef.io>
Signed-off-by: Christopher Maier <cmaier@chef.io>
Looks like it's having trouble properly formatting deeply-nested / chained futures. Signed-off-by: Christopher Maier <cmaier@chef.io>
Signed-off-by: Christopher Maier <cmaier@chef.io>
Naming is hard Signed-off-by: Christopher Maier <cmaier@chef.io>
Signed-off-by: Christopher Maier <cmaier@chef.io>
Until such time as we decide to remove it, that is. Signed-off-by: Christopher Maier <cmaier@chef.io>
Signed-off-by: Christopher Maier <cmaier@chef.io>
More self-describing this way. Signed-off-by: Christopher Maier <cmaier@chef.io>
Looks like `path` attributes are invisible to rustfmt: - rust-lang/rustfmt#1208 - rust-lang/rustfmt#2407 Ideally, it would be nice to not use the `path` attribute at all, and we can actually formulate this in a way that doesn't use `path`, but it seems to involve a lot more repetition. It's not at all clear that that's a win here, particularly given that we're only going to have two implementations for a short period of time. Signed-off-by: Christopher Maier <cmaier@chef.io>
From the [`hostname` man page](https://www.systutorials.com/docs/linux/man/1-hostname/): >The FQDN (Fully Qualified Domain Name) of the system is the name that the resolver(3) returns for the host name, such as, **ursula.example.com**. It is usually the hostname followed by the DNS domain name (the part after the first dot). You can check the FQDN using `hostname --fqdn` or the domain name using `dnsdomainname`. As the man page says it, the FQDN is the combination of the Hostname and the Domain Name. But technically speaking: >The FQDN is the name getaddrinfo(3) returns for the host name returned by gethostname(2). The DNS domain name is the part after the first dot. This change is adding two new `core::os::net` functions: - `lookup_fqdn(hostname)`: returns a vector of fqdn that resolves the provided hostname. - `fqdn()`: returns the FQDN (fully qualified domain name) of the running machine. These functions are leveraging the [dns-lookup crate](https://docs.rs/dns-lookup/1.0.0/dns_lookup/index.html) that implements the C function called `getaddrinfo()` that we technically need to get FQDN of the running machine. Habitat already have a function that returns the hostname of the machine[ called `hostname()`](https://github.com/habitat-sh/habitat/blob/master/components/core/src/os/net/windows.rs#L22), we are leveraging that function inside the new `fqdn()` one. I have created an issue #6531 to explore the possibility of refactoring the existing `hostname()` function in favor of `dns_lookup::lookup_host()` Signed-off-by: Salim Afiune <afiune@chef.io>
Signed-off-by: Christopher Maier <cmaier@chef.io>
Signed-off-by: Christopher Maier <cmaier@chef.io>
The user will be able to set this parameter through an environment variable or an option in the habitat CLI, just as you will be able to do with application and environment. Signed-off-by: Salim Afiune <afiune@chef.io>
Signed-off-by: Salim Afiune <afiune@chef.io>
Signed-off-by: Salim Afiune <afiune@chef.io>
Signed-off-by: Salim Afiune <afiune@chef.io>
fc8f02f
to
74d7189
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Obvious fix; these changes are the result of automation not creative thinking.
Rather than the ad-hoc string serialization used for the prototype,
we'll begin to evolve a Protobuf-based encoding for our events.
The current thinking is that all events will have a "supervisor
metadata" field. Any events that pertain to services will have an
additional "service metadata" field. Any additional information will
be added as fields on the specific concrete event.
For creating events, we'll use a functional interface at the sites
where events are created. These functions then initialize the
protobuf-derived Rust types according to their arguments. When we go
to publish the events, we'll inject the (global) Supervisor metadata,
serialize the whole thing to bytes, and send them to NATS.
Signed-off-by: Christopher Maier cmaier@chef.io