From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mail.openembedded.org (Postfix) with ESMTP id 0F3CE771CB for ; Mon, 22 Feb 2016 16:36:40 +0000 (UTC) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP; 22 Feb 2016 08:36:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,485,1449561600"; d="scan'208";a="891847121" Received: from bitbang.jf.intel.com (HELO [10.7.199.163]) ([10.7.199.163]) by orsmga001.jf.intel.com with ESMTP; 22 Feb 2016 08:36:41 -0800 To: =?UTF-8?B?QW7DrWJhbCBMaW3Ds24=?= , openembedded-core@lists.openembedded.org References: <64384d8bd09f15c666f133893c3beb96e66af51d.1456153260.git.anibal.limon@linux.intel.com> <56CB34E8.6060203@linux.intel.com> <56CB36C3.2080609@linux.intel.com> From: Randy Witt Message-ID: <56CB3918.7060503@linux.intel.com> Date: Mon, 22 Feb 2016 08:36:40 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56CB36C3.2080609@linux.intel.com> Cc: paul.eggleton@linux.intel.com, =?UTF-8?B?QW7DrWJhbCBMaW3Ds24=?= Subject: Re: [PATCH 4/4] oeqa/sdkext: Add sdk_update.SDKUpdateTest class. X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 16:36:43 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 >>> >>> 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 >>> --- >>> 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. >> >> 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. > >> >>> + 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) >>> >> >