| *** ricolin_ is now known as ricolin | 05:05 | |
| *** rpittau|afk is now known as rpittau | 07:06 | |
| yasufum | hi tacker team | 08:01 |
|---|---|---|
| ueha | Hi | 08:01 |
| manpreetk | hi | 08:01 |
| h_asahina | hi | 08:01 |
| hirofumi-noguchi | hi | 08:01 |
| masaki-ueno | hi | 08:01 |
| masazumi_ota | hi | 08:02 |
| takahashi-tsc | hi | 08:02 |
| yasufum | #startmeeting tacker | 08:03 |
| opendevmeet | Meeting started Tue Jun 22 08:03:04 2021 UTC and is due to finish in 60 minutes. The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot. | 08:03 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:03 |
| opendevmeet | The meeting name has been set to 'tacker' | 08:03 |
| yasufum | We have two topics on etherpad. | 08:04 |
| yasufum | #link https://etherpad.opendev.org/p/tacker-meeting | 08:04 |
| yasufum | Can we start from first one? | 08:04 |
| h_asahina | Sure. Can I explain it? | 08:07 |
| yasufum | yes | 08:07 |
| h_asahina | Recently, we are considering to provide vagrant box on the official document of Tacker for the ease of development. | 08:09 |
| h_asahina | We'd like to know if it's useful or not. | 08:10 |
| h_asahina | So, please tell us the development environment you use on the etherpad. I made a survey form. | 08:11 |
| yasufum | Thanks | 08:13 |
| ueha | I wrote on etherpad. (Vagrant+) | 08:15 |
| h_asahina | Thanks | 08:15 |
| yasufum | I’d confirm the point of your survey correctly. | 08:16 |
| yasufum | because vagrant provides several types of provider, such as virtual box or vmware or so | 08:18 |
| yasufum | What do you want know is the number of people using vagrant, right? | 08:18 |
| yasufum | Do you think of providing several types of boxes? | 08:19 |
| yasufum | In my case, I use vagrant with virtualbox. | 08:20 |
| h_asahina | I think we can, but I assumed the vagrant with virtualbox. | 08:21 |
| yasufum | understand | 08:22 |
| h_asahina | I think write it clearly, i.e., we are basically assuming vagrant with virtualbox. What do you think? | 08:24 |
| yasufum | umm… I’m not sure it is the typical case. | 08:25 |
| yasufum | What do you think adding options, virtualbox and libvirt are enough, under ‘Vagrant’ instead? | 08:26 |
| h_asahina | Sorry, what do you mean? do you mean intergrating virtualbox and libvirt into Vagrant? | 08:29 |
| yasufum | Anyway, I hope everyone tell us your usecase on the survey, thanks. | 08:30 |
| yasufum | Is there any other comment? | 08:30 |
| ueha | I use vagrant with libvirt as provider. but I think either is fine as long as it can be used as a development environment. | 08:30 |
| yasufum | :) | 08:31 |
| ueha | Will you create a vagrant box and upload it to the cloud? Or will you start up a virtual machine with a provision in the Vagrantfile? | 08:32 |
| ueha | I want to know what mean "to provide vagrant box" you said. | 08:33 |
| h_asahina | I mean uploading the boxes with the development environment to Vagrant Cloud. | 08:35 |
| ueha | Thanks, I understood. Does box contain everything before users clone devstack to build the environment? | 08:38 |
| ueha | I think users want to use latest environment or any stable version. | 08:39 |
| h_asahina | I understood. | 08:40 |
| ueha | Anyway, it's great to make it easier for new users and developers to build environment! | 08:41 |
| h_asahina | I considered to provide the box that VNF package has already instantiated. | 08:41 |
| h_asahina | So that user can follow the instruction on the official document easily. | 08:41 |
| h_asahina | So, it might not be the latest version. | 08:42 |
| h_asahina | But, we can provide a box with the latest version of Tacker as well. So the answer for your question can be YES. | 08:44 |
| ueha | Thanks, It would be good if the user can customize it easily. | 08:45 |
| yasufum | I believe we have several options for providing such a environment, | 08:45 |
| yasufum | for example, providing several boxes, or boxes only for stable and Vagrantfile for the latest, or so. | 08:46 |
| yasufum | I think we need to have further discussion for conclusion. | 08:46 |
| h_asahina | I agree | 08:47 |
| yasufum | Please continue to do so on the next meetings or etherpad. | 08:47 |
| h_asahina | I got it | 08:47 |
| yasufum | If no more comment, go to the next topic. | 08:48 |
| yasufum | from ueha | 08:48 |
| ueha | Yes, it is the topic that I announced last week. | 08:48 |
| ueha | Just information sharing from me about "Zuul FT Environmental Performance of MgmtDriver". | 08:49 |
| ueha | In the Wallaby release, the FT on Zuul in mgmtDriver, which builds the k8s cluster, had a problem and placed it in the sample folder. | 08:49 |
| ueha | As discussed in the past, refer to https://meetings.opendev.org/meetings/tacker/2021/tacker.2021-02-09-08.03.log.html#l-65 | 08:49 |
| ueha | Since then we have continued to try to pass FT of the mgmtDriver for k8s cluster on Zuul, and found that the Zuul environmental performance made it difficult to complete the FT in time. | 08:50 |
| ueha | The Xena release also updates the mgmtDriver for k8s cluster, but I think it is difficult to pass the Zuul FT by above reason. | 08:51 |
| ueha | So I would like to share with you that we are going to place the Xena development results (mgmtDriver for k8s driver) in the sample folder. | 08:52 |
| ueha | That's all from my side. any comment or question? | 08:53 |
| yasufum | Do you know what is the reason why it doesn’t pass? | 08:54 |
| ueha | The reason is that it times out with a time limit of 3 hours. | 08:55 |
| yasufum | I don’t know it can be fixed or not actually. | 08:56 |
| yasufum | I remember we had similar issue before, and fixed it by separating zuul’s tasks. | 08:57 |
| yasufum | What do you think we cau take the same approach, or difficult to separate? | 08:58 |
| ueha | Yes, but too many times spend during build k8s cluster in one testing. So it is difficult to separate.. | 08:59 |
| yasufum | Sorry, divided processes into several nodes correctly. | 09:00 |
| ueha | Currently, the time has expired when the k8s master node was built by mgmtDriver. | 09:01 |
| yasufum | Do you know which part of building k8s is the most costly? | 09:03 |
| ueha | "k8s master node was built by mgmtDriver" is most costly, at the moment. | 09:05 |
| ueha | but, then there is the worker node build. | 09:06 |
| ueha | (85 minutes is needed to installing a single MasterNode.) | 09:07 |
| yasufum | OK, I understand about the situation roughly. | 09:08 |
| yasufum | It seems we have no other choices now… | 09:09 |
| ueha | Yes.. | 09:09 |
| yasufum | but I would like to dive into it because it should be tested if possible, not just a sample code. | 09:10 |
| yasufum | Is there any question or comment? | 09:11 |
| yasufum | or topic? | 09:11 |
| manpreetk | JFYI, the FT cases are failing while migrating sqlalchemy 4.1. | 09:12 |
| manpreetk | https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_95f/796160/4/check/tacker-functional-devstack-multinode-legacy/95f3b8e/testr_results.html | 09:12 |
| manpreetk | I am trying to reproduce the issue in local env. | 09:12 |
| manpreetk | On reproduction, would revert sqlalchemy changes to rule out the cause of gate job failure. | 09:12 |
| manpreetk | And in parallel I am investigating aodhclient error, one pointed by Ueha san. | 09:12 |
| manpreetk | https://zuul.opendev.org/t/openstack/build/95f3b8e79e7f4635b8d5a44ee85673a0/log/controller/logs/screen-h-eng.txt?severity=4 | 09:12 |
| ueha | yasufum: thanks | 09:12 |
| yasufum | manpreet: thank you for your effort. | 09:13 |
| yasufum | Unit tests are all green, but just some failures remained in FTs. | 09:15 |
| manpreetk | Yes and need to check whether its SQL changes or something else. Any help will be highly appreciated :) Thanks | 09:15 |
| yasufum | thanks | 09:16 |
| ueha | Thank you! I will comment again if I know something. | 09:16 |
| manpreetk | Thanks ueha :) | 09:17 |
| manpreetk | Thats all from my side. Thanks | 09:18 |
| yasufum | Although it is the time to close this meeting, I have one thing to ask you shortly. | 09:20 |
| yasufum | It is closed to the end of the time for spec freeze, June 30th as we agreed in the previous vPTG, so please help reviewing sugggested speces. | 09:22 |
| yasufum | going to be merged. | 09:22 |
| hirofumi-noguchi | I will upload patch sets of my Specs by the end of this week. | 09:22 |
| hirofumi-noguchi | I am making corrections corresponding to the review comments. | 09:22 |
| takahashi-tsc | Sorry, we should update some spec but not completed yet, We will hurry in this week | 09:23 |
| hirofumi-noguchi | In addition, I will upload a new Spec regarding SOL v3 API. | 09:23 |
| hirofumi-noguchi | The upload of new Spec is likely to be next week or the week after. I am sorry for late. | 09:24 |
| hirofumi-noguchi | I would like to update it if I can. | 09:24 |
| masaki-ueno | I'm also working on correcting specs, thank you for your comments. > ueha, manpreet :) | 09:25 |
| yasufum | hirofumi-noguchi: For the new one, is it not so big change as required to have a discussion for, right? | 09:26 |
| hirofumi-noguchi | Yes, most of all are same as v1 API. I think the changes are very small. | 09:27 |
| yasufum | OK, thanks | 09:28 |
| yasufum | masaki-ueno: Thanks for sharing. | 09:28 |
| yasufum | If no more comment, I’d like to close this meeting. | 09:29 |
| yasufum | Thanks for joining, bye. | 09:30 |
| takahashi-tsc | thanks | 09:30 |
| ueha | Thanks, bye | 09:30 |
| manpreetk | thanks bye | 09:30 |
| hirofumi-noguchi | thanks | 09:30 |
| masaki-ueno | bye | 09:30 |
| yasufum | #endmeeting | 09:31 |
| opendevmeet | Meeting ended Tue Jun 22 09:31:06 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 09:31 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tacker/2021/tacker.2021-06-22-08.03.html | 09:31 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tacker/2021/tacker.2021-06-22-08.03.txt | 09:31 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tacker/2021/tacker.2021-06-22-08.03.log.html | 09:31 |
| *** osmanlicilegi is now known as Guest187 | 12:25 | |
| *** ChanServ changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings/" | 12:29 | |
| *** rpittau is now known as rpittau|afk | 17:11 | |
| oneswig | #startmeeting scientific_sig | 21:00 |
| opendevmeet | Meeting started Tue Jun 22 21:00:22 2021 UTC and is due to finish in 60 minutes. The chair is oneswig. Information about MeetBot at http://wiki.debian.org/MeetBot. | 21:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 21:00 |
| opendevmeet | The meeting name has been set to 'scientific_sig' | 21:00 |
| * oneswig double-checks the spelling as usual | 21:00 | |
| julianp | Heh. | 21:00 |
| oneswig | greetings julianp how are you? | 21:00 |
| julianp | Hi oneswig. I'm doing well. Getting ready for summer vacation. | 21:01 |
| julianp | How are you? | 21:01 |
| oneswig | Well our CEO's on vacation and I'm holding the fort. Just about. | 21:01 |
| oneswig | Got a few extra things going on but I am not complaining. | 21:02 |
| julianp | Excellent. | 21:02 |
| oneswig | One of those things has been testing to confirm that one tenancy on the Scalable Metal Service cannot adversely impact other tenancies. ie, that we've got the security model about right. | 21:03 |
| oneswig | It has taken a little longer than anyone would have liked :-) | 21:03 |
| julianp | Ooh. Yeah, I guess that's important to get right. | 21:03 |
| oneswig | As a budget service, IPV4's getting pricey so we are embracing IPV6. It's a weird form of embrace | 21:04 |
| oneswig | I assume other people in the world are serious on IPV6 but it does take some getting used to | 21:04 |
| julianp | Yes. I know what you mean. | 21:05 |
| oneswig | What's new with Exosphere? | 21:06 |
| oneswig | Do you have IPV6 support up and running? | 21:06 |
| julianp | Quite a bit. | 21:07 |
| julianp | Biggest news is that we're working on sharing workflows. Instead of having to maintain long-lived OpenStack images. | 21:07 |
| julianp | We're leveraging this specification: https://repo2docker.readthedocs.io/en/latest/specification.html | 21:07 |
| julianp | It's the same tool used by Jupyter's Binder project. | 21:08 |
| julianp | We want to go where the community is, and this seems like a relatively low burden for minimal viable reproducible workflows. | 21:08 |
| oneswig | ooh, interesting. How will you use it? | 21:08 |
| rbudden | hello | 21:09 |
| oneswig | hey rbudden, nice to see you | 21:09 |
| julianp | Hey rbudden! Long time no see. | 21:09 |
| rbudden | yep, been awhile, good to see everyone | 21:10 |
| oneswig | What's up with you rbudden? | 21:11 |
| julianp | First approach is to allow a user to specify a GitHub repo (or Zenodo DOI, etc.) when launching a server. Then we use the repo2docker tool to create a container from that, and then have a link to launch the Jupyter Notebook, RStudio or whatever. Similar to how we do web terminal and remote desktop in the browser. | 21:11 |
| rbudden | Knee deep in our new production OpenStack deploy, so playing with Wallaby | 21:11 |
| oneswig | julianp: is what you're doing involving open ondemand or is that competing/irrelevant here? | 21:11 |
| oneswig | rbudden: Wallaby? Cutting edge :-) | 21:12 |
| rbudden | haha, yeah, well we figured why deploy a CentOS 7 Train cloud like our TDS and immediately need to do upgrades ;) | 21:13 |
| rbudden | so we’re building on CentOS Stream and Wallaby ATM | 21:14 |
| julianp | oneswig: It's competing with the notebook interface for Open OnDemand, I think, but we go further. In particular we leverage REES to allow researchers to specify dependencies easily. | 21:14 |
| oneswig | rbudden: nice. I think we start on the same setup this week (but you guys roll your own deployments, right?) | 21:14 |
| rbudden | correct | 21:14 |
| rbudden | we’re in the process of moving from Puppet -> Ansible as well | 21:15 |
| julianp | Whoah. | 21:15 |
| julianp | rbudden: What was the motivation for moving to Ansible? | 21:15 |
| oneswig | julianp: would be interesting for the team here to see a demo of your work, if you have time. I think it would be informative. | 21:15 |
| julianp | oneswig: We can definitely do that. I have time this week. Ping me on Slack. | 21:16 |
| oneswig | Thanks julianp - I may not have time this week but I'll ping you all the same. | 21:17 |
| rbudden | So we wrapped Ansible around our custom deploy model mainly for mainly for automation purposes. | 21:18 |
| rbudden | We have our TDS nailed down to being able to rebuild our entire infrastructure from scratch with essentially a single playbook (two separate openstack clouds) from the metal -> xCAT imagining -> OpenStack deploy | 21:19 |
| oneswig | Nice work. I bet those playbooks look lovely | 21:21 |
| rbudden | We liked the setup and decided we’d slowly replace the pieces over time. Additionally, for security reasons it’s also simpler for us to deploy over SSH | 21:22 |
| rbudden | oneswig: they are getting there. still a lot of work to do, but I structured it similar to the Ansible setup I did at PSC | 21:23 |
| oneswig | rbudden: did they go greenlake with bridges-2 do you know? | 21:23 |
| rbudden | I’m not sure TBH, I’ve been out of touch with ppl there since COVID started | 21:24 |
| rbudden | but I know they’ve switched directions on a few fronts | 21:24 |
| oneswig | interesting, thanks rbudden | 21:25 |
| oneswig | So how far on are you with Stream? | 21:26 |
| rbudden | we have a full control plane built right now, I’m troubleshooting an issue with our Neutron server/api and communication to the Neutron network nodes | 21:27 |
| oneswig | Are you using OVN? | 21:27 |
| rbudden | no no, we’re still just doing provider networks, straight VLANs with LB | 21:28 |
| martial | sorry for being late | 21:28 |
| oneswig | rbudden: nice. Did anything happen on linuxbridge and driver maintenance? | 21:28 |
| oneswig | hi martial, you made it! | 21:28 |
| oneswig | #chair martial | 21:28 |
| opendevmeet | Current chairs: martial oneswig | 21:28 |
| rbudden | I know Mills was fighting for LB support in the PTG, we’re getting nervous about continued support | 21:29 |
| rbudden | we’ve both done OVS setups in the past so we may move towards that in the future and see what kind of VXLAN offload support could do for us, etc. | 21:30 |
| rbudden | not very familiar with OVN yet, is that what StackHPC is deploying these days? | 21:30 |
| oneswig | Yes unless required otherwise. | 21:31 |
| rbudden | Our focus lately has been in the multi AZ/Cell setup pieces. | 21:31 |
| oneswig | We've been having fun with OVN and hardware offloads for OVS flows. | 21:31 |
| rbudden | well, I’m happy to have you convince me about OVN before we go production ;) | 21:31 |
| oneswig | Any effort to convince you would entail a moral obligation to support it afterwards :-) | 21:32 |
| rbudden | lol | 21:33 |
| oneswig | The major advantage of it is that the project has a pulse. The only advantage I can think of otherwise is that you can do load-balancers in SDN flow rules, instead of booting Amphora VMs running HAProxy. | 21:34 |
| rbudden | we have a tight schedule actually, since we have to merge our two running OpenStack’s into this new cluster, so we aren’t deviating into new tech much yet | 21:34 |
| oneswig | wise move | 21:34 |
| rbudden | the only major changes are to AZs really | 21:34 |
| rbudden | so we can have localized storage/network/etc to each respective building | 21:35 |
| rbudden | but also failover to another building if necessary | 21:35 |
| rbudden | We are interested in BPG Unnumbered and other alternatives to our network stack though | 21:36 |
| oneswig | That sounds neat. I'm wary on AZs it would be interesting to see them used well | 21:36 |
| rbudden | they work well in our TDS aside from a few bugs that I’m hoping may have been fixed in Wallaby | 21:36 |
| ewimmer | Hi oneswig, sorry I almost forget about the meeting today. | 21:36 |
| oneswig | Hi ewimmer, good to see you | 21:37 |
| oneswig | rbudden: well hopefully someone else will have hit the same issues as you | 21:37 |
| oneswig | ewimmer: we haven't covered BGP to the host, shall we? | 21:37 |
| oneswig | Although jmlowe isn't here and he was the other respondent on it. | 21:38 |
| ewimmer | oneswig: Would be nice to see if someone has done it before! | 21:38 |
| oneswig | I'm sure it has been done but I just don't know anyone who has done it! | 21:39 |
| rbudden | ditto, I don’t think anyone on the Slack channel admitted to actively using it | 21:40 |
| ewimmer | So maybe we can think of the downsides if any? | 21:41 |
| oneswig | I may be mixing this with routed networks but does it create tenant networks without L2 connectivity? | 21:41 |
| ewimmer | Or maybe on the usecase first! :) | 21:42 |
| ewimmer | oneswig: is that possible? | 21:43 |
| ewimmer | these networks have to be connected to somewhere | 21:43 |
| oneswig | Yes - if you got instances on packet.net, they had l3-only networking due to a BGP-managed fabric | 21:44 |
| ewimmer | So VXLAN only? | 21:47 |
| oneswig | I think the way it worked was all hosts got their own /30 network. So any communication with another host was via a gateway | 21:48 |
| oneswig | This might also be how Calico works | 21:48 |
| oneswig | But I'm not sure if that's the same experience as BGP to the host - perhaps you still do VXLAN overlays in that case. | 21:49 |
| ewimmer | Calico uses BGP | 21:50 |
| ewimmer | Hm I was more thinking of using VXLAN for segmentation, replaceing my VLANs | 21:51 |
| ewimmer | And using OVS/OVN on top. | 21:52 |
| ewimmer | BGP would just help to get ECMP to the host. Replacing bonds. | 21:53 |
| oneswig | That would be the extension of the Cumulus model, wouldn't it? | 21:53 |
| oneswig | I mean, instead of VXLAN from the switch, VXLAN from within the hypervisor. | 21:53 |
| ewimmer | Exactly, BGP EVPN | 21:53 |
| ewimmer | Cumulus can do what they call multihoming, using BGP instead of a MC-LAG on the leaf switches, but presenting still a bond to the hosts. | 21:55 |
| ewimmer | But this works for Mellanox ASICs only... | 21:55 |
| ewimmer | So if I can't have this bonding feature, I will have to bring the routing protocol to the hosts. | 21:56 |
| oneswig | I think so. The quest is for a kolla user who sets a precedent. | 21:58 |
| oneswig | Ah, we are out of time. | 22:00 |
| ewimmer | I will tell you hopefully next time :) | 22:00 |
| oneswig | Too bad we didn't get a user story on this | 22:00 |
| oneswig | Good luck ewimmer :-) | 22:00 |
| oneswig | Final comments anyone? | 22:00 |
| oneswig | #endmeeting | 22:01 |
| opendevmeet | Meeting ended Tue Jun 22 22:01:46 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 22:01 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/scientific_sig/2021/scientific_sig.2021-06-22-21.00.html | 22:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/scientific_sig/2021/scientific_sig.2021-06-22-21.00.txt | 22:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/scientific_sig/2021/scientific_sig.2021-06-22-21.00.log.html | 22:01 |
| oneswig | Thanks all | 22:01 |
| rbudden | ttyl later! | 22:01 |
| julianp | Till next time. :wave: | 22:02 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!