| opendevreview | James Denton proposed openstack/openstack-ansible-os_nova master: Add authentication for [cinder] section of nova.conf https://review.opendev.org/c/openstack/openstack-ansible-os_nova/+/872279 | 03:52 |
|---|---|---|
| hamburgler | Hey all, I noticed that when deploying OSA Zed with OVN on Ubuntu 20.04 the additional upstream repo(s) that gets installed will allow for openvswitch to be upgraded to 2.17.0 > which is also required by an OVN deployment but the repo for openvswitch installs a version for (22.04), now the deployment works fine and it looks like all dependencies are met - but does anyone believe this is going to pose a long term problem | 04:48 |
| hamburgler | or is this as expected functionality for now? Nowhere in the OSA deployment requirements does it say an OVN deployment can only be on 22.04 which is still labelled as experimental. dpkg -s openvswitch-switch : Version: 2.17.3-0ubuntu0.22.04.1~cloud0 | 04:48 |
| NeilHanlon | noonedeadpunk: hm.. did not realize this would have an effect on OSA... | 07:58 |
| noonedeadpunk | hamburgler: hey there. I beleive that openvswitch comes from Ubuntu Cloud Archive. So basically that's the repository where Ubuntu maintainers does push appropriate packages (https://wiki.ubuntu.com/OpenStack/CloudArchive) that are going to work in conjuction with openstack. | 08:35 |
| noonedeadpunk | That used to work good enough, and yes, they're backporting packages from newer releases back to older ones. But I don't think there's gonna be a problem with that | 08:36 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-openstack_hosts master: Install curl by defining binary that is provided https://review.opendev.org/c/openstack/openstack-ansible-openstack_hosts/+/872973 | 08:39 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Install curl by defining binary that is provided https://review.opendev.org/c/openstack/openstack-ansible/+/872896 | 08:39 |
| hamburgler | noonedeadpunk: wonderful thank you :) | 08:40 |
| noonedeadpunk | hamburgler: though, for ubuntu 20.04 they've stopped supporting it on Yoga, so we're actually installing Yoga repo there as latest supported ones. But since it's used only for things like libvirt/qemu/ovs - it should be fine as 20.04 support in openstack will remain at least until Antelope (will be dropped at Bobcat) | 08:43 |
| noonedeadpunk | But you can override openstack_hosts_package_repos variables if you want (or define it to the empty list) to skip installation of UCA. Now it's defined as https://opendev.org/openstack/openstack-ansible-openstack_hosts/src/branch/master/vars/ubuntu-20.04.yml#L88-L91 | 08:44 |
| hamburgler | noonedeadpunk: Awesome this is great thank you! Do you think it's reasonably safe to use a Zed deployment then with the yoga repo then? | 08:48 |
| noonedeadpunk | Well. I would make sense to use 22.04 to be frank on Zed, as if it's relatively new deployment, I'm not sure you want to upgrade OS with next OpenStack upgrade | 08:49 |
| noonedeadpunk | But packages there does satisfy all minimal requirements that are set in Zed for software versions. As there should be no major changes in these requirement from Yoga to Antelope to allow SLURP upgrades | 08:50 |
| hamburgler | Hmm yeah on the OSA deployment page it still says that 22.04 has experimental support | 08:50 |
| noonedeadpunk | We should clarify that better. It's in that stage only due to ceph, since ceph comunity repo does not have anything for 22.04. So we install ceph client also from UCA, which means you're not able to control version of ceph client that will be installed comparing to community repo | 08:52 |
| noonedeadpunk | hamburgler: do you happen to have a link to the doc page you're reffering to ? :-) | 08:53 |
| noonedeadpunk | `Experimental support in Yoga release` -> I assume that... | 08:53 |
| hamburgler | that's right yeah :) | 08:54 |
| noonedeadpunk | Well, you're running Zed, so... :p | 08:54 |
| hamburgler | haha I had read that wrong :p | 08:54 |
| hamburgler | my bad | 08:54 |
| noonedeadpunk | I will fix docs now | 08:54 |
| hamburgler | I appreciate all the help :) - I think we were a bit hesitant to run with 22.04 at this stage | 08:55 |
| hamburgler | Our Ceph role is internal though | 08:55 |
| noonedeadpunk | well, I'm talking also about ceph-client one https://opendev.org/openstack/openstack-ansible-ceph_client | 08:56 |
| noonedeadpunk | Which is smth you wanna use/configure for sure | 08:56 |
| hamburgler | Ah yes | 08:56 |
| noonedeadpunk | iirc you will end up with quincy client there for 22.04 | 08:57 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: [doc] Update Ubuntu 22.04 support status https://review.opendev.org/c/openstack/openstack-ansible/+/873091 | 09:16 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Use 2.0.0 release for ansible-collections-openstack https://review.opendev.org/c/openstack/openstack-ansible/+/873092 | 09:20 |
| hamburgler | noonedeadpunk: Is there somewhere I can view the differences in packages between yoga and zed as it pertains to the UCA? | 09:23 |
| noonedeadpunk | hamburgler: So in UCA there're packages for Zed for 22.04 and for Yoga for 20.04 without any good upgrade path in between. So you can check packages on their tracker though https://openstack-ci-reports.ubuntu.com/reports/cloud-archive/yoga_versions.html | 09:26 |
| noonedeadpunk | hamburgler: in case you're doing source install (default way) - you should skip all openstack packages (like cinder/nova/glance/etc) as they're not used | 09:28 |
| noonedeadpunk | s/skip/ignore/ | 09:29 |
| noonedeadpunk | so we mainly use just libvirt/ovs/ovn/some dependencies for these | 09:30 |
| noonedeadpunk | So it's eventually quite limited subset of packages coming from UCA by default, and eventually in some cases that could be even skipped. | 09:36 |
| hamburgler | Wonderful thank you so much :) | 09:36 |
| jrosser | noonedeadpunk: i had another tricky isolated deployment thing you might be interested in - if you mirror stuff at http://mirror.example.com/ubuntu and http://mirror.example.com/uca it gets difficult to write the proper apt pins | 10:47 |
| jrosser | the apt pins we have used in OSA refer to mirror.example.com sop can't distinguish for example ceph in /ubuntu and ceph in /uca | 10:48 |
| jrosser | but you can easily make CNAME for the mirror to have mirror-uca.example.com or whatever else, then the apt pins all work as you'd expect | 10:48 |
| noonedeadpunk | well, for that env we have 22.04, so no choice of ceph there.... | 10:50 |
| jrosser | ahh ok - becasue of ceph/22.04 we are still trying to decide what to do next :/ | 10:50 |
| jrosser | one option which is feeling least bad, pretty unbelievably, is to build our own ceph :( | 10:51 |
| noonedeadpunk | Well, we have Quincy running anyway, so maybe less of an issue | 10:51 |
| noonedeadpunk | yeah, did that and it wasn't so bad to be frank | 10:51 |
| noonedeadpunk | Eventually for client part I'm not sure how much it matters. But for ceph-ansible part - yeah... I'd build ceph... | 10:53 |
| noonedeadpunk | but yes, that's quite interesting pinning issue... | 10:55 |
| noonedeadpunk | And tbh I wouldn't exepct such behaviour, given that today we pin based on the release - https://opendev.org/openstack/openstack-ansible-ceph_client/src/branch/master/defaults/main.yml#L43 | 10:56 |
| noonedeadpunk | I assumed that release can distinguish source nicely tbh | 10:58 |
| moha7 | This Chinese forum has a lot of posts related to openstack: https://zzk.cnblogs.com/s/blogpost?Keywords=openstack&DateTimeRange=OneYear | 11:02 |
| moha7 | for example: https://www.cnblogs.com/liujitao79/p/15251805.html | 11:02 |
| moha7 | I finally decided to use local repos as I get: opendev: less 100 KB/s | github: less than 5 MB/s | local repo: more than 20 MB/s | 11:03 |
| moha7 | As it's recommended here: `/opt/openstack-ansible/doc/source/user/limited-connectivity/index.rst` to have your Pypi repo, I also cached the pip-required packages using Nexus Sonatype. I think it would useful if this kind of Easter egg be mentioned here: https://docs.openstack.org/project-deploy-guide/openstack-ansible/zed/targethosts.html (I'll do if I get rid of setting the stage env up soon) | 11:09 |
| moha7 | I got demo from https://openmetal.io/, free for 32 hours. They're using Kolla-ansible. | 11:10 |
| moha7 | I asked the "why Kolla", and here is their answer: During development we tested various deployment options including TrippleO, openstack-ansible, Juju, etc and made the decision based on our experience, familiarity, and understanding of similar systems. Our goals include the ability to deploy a production-ready OpenStack default. Some customers may customize and reconfigure their clouds as they see fit if they have or are | 11:18 |
| moha7 | willing to acquire the experience to modify OpenStack post our default, in fact, many do so. | 11:18 |
| moha7 | --- | 11:18 |
| moha7 | Maybe this question I want to ask is like the historical question of debate whether Vim or Emacs is better! But I'd like to hear your perspective on the deployment methods from Kolla to Juju and why you found OSA so valuable that you're still developing it. | 11:18 |
| moha7 | I started from Kolla and it was deployed in half a day. Then I came to OSA and got a lot of help from you. We will choose this OSA. But knowing your point of view will help me defend my decision in the future. One of the strengths of OSA for me is its Hardenning feature and of course the active community, here. | 11:23 |
| moha7 | Note: when Zed is released by OpenStack officially, Kolla releases its support for Yoga intended for production deployments, then OVN is not provided yet. | 11:24 |
| noonedeadpunk | Well, yes, it's indeed quite a debate we tend not to raise - everyone have it's own taste when it comes to technology. I'd say that main reason is that OSA is way more flexible then kolla. Then - you just need to know ansible to read the code - we're trying to keep it rather readable and use common practises. Also - with OSA you're not locked with docker containers, as it's not that easy to debug them after all, and you're able to do just | 11:53 |
| noonedeadpunk | bare metal deploys without any containers in the picture | 11:53 |
| noonedeadpunk | moha7: we also have some "internal" policy, that we don't suggest upgrading production environments to *.0.0 tag - we usually recommend waiting for *.1.0 before upgrading your production environments to the new release | 11:54 |
| noonedeadpunk | I'm not sure if it's described anywhere to be frank | 11:54 |
| noonedeadpunk | From other side - kolla is faster in execution, as they use same container image for all hosts that should contain it. We do allow to use even different versions of service in same deployment. For example it might be handy while debugging things, like you're trying some upstream patch - you can define external github repo and SHA with this patch included only for 1 compute or 1 glance-api container, and provide this backend with ACL rule | 11:57 |
| noonedeadpunk | for haproxy backend to pass all traffic from your internal IP towards this backend only | 11:57 |
| noonedeadpunk | So you can do really crazy things with OSA | 11:57 |
| noonedeadpunk | I assume speed does matter for openmetal.io and they don't care much about use-cases we do have for our deployments as operators. As their business is mainly - spin up many clouds as fast as possible. | 11:59 |
| moha7 | noonedeadpunk: Thanks for sharing your comments. It is a convincing conclusion. | 13:03 |
| *** tosky_ is now known as tosky | 14:19 | |
| prometheanfire | are there consultancies that work with OSA (work is asking for if I get hit by a bus)? | 19:19 |
| noonedeadpunk | There for sure are! | 19:26 |
| spatel | prometheanfire pay me :) | 19:36 |
| spatel | Let integrate OSA with AI which will self drive everything... hehe | 19:37 |
| spatel | I am using ceph deployment and somehow vm boot time is slow. I thought with ceph it should be quick if using raw images | 19:38 |
| prometheanfire | lolol | 19:39 |
| prometheanfire | ceph's been quick for me | 19:39 |
| jrosser | you’ve enabled all the snapshot stuff? | 19:39 |
| spatel | I didn't do anything, this is fresh installation | 19:39 |
| jrosser | like between glance and cinder pools | 19:39 |
| spatel | I have no snapshot at all | 19:40 |
| jrosser | it should be a noop in the storage backend to snapshot the image in glance into the cinder pool | 19:40 |
| jrosser | if that’s not happening you should fix that | 19:40 |
| spatel | hmm wait where is that setting? | 19:41 |
| jrosser | I can’t look just now sorry | 19:41 |
| spatel | let me google it out.. thanks for the clue.. | 19:41 |
| spatel | jrosser not able to find any reference in nova.conf config.. | 19:50 |
| spatel | just ping me whenever you available and i will give it a shot | 19:50 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/ansible-role-python_venv_build master: Drop empty elements from constraint/requirement files https://review.opendev.org/c/openstack/ansible-role-python_venv_build/+/873208 | 20:49 |
| jrosser | spatel: it is glance not nova https://opendev.org/openstack/openstack-ansible-os_glance/src/branch/master/templates/glance-api.conf.j2#L28 | 20:52 |
| jrosser | https://docs.ceph.com/en/latest/rbd/rbd-openstack/#enable-copy-on-write-cloning-of-images | 20:53 |
| spatel | oh!! so i need to set show_image_direct_url = True | 20:55 |
| spatel | let me see if i have that in place | 20:55 |
| jrosser | the glance role should be doing that | 20:55 |
| jrosser | https://opendev.org/openstack/openstack-ansible-os_glance/src/branch/master/defaults/main.yml#L85 | 20:56 |
| jrosser | spatel: you are using ceph for your glance storage too? | 20:56 |
| spatel | Yes ceph for everything | 21:02 |
| spatel | nova/glance/cinder all using ceph | 21:02 |
| jrosser | so you should see that the cinder rbd are snapshots of the images out of the glance pool | 21:07 |
| spatel | I don't have this option - show_image_direct_url = True | 21:22 |
| spatel | I am going to set this first and compare speed before vs after | 21:23 |
| spatel | jrosser do i need to re-upload images or it should work with existing images? | 21:48 |
| jrosser | well question is why | 21:48 |
| jrosser | is this OSA? | 21:48 |
| spatel | jrosser now its freaking fast... | 22:00 |
| spatel | 5 min vs 30 second :) | 22:00 |
| spatel | i didn't re-upload image | 22:00 |
| spatel | just change option and it works | 22:00 |
| admin1 | moha7, why are you using OSA and not kolla ? | 22:09 |
| admin1 | just asking as what are your points of using this | 22:10 |
| admin1 | as a new user | 22:10 |
| moha7 | OSA: endemic to OPS itself, more native + security | 22:24 |
| moha7 | Juju: no familiarity with the stack | 22:24 |
| moha7 | Kolla: Lack of security enhancements; If docker, why not Kubernetes by OpenStack-Helm | 22:24 |
| moha7 | OpenStack-Helm: Not well documented, OVN is not supported yet, Need time to master structural complexity | 22:25 |
| moha7 | VIO: Paid and exclusive | 22:26 |
| moha7 | admin1: ^ | 22:26 |
| admin1 | i started on openstack around 2014 as full time .. and i think around early 2015 used OSA .. and got hooked into it .. .. for a specific company my job was to setup every known openstack platforms and certify/test our products/solutions on top of it, so I have an idea of all setups and deployments .. whenever there was a custom request, i always | 22:33 |
| admin1 | found that it could be done with OSA and not with anything else.. OSA is poweful to deploy with almost zero changes .. i most of the time only work on the variables and setup file and that is it .. 2 files and you can pretty much get a very good openstack .. but also if you want, you can dive deep and change anything and do it your own way | 22:33 |
| admin1 | another is the level of support .. if you go into any other deployment channels /lists and ask a non default question and there is total silence .. as no one knows .. but with OSA , because of the flexibility, you find a lot of experience in this channel | 22:34 |
| admin1 | here you an ask any kind of deployment scenario and chances are people here have done it | 22:35 |
| admin1 | with others you mentioned, its like the juju demostration .. run it, it works and then done .. if something breaks of if you want something out of the non-defaults to suit your needs, you get stuck as there is no knowledge on it | 22:36 |
| admin1 | also upgrades :) | 22:37 |
| admin1 | the way i present OSA now a days to others is OSA is a framework to build openstack the way you need .. while others, I consider them just tools . they work in specific way and not as flexible as osa | 22:40 |
| moha7 | > "f you want something out of the non-defaults to suit your needs, you get stuck, total silence", | 22:43 |
| moha7 | Ah, good point. I had not thought about it | 22:43 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!