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
<[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
<[email protected]> 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 <[email protected]
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 <[email protected]> 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
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
an/listinfo/maas-devel
--
Andres RodriguezEngineering Manager, MAASCanonical USA, Inc.
--
Maas-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
an/listinfo/maas-devel
--
Maas-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
an/listinfo/maas-devel
--
Maas-devel mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/maas-devel
