Re: [OpenStack-Infra] Merging feature/zuulv3 into master in Zuul and Nodepool repos
Clark Boylan writes: > Hello, > > I think we are very close to being ready to merge the zuulv3 feature > branch into master in both the Zuul and Nodepool repos. In particular > we merged https://review.openstack.org/#/c/523951/ which should > prevent breakages for anyone using that deployment method > (single_node_ci) for an all in one CI suite. > > One thing I've noticed is that we don't have this same handling in the > lower level individual service manifests. For us I don't think that is > a major issue, we'll just pin our builders to the nodepool 0.5.0 tag, > do the merge, then update our configs and switch back to master. But > do we have any idea if it is common for third part CI's to bypass > single_node_ci and construct their own like we do? > > As for the actual merging itself a quick test locally using `git merge > -s recursive -X theirs feature/zuulv3` on the master branch of > nodepool appears to work. I have to delete the files that the feature > branch deleted by hand but otherwise the merge is automated. The > resulting tree does also pass `tox -e pep8` and `tox -epy36` testing. > > We will probably want a soft freeze of both Zuul and Nodepool then do > our best to get both merged together so that we don't have to remember > which project has merged and which hasn't. Once that is done we will > need to repropose any open changes on the feature branch to the master > branch, abandon the changes on the feature branch then delete the > feature branch. Might be a good idea to merge as many feature branch > changes as possible before hand? > > Am I missing anything? > > Thank you, > Clark Thanks for looking into that! I don't think we're in a great position to merge a lot of the outstanding changes on the feature branch -- many of them are post 3.0 things and I don't want to distract us from stabilizing and finalizing the release. We may just want to plan on porting a bunch over. Let's plan on performing the merge this Thursday, Jan 18th. -Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Adding ARM64 cloud to infra
On 01/16/2018 12:11 AM, Frank Jansen wrote: do you have any insight into the availability of a physical environment for the ARM64 cloud? I’m curious, as there may be a need for downstream testing, which I would assume will want to make use of our existing OSP CI framework. Sorry, not 100% sure what you mean here? I think the theory is that this would be an ARM64 based cloud attached to OpenStack infra and thus run any jobs infra could ... -i ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Adding ARM64 cloud to infra
On 01/12/2018 07:21 PM, Clark Boylan wrote:
> On Fri, Jan 12, 2018, at 3:27 PM, Dan Radez wrote:
>> fwiw
>> We've been building arm images for tripleo and posting them.
>> https://images.rdoproject.org/aarch64/pike/delorean/current-tripleo-rdo/
>>
>>
>> This uses delorean and overcloud build:
>>
>> DIB_YUM_REPO_CONF+="/etc/yum.repos.d/delorean-deps-${OSVER}.repo
>> /etc/yum.repos.d/delorean-${OSVER}.repo /etc/yum.repos.d/ceph.repo
>> /etc/yum.repos.d/epel.repo /etc/yum.repos.d/radez.fedorapeople.repo" \
>> openstack --debug overcloud image build \
>> --config-file overcloud-aarch64.yaml \
>> --config-file
>> /usr/share/openstack-tripleo-common/image-yaml/overcloud-images.yaml \
>> --config-file
>> /usr/share/openstack-tripleo-common/image-yaml/overcloud-images-centos7.yaml
>> # --config-file overcloud-images.yaml --config-file
>> overcloud-images-centos7.yaml --config-file aarch64-gumpf.yaml --image-name
>> #openstack --debug overcloud image build --type overcloud-full
>> --node-arch aarch64
>>
>> It's not quite an orthodox RDO build, There are still a few things in
>> place that work around arm related packaging discrepancies or x86
>> related configs. But we get good builds from it.
>>
>> I don't know the details of what overcloud build does to the dib builds,
>> Though I don't believe these are whole disk images. I think the
>> overcloud and undercloud are root partition images and the kernel an
>> initrd are composed into the disk for the overcloud by OOO and we direct
>> boot them to launch a undercloud VM.
>>
>> Happy to share details if anyone wants more.
>>
>> Radez
> Looking into this a big more `openstack overcloud image build` takes in the
> yaml config files you list and converts that into a forked diskimage-builder
> process to build an image. The centos7 dib element in particular seems to
> have aarch64 support via building on top of the upstream centos7 aarch64
> image. We do use the centos-minimal element for our images though as it
> allows us to do things like install glean. Chances are we still need need to
> sort out UEFI and GPT for general dib use.
>
> Just to be sure there isn't any other magic going on can you provide the
> contents of the overcloud-aarch64.yaml or point to where it can be found? It
> doesn't appear to be in tripleo-common with the other configs.
>
> It is good to know that this is working in some cases though.
>
> Clark
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
The centos support that's there is because I added it. :)
Here's the overcloud-aarch64 file, Its purpose is just to switch the
arch for the two images built.
I think the packages reference was because there was a missing dep that
has since been resolved.
[stack@localhost ~]$ cat overcloud-aarch64.yaml
disk_images:
-
imagename: overcloud-full
arch: arm64
packages:
- os-collect-config
-
imagename: ironic-python-agent
arch: arm64
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Adding ARM64 cloud to infra
On 01/13/2018 01:26 PM, Ian Wienand wrote: In terms of implementation, since you've already looked, I think essentially diskimage_builder/block_device/level1.py create() will need some moderate re-factoring to call a gpt implementation in response to a gpt label, which could translate self.partitions into a format for calling parted via our existing exec_sudo. bringing up a sample config and test, then working backwards from what calls we expect to see I've started down this path with https://review.openstack.org/#/c/533490/ ... still very wip -i ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
