-
Notifications
You must be signed in to change notification settings - Fork 44
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
Expose the networking API over HTTP #1064
Conversation
8d04750
to
349f6ee
Compare
1f47214
to
2ce4047
Compare
2ce4047
to
d7b3133
Compare
d7b3133
to
2dcc8df
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.
In general, it looks good. The only thing I am not convinced of is to expose the internal model directly. Perhaps we should convert the objects to a *Settings
object, as we already discussed offline.
Yep, I'm also not convinced about it but as a POC it was good enough. |
7d5698c
to
eee87a5
Compare
4ea2a52
to
f550483
Compare
f550483
to
af3ce48
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.
Great work! However, I have some comments (as usual) :-) I have not finished the review yet, but you can start looking into the suggestions.
@@ -21,11 +21,18 @@ pub enum Action { | |||
DeviceType, | |||
Responder<Result<OwnedObjectPath, NetworkStateError>>, | |||
), | |||
/// Gets a connection | |||
/// Add a new connection | |||
NewConnection( |
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.
To be consistent, it should be named AddConnection
. I know it collides with the AddConnection
action for the D-Bus part, but perhaps it is time to start dropping them. But we can handle that in a separate PR.
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 planned to add this new method, but at the end used the AddConnection + UpdateConnection, but as you commented maybe it is the time to remove them and any DBUS specific action.
GetConnectionPath(Uuid, Responder<Option<OwnedObjectPath>>), | ||
/// Gets a connection | ||
/// Gets a connection path by id |
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.
Another candidate to drop :-)
@@ -130,6 +130,10 @@ impl Tree { | |||
self.objects.devices_paths() | |||
} | |||
|
|||
pub fn device_path(&self, name: &str) -> Option<OwnedObjectPath> { |
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 do not think we want to evolve the D-Bus interface even more. We should be dropping most of it (and just keeping the signals).
|
||
state | ||
.actions | ||
.send(Action::AddConnection( |
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.
IMHO we should remove the need of having separate actions (AddConnection
and UpdateConnection
).
5a25072
to
9506e1f
Compare
After a few months of work, it is time to merge the `architecture_2024` branch into `master`. It is still a work-in-progress, but all the efforts should be go now against that branch. ## Pull requests * #1061 * #1064 * #1073 * #1074 * #1080 * #1089 * #1091 * #1092 * #1094 * #1095 * #1099 * #1100 * #1102 * #1103 * #1112 * #1114 * #1116 * #1117 * #1119 * #1120 * #1123 * #1126 * #1129 * #1130 * #1131 * #1132 * #1133 * #1134 * #1136 * #1139 * #1140 * #1143 * #1146 ## Other commits * 8efa41f * 9e2dec0
Prepare for releasing Agama 8. It includes the following pull requests: * #884 * #886 * #914 * #918 * #956 * #957 * #958 * #959 * #960 * #961 * #962 * #963 * #964 * #965 * #966 * #969 * #970 * #976 * #977 * #978 * #979 * #980 * #981 * #983 * #984 * #985 * #986 * #988 * #991 * #992 * #995 * #996 * #997 * #999 * #1003 * #1004 * #1006 * #1007 * #1008 * #1009 * #1010 * #1011 * #1012 * #1014 * #1015 * #1016 * #1017 * #1020 * #1022 * #1023 * #1024 * #1025 * #1027 * #1028 * #1029 * #1030 * #1031 * #1032 * #1033 * #1034 * #1035 * #1036 * #1038 * #1039 * #1041 * #1042 * #1043 * #1045 * #1046 * #1047 * #1048 * #1052 * #1054 * #1056 * #1057 * #1060 * #1061 * #1062 * #1063 * #1064 * #1066 * #1067 * #1068 * #1069 * #1071 * #1072 * #1073 * #1074 * #1075 * #1079 * #1080 * #1081 * #1082 * #1085 * #1086 * #1087 * #1088 * #1089 * #1090 * #1091 * #1092 * #1093 * #1094 * #1095 * #1096 * #1097 * #1098 * #1099 * #1100 * #1102 * #1103 * #1104 * #1105 * #1106 * #1109 * #1110 * #1111 * #1112 * #1114 * #1116 * #1117 * #1118 * #1119 * #1120 * #1121 * #1122 * #1123 * #1125 * #1126 * #1127 * #1128 * #1129 * #1130 * #1131 * #1132 * #1133 * #1134 * #1135 * #1136 * #1138 * #1139 * #1140 * #1141 * #1142 * #1143 * #1144 * #1145 * #1146 * #1147 * #1148 * #1149 * #1151 * #1152 * #1153 * #1154 * #1155 * #1156 * #1157 * #1158 * #1160 * #1161 * #1162 * #1163 * #1164 * #1165 * #1166 * #1167 * #1168 * #1169 * #1170 * #1171 * #1172 * #1173 * #1174 * #1175 * #1177 * #1178 * #1180 * #1181 * #1182 * #1183 * #1184 * #1185 * #1187 * #1188 * #1189 * #1190 * #1191 * #1192 * #1193 * #1194 * #1195 * #1196 * #1198 * #1199 * #1200 * #1201 * #1203 * #1204 * #1205 * #1206 * #1207 * #1208 * #1209 * #1210 * #1211 * #1212 * #1213 * #1214 * #1215 * #1216 * #1217 * #1219 * #1220 * #1221 * #1222 * #1223 * #1224 * #1225 * #1226 * #1227 * #1229
Implementation PBI description
In the previous PBI we documented a possible API and also created a POC but it just allowed to query some configuration, so we have extended the PR with the API implementation
Implemented Network API
Resource /network/state
Request example
Request example
Resource /network/devices
Request example
Resource /network/connections
Request example
** Request example **
/network/connections/:id
The attributes for updating a connection or creating a new one could follow the same schema used for the profile:
Which means that for bringing up or down an specific connection / device could need an specific method or it could be handle as any other attribute.
Resource /network/wifi
Request example
Resource /network/system/apply
Request example
Testing
Tested manually
Documentation PBI description
Problem
We would like to expose the Networking API over http which is currently not available.
Solution
Document an HTTP alternative as well as provide a POC exposing it.
API Design
Our Rest API could expose the general state and configuration of the network as well as the devices and connections resources below the network namespace as shown below:
Resource /network/state
Resource /network/config
Resource /network/devices
/network/devices/:name
Request example
Resource /network/connections
Request example
/network/connections/:id
The attributes for updating a connection or creating a new one could follow the same schema used for the profile:
Which means that for bringing up or down an specific connection / device could need an specific method or it could be handle as any other attribute.
Resource /network/wifi_networks
Note: Which attributes should be required and exposed needs to be discussed, and probably we should expose the persistent and running configuration maybe as part of the same resource or separately.
Example of the OpenAPI generated documentation based on the implemented POC code
Signals / Websocket notifications
With websockets we can carry more information than what is usually emitted over DBUS therefore we could subscribe to DBUS signals in the backend for the different resources submitting more information over the websocket, for example for any new device connected or any change in a connection property but have not gone over what to notify so far as we are not subscribing to signals in the backend at all and we are only sending when a connections has been added or removed.
Testing
Tested manually