07:19:20 #startmeeting sahara 07:19:20 Meeting started Tue Oct 19 07:19:20 2021 UTC and is due to finish in 60 minutes. The chair is tosky. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:19:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 07:19:20 The meeting name has been set to 'sahara' 07:19:41 #chair qiujunting ruifaling 07:19:41 Current chairs: qiujunting ruifaling tosky 07:20:25 welcome to the meeting! qiujunting, can you please ask again your last question ? 07:24:39 Can you introduce the organization process of the regular project meeting? 07:25:39 Consider the regular meeting of the Sahara project 07:27:42 tosky: 07:28:27 normal IRC meetings are more or less the same, and described here: https://wiki.openstack.org/wiki/Meetings/ChairaMeeting 07:28:41 you go through the points on your agenda one by one 07:29:40 ok, thanks 07:30:05 I have a point that saharaahara support the creating the instance by specifying system volumes. 07:30:25 I have a point that sahara support the creating the instance by specifying system volumes. 07:31:13 The VM instance boot by a volume. 07:31:58 An existing volume ? 07:32:06 yes 07:33:13 so you mean there are some volumes has been created,then we lanch a cluster by those volumes ? 07:33:48 First create the boot volume of the VM instance, and specify the volume boot VM instance. 07:33:59 yes 07:34:39 but sahara supports boot from volume, as far as I remember 07:35:28 This can reduce the time it takes for Sahara to deploy the cluster. 07:35:29 yes, 07:35:32 it was added here: https://storyboard.openstack.org/#!/story/2001820 07:35:57 oh, do you mean having sahara deploy on VMs which are already running? 07:39:04 No, I mean it is faster for nova to start the virtual machine with volume, and Sahara can assign this volume to nova. 07:39:48 but sahara doesn't start the volume, sahara asks nova to start virtual machines 07:40:12 and sahara supports boot from volume, which was described by https://specs.openstack.org/openstack/sahara-specs/specs/backlog/boot-from-volume.html 07:40:31 that document is in the "backlog" section but it was implemented by https://storyboard.openstack.org/#!/story/2001820 07:40:40 how does your proposal differ from that? 07:44:23 I mean like this:https://specs.openstack.org/openstack/sahara-specs/specs/backlog/boot-from-volume.html 07:45:05 sahara has been suuported this ? 07:46:42 yes, please see the commits referenced by https://storyboard.openstack.org/#!/story/2001820 07:55:35 so the other topic to discussion in qiu's email is :Sahara deploys a dedicated cluster through cloud host VM tools (qemu-guest-agent) 07:57:19 maybe it means using QGA to deploy clusters 07:57:33 Ian Wienand proposed openstack/openstack-ansible-os_sahara stable/stein: Remove debian-stable jobs https://review.opendev.org/c/openstack/openstack-ansible-os_sahara/+/814349 08:00:30 can you please explain this point a bit more? 08:02:17 In the current version, the script is executed by Sahara through SSH to the VM 08:03:17 It rely on the external networks 08:05:49 or even internal network, but yes, that's correct, the controller should be able to reach the VMs through some network 08:06:33 Use qga to execute the script could weakening the dependence on network 08:06:55 but this means a tight dependency between sahara and the instances 08:07:37 yes 08:07:48 sahara doesn't know about the way instances are managed, it would go against being an abstraction layer 08:07:57 also, nova can support multiple ways of deployments 08:08:08 and that wouldn't work with baremetal instances of course 08:11:27 oh yes,BM,may be distinguish between virtual machines and bare metal machines 08:12:29 but again, you would also need to access the hypervisor, and that solution would be targeted to a specific hypervisor 08:15:14 moreover, the virtual machines requires to have a network anyway, because the hadoop services on the cluster need to talk to each other 08:16:56 yes, before we need the falt network, by 08:17:44 by qga, we need not network must be flat network. 08:18:18 the controller reach to the vms not very necessary 08:20:43 but it's the only way to not break the abstraction 08:21:16 you don't need the network to be a flat one, because you can configure the access though a specific node using the proxy settings 08:21:30 https://docs.openstack.org/sahara/latest/admin/advanced-configuration-guide.html#custom-network-topologies 08:24:58 you can set up a "jumphost" which can be reached by the controllers, and that can reach the instances 08:38:08 ok,I understand ,thank you,tosky 08:54:43 qiujunting: is there any other topic before closing? 08:55:07 no, thank you tosky 08:55:10 for example, do you have a plan about which backends should be kept and updated and which ones should be dropped? 08:55:37 sorry, plugins - I suspect some of them may not work anymore, especially ambari and cdh, given the recent changes in Cloudera 08:55:47 and the vanilla one is very outdated 08:55:53 do you plan any work on updating them? 08:57:40 If possible, consider updating them in the yoga version. 08:58:21 You can introduce the plan in detail. 08:59:16 We can communicate by email 09:05:23 I don't have a plan because my time on sahara is limited, I can help with revisions 09:05:45 but right now the supported plugins are not really useful for the users 09:05:57 so if you want to use it, you may be interested in updating them as well 09:06:05 anything else? Can I close the meeting? 09:06:36 (please note that I set you both as chair for this specific meeting with the command #chair , so anyone of us can close the meeting with #endmeeting ) 09:08:50 qiujunting, ruifaling ^ 09:09:19 ok,thank you very much 09:09:27 bye 09:09:33 thank you all 09:09:38 #endmeeting