Support hostnames in project spc#1243
Conversation
grafnu
left a comment
grafnu
left a comment
There was a problem hiding this comment.
Is there some change you can make in tests/ (tests/sites/?) that exemplifies this change? It looks like you'l allowing a . in a name... that's somewhat dangerous. I'd like to fully understand exactly where that ends up (and why maybe) -- and the best way to do that is with an example!
|
This was so I could connect to a remote MQTT endpoint e.g. I do have this error from validator: So it looks like there might be more to it than just this change. Will come back with fixes and test cases. |
|
@noursaidi At present, when using MQTT as the iotProvider, support is limited to localhost as documented in the project_spec.md. |
|
There's already a hostname field in the endpoint definition, I'm not sure
if this is something different... ?
"reflector_endpoint": {
"client_id":
"projects/bos-platform-prod/locations/us-central1/registries/UDMI-REFLECT/devices/US-NYC-9TH",
"hostname": "mqtt.bos.goog",
"protocol": "mqtt"
},
…On Fri, Mar 13, 2026 at 3:01 AM Nitish Jain ***@***.***> wrote:
*jainrocks* left a comment (faucetsdn/udmi#1243)
<#1243 (comment)>
@noursaidi <https://github.com/noursaidi> At present, when using MQTT as
the iotProvider, support is limited to localhost as documented in the
project_spec.md
<https://github.com/faucetsdn/udmi/blob/master/docs/tools/project_spec.md>
.
To address this, we likely need to change the envelope schema
<https://github.com/faucetsdn/udmi/blob/master/schema/envelope.json#L26>.
Regarding the implementation, instead of continuing to use project_id as
the hostname (per MqttPublisher.java
<https://github.com/faucetsdn/udmi/blob/master/validator/src/main/java/com/google/bos/iot/core/proxy/MqttPublisher.java#L194>),
should we introduce a hostname query parameter? This would allow a specific
hostname to be used when provided, while still defaulting to project_id
(localhost) if it is absent.
—
Reply to this email directly, view it on GitHub
<#1243 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIEPD2R73UTLNP2XRPYVAD4QPL5XAVCNFSM6AAAAACWOHTX3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANJTHE4DAOBWGY>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
|
This is is specifically for invoking from the command line e.g. What is the problem with full stops in this scenario? This is no longer a blocker for me because it was primarily for testing and I've progressed beyond it, but I do think it's necessary to allow a non localhost MQTT broker |
|
The problem was that at the point of the change I couldn't tell what it
was! It makes more sense with your explanation. And yes, it's something we
do need to support. I don't think there was an example of where it was used
in the PR so I couldn't piece it all together.
…On Sat, Apr 4, 2026 at 10:10 AM Noureddine ***@***.***> wrote:
*noursaidi* left a comment (faucetsdn/udmi#1243)
<#1243 (comment)>
This is is specifically for invoking from the command line e.g. bin/registrar
//mqtt/example.mosquitto.com which is not permitted. The tools then build
the configuration object.
What is the problem with full stops in this scenario?
This is no longer a blocker for me because it was primarily for testing
and I've progressed beyond it, but I do think it's necessary to allow a non
localhost MQTT broker
—
Reply to this email directly, view it on GitHub
<#1243 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIEPD6HGLHQUDQCGD3NNHT4UE6ZTAVCNFSM6AAAAACWOHTX3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOBXGQZDOOJQGM>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
3 participants
No description provided.