Openembedded Core Discussions
 help / color / mirror / Atom feed
From: "Aníbal Limón" <anibal.limon@linux.intel.com>
To: Randy Witt <randy.e.witt@linux.intel.com>,
	openembedded-core@lists.openembedded.org
Cc: paul.eggleton@linux.intel.com, "Aníbal Limón" <limon.anibal@gmail.com>
Subject: Re: [PATCH 4/4] oeqa/sdkext: Add sdk_update.SDKUpdateTest class.
Date: Mon, 22 Feb 2016 11:10:00 -0600	[thread overview]
Message-ID: <56CB40E8.1000709@linux.intel.com> (raw)
In-Reply-To: <56CB3918.7060503@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 5034 bytes --]



On 02/22/2016 10:36 AM, Randy Witt wrote:
> On 02/22/2016 08:26 AM, Aníbal Limón wrote:
>>
>>
>> On 02/22/2016 10:18 AM, Randy Witt wrote:
>>> On 02/22/2016 07:03 AM, Aníbal Limón wrote:
>>>> From: Aníbal Limón <limon.anibal@gmail.com>
>>>>
>>>> The SDKUpdateTest class test devtool sdk-update mechanism inside
>>>> eSDK.
>>>>
>>>> The SDKUpdateTest class search for new sdk if not found uses
>>>> the main one then it publish the eSDK into known folder
>>>> inside work and it starts a web server for serve the eSDK.
>>>>
>>>> Finally it executes sdk-update over http, the local test is
>>>> commented due to bug [1].
>>>>
>>>> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=9043
>>>>
>>>> [YOCTO #9089]
>>>>
>>>> Signed-off-by: Aníbal Limón <limon.anibal@gmail.com>
>>>> ---
>>>>    meta/lib/oeqa/sdkext/sdk_update.py | 39
>>>> ++++++++++++++++++++++++++++++++++++++
>>>>    1 file changed, 39 insertions(+)
>>>>    create mode 100644 meta/lib/oeqa/sdkext/sdk_update.py
>>>>
>>>> diff --git a/meta/lib/oeqa/sdkext/sdk_update.py
>>>> b/meta/lib/oeqa/sdkext/sdk_update.py
>>>> new file mode 100644
>>>> index 0000000..16f5b10
>>>> --- /dev/null
>>>> +++ b/meta/lib/oeqa/sdkext/sdk_update.py
>>>> @@ -0,0 +1,39 @@
>>>> +import os
>>>> +import shutil
>>>> +import subprocess
>>>> +
>>>> +from oeqa.oetest import oeSDKExtTest
>>>> +from oeqa.utils.httpserver import HTTPService
>>>> +
>>>> +class SdkUpdateTest(oeSDKExtTest):
>>>> +
>>>> +    @classmethod
>>>> +    def setUpClass(self):
>>>> +        self.publish_dir = os.path.join(self.tc.sdktestdir,
>>>> 'esdk_publish')
>>>> +        if os.path.exists(self.publish_dir):
>>>> +            shutil.rmtree(self.publish_dir)
>>>> +        os.mkdir(self.publish_dir)
>>>> +
>>>> +        tcname_new = self.tc.d.expand(
>>>> +            "${SDK_DEPLOY}/${TOOLCHAINEXT_OUTPUTNAME}-new.sh")
>>>> +        if not os.path.exists(tcname_new):
>>>> +            tcname_new = self.tc.tcname
>>>> +
>>>> +        cmd = 'oe-publish-sdk %s %s' % (tcname_new, self.publish_dir)
>>>> +        subprocess.check_output(cmd, shell=True)
>>>> +
>>>> +        self.http_service = HTTPService(self.publish_dir)
>>>> +        self.http_service.start()
>>>
>>> I think Paul and I briefly mentioned it, but SimpleHTTPServer fails as
>>> an sstate mirror if enough fetchers run. We think it was because of a
>>> limit on the number of simultaneous connections. So I would expect this
>>> to fail for instance if all packages were updated.
>>
>> I tested running an update and didn't fail this implementation of
>> oeqa.utils open another process with multiprocessing for serve http only.
> 
> My suspicion is because nothing actually updated. And even if something
> updated, unless you hit the max connection limit when pulling from
> sstate_mirror it would be fine.

Not it was updated the first time didn't display Already up to date that
was the second time also i saw the connections from sdk-update to local
web server.

> 
>>>
>>> But really we shouldn't care too much about the sstate updating part,
>>> and more about the layer updating etc. Ideally this test would check to
>>> make sure the local sdk now matches the remote.
>>
>> I could add a test for the output that i saw displays "Already updated"
>> or what you mean about match?
> 
> devtool sdk-update will check the remote conf/sdk-conf-manifest to see
> if any configuration changed. So for instance the creator of the sdk
> could add new configuration variables, or even items to bblayers.conf.
> 
> If the sdk-conf-manifest is changed, the updater should pull down the
> new layer by pulling(cloning if that fails) layers/.git on the remote
> and moving the layers to the appropriate local location. It should also
> update the local configuration to match what is on the remote.
> 
> So if you get "Already up-to-date" nothing changed and nothing was
> updated. To test the updating, we need to make sure the configuration
> actually changes, and potentially even add another layer, then update,
> and then make sure the local sdk matches what we think it should based
> on the remote sdk we published.

Up comment,

That's the reason for search new esdk (suffix -new) in the code because
that is another task (AB task) to generate the new eSDK, this test
satisfy the requeriment for install the eSDK launch the webserver and
launch sdk-update tool over it.


> 
>>
>>>
>>>> +        self.http_url = "http://127.0.0.1:%d" % self.http_service.port
>>>> +
>>>> +    def test_sdk_update_http(self):
>>>> +        output = self._run("devtool sdk-update \"%s\"" %
>>>> self.http_url)
>>>> +
>>>> +#    def test_sdk_update_local(self):
>>>> +#        output = self._run("devtool sdk-update \"%s\"" %
>>>> self.publish_dir)
>>>> +
>>>> +    @classmethod
>>>> +    def tearDownClass(self):
>>>> +        self.http_service.stop()
>>>> +        shutil.rmtree(self.publish_dir)
>>>>
>>>
>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

      reply	other threads:[~2016-02-22 17:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-22 15:03 [PATCH 0/4] Add extensible SDK update test Aníbal Limón
2016-02-22 15:03 ` [PATCH 1/4] classes/testsdk: Move code for avoid PATHs to oeqa.utils Aníbal Limón
2016-02-22 15:03 ` [PATCH 2/4] classes/testsdk: Move the removal of bitbake PATH to eSDK context only Aníbal Limón
2016-02-22 15:54   ` Randy Witt
2016-02-22 16:09     ` Aníbal Limón
2016-02-22 16:23       ` Randy Witt
2016-02-22 16:37         ` Aníbal Limón
2016-02-22 16:48           ` Burton, Ross
2016-02-22 17:05             ` Aníbal Limón
2016-02-22 17:27               ` Randy Witt
2016-02-22 17:47                 ` Aníbal Limón
2016-02-22 18:04                   ` Aníbal Limón
2016-02-22 15:03 ` [PATCH 3/4] classes/testsdk: Pass tcname to SDK and SDKExt contexts Aníbal Limón
2016-02-22 15:03 ` [PATCH 4/4] oeqa/sdkext: Add sdk_update.SDKUpdateTest class Aníbal Limón
2016-02-22 16:18   ` Randy Witt
2016-02-22 16:26     ` Aníbal Limón
2016-02-22 16:36       ` Randy Witt
2016-02-22 17:10         ` Aníbal Limón [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56CB40E8.1000709@linux.intel.com \
    --to=anibal.limon@linux.intel.com \
    --cc=limon.anibal@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    --cc=randy.e.witt@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox