Apply suggestions from code review

Co-authored-by: shadeofblue <[email protected]>

examples/simple-service-poc/simple_service.py

@@ -59,8 +59,8 @@ async def get_payload():
 
     async def start(self):
         # handler responsible for starting the service
-        self._ctx.deploy()
-        self._ctx.start()
+        async for script in super().start():
+            yield script
         self._ctx.run(self.SIMPLE_SERVICE_CTL, "--start")
         yield self._ctx.commit()
 

tests/goth_tests/test_instance_restart/requestor.py

@@ -39,8 +39,8 @@ async def start(self):
 
         global instances_started
 
-        self._ctx.deploy()
-        self._ctx.start()
+        async for script in super().start():
+            yield script
 
         self._ctx.run("/bin/echo", "STARTING", str(instances_started + 1))
         future_results = yield self._ctx.commit()

yapapi/services.py

@@ -291,11 +291,11 @@ async def start(self):
 
         Therefore, this default implementation performs the minimum required for a VM payload to
         start responding to `run` commands. If your service requires any additional operations -
-        you'll need to override this method (possibly starting with yielding everything yielded by
-        `super().start()`) to add appropriate preparatory steps.
+        you'll need to override this method (possibly first yielding from the parent - `super().start()` - generator ) 
+        to add appropriate preparatory steps.
 
         In case of runtimes other than VM, `deploy` and/or `start` might be optional or altogether
-        disallowed, plus `deploy`/`start` itself might take some parameters. It is up to the author of the
+        disallowed, plus `deploy`/`start` themselves may take some parameters. It is up to the author of the
         specific `Service` implementation that uses such a payload to adjust this method accordingly
         based on the requirements for the given runtime/exe-unit type.
         """