Merge lp:~canonical-platform-qa/ubuntu-ota-tests/check-for-running-service into lp:ubuntu-ota-tests
| Status: | Merged |
|---|---|
| Approved by: | Christopher Lee on 2015-03-10 |
| Approved revision: | 12 |
| Merged at revision: | 3 |
| Proposed branch: | lp:~canonical-platform-qa/ubuntu-ota-tests/check-for-running-service |
| Merge into: | lp:ubuntu-ota-tests |
| Diff against target: |
212 lines (+183/-2) 5 files modified
debian/tests/control (+4/-2) debian/tests/ubuntu_ota_tests/__init__.py (+27/-0) debian/tests/ubuntu_ota_tests/selftests/test_services.py (+32/-0) debian/tests/ubuntu_ota_tests/services.py (+86/-0) debian/tests/ubuntu_ota_tests/system.py (+34/-0) |
| To merge this branch: | bzr merge lp:~canonical-platform-qa/ubuntu-ota-tests/check-for-running-service |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| PS Jenkins bot | continuous-integration | Approve on 2015-03-10 | |
| Christopher Lee (community) | Approve on 2015-03-10 | ||
| Leo Arias (community) | 2015-03-06 | Approve on 2015-03-10 | |
| Barry Warsaw (community) | Needs Fixing on 2015-03-09 | ||
|
Review via email:
|
|||
Commit Message
Add script for ensuring the system-image-dbus process is not running.
Description of the Change
Add script for ensuring the system-image-dbus process is not running.
Perhaps there is a better way to have the support scripts instead of in the d/tests/ dir. SHould they instead be packaged up in ubuntu-ota-tests so that they can be consumed outside of the dep8 tests?
Also, note that the is a simple workable case in revno 4 where it just catches the dbus exception, I added the use of checking for the running of the process (check with psutil) but that adds a Depends: python3-psutil meaning the test setup will take a little longer.
Also, also :-) I don't think the test that I have there will stay, it's purely there as a stand-in for now.
| Barry Warsaw (barry) wrote : | # |
Oh also, re: packaging. Yes, they probably should live outside the debian/tests directory, i.e. get installed into the system Python 3's dist-packages like a normal Python 3 package. That's a little more work though, so I think we can refactor that in later.
- 6. By Christopher Lee on 2015-03-10
-
Tidy up use of list comprehension.
- 7. By Christopher Lee on 2015-03-10
-
Add timed check to ensure process has actually stopped, adds depends on autopilot though.
- 8. By Christopher Lee on 2015-03-10
-
Use global for process name
- 9. By Christopher Lee on 2015-03-10
-
Rename loop method
| Christopher Lee (veebers) wrote : | # |
Thanks Barry I've made the suggested changes.
I came across an issue today where the example test would fail due to the process not being exited right at that moment. As a fix I'm using some functionality from autopilot, but I'm concerned by this for som ereasons:
1. This pulls in autopilot as a dep. Not sure if we want to do that for the core parts of the scripts.
2. There may be a better way to resolve the issue I use ap for.
I agree re: the packaging, we can iterate over it this week. We need to get the base code down so we can continue.
I'll take a closer look at what systemimage provides. Are you suggesting that there is code there already I can use in this instance?
| Leo Arias (elopio) wrote : | # |
I moved the selftest to a directory, and made it a test case so we get nice results out of it.
| Leo Arias (elopio) wrote : | # |
When using 3.0 from barry's branch, the test fails with:
Traceback (most recent call last):
File "/usr/lib/
return self.get_
File "/usr/lib/
's', (bus_name,), **keywords)
File "/usr/lib/
message, timeout)
dbus.exceptions
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/tmp/adt-
services.
File "/tmp/adt-
service = system_
File "/usr/lib/
follow_
File "/usr/lib/
self.
File "/usr/lib/
self.
File "/usr/lib/
'su', (bus_name, flags)))
File "/usr/lib/
message, timeout)
dbus.exceptions
-------
| Federico Gimenez (fgimenez) wrote : | # |
One inline comment, I think also that we should describe a bit in the README the layout that we have decided for the project in order to make it more understandable: if we are not building any debian package, why is the source code under debian/tests? It seems that you must know about autopkgtest to understand where to find things, the layout seems to be conditioned by the tool used to run the tests.
Cheers!
| Leo Arias (elopio) wrote : | # |
Now the tests are passing for me. Weird because I didn't change anything, just reflashed. Maybe my phone was broken before.
| Barry Warsaw (barry) wrote : | # |
On Mar 10, 2015, at 03:42 AM, Christopher Lee wrote:
>I came across an issue today where the example test would fail due to the
>process not being exited right at that moment. As a fix I'm using some
>functionality from autopilot, but I'm concerned by this for som ereasons:
Yeah, D-Bus is notoriously unreliable for tests like this. It's a source of
constant sorrow for getting system-image built in a PPA. I'm now testing some
new techniques using the org.freedesktop
things but it's not perfect. There are still opportunities for race
conditions, and I suspect they're just inherent in D-Bus.
>1. This pulls in autopilot as a dep. Not sure if we want to do that for the
>core parts of the scripts.
I say "whatever works" :)
>2. There may be a better way to resolve the issue I use ap for.
Here's what I'm using now:
bus = dbus.SystemBus()
service = dbus.SystemBus(
iface = dbus.Interface(
reply = 0
# 2015-03-09 BAW: This could potentially spin forever, but we'll assume
# D-Bus eventually is successful in starting the service.
while reply != 2:
reply = iface.StartServ
`reply` could be 1 or 2. 1 means it's started but 2 means it's already
running, which is why I wait for that.
| Barry Warsaw (barry) wrote : | # |
On Mar 10, 2015, at 09:18 AM, Federico Gimenez wrote:
>> +def ensure_
>> + global _loop_running
>
>This global variable and the need for the client code of this module to know
>how it works internally (it has to request first a interface and later pass
>that object to the module methods) makes me wonder if we should use better a
>class here, it seems that the design would be more suited to the task.
I have a somewhat different approach in my branch. We'll need to decide which
way we want to go.
| Barry Warsaw (barry) wrote : | # |
On Mar 10, 2015, at 06:37 AM, Leo Arias wrote:
>When using 3.0 from barry's branch, the test fails with:
I can't tell you what's causing the NoMember error. As best I've been able to
determine, the NameHasNoOwner error occurs when the process
(system-image-dbus) associated with the name (com.canonical.
hasn't yet started. See my previous comment for a new approach I'm trying to
take, which works locally, although the proof will be in the PPA pudding.
| Leo Arias (elopio) wrote : | # |
This is good for me, lets use it as a bootstrap and improve things as we find them.

Comments inline.
I like the way you've created a package for utilities to live in. We should definitely do that. Also, I think it's perfectly fine to import things from the systemimage package. There's a lot of useful utilities there, such as systemimage. reactor. Reactor, and since this is the SUT, I think it's perfectly acceptable to use them when appropriate.
(Note, in the case where you locate the system-image-dbus process, si has a similar utility, but it's semantics are somewhat different, so it's not a perfect fit.)