Curtin post installation question

Wed Oct 11 05:34:07 UTC 2017

 I think I understand what you want to achieve. But without disrupting MAAS functionality, you can have a lock file created for the first time, so that your script does not run 2nd time. This will ensure that though late_commands run everytime, your executing will happen only once.
Regards,Sagar
    On Tuesday, October 10, 2017, 11:14:27 PM GMT+5:30, Syed Mushtaq <syed1.mushtaq at gmail.com> wrote:  

 So the `late_commands` are run at the end of curtin installation correct? What I was thinking was to have some kind of first-boot script installed by `late_commands` so, when a host boots, it will notify MaaS that it is deployed, and then my script will kick in which will trigger the necessary changes required to add that host into Cloudstack. Does this make sense?

On Tue, Oct 10, 2017 at 12:28 PM, Scott Moser <scott.moser at canonical.com> wrote:

Your documentation already shows using late_commands ( test_syed_script).Is there a reason you couldn't just do whatever api request you needed there?

As Andres pointed out, reporting done before successful boot is probably not ideal, but you could report to some API endpoint that the vlans need to be switched at that point.
late_commands run in C locale name-sorted order. so zz_call_home will run as pretty much the last thing that curtin does.

On Tue, Oct 10, 2017 at 11:11 AM, Syed Mushtaq <syed1.mushtaq at gmail.com> wrote:

Thanks Sagar,

I was hoping that I could avoid one more reboot but it looks like it is inevitable. I would be really happy if you could share your post-install scripts with me. Is there a github repo or some place that I can find them?

Thanks,
-Syed

On Tue, Oct 10, 2017 at 2:04 AM, sagar shukla <sa_shukla at yahoo.com> wrote:

 Hi Syed,
I think in Curtin there are already post-installation hooks available which get's triggered when the OS boots up for the first time. I understand that it might be a little late for the VLAN changes on the VM / baremetal, but I feel it is still possible to reboot the box after 1st boot process is completed followed by needful VLAN changes.
This would mean that on 1st boot, server would be under MAAS VLAN and on 2nd boot, it will be under CloudStack VLAN.
In case if you want me to help you further then feel free to PM me. I had implemented post-installation saltstack scripts for server configuration after 1st boot, so that it can be part of configuration management network.
Regards,Sagar

    On Tuesday, October 10, 2017, 4:49:16 AM GMT+5:30, Syed Mushtaq <syed1.mushtaq at gmail.com> wrote:  

 Thanks for the reply Andres. I'm developing a MaaS plugin for Apache Cloudstack. The idea is that MaaS will be a provisioner for baremetal hosts. Now, in this Scenario, Cloudstack is incharge of networking. The way I have it designed currently is that MaaS resides in a specific VLAN and deploys the OS on the host. After the installation, I change the VLAN on the ToR switch from Cloudstack (Cloudstack has plugins for ToR switches as well), move it into the correct VLAN and move it to the the VLAN which Cloudstack has designated for a particular virtual network. This way, both VMs and Baremetal hosts can communicate.

Right now, I'm using preseed scripts to do most of the work like removing the MaaS cloud provider because Cloudstack will now become the cloud-init provider. 

I have documented this in an FS at https://cwiki.apache.org/confl uence/display/CLOUDSTACK/MaaS+ Integration+for+Baremetal+Prov isioning+in+Cloudstack

I see your point that I should not manually trigger a deployed event before the OS is installed. What I can do instead is to have some kind of firstboot action which will do the required setup for me.

Does my approach make sense? Right now I am using preseed scripts to acomplish running post-install commands. Is there any way I can achieve the same using API calls?

I'm open to any and all suggestions. So please don't hesitate to tell me if I am completely stupid and there is a better way to do things.

Thanks,
-Syed

On Fri, Oct 6, 2017 at 9:55 AM, Andres Rodriguez <andres.rodriguez at canonical.co m> wrote:

Hi Syed,
That is not possible. Doing so would mean that you are marking the machine as deployed before it boots into the OS for the first time. This could obviously lead you to think that the machine has deployed successfully when you haven't proven that to be the case.
Is there any specific use case you were looking to cover?
Thanks!
On Mon, Oct 2, 2017 at 12:30 PM, Syed Mushtaq <syed1.mushtaq at gmail.com> wrote:

Hi All,

Currently, when you deploy a node, the state change from Deploying to Deployed happens when MAAS receives a cloud-init request after the node boots up. Is it possible to manually trigger that from a preseed script? 

Thanks,
-Syed

--
Maas-devel mailing list
Maas-devel at lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm an/listinfo/maas-devel

-- 
Andres RodriguezEngineering Manager, MAASCanonical USA, Inc.

-- 
Maas-devel mailing list
Maas-devel at lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm an/listinfo/maas-devel

--
Maas-devel mailing list
Maas-devel at lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm an/listinfo/maas-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/maas-devel/attachments/20171011/c6f688b7/attachment-0001.html>