-
Notifications
You must be signed in to change notification settings - Fork 61
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1686 +/- ##
===========================================
- Coverage 78.26% 65.03% -13.23%
===========================================
Files 190 190
Lines 12756 15346 +2590
===========================================
- Hits 9983 9980 -3
- Misses 2773 5366 +2593
Continue to review full report at Codecov.
|
The LGTM failure looks pretty bogus to me; it failed because of a timeout fetching from the Ubuntu servers. I can't figure out how to retry it, though. |
If you log in, they have a "retry analysis" button. Just clicked it. |
81e1837
to
c890cf7
Compare
Thanks. I logged in and looked around but couldn't find it. Anyway, I just pushed another tiny commit, so it probably got retriggered by that, too. |
c890cf7
to
70df3f1
Compare
auto statement = db.prepareStatement<std::string, std::string, int>( | ||
"INSERT INTO misconfigured_ecus VALUES (?,?,?);", it->serial.ToString(), it->hardware_id.ToString(), | ||
static_cast<int>(it->state)); | ||
auto statement = db.prepareStatement<std::string>("SELECT count(*) FROM misconfigured_ecus WHERE serial = ?;", |
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.
We could get rid of the count and use INSERT OR REPLACE
here. serial
would be better off being a primary key instead of just "unique" but it should also work.
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.
We could get rid of the count and use
INSERT OR REPLACE
here.
Good point.
serial
would be better off being a primary key instead of just "unique" but it should also work.
True, but then I have to add a migration. Is that worth it?
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 think it should work without so probably not.
0cbc6bc
to
5201bf4
Compare
<< it->second->getHwId() << " not found in storage."; | ||
register_ecus = true; | ||
} else { | ||
found[static_cast<size_t>(std::distance(stored_ecu_serials.cbegin(), store_it))] = true; |
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.
found[static_cast<size_t>(std::distance(stored_ecu_serials.cbegin(), store_it))] = true; | |
found[store_it - stored_ecu_serials.cbegin()] = true; |
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.
Ah this code was just moved...
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.
Indeed, but I think I also wrote it originally. Can't remember why exactly I used std::distance
here. Do you see a good reason to prefer one over the other?
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.
oh oops I thought I answered earlier, must have missed the button.
So after reading some docs, I can't really see the difference but the substraction is shorter and seems clearer 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.
Fixed.
@@ -65,53 +64,11 @@ TEST(PrimarySecondaryReg, SecondariesMigration) { | |||
EXPECT_EQ(secs_info[0].type, "IP"); | |||
EXPECT_EQ(secs_info[0].extra, R"({"ip":"127.0.0.1","port":9061})"); | |||
} | |||
|
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.
What's the reason to remove this part of the test?
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 knew you were going to ask about that! Well, I spent a lot of time trying to get it to work, and then I realized it was testing something that we never tried to fix: it's migrating two Secondaries from the old storage layout to the new storage. In the actual migration code for that (in src/aktualizr_primary/secondary.cc
), it explicitly only does the migration for one Secondary. Previously, this test was doing something kind of strange. Now, this isn't allowed: we just reprovision the device with two Secondaries in this case. Migration doesn't really make sense here.
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.
Thanks! That's a satisfying reason.
5201bf4
to
b73bde3
Compare
I've added a fix for a somewhat obscure issue with trying to reregister Secondaries while an update is active. The backend will reject the registration, and the only resolution is to restore the previous Secodnary configuration, which was complicated by the fact that we'd already stored the new Secondary information. Now we wait to store it until registration is succesful. |
b73bde3
to
0e688c5
Compare
0e688c5
to
6b43af9
Compare
@lbonn Sorry, just blasted your review because I realized I'd broken the networking test without realizing it. Thankfully the fix was easy. :) |
Finally fixed all the tests. |
auto statement = db.prepareStatement<std::string, std::string, int>( | ||
"INSERT OR REPLACE INTO misconfigured_ecus VALUES (?,?,?);", ecu.serial.ToString(), ecu.hardware_id.ToString(), | ||
static_cast<int>(ecu.state)); | ||
if (statement.step() != SQLITE_DONE || sqlite3_changes(db.get()) != 1) { |
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 not sure it's worth checking sqlite3_changes
value here. My understanding was that it is only useful when you have WHERE
in your statement or something similar.
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.
Oops, that was lazy copying on my part, didn't even think about it. I'll double check but will probably remove it.
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.
Fixed. Not is it not necessary, but according to https://www.sqlite.org/c3ref/changes.html it doesn't even do anything for REPLACE
, so it would've caused a bug.
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.
That was my first impression as well, but it looks like while REPLACE
doesn't increment the counter, the subsequent INSERT
does. As I understood, REPLACE
does only the deleting part.
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.
Oh, I see. Well, I removed it anyway. :) Seems unnecessary.
Works for Virtual Secondaries, but still a work in progress for IP Secondaries. Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
Now they cover adding, remove, and replacing Secondary ECUs. Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
The logic for matching addresses to ECUs is not trivial, so it's worth being extra careful. Also test replacing an ECU that reuses the same address and port and that we correctly track an ECU that changes its address or port. Also note some the timeouts (and some ordering issues) that were necessary to get some of these tests to pass. These are more reasons why a proper connection manager would be nice to have; things like this really shouldn't be necessary. Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
We no longer track unregistered ECUs, since that is no longer a problem. Still dump anything in the database with that flag, just in case, but it shouldn't happen. Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
There's no real problem, just an ugly log message that will go away eventually on its own. Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
For device credential provisioning, it is still a fatal error if the cert is unavailable. For shared cred prov, we revert to the old behavior of generating a random pet name if the cert is unavailable. This is generally only observable if you attempt to replace a Primary ECU, which requires reusing the same device certificate. Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
The backend does not accept empty filenames, but we have to say something. This comes up if you wipe a Secondary's database but keep the image file. Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
If registration fails (due to the server complaining about an update in progress, for example), we want to make it easier to undo the changes and prevent re-registration. Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
6b43af9
to
d943cd9
Compare
Allow ECU re-registration to support adding, removing, and replacing Secondaries. Tested manually and with unit tests for virtual and IP Secondaries.