-
Notifications
You must be signed in to change notification settings - Fork 68
Expose the Progress interface through the HTTP/JSON API #1092
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
Conversation
3586de9 to
9dbdc28
Compare
| "org.opensuse.Agama.Software1", | ||
| "/org/opensuse/Agama/Software1", | ||
| ) | ||
| .await, |
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.
well, tokio explicitelly mention to not do multiple merge. See documentation at https://dtantsur.github.io/rust-openstack/tokio/stream/trait.StreamExt.html#method.merge
They suggest to use StreamMap for such case https://docs.rs/tokio-stream/latest/tokio_stream/struct.StreamMap.html
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.
Yes, I want to search for an alternative. Thanks for the hint, I skipped that part of the docs 😉. The StreamMap looks good enough. I was also checking the StreamExt of the futures crate.
rust/agama-server/src/web/common.rs
Outdated
|
|
||
| async fn progress(State(state): State<ProgressState<'_>>) -> Json<Progress> { | ||
| let proxy = state.proxy; | ||
| let progress = Progress::from_proxy(&proxy).await.unwrap(); |
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.
so it should crash when there is issue with dbus? I think that having some error status would be nicer.
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.
Yes, sure, it is just a draft. There are a couple of unwraps here and there.
| ) -> Result<ProgressProxy<'a>, zbus::Error> { | ||
| let proxy = ProgressProxy::builder(&dbus) | ||
| .destination(destination.to_string())? | ||
| .path(path.to_string())? |
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 am not sure if there is advantage of using &str when you inside always needs to create new string. If you have String in method call already, then it can be passed or created outside and just passed.
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.
Well, using &str in the boundaries looks more flexible to me. And, after all, from outside you do not need to know what is going to happen inside. But yes, I could reconsider it.
| ServiceStatusChanged { | ||
| service: String, | ||
| status: u32, | ||
| }, |
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 expect that they usually come together that Busy and ServiceStatus change?
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.
They are different things: one is the list of busy services, which is only kept by the Manager. The ServiceStatusChanged belongs to each separate service. However, I am thinking that perhaps we are not interested in the BusyServicesChanged event from the web UI. I will check.
9a7046e to
e234b29
Compare
* It is replaced by the ProgressStream.
e234b29 to
859617b
Compare
jreidinger
left a comment
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.
LGTM
Adapt the `WithProgress` to the HTTP-based implementation of the D-Bus progress interface (#1092).
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
Trello: https://trello.com/c/2RvcZBFR/3564-5-expose-the-progress-api-over-http
This PR exposes the
ProgressAPI for the Manager and Software services through the HTTP/JSON interface. It is implemented as a pair of functions that can be reused in all services that want to implement such an interface.A
/SERVICE/progressendpointThe
progress_routerfunction allows to add a/SERVICE/progressroute that exposes the current progress:{ "current_step": 4, "max_steps": 4, "current_title": "Calculating the software proposal", "finished": false }The events stream
The
progress_streambuilds an events stream that emits a new event when thecurrent_stepchanges:{ "type": "Progress", "service": "org.opensuse.Agama.Software1", "current_step": 4, "max_steps": 4, "current_title": "Calculating the software proposal", "finished": false }Enabling
ServiceStatusandProgressfor the Software serviceAdditionally, the PR enables the
ServiceStatus(implemented #1089) and theProgressfor the Software service too.