[04:22] <mup> Bug #1625910 opened: [2.1] MAAS doesn't have routing to BMC IP, but MAAS shows the power as ON <MAAS:New> <https://launchpad.net/bugs/1625910>
[05:06] <sujeet_> Hi roaksoax
[05:06] <sujeet_> Hi kiko
[12:02] <NewJorg> Hello, is there a way to access the tags of a machine in commissioning? We have some nodes with hardware raids and want to configure the disks differently (RAID0 for every disk or RAID10 for all disks) depending on a tag.
[12:37] <rock__> Hi. MAAS cloud juju bootstrap failed. Followed https://jujucharms.com/docs/2.0/clouds-maas I used MAAS 2.0 on Xenial(16.04). I am using all physical servers. I want to have [MAAS+Openstack base bundle] setup with our own bundle. But we are facing the issue while JUJU bootstrapping the MAAS cloud.
[12:37] <rock__> Complete issue details: http://paste.openstack.org/show/582397/.  Please help me in resolving this.
[12:37] <rock__> roaksoax: Can you please help me in this.
[12:39] <kiko> lesseee
[12:40] <kiko> NewJorg, it should be possible, yes. what does the machine query return to you?
[12:40] <kiko> rock__, first, can you deploy Ubuntu manually to all of the nodes in your MAAS?
[12:41] <rock__> kiko: Yes. I deployed and tried. working fine.
[12:45] <baldpope> kiko, question on deploying ubuntu via maas - is it still iscsi root?
[12:46] <baldpope> so I could use all local disks for something other than /
[12:50] <rock__> kiko/roaksoax: So what I need to do here to resolve the issue. Am I need to change "curtin_userdata" script by putting some sleep before updating apt-get to reflect the change what we made through SSH into that bootstrapping node?
[12:50] <kiko> roaksoax, hmm, what change you made through SSH?
[12:51] <kiko> baldpope, it never was iscsi root, except for the ephemeral environment. does that make sense or should I explain?
[12:51] <roaksoax> rock/win 4
[12:51] <roaksoax> err
[12:52] <roaksoax> rock__: as per kiko above, what change you made with SSH
[12:52] <rock__> kiko: To avoid that Hash sum mismatch issue , http://paste.openstack.org/show/582398/
[12:52] <rock__> roaksoax: I did the above change
[12:53] <kiko> rock__, that change doesn't make sense to me
[12:53] <kiko> rock__, why did you make it?
[12:53] <baldpope> kiko, no, i got it - ty
[12:53] <kiko> baldpope, HOWEVER, the caringo team has a set of patches proposed to us that allow you to do exactly that
[12:54] <kiko> baldpope, i.e. deploy an OS that is a kernel and initrd only, and then use the local disks for object storage
[12:56] <rock__> kiko/roaksoax:  why  i added info : http://paste.openstack.org/show/582400/.
[12:57] <kiko> rock__, that error points to a wider problem
[12:57] <kiko> rock__, is your local mirror not functioning properly?
[12:57] <kiko> rock__, or do you have a proxy issue?
[12:59] <NewJorg> kiko, what do you mean exactly with machine query?
[13:00] <baldpope> kiko, please accept those changes ;)
[13:01] <baldpope> that would be exactly what we'd want - use all the local disks for the object storage
[13:01] <rock__> kiko/roaksoax: we got the same hash sum mismatch issue in our local systems , then we genarally used to add that. Local mirror working fine now.
[13:01] <samek_> hi
[13:02] <samek_> how can I debug adding a chassis ?
[13:02] <samek_> we have a moonshot chassis and I want to add it
[13:02] <samek_> All I get is Unable to find a rack controller with access to chassis X.X.X.X
[13:03] <rock__> kiko/roaksoax: No . I don't have any proxy issue.
[13:05] <rock__> kiko/roaksoax: I don't know what to do now. please tell me if you any ideas to resolve this issue.
[13:08] <kiko> samek_, there is no rack controller that is active on that subnet
[13:08] <kiko> rock__, your problem is not inside MAAS. it is outside MAAS.
[13:09] <kiko> rock__, that apt-get update needs to pass without error. your network, proxy or mirror are broken.
[13:09] <kiko> rock__, plug a laptop in. does the apt-get upgrade show the same error?
[13:11] <samek_> kiko
[13:11] <baldpope> rock__, did you define a proxy in maas?
[13:12] <baldpope> if so, does your network allow the internal network to talk with the proxy?
[13:12] <rock__> kiko:  sorry. Didn't get. Please tell me clearly.
[13:12] <rock__> baldpope: Didn't define proxy.
[13:13] <samba35> can some one please give me link to read how to /start using kind of stuff for maas ,i am on ubuntu 16.04.1 with maas 2
[13:13] <baldpope> so in that case (I think - kiko, please chime in) the internal hosts are going to attempt direct network access - does the internal network have access to the public internet through your firewall?
[13:14] <samek_> kiko It is accessible from the server where everything is on.
[13:14] <rock__> baldpope: Yes.
[13:14] <baldpope> hm
[13:16] <baldpope> apologies - I didn't see the paste at openstack - network does not appear to be the issue, your getting out and package info back
[13:17] <kiko> baldpope, it is either a network issue, or bad RAM/NIC
[13:17] <kiko> rock__, can a laptop, plugged into the same network, using the same mirror, do an apt-get update successfully?
[13:17] <baldpope> kiko, line 6/7 - wouldn't that imply a bad file received?
[13:18] <rock__> kiko: $ sudo apt-get upgrade && sudo apt-get dist-upgrade  working fine.
[13:18] <rock__> kiko: apt-get update also working fine.
[13:18] <baldpope> rock__, but you need to prep by running update - that tells upgrade what to do
[13:19] <baldpope> and based on your paste - update is failing
[13:20] <rock__> kiko/baldpope: From MAAS conigured node , I am able to do apt-get update successfully.
[13:22] <baldpope> i'm confused - where is apt-get update failing then?
[13:24] <rock__> baldpope: On MAAS  slave nodes.
[13:26] <baldpope> am I missing something or do your last 2 statements contradict each other?
[13:26] <kiko> they do
[13:26] <kiko> thanks baldpope :)
[13:35] <rock__> koko/roaksoax/baldpope: when juju bootstrapping the MAAS cloud on one of MAAS Slave node I am getting apt-get issue.
[13:38] <kiko> rock__, oh. you are saying that only during a juju bootstrap does the error happen
[13:38] <kiko> hmmmmmm
[13:38] <kiko> rock__, is the clock on these machines synchronized?
[13:43] <rock__> kiko: please look at this once.  http://paste.openstack.org/show/582407/.
[13:45] <rock__> kiko: I think machines are synchronized with the above result.
[13:47] <rock__> Kiko/roaksoax: Exactly I found the issue. When we did juju bootstrap of MAAS cloud on one of MAAS slave node,
[13:49] <rock__> kiko/roaksoax: I ssh into that bootstrapping node and run apt-get update . Then it was giving Hash sum mismatch issue. But after adding http://paste.openstack.org/show/582398/ in that maas slave node apt-get update going successfully.
[13:51] <rock__> kiko/roaksoax: But While it was doing juju bootstrap, we added change is not reflecting immediately. Because curtin script is going very fast. without taking our changes it was giving issues.
[13:52] <rock__> kiko/roaksoax: So can we modify curtin script to put delay before running apt-get update?
[13:53] <rock__> kiko/roaksoax: Please tell me how to edit curtin script if we can.
[13:58] <baldpope> rock__, why do you think you need to edit curtain?
[13:59] <rock__> baldpope: whie running curtin script only right we got that issue.
[14:00] <baldpope> but (as I understand it) curtain is just setting up your environment, and arguably you'd want to run an apt-get update as one of the first things, right?
[14:00] <baldpope> so instead of skipping that step, lets figure out why it's failing
[14:01] <rock__> baldpope: Just look at /etc/maas/preseeds/curtin_userdata
[14:02] <rock__> baldpope: Curtin itself doing apt-get update . there it is failing
[14:03] <rock__> baldpope: Curtin installation failed due to that apt-get update failure
[14:06] <neith> anyone knows if I can deploy heat with autopilot or other penstac modules?
[14:06] <neith> *Openstack
[14:07] <rock__> kiko/roaksoax: Please give me the reply  .
[14:07] <kiko> rock__, I have already told you what I can
[14:08] <kiko> either it's bad at source (my #1 bet), goes bad over the wire, or goes bad upon reception.
[14:22] <rock__> kiko: OK. Thank you for your support.
[14:28] <rock__> roaksoax: How can I customize the curtin script?
[14:37] <neith> kiko: Can I deploy the heat component with juju on an openstack autopilot deployment?
[14:42] <rock__> roaksoax: cloud-init-output.log for my issue: http://paste.openstack.org/show/582417/. If you have any idea please help me.
[14:58] <roaksoax> rock__: a problem with your mirror http://ubuntu.cs.utah.edu/ubuntu
[14:59] <roaksoax> rock__: maybe your mirror has older packages than the ones in the Ubuntu image
[14:59] <roaksoax> or similar
[15:18] <lucas__> good day guys
[15:18] <lucas__> anyone
[15:23] <kiko> roaksoax, I've tried to tell rock__ that a few times, but was unable to communicate effectively :-/
[15:24] <kiko> neith, you can't. I think we have juju charms for heat, though, and you can probably deploy manually -- it's not that much harder than using autopilot
[15:50] <roaksoax> wom 12
[16:02] <rock__> roaksoax: Thank you . Actually I tried with different mirrors . But I faced the same issue. OK. I will try to redeploy once again. Thanks .
[16:04] <rock__> kiko:  No problem, You provide good info. Thank you.
[16:40] <kiko> rock__, could your RAM or CPU or NIC be bad?