Re: [Openstack] help - Fuel Community 11 - PXE

2017-10-31 Thread Evgeniy L
I'm not sure if these options should be set, because they are required only
if PXE server is on different host from DHCP server, which is not the case
for Fuel.

On Thu, Oct 26, 2017 at 8:25 AM, Ken Houle 
wrote:

> Evgeniy L:
>
>
>
> Thank you for the information. I have a few, possible silly/noob,
> question. After your email I reviewed the tcpdump again and identified that
> the “dhcp offer” does not contain options 66 and 67.
>
> You can see from the excerpt of a bootp capture the highlighted portions
> contain the IP address offered, next server, and boot file.
>
>
>
> However, in the options section there is not an option 66, tftp server
> name, and option 67, bootfile name.
>
>
>
> SO here is the question, taking cobbler into account which file should I
> be editing to attempt to add these options? Is the
> “/etc/cobbler/dhcp.template” file the correct file; thought “template”
> seems to  indicate that it is not?
>
> If not, again silly/noob, which file should I be editing.
>
>
>
> Any assistance would be appreciated.
>
>
>
>
>
> Frame 4138: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits)
>
> Ethernet II, Src: Dell_b9:6a:02 (d4:ae:52:b9:6a:02), Dst: Broadcast
> (ff:ff:ff:ff:ff:ff)
>
> Internet Protocol Version 4, Src: 10.10.30.10, Dst: 255.255.255.255
>
> User Datagram Protocol, Src Port: 67, Dst Port: 68
>
> Bootstrap Protocol (Offer)
>
> Message type: Boot Reply (2)
>
> Hardware type: Ethernet (0x01)
>
> Hardware address length: 6
>
> Hops: 0
>
> Transaction ID: 0x906a77f9
>
> Seconds elapsed: 18
>
> Bootp flags: 0x8000, Broadcast flag (Broadcast)
>
> 1...    = Broadcast flag: Broadcast
>
> .000    = Reserved flags: 0x
>
> Client IP address: 0.0.0.0
>
> Your (client) IP address: 10.10.30.21
>
> Next server IP address: 10.10.30.10
>
> Relay agent IP address: 0.0.0.0
>
> Client MAC address: SuperMic_6a:77:f9 (00:25:90:6a:77:f9)
>
> Client hardware address padding: 
>
> Server host name: boothost
>
> Boot file name: pxelinux.0
>
> Magic cookie: DHCP
>
> Option: (53) DHCP Message Type (Offer)
>
> Option: (54) DHCP Server Identifier
>
> Option: (51) IP Address Lease Time
>
> Option: (58) Renewal Time Value
>
> Option: (59) Rebinding Time Value
>
> Option: (1) Subnet Mask
>
> Option: (28) Broadcast Address
>
> Option: (15) Domain Name
>
> Option: (6) Domain Name Server
>
> Option: (3) Router
>
> Option: (255) End
>
> Padding: 00
>
>
>
> Regards,
>
>
>
> *Ken Houle*
> 469-634-4171 : kho...@developingsolutions.com
>
>
>
> *From:* Evgeniy L [mailto:e...@mirantis.com]
> *Sent:* Wednesday, October 25, 2017 11:45 AM
> *To:* Ken Houle 
> *Cc:* Openstack 
> *Subject:* Re: [Openstack] help - Fuel Community 11 - PXE
>
>
>
> Hi Ken,
>
>
>
> Fuel uses Cobbler which uses DNSMasq to provide DHCP and PXE boot, if the
> issue is hardware specific, you can try to search if anybody else had such
> problems with DNSMasq PXE boot and similar hardware.
>
>
>
> Thanks,
>
>
>
> On Wed, Oct 25, 2017 at 7:12 AM, Ken Houle 
> wrote:
>
> All:
>
>
>
> First off not sure I am in the right place so if I am not please be kind
> and point me in the correct direction. I am attempting to build an
> Openstack system with Fuel Community 11 with a mix servers from different
> manufacturers. I have successfully installed Fuel Community 11 on the
> master node and am attempting to add nodes to the Openstack environment.
> The “Dell” servers pxe boot fine, see the master node and can be added to
> the system. However, I have an older “Silicon Mechanics” server that will
> not pxe boot.
>
>
>
> I have upgraded the AMI BIOS on the “Supermicro” system board to the
> latest release as well as the IPMI firmware. I have attempted to use both
> legacy and UEFI boot from the BIOS and I always see the same error. Please
> note that the Intel PXE release is 1.5.13.
>
>
>
> “PXE-E7B: Missing MTFTP server IP address. This message is displayed when
> the ROM did not receive any PXE discovery tags or proxyDHCP offers and the
> DHCP SIADDR field is set to 0.0.0.0.”
>
>
>
> I have take a tcpdump and see the dhcp discover and the dhcp offer. The
> Fuel master node is offering the server an IP address and is telling it
> what its next server and file are.
>
>
>
> Any assistance and or information would 

Re: [Openstack] Fuel-9.2 - Broken deployment on one node stops all other nodes too

2017-10-31 Thread Evgeniy L
time'
> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/util.rb:335:in
> `block in thinmark'
> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:147:in
> `block (2 levels) in evaluate'
> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:147:in
> `call'
> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:217:in
> `eval_resource'
> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:204:in
> `apply'
> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/
> transaction/resource_harness.rb:20:in `evaluate'
> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/
> transaction/resource_harness.rb:81:in `perform_changes'
> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/
> transaction/resource_harness.rb:128:in `sync_if_needed'
> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/
> transaction/resource_harness.rb:204:in `sync'
> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/property.rb:581:in
> `sync'
> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/property.rb:498:in
> `set'
> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/property.rb:197:in
> `call_valuemethod'
> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/type/package.rb:73:in
> `block (3 levels) in '
> 2017-10-31 06:45:11ERR/etc/puppet/modules/osnailyfacter/lib/
> puppet/provider/package/apt_fuel.rb:72:in `install'
> 2017-10-31 06:45:11ERR/etc/puppet/modules/osnailyfacter/lib/
> puppet/provider/package/apt_fuel.rb:72:in `each'
> 2017-10-31 06:45:11ERR/etc/puppet/modules/osnailyfacter/lib/
> puppet/provider/package/apt_fuel.rb:74:in `block in install'
> 2017-10-31 06:45:11ERR/etc/puppet/modules/osnailyfacter/lib/
> puppet/provider/package/apt_fuel.rb:66:in `wait_for_lock'
> 2017-10-31 06:45:11ERR/etc/puppet/modules/osnailyfacter/lib/
> puppet/provider/package/apt_fuel.rb:75:in `block (2 levels) in install'
> 2017-10-31 
> 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/provider/package/apt.rb:73:in
> `install'
> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/provider.rb:463:in
> `block in create_class_and_instance_method'
> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/provider.rb:237:in
> `block in has_command'
> 2017-10-31 
> 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/provider/command.rb:23:in
> `execute'
> 2017-10-31 
> 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/util/execution.rb:219:in
> `execute'
> 2017-10-31 06:45:11ERRE: Unable to locate package fuel-ha-utils
> 2017-10-31 06:45:11ERRReading state information...
> 2017-10-31 06:45:11ERRBuilding dependency tree...
>
> I can see fuel-ha-utils deb package in /var/www/ tree:
>
> [root@fuel ~]# cd /var/www/nailgun/
> [root@fuel nailgun]# find . -name fuel-ha-utils*
> ./mitaka-9.0/mos-centos/x86_64/Packages/fuel-ha-utils-9.0.
> 0-1.mos8460.noarch.rpm
> ./mitaka-9.0/ubuntu/x86_64/pool/main/f/fuel-library9.0/
> fuel-ha-utils_9.0.0-1~u14.04+mos8460_all.deb
> [root@fuel nailgun]#
>
> On a node which was installed before building local repo, I can see the
> package fuel-ha-utils installed, but a different version i think:
> root@node-4:~# dpkg -l fuel-ha-utils
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/
> trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name   Version
> Architecture Description
> +++-==--
> -===
> ===
> ii  fuel-ha-utils  9.0.0-1~u14.04+mos87
> all  Fuel Library HA utils
> root@node-4:~#
>
> Is there a way to fix this problem? Or should I just remove all nodes and
> start the deployment from scratch - since local repo was built after
> deploying 5 nodes?
>
> Please advise.
>
> Best Regards,
> Raja.
>
> On 30 October 2017 at 19:27, Evgeniy L  wrote:
>
>> Hi,
>>
>> fuel_pkgs/9 means that "fuel_pkgs" task failed on node with id 9, find
>> the node with this id using "fuel node" (run it from Fuel node), ssh to the
>> nodes and look for errors in /var/log/puppet.log.
>>
>> If Nova service was running before, it should be running even after
>> fuel_pkgs task failed on one of the nodes, see nova logs, to find what
>> happened to nova.
>>
>> Thanks,
>>
>> On Mon, Oct 30, 2017 at 12:23 AM, Raja T Nair  wrote:
>>
>>> Hello All,
>>>
>>> Trying to add one more node to the group, and it breaks with error:
>>> Failed tasks: Task[fuel_pkgs/9] Stopping the deployment process!
>>>
>>> But now the entire cluster is stopped - nova service on all nodes are
>>> down.
>>> Is this expected behaviour? How do I get back my cluster active?
>>>
>>> Please help me to resolve this problem.
>>>
>>> Regards,
>>> Raja.
>>>
>>>
>>> --
>>> :^)
>>>
>>> ___
>>> Mailing list: http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>> Post to : openstack@lists.openstack.org
>>> Unsubscribe : http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>>
>>>
>>
>
>
> --
> :^)
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] Fuel-9.2 - Broken deployment on one node stops all other nodes too

2017-10-30 Thread Evgeniy L
Hi,

fuel_pkgs/9 means that "fuel_pkgs" task failed on node with id 9, find the
node with this id using "fuel node" (run it from Fuel node), ssh to the
nodes and look for errors in /var/log/puppet.log.

If Nova service was running before, it should be running even after
fuel_pkgs task failed on one of the nodes, see nova logs, to find what
happened to nova.

Thanks,

On Mon, Oct 30, 2017 at 12:23 AM, Raja T Nair  wrote:

> Hello All,
>
> Trying to add one more node to the group, and it breaks with error:
> Failed tasks: Task[fuel_pkgs/9] Stopping the deployment process!
>
> But now the entire cluster is stopped - nova service on all nodes are down.
> Is this expected behaviour? How do I get back my cluster active?
>
> Please help me to resolve this problem.
>
> Regards,
> Raja.
>
>
> --
> :^)
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] help - Fuel Community 11 - PXE

2017-10-25 Thread Evgeniy L
Hi Ken,

Fuel uses Cobbler which uses DNSMasq to provide DHCP and PXE boot, if the
issue is hardware specific, you can try to search if anybody else had such
problems with DNSMasq PXE boot and similar hardware.

Thanks,

On Wed, Oct 25, 2017 at 7:12 AM, Ken Houle 
wrote:

> All:
>
>
>
> First off not sure I am in the right place so if I am not please be kind
> and point me in the correct direction. I am attempting to build an
> Openstack system with Fuel Community 11 with a mix servers from different
> manufacturers. I have successfully installed Fuel Community 11 on the
> master node and am attempting to add nodes to the Openstack environment.
> The “Dell” servers pxe boot fine, see the master node and can be added to
> the system. However, I have an older “Silicon Mechanics” server that will
> not pxe boot.
>
>
>
> I have upgraded the AMI BIOS on the “Supermicro” system board to the
> latest release as well as the IPMI firmware. I have attempted to use both
> legacy and UEFI boot from the BIOS and I always see the same error. Please
> note that the Intel PXE release is 1.5.13.
>
>
>
> “PXE-E7B: Missing MTFTP server IP address. This message is displayed when
> the ROM did not receive any PXE discovery tags or proxyDHCP offers and the
> DHCP SIADDR field is set to 0.0.0.0.”
>
>
>
> I have take a tcpdump and see the dhcp discover and the dhcp offer. The
> Fuel master node is offering the server an IP address and is telling it
> what its next server and file are.
>
>
>
> Any assistance and or information would be greatly appreciated.
>
>
>
>
>
> Regards,
>
>
>
> [image: logo] 
>
> *Ken Houle*
> *Sales Engineering *
> *Developing Solutions, Inc.* 
> 469-634-4171 : kho...@developingsolutions.com
>
>
>
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] Mirantis - Fuel 9.2 Failed Deployment

2017-10-25 Thread Evgeniy L
t/transaction.rb:138:in `evaluate'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/graph/relationship_graph.rb:118:in
>>>>> `traverse'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:147:in `block in
>>>>> evaluate'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/util.rb:334:in `thinmark'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/util.rb:335:in `block in thinmark'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:147:in `block (2
>>>>> levels) in evaluate'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:147:in `call'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:221:in `eval_resource'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/transaction/event_manager.rb:19:in
>>>>> `process_events'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/transaction/event_manager.rb:92:in
>>>>> `queued_events'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/transaction/event_manager.rb:92:in
>>>>> `each'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/transaction/event_manager.rb:93:in
>>>>> `block in queued_events'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/transaction/event_manager.rb:20:in
>>>>> `block in process_events'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/transaction/event_manager.rb:101:in
>>>>> `process_callback'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/type/exec.rb:583:in `refresh'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/type/exec.rb:127:in `sync'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/type/exec.rb:127:in `times'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/type/exec.rb:130:in `block in sync'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/provider/exec/posix.rb:45:in `run'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/provider/exec.rb:29:in `run'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/provider/exec.rb:29:in `chdir'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/provider/exec.rb:64:in `block in run'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/provider/exec.rb:68:in `block (2
>>>>> levels) in run'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>>>> /usr/lib/ruby/vendor_ruby/puppet/util/execution.rb:186:in `execute'
>>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update])
>>&g

Re: [Openstack] Mirantis - Fuel 9.2 Failed Deployment

2017-10-24 Thread Evgeniy L
Hi,

Yes, execution expired, means that it could not build an image within
required period of time.
The message you see can be used to build an image (copy paste into console
"command"), also there is a file with logs /var/log/fuel-agent-env-1.log,
which you can use to try to identify where the problem is.

Thanks,

On Tue, Oct 24, 2017 at 7:48 AM, Raja T Nair  wrote:

> Hello All,
>
> We are trying to deploy one environment using Fuel 9.2, and it failed at
> around 23%.
>
> The error says:
>
> <>
> Error
> Provision has failed. Failed to execute hook 'shell'
>
> command: cd / && fa_build_image --image_build_dir /var/lib/fuel/ibp
> --log-file /var/log/fuel-agent-env-1.log --data_driver nailgun_build_image
> --input_data '{"image_data": {"/boot": {"container": "gzip", "uri": "
> http://172.22.66.2:8080/targetimages/env_1_ubuntu_1404_amd64-boot.img.gz";,
> "format": "ext2"}, "/": {"container": "gzip", "uri": "
> http://172.22.66.2:8080/targetimages/env_1_ubuntu_1404_amd64.img.gz";,
> "format": "ext4"}}, "output": "/var/www/nailgun/targetimages", "repos":
> [{"name": "ubuntu", "section": "main universe multiverse", "uri": "
> http://archive.ubuntu.com/ubuntu/";, "priority": null, "suite": "trusty",
> "type": "deb"}, {"name": "ubuntu-updates", "section": "main universe
> multiverse", "uri": "http://archive.ubuntu.com/ubuntu/";, "priority":
> null, "suite": "trusty-updates", "type": "deb"}, {"name":
> "ubuntu-security", "section": "main universe multiverse", "uri": "
> http://archive.ubuntu.com/ubuntu/";, "priority": null, "suite":
> "trusty-security", "type": "deb"}, {"name": "mos", "section": "main
> restricted", "uri": "http://172.22.66.2:8080/mitaka-9.0/ubuntu/x86_64";,
> "priority": 1050, "suite": "mos9.0", "type": "deb"}, {"name":
> "mos-updates", "section": "main restricted", "uri": "
> http://mirror.fuel-infra.org/mos-repos/ubuntu/9.0/";, "priority": 1050,
> "suite": "mos9.0-updates", "type": "deb"}, {"name": "mos-security",
> "section": "main restricted", "uri": "http://mirror.fuel-infra.org/
> mos-repos/ubuntu/9.0/", "priority": 1050, "suite": "mos9.0-security",
> "type": "deb"}, {"name": "mos9.2-updates", "section": "main restricted",
> "uri": "http://mirror.fuel-infra.org/mos-repos/ubuntu/9.2";, "priority":
> 1050, "suite": "mos9.0-updates", "type": "deb"}, {"name":
> "mos9.2-security", "section": "main restricted", "uri": "
> http://mirror.fuel-infra.org/mos-repos/ubuntu/9.2";, "priority": 1050,
> "suite": "mos9.0-security", "type": "deb"}, {"name": "Auxiliary",
> "section": "main restricted", "uri": "http://172.22.66.2:8080/
> mitaka-9.0/ubuntu/auxiliary", "priority": 1150, "suite": "auxiliary",
> "type": "deb"}, {"name": "mos9.2-holdback", "section": "main restricted",
> "uri": "http://mirror.fuel-infra.org/mos-repos/ubuntu/9.2";, "priority":
> 1100, "suite": "mos9.0-holdback", "type": "deb"}], "packages": ["acl",
> "anacron", "bash-completion", "bridge-utils", "bsdmainutils",
> "build-essential", "cloud-init", "curl", "daemonize", "debconf-utils",
> "gdisk", "grub-pc", "hwloc", "i40e-dkms", "linux-firmware",
> "linux-firmware-nonfree", "linux-headers-generic-lts-xenial",
> "linux-image-generic-lts-xenial", "lvm2", "mcollective", "mdadm",
> "multipath-tools", "multipath-tools-boot", "nailgun-agent",
> "nailgun-mcagents", "network-checker", "ntp", "openssh-client",
> "openssh-server", "puppet", "python-amqp", "ruby-augeas", "ruby-ipaddress",
> "ruby-json", "ruby-netaddr", "ruby-openstack", "ruby-shadow", "ruby-stomp",
> "telnet", "ubuntu-minimal", "ubuntu-standard", "uuid-runtime", "vim",
> "virt-what", "vlan"], "codename": "trusty"}'
>
> Task: a84a3af7-2ed4-4d5e-9911-a12dfc0f05e9: overall timeout error:
> execution expired
> Task timeout: 3600, Retries: 1
>
> 
>
> I understand it was a timeout, probably because of a slow Internet
> connection, while building a required image - please correct me if I'm
> wrong here.
>
> Might be stupid question - but is there a way for me to build such images
> before clicking the deploy button, thereby avoiding the timeout issue?
>
> Can anyone guide me or point me to a document to understand what is going
> wrong here?
>
> Many thanks in advance.
>
> Regards,
> Raja.
>
> --
> :^)
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] [Fuel] Danube Fuel 10 compute node base system partition size

2017-10-03 Thread Evgeniy L
Hi Jim,

It's possible to change the amount of space required for base system, but
it will require to change partitioning schema in release model.

You can retrieve it from Nailgun using:
curl -H "X-Auth-Token: $(fuel token)"
http://172.29.194.19:8000/api/v1/releases// | python -m
json.tool > rel.json

Fix rel.json file and upload it back with PUT request.

The format of volume configuration is described in these documents:
https://github.com/openstack/fuel-docs/blob/master/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles/volume-allocation.rst
https://docs.openstack.org/fuel-docs/latest/devdocs/develop/nailgun/customization/partitions.html

Let me know if you need any other help with that.

Thanks,


On Wed, Sep 13, 2017 at 8:30 AM, Jim Okken  wrote:

> Hi all,
>
>
>
>
> In danube disk provisioning for a compute node, the smallest
> disk/partition size for the base system is 54GB.
>
>
>
> After I deploy a compute node I see 44GB free of the 54GB. So it seems
> something smaller that 54GB can be used.
>
>
>
> Can I somehow change the setting for the smallest disk/partition size to
> something smaller so I can have Fuel deploy the base OS to a smaller drive?
>
> I have 14 HP blades with an internal 32GB disk which I would prefer to use
> for the base system.
>
>
>
>
>
>
>
> See /dev/mapper/os-root:
>
>
>
> Filesystem   Size  Used Avail
> Use% Mounted on
>
> udev  63G 0   63G
> 0% /dev
>
> tmpfs 13G   49M   13G
> 1% /run
>
> /dev/mapper/os-root   50G  3.0G   44G   7% /
>
> tmpfs 63G 0   63G
> 0% /dev/shm
>
> tmpfs5.0M 0  5.0M
> 0% /run/lock
>
> tmpfs 63G 0   63G
> 0% /sys/fs/cgroup
>
> /dev/sda3196M   58M  129M
> 32% /boot
>
> /dev/mapper/vm-nova  318G   33M  318G   1%
> /var/lib/nova
>
> cgmfs100K 0  100K
> 0% /run/cgmanager/fs
>
> /dev/mapper/3600c0ff0001ea00fa8a1b6590300-part1  280G  4.5G  275G
> 2% /mnt/MSA_FC_Vol1
>
> tmpfs 13G 0   13G
> 0% /run/user/0
>
>
>
>
> thanks!
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] Help needed with migrating Fuel server

2017-09-25 Thread Evgeniy L
Hi,

Try following this guide:
https://docs.mirantis.com/openstack/fuel/fuel-7.0/operations.html#howto-backup-and-restore-fuel-master

Thanks,

On Sun, Sep 24, 2017 at 11:57 PM, Raja T Nair  wrote:

> Hello All,
>
> Can somebody help me with info on how to migrate OR backup/restore fuel
> server to another hardware?
> Fuel version - fuel-7.0.0-6122.1
>
> We want to migrate fuel services to a new hardware.
>
> Many Thanks.
> Raja.
>
> --
> :^)
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] [Fuel] Fuel 11 does not boot into setup menu, does not install successfully

2017-09-25 Thread Evgeniy L
Hi,

I've never tried installing 11 version, but this looks suspicious:
fuelmenu=10.0.0

I think it should be version 11, not 10.

Thanks,

On Thu, Sep 21, 2017 at 9:30 AM, Tomas Brännström <
tomas.a.brannst...@tieto.com> wrote:

> Hi
> I'm trying to install the Fuel 11 release in a Virtualbox VM, but to no
> success. When the OS install is finished, instead of starting the fuelmenu,
> I just get to a login prompt. Scrolling up the tty reveals a stack trace
> from python:
>
> + fuelmenu --save-only --iface=eth0
> Traceback (most recent call last):
>   File "/bin/fuelmenu", line 9, in 
> load_entry_point('fuelmenu=10.0.0', 'console_scripts', 'fuelmenu')()
>   File "/usr/lib/python2.7/site-packages/fuelmenu/fuelmenu.py", line 385,
> in main
> managed_iface=options.iface)
>   File "/usr/lib/python2.7/site-packages/fuelmenu/fuelmenu.py", line 340,
> in setup
> FuelSetup(**kwargs)
>   File "/usr/lib/python2.7/site-packages/fuelmenu/fuelmenu.py", line 78,
> in __init__
> self.main()
>
> (sorry for any typos, I had to type it out by hand...)
>
> Once logged in I can run fuelmenu without any arguments, but even after
> doing the regular configuration there I can tell that everything hasn't
> been successfully installed: the web GUI is not running and I can't ssh
> into the VM. Also the install procedure usually takes a lot longer than
> what I'm seeing here.
>
> This is running in Virtualbox version 5.1.26r117224. The VM has two NIC's
> (one NAT:ed and one bridged with the ADMIN vlan), if that matters.
>
> We've been using Fuel 9 previously without issues.
>
> /Tomas
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] Mirantis Fuel 9.2 - nailgund not available when attempting to save changes to cloud environment

2017-04-05 Thread Evgeniy L
Given the fact that you can see settings tab with parameters, the error
"Nailgun server is unavailable.  Please check your connection and contact
your system administrator." most likely means that Nailgun responded with
5xx error, which may happen because of some unhandled exception.

1. We need to confirm that the problem is indeed in unhandled exception.
In "/var/log/nailgun/api.log" you should see an api request from your
browser and corresponding response code.

2. Without python traceback/logs it's hard to say what went wrong, as far
as I remember python traceback will be in "/var/log/nailgun/api.log" file
alongside with a request from your browser.

Thanks,

On Wed, Apr 5, 2017 at 9:29 AM, sil...@gmail.com  wrote:

> When I attempt to save any changes to a cloud environment I've created,
> such as within 'Setting' changing 'Hypervisor type' in the 'Compute'
> setting menu from 'QEMU' to 'KVM', the save button circles for about
> 7-8secs and then a pop-up dialog box comes up that says:
>
> OpenStack Settings Configuration Error
>
> Nailgun server is unavailable.  Please check your connection and contact
> your system administrator.
>
> This happens while trying to use any version of Fuel greater than 9.0 on a
> HP DL180 gen6 server (I also tried version 11 with the same results). I can
> use any version of Fuel without problems using identical settings on a Dell
> r610 server.
>
> I checked all of the logs in /var/log/nailgun and none of them indicate
> any errors that I can see.  There are also plenty of nailgun related
> processes running on the Fuel server.
>
> On 04/05/2017 10:14 AM, Evgeniy L wrote:
>
>> Hi,
>>
>> Could you please clarify, do you receive this error in the UI? What do
>> you mean by "save any changes"?
>> I'm not sure if ranges can cause such behavior, please see logs
>> "/var/log/nailgun/app.log" and "/var/log/nailgun/api.log" for any
>> errors/python tracebacks.
>>
>> Thanks,
>>
>> On Mon, Apr 3, 2017 at 8:12 PM, sil...@gmail.com
>> <mailto:sil...@gmail.com> mailto:sil...@gmail.com>>
>> wrote:
>>
>> Has anyone had a problem with Mirantis Fuel giving a 'nailgund not
>> available' error when attempting to save any changes to a cloud
>> environment?  I'm encountering this problem after a fresh install of
>> Mirantis Fuel 9.0 and then immediately upgrading to 9.2 (didn't even
>> login to the Fuel web interface prior to the upgrade).
>>
>> I've verified that nailgund is running and the network configured in
>> 'fuelmenu' during the initial 9.0 install is legit with Internet
>> connectivity (172.16.0.0/22 <http://172.16.0.0/22> network,
>> 172.16.3.250 is fuel server, 172.16.0.1 is the Internet gateway and
>> 172.16.1.1-172.16.2.254 is handed out via the fuel DHCP server).
>> I've also verified that no other DHCP servers exist on this network,
>> no errors or warnings in the 'fuelmenu' portion of the installation.
>>
>> I've installed this before using the same exact methods/options on
>> some Dell hardware in a lab of mine however I'm having this problem
>> on a production deployment using some older HP servers.  The only
>> difference between the functional installation and this one is the
>> IP ranges that were used and I set a root/admin password on the
>> production setup (I left admin/root at default on the functional
>> setup).  I have a suspicion that using the 172.16.0.0/22
>> <http://172.16.0.0/22> network as the admin/PXE network for fuel
>> deployments might be the culprit as I noticed that the nailgund
>> config file defines '172.16.0.0/16 <http://172.16.0.0/16>' as
>> 'PUBLIC' in the template section as shown below:
>>
>> /etc/nailgun/settings.yaml
>>
>> "
>> STATIC_DIR: "/usr/share/nailgun/static"
>> TEMPLATE_DIR: "/usr/share/nailgun/static"
>> NETWORK_POOLS:
>>   public:
>> - "172.16.0.0/16 <http://172.16.0.0/16>"
>>   private10:
>> - "10.0.0.0/8 <http://10.0.0.0/8>"
>>   private192:
>> - "192.168.0.0/16 <http://192.168.0.0/16>"
>>
>> NET_EXCLUDE:
>>   - "172.16.0.0/22 <http://172.16.0.0/22>"
>>
>> ADMIN_NETWORK:
>>   cidr: "172.16.0.0/22 <http://172.16.0.0/22>"
>>

Re: [Openstack] Fuel Reset Environment Never works

2017-04-05 Thread Evgeniy L
Hi,

Could you please elaborate on the issue? What do you see after reset? How
does consequent deployment fail?

Thanks,

On Tue, Apr 4, 2017 at 10:32 PM, Waqas Riaz  wrote:

> Hi,
>
> Does anyone know why Fuel's Reset Environment feature never works?
> The deployment after a reset always fails. I'm forced to delete the
> environment and start all over again and only then does the deployment
> finish successfully.
>
> It'll save me much time if somehow I can figure out how to get Fuel's
> Reset Environment to work.
> I am using Fuel 11, with Ocata OpenStack.
>
> Thanks!
> Waqas Riaz
>
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] Mirantis Fuel 9.2 - nailgund not available when attempting to save changes to cloud environment

2017-04-05 Thread Evgeniy L
Hi,

Could you please clarify, do you receive this error in the UI? What do you
mean by "save any changes"?
I'm not sure if ranges can cause such behavior, please see logs
"/var/log/nailgun/app.log" and "/var/log/nailgun/api.log" for any
errors/python tracebacks.

Thanks,

On Mon, Apr 3, 2017 at 8:12 PM, sil...@gmail.com  wrote:

> Has anyone had a problem with Mirantis Fuel giving a 'nailgund not
> available' error when attempting to save any changes to a cloud
> environment?  I'm encountering this problem after a fresh install of
> Mirantis Fuel 9.0 and then immediately upgrading to 9.2 (didn't even login
> to the Fuel web interface prior to the upgrade).
>
> I've verified that nailgund is running and the network configured in
> 'fuelmenu' during the initial 9.0 install is legit with Internet
> connectivity (172.16.0.0/22 network, 172.16.3.250 is fuel server,
> 172.16.0.1 is the Internet gateway and 172.16.1.1-172.16.2.254 is handed
> out via the fuel DHCP server).  I've also verified that no other DHCP
> servers exist on this network, no errors or warnings in the 'fuelmenu'
> portion of the installation.
>
> I've installed this before using the same exact methods/options on some
> Dell hardware in a lab of mine however I'm having this problem on a
> production deployment using some older HP servers.  The only difference
> between the functional installation and this one is the IP ranges that were
> used and I set a root/admin password on the production setup (I left
> admin/root at default on the functional setup).  I have a suspicion that
> using the 172.16.0.0/22 network as the admin/PXE network for fuel
> deployments might be the culprit as I noticed that the nailgund config file
> defines '172.16.0.0/16' as 'PUBLIC' in the template section as shown
> below:
>
> /etc/nailgun/settings.yaml
>
> "
> STATIC_DIR: "/usr/share/nailgun/static"
> TEMPLATE_DIR: "/usr/share/nailgun/static"
> NETWORK_POOLS:
>   public:
> - "172.16.0.0/16"
>   private10:
> - "10.0.0.0/8"
>   private192:
> - "192.168.0.0/16"
>
> NET_EXCLUDE:
>   - "172.16.0.0/22"
>
> ADMIN_NETWORK:
>   cidr: "172.16.0.0/22"
>   netmask: "255.255.252.0"
>   mac: "e4:11:5b:e6:90:3a"
>   size: "1024"
>   first: "172.16.1.1"
>   last: "172.16.2.254"
>   gateway: "172.16.3.250"
>
> VLANS_RANGE_START: "100"
> VLANS_RANGE_END: "1000"
> "
>
> I tried using Mirantis Fuel 9.0 without patching and it doesn't exhibit
> this same problem although this time around I left the admin/root passwords
> at default and did not set them as I did with the previous installations
> when I upgraded directly to 9.2 so I'm not sure if that is factoring in
> here.
>
> Any ideas what the issue may be?
>
> Also, sorry if this is a repost, I sent this email many hours ago and
> didn't see it appear on the mailing list archives, not sure what the issue
> is or if I didn't wait long enough.
>
> silox
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] [Fuel] - OpenStack installation using Fuel Error!!!Task[netconfig/21] Stopping the deployment process

2017-03-31 Thread Evgeniy L
Could you please elaborate on what is "services"? Do you want to assign
additional roles to already deployed node?

On Thu, Mar 30, 2017 at 11:12 PM, pratik dave  wrote:

> Thanks I have created a mirror and deployment done successfully.
>
> One more thing can we add more services to already added nodes?
>
> Or we have to scale down add services and again scale up?
>
> On Mar 30, 2017 9:12 PM, "Evgeniy L"  wrote:
>
>> The repository contains packages important for OpenStack installation, as
>> an option I can suggest to create a mirror of the repository on Fuel Master
>> [1].
>>
>> Thanks,
>>
>> [1] https://docs.openstack.org/developer/fuel-docs/userdocs/
>> fuel-install-guide/local-repo.html
>>
>> On Wed, Mar 29, 2017 at 11:23 PM, pratik dave  wrote:
>>
>>> Hi,
>>>
>>> Otherwise if you can help to configure repository for this would be
>>> grateful.
>>>
>>> Thanks
>>>
>>> On Mar 30, 2017 11:23 AM, "pratik dave"  wrote:
>>>
>>>> Hi,
>>>>
>>>> Thank you so much for your inputs , we could able to resolve the issue.
>>>>
>>>> Now, We are able to setup controller node successfully. However we are
>>>> getting below error in compute node.
>>>>
>>>> *2017-03-29 16:32:45 ERR ERROR: Unable to fetch url
>>>> 'http://mirror.fuel-infra.org/mos-repos/ubuntu/9.0/
>>>> <http://mirror.fuel-infra.org/mos-repos/ubuntu/9.0/>', error 'No route to
>>>> host - connect(2)'. *
>>>> *Please verify node connectivity to this URL, or remove it from the
>>>> settings page if it is invalid. on node node-22.domain.tld*
>>>>
>>>> Looking at the error we felt server is not able to reach internet to
>>>> download some repos. We have already provided Public domain interface for
>>>> compute but we could see we do not get any route for it.
>>>>
>>>> *root@node-22:~# ip route*
>>>> *default via 192.168.0.3 dev br-mgmt*
>>>> *10.20.0.0/24 <http://10.20.0.0/24> dev br-fw-admin  proto kernel
>>>>  scope link  src 10.20.0.4*
>>>> *unreachable 169.254.169.254  scope host*
>>>> *192.168.0.0/24 <http://192.168.0.0/24> dev br-mgmt  proto kernel
>>>>  scope link  src 192.168.0.5*
>>>> *192.168.1.0/24 <http://192.168.1.0/24> dev br-storage  proto kernel
>>>>  scope link  src 192.168.1.3*
>>>>
>>>> Default route goes to br-mgmt which is tagged vlan and does not go to
>>>> internet. Public interface does not come up for compute node where
>>>> controller node br-ex takes that IP and connects to internet.
>>>>
>>>> It is asking to remove from settings if it doesn't require, can we
>>>> remove that from settings?
>>>>
>>>> Please suggest.
>>>>
>>>> Thanks.
>>>>
>>>> On Mar 29, 2017 11:16 PM, "Evgeniy L"  wrote:
>>>>
>>>>> Look like default gateway (*10.144.243.129*) from node, where puppet
>>>>> failed is not available .
>>>>>
>>>>> On Tue, Mar 28, 2017 at 1:42 AM, pratik dave 
>>>>> wrote:
>>>>>
>>>>>> Hello Everyone,
>>>>>>
>>>>>> I am still stuck with this issue.
>>>>>>
>>>>>> As it looks like network config issue would like to explain how I
>>>>>> configured my network configuration here.
>>>>>>
>>>>>> We have fuel master node with two NIC.
>>>>>>
>>>>>> NIC1- Connected to Public network(vlan1120 )
>>>>>> NIC1- Connected for PXE boot(PG_OSP4NET)
>>>>>>
>>>>>> We have fuel controller and fule compute nodes with 3 NICs.
>>>>>>
>>>>>> NIC1- VLAN1120
>>>>>> NIC2- test-vlan1120
>>>>>> NIC3- PG_OSP4NET
>>>>>>
>>>>>> ###
>>>>>>
>>>>>> Now in network configuration tab I have three parts like PXE admin,
>>>>>> storage and management.
>>>>>>
>>>>>> I am not touching anything on storage and management just changing
>>>>>> public network with my vlan1120 network range.
>>>>>>
>>>>>> One more thing observed is if I use vlan tagging

Re: [Openstack] [Fuel] - OpenStack installation using Fuel Error!!!Task[netconfig/21] Stopping the deployment process

2017-03-30 Thread Evgeniy L
The repository contains packages important for OpenStack installation, as
an option I can suggest to create a mirror of the repository on Fuel Master
[1].

Thanks,

[1]
https://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/local-repo.html

On Wed, Mar 29, 2017 at 11:23 PM, pratik dave  wrote:

> Hi,
>
> Otherwise if you can help to configure repository for this would be
> grateful.
>
> Thanks
>
> On Mar 30, 2017 11:23 AM, "pratik dave"  wrote:
>
>> Hi,
>>
>> Thank you so much for your inputs , we could able to resolve the issue.
>>
>> Now, We are able to setup controller node successfully. However we are
>> getting below error in compute node.
>>
>> *2017-03-29 16:32:45 ERR ERROR: Unable to fetch url
>> 'http://mirror.fuel-infra.org/mos-repos/ubuntu/9.0/
>> <http://mirror.fuel-infra.org/mos-repos/ubuntu/9.0/>', error 'No route to
>> host - connect(2)'. *
>> *Please verify node connectivity to this URL, or remove it from the
>> settings page if it is invalid. on node node-22.domain.tld*
>>
>> Looking at the error we felt server is not able to reach internet to
>> download some repos. We have already provided Public domain interface for
>> compute but we could see we do not get any route for it.
>>
>> *root@node-22:~# ip route*
>> *default via 192.168.0.3 dev br-mgmt*
>> *10.20.0.0/24 <http://10.20.0.0/24> dev br-fw-admin  proto kernel  scope
>> link  src 10.20.0.4*
>> *unreachable 169.254.169.254  scope host*
>> *192.168.0.0/24 <http://192.168.0.0/24> dev br-mgmt  proto kernel  scope
>> link  src 192.168.0.5*
>> *192.168.1.0/24 <http://192.168.1.0/24> dev br-storage  proto kernel
>>  scope link  src 192.168.1.3*
>>
>> Default route goes to br-mgmt which is tagged vlan and does not go to
>> internet. Public interface does not come up for compute node where
>> controller node br-ex takes that IP and connects to internet.
>>
>> It is asking to remove from settings if it doesn't require, can we remove
>> that from settings?
>>
>> Please suggest.
>>
>> Thanks.
>>
>> On Mar 29, 2017 11:16 PM, "Evgeniy L"  wrote:
>>
>>> Look like default gateway (*10.144.243.129*) from node, where puppet
>>> failed is not available .
>>>
>>> On Tue, Mar 28, 2017 at 1:42 AM, pratik dave  wrote:
>>>
>>>> Hello Everyone,
>>>>
>>>> I am still stuck with this issue.
>>>>
>>>> As it looks like network config issue would like to explain how I
>>>> configured my network configuration here.
>>>>
>>>> We have fuel master node with two NIC.
>>>>
>>>> NIC1- Connected to Public network(vlan1120 )
>>>> NIC1- Connected for PXE boot(PG_OSP4NET)
>>>>
>>>> We have fuel controller and fule compute nodes with 3 NICs.
>>>>
>>>> NIC1- VLAN1120
>>>> NIC2- test-vlan1120
>>>> NIC3- PG_OSP4NET
>>>>
>>>> ###
>>>>
>>>> Now in network configuration tab I have three parts like PXE admin,
>>>> storage and management.
>>>>
>>>> I am not touching anything on storage and management just changing
>>>> public network with my vlan1120 network range.
>>>>
>>>> One more thing observed is if I use vlan tagging it goes ahead and
>>>> gives me error as 'No route to host for compute node'
>>>>
>>>> Any help on this would be appropriated.
>>>>
>>>> On Mar 27, 2017 11:28 PM, "pratik dave"  wrote:
>>>>
>>>>> Dear Evgeniy,
>>>>>
>>>>> I have got below puppet logs from dashboard of fuel.
>>>>>
>>>>> Could you please help me to resolve the issue and make my Mirantis
>>>>> OpenStack environment run successfully?
>>>>>
>>>>> Below are logs:
>>>>>
>>>>> 
>>>>> --
>>>>>
>>>>> *2017-03-27 17:18:57 ERR
>>>>> (/Stage[main]/Osnailyfacter::Netconfig::Netconfig/Ping_host[10.144.243.129]/ensure)
>>>>> change from down to up failed: Timeout waiting for host '10.144.243.129'
>>>>> status to become 'up' after 60 seconds!*
>>>>>
>>>>> *2017-03-27 17:18:57 ERR  /usr/bin/puppet:8:in `'*
>

Re: [Openstack] [Fuel] - OpenStack installation using Fuel Error!!!Task[netconfig/21] Stopping the deployment process

2017-03-29 Thread Evgeniy L
ruby/vendor_ruby/puppet/transaction/report.rb:112:in
>> `as_logging_destination'*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/util/log.rb:149:in `with_destination'*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/resource/catalog.rb:169:in `block in
>> apply'*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:138:in `evaluate'*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/graph/relationship_graph.rb:118:in
>> `traverse'*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:147:in `block in evaluate'*
>>
>> *2017-03-27 17:18:57 ERR /usr/lib/ruby/vendor_ruby/puppet/util.rb:334:in
>> `thinmark'*
>>
>> *2017-03-27 17:18:57 ERR /usr/lib/ruby/1.9.1/benchmark.rb:295:in
>> `realtime'*
>>
>> *2017-03-27 17:18:57 ERR /usr/lib/ruby/vendor_ruby/puppet/util.rb:335:in
>> `block in thinmark'*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:147:in `block (2 levels) in
>> evaluate'*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:147:in `call'*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:217:in `eval_resource'*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:204:in `apply'*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:20:in
>> `evaluate'*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:81:in
>> `perform_changes'*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:128:in
>> `sync_if_needed'*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:204:in
>> `sync'*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/property.rb:581:in `sync'*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/property.rb:503:in `set'*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/property.rb:178:in `call_provider'*
>>
>> *2017-03-27 17:18:57 ERR
>> /etc/puppet/modules/osnailyfacter/lib/puppet/provider/ping_host/ping_host.rb:38:in
>> `ensure='*
>>
>> *2017-03-27 17:18:57 ERR
>> /usr/lib/ruby/vendor_ruby/puppet/util/errors.rb:106:in `fail'*
>>
>> *2017-03-27 17:18:57 ERR  Timeout waiting for host '10.144.243.129'
>> status to become 'up' after 60 seconds!*
>>
>> 
>> --
>>
>> On Mar 27, 2017 10:12 PM, "pratik dave"  wrote:
>>
>>> Hi Evgeniy,
>>>
>>> Thanks for your reply.
>>>
>>> I went to /var/log bt I could not find puppet.log anywhere. Is it
>>> possible for you to guide?
>>>
>>> Please refer below screenshot.
>>>
>>> On Mar 27, 2017 9:23 PM, "Evgeniy L"  wrote:
>>>
>>>> Hi,
>>>>
>>>> *netconfig* task is responsible for network configuration.
>>>> *21* - specifies a node id, where task failed, use `fuel node | grep
>>>> 21` to find ip address of the node, go to the node using ssh and see
>>>> results of puppet execution "/var/log/puppet.log".
>>>>
>>>> Thanks,
>>>>
>>>> On Mon, Mar 27, 2017 at 7:56 AM, pratik dave 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am trying to deploy openstack ubuntu using FUEL 9.0.
>>>>>
>>>>> I am adding 2 nodes and selecting controller and compute+cinder; i am
>>>>> getting below eeror on controller node while openstack deployment.
>>>>>
>>>>> *13:17:11*
>>>>>
>>>>> *Deployment has failed. All nodes are finished. Failed tasks:
>>>>> Task[netconfig/21] Stopping the deployment process!*
>>>>>
>>>>> *13:17:11*
>>>>>
>>>>> *Failed to deploy node 'Untitled (b1:04)': Unknown error*
>>>>>
>>>>> Any help on this would be appriciated.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> ___
>>>>> Mailing list: http://lists.openstack.org/cgi
>>>>> -bin/mailman/listinfo/openstack
>>>>> Post to : openstack@lists.openstack.org
>>>>> Unsubscribe : http://lists.openstack.org/cgi
>>>>> -bin/mailman/listinfo/openstack
>>>>>
>>>>>
>>>>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] [Fuel] - OpenStack installation using Fuel Error!!!Task[netconfig/21] Stopping the deployment process

2017-03-27 Thread Evgeniy L
Hi,

*netconfig* task is responsible for network configuration.
*21* - specifies a node id, where task failed, use `fuel node | grep 21` to
find ip address of the node, go to the node using ssh and see results of
puppet execution "/var/log/puppet.log".

Thanks,

On Mon, Mar 27, 2017 at 7:56 AM, pratik dave  wrote:

> Hi,
>
> I am trying to deploy openstack ubuntu using FUEL 9.0.
>
> I am adding 2 nodes and selecting controller and compute+cinder; i am
> getting below eeror on controller node while openstack deployment.
>
> *13:17:11*
>
> *Deployment has failed. All nodes are finished. Failed tasks:
> Task[netconfig/21] Stopping the deployment process!*
>
> *13:17:11*
>
> *Failed to deploy node 'Untitled (b1:04)': Unknown error*
>
> Any help on this would be appriciated.
>
> Thanks.
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] [Fuel] Unable to provision Compute node

2017-03-27 Thread Evgeniy L
Hi,

There is a parameter reboot_timeout in /etc/astute/astuted.conf file on
Fuel node.
But there were some changes in provisioning process in latest versions, so
I'm not 100% sure that it will help.

Thanks,

On Fri, Mar 17, 2017 at 8:33 AM, Vimal Kumar  wrote:

> 2017-03-17 15:31:56 ERROR [1236] c2cdd699-609d-4904-9d19-3e1269347d0c:
> file was not uploaded /tmp/provision.json on node 3 with timeout 180: node
> has not answered
>
> Is there any way to extend this 180 timeout?
>
> On Fri, Mar 17, 2017 at 5:00 PM, Vimal Kumar  wrote:
>
>> Hi,
>>
>> I am trying to install OpenStack using Fuel 11. A Fuel slave was
>> provisioned successfully as Controller, but when I try to provision another
>> slave as Compute, I am facing some issues.
>>
>> During provisioning, the 'system_provision' task always fails. This task
>> refers to /usr/bin/provision but I see that this executable is not even
>> present in the slave node (it is there in the master though). Is it normal?
>>
>> Secondly, this particular server takes a while to boot up (around 5-6
>> minutes). From astute logs I see that the timeout value is 180 seconds. The
>> server never comes back online within this time and always goes "away" and
>> the task fails. Is there any configuration file where I can increase
>> timeout for reboot tasks?
>>
>> Thank you!
>>
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] [Fuel] Cannot access Fuel 10.0 UI because of unavailable Nailgun server

2017-02-13 Thread Evgeniy L
I have several additional questions:
1. What version of Fuel do you use?
2. What instruction do you fallow to install Fuel?

>> reinstalling from a "basic" CentOS 7 installation
3.  Could you please clarify how exactly you do installation?

Thanks,

On Mon, Feb 13, 2017 at 9:33 AM, Vincent Jahjah 
wrote:

> So, I tried reinstalling from a "basic" CentOS 7 installation.
>
> I observed similar strange behavior from the previous time I tried the
> installation, which means it is reproducible and that I don't can't move on.
>
>
> I don't know how to export the log file from my server, and considering
> its size, I doubt it's much of a loss if I send only screenshots of the
> most suspicious parts. The last one specifically is the Cobbler failure,
> which has a stacktrace that doesn't seem to appear in the log file; it only
> appears during the error (and I can't scroll up D:).
>
>
> Reading the error, I checked if httpd was running, but "status" indicates
> it's active. I'm not sure what is meant by "SELinux could be in the way".
>
>
> The other screenshots are in chronological order, the first one occurring
> shortly after the GRUB setup of fuel; I understand it has to do with
> finding apt-get-like programs.
>
>
> (I'm sorry if my feedback output is limited: the cycle for reproducing the
> error is of about an hour and I'm very limited by my remote-access
> technology in terms of copy-pasting things. If you really need additional
> feedback, I'll do my best to give you the full output)
>
>
> Regards
> --
> *De :* Evgeniy L 
> *Envoyé :* 10 février 2017 17:58:56
>
> *À :* Vincent Jahjah
> *Cc :* openstack@lists.openstack.org
> *Objet :* Re: [Openstack] [Fuel] Cannot access Fuel 10.0 UI because of
> unavailable Nailgun server
>
> The problem is for some reasons your Fuel Master installation was not
> finished successfully, there are logs which you can check to figure out
> what went wrong (see my previous message), also send a full output of
> `bootstrap_admin_node.sh` command execution. It may make sense to try to
> install from scratch, if you did a lot of manual changes and
> configurations, to ensure there are no overlapping problems.
>
> Thanks,
>
> On Fri, Feb 10, 2017 at 9:42 AM, Vincent Jahjah <
> vincent_jah...@hotmail.com> wrote:
>
>> Hello,
>>
>> Thank you for your advice!
>>
>>
>> Curl did not work on the master node.
>>
>> It seems that nginx was not installed (service nginx status did not
>> detect nginx).
>>
>> I used yum to install nginx, but doing this seems arbitrary and does not
>> seem to do anything (was it not supposed to be there in the first place?)
>>
>>
>> The bootstrap_admin_node logs suggested I use "fuel-bootstrap build
>> --activate" once I had fixed the network.
>>
>> This command crashes on a Cobbler issue (first image).
>>
>> The configuration file of Cobbler has a comment suggesting I restart the
>> cobbler demon. (second image)
>>
>> The command still fails after restarting the demon.
>>
>> This is the point where I begin to suspect httpd (apache) is in cause.
>>
>> When I restart httpd, I get a strange error explaining how there is a
>> name duplication in the Cobbler configuration file inside the /etc/httpd
>> folders. (two last images) Specifically:
>>
>>
>> > # Use separate process group for wsgi
>> > WSGISocketPrefix /var/run/wsgi
>> > WSGIScriptAlias /cobbler_web /usr/share/cobbler/web/cobbler.wsgi
>> > WSGIDaemonProcess cobbler_web display-name=%{GROUP}  /// ***This
>> line***
>> > WSGIProcessGroup cobbler_web
>> > WSGIPassAuthorization On
>>
>>
>> At this point, I am rather clueless and am starting to wonder if I am not
>> breaking the OS further by stabbing in the dark. I wonder if this is
>> leading anywhere, or whether I should just restart the Fuel installation
>> from the CentOS image...
>>
>>
>> Vincent
>> --
>> *De :* Evgeniy L 
>> *Envoyé :* 7 février 2017 13:07:32
>> *À :* Vincent Jahjah
>> *Cc :* openstack@lists.openstack.org
>> *Objet :* Re: [Openstack] [Fuel] Cannot access Fuel 10.0 UI because of
>> unavailable Nailgun server
>>
>> Hi,
>>
>> Try to access UI using "curl" from your machine and from Fuel Master:
>> 1. If it's not available from your machine but available from Fuel
>> Master, make sure that your network is configured correctly use regular

Re: [Openstack] [OpenStack] [Fuel] Packing kernel drivers into target image.

2017-02-13 Thread Evgeniy L
Hi,

Steps 3 and 4 are not necessary (but at the same time they do not harm),
because configuration in step 2 is what really used to get packages for the
image.
Anyway, glad to see your issue resolved.

A bit more extended explanation on why steps 3 and 4 are not mandatory:
1. During Fuel master node provisioning, Nailgun initialization happens.
2. openstack.yaml file is used to create releases in Nailgun database
during initial setup, so user can create cluster based on them.
3. During cluster creation, releases (stored in database) are used as
templates for cluster configuration, it copies some default parameters from
releases model to cluster models, after that user can do configuration on
per-cluster basis. E.g. during provisioning and image build, repositories
are taken from environment configuration (which are stored in database).

Thanks,

On Sun, Feb 12, 2017 at 4:59 PM, Eddie Yen  wrote:

> Hi Evgeniy,
>
> I built a repository and added my DKMS deb package into the repository,
> then added repository URL and package name into:
> 1. /etc/fuel-bootstrap-cli/fuel_bootstrap_cli.yaml
> 2. Fuel UI > Settings > General
> 3. /usr/lib/python2.7/site-packages/nailgun/fixtures/openstack.yaml
> 4. /usr/share/fuel-openstack-metadata/openstack.yaml
>
> (For position 3 and 4, I wish it can install driver during provisioning. I
> tried not to do 3 and 4 but seems like it didn't install package after
> provision.)
>
> After that, rebuild the new bootstrap and environment images, then driver
> successfully updated.
>
> Thanks for the advice, really appreciate!
>
> Eddie.
>
> 2017-02-11 6:25 GMT+08:00 Evgeniy L :
>
>> You have several options:
>> 1. Build new repository and configure your environment to use it (pay
>> attention to repositories priority).
>> 2. Add package to existing repository, and rebuild the repo (to update
>> metadata about the packages).
>>
>> 1st option is more preferable, it would simplify for you further upgrades.
>>
>> Thanks,
>>
>> On Tue, Feb 7, 2017 at 5:35 PM, Eddie Yen  wrote:
>>
>>> Hi Evgeniy, thanks for the reply first.
>>>
>>> According from your options, I have a idea about first option
>>>
>>> Since I already built a driver as DKMS module, I may try to put package
>>> into a repository that inside a Fuel Master node. And add package name into
>>> the installation list so that DKMS module will install during bootstrap
>>> image or environment image build.
>>>
>>> Is that feasible?
>>>
>>> Thanks,
>>> Eddie.
>>>
>>> 2017-02-08 2:18 GMT+08:00 Evgeniy L :
>>>
>>>> Hi,
>>>>
>>>> Bootstrap image is used only when node is in discovery state (before
>>>> provisioning is done), when you send nodes for provisioning, Fuel builds an
>>>> image using repository from environment configuration, after the image is
>>>> built, it reuses it for future deployments you can find details in
>>>> documentation, for example here [1] "Image building" section.
>>>> You have multiple options:
>>>> 1. Make sure that new kernel is available in configured repository,
>>>> remove image from "/var/www/nailgun/targetimages" run deployment of
>>>> new nodes, which would trigger image rebuild.
>>>> 2. More safe option would be to rebuild image in place
>>>> "/var/www/nailgun/targetimages", in this case don't forget to update
>>>> checksums in "env_1_ubuntu_1404_amd64.yaml" file.
>>>>
>>>> Thanks,
>>>>
>>>> [1] https://docs.mirantis.com/openstack/fuel/fuel-9.1/refere
>>>> nce-architecture/single/index.html
>>>>
>>>> On Sun, Feb 5, 2017 at 11:42 PM, Eddie Yen 
>>>> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I'm using Fuel 9.1 to deploy OpenStack, but I found that the kernel
>>>>> still too old to support Intel i219-LM NIC card.
>>>>>
>>>>> So I'm followed the instruction from OpenStack Documents and built the
>>>>> bootstrap kernel with latest e1000e driver. Then tested and it 
>>>>> successfully
>>>>> catch i219-LM information in Fuel UI and bootstrap node.
>>>>>
>>>>> But after these, I thought a one problem. Even I successfully modify
>>>>> bootstrap kernel, it will got no changes and may cause issue after
>>>>> deployment if target node didn't use bootstrap kernel as environment 
>>>>> kernel.
>>>>>
>>>>> So does target image will use bootstrap kernel as kernel image? If
>>>>> not, how can I modify target kernel image?
>>>>>
>>>>> Many thanks,
>>>>> Eddie.
>>>>>
>>>>> ___
>>>>> Mailing list: http://lists.openstack.org/cgi
>>>>> -bin/mailman/listinfo/openstack
>>>>> Post to : openstack@lists.openstack.org
>>>>> Unsubscribe : http://lists.openstack.org/cgi
>>>>> -bin/mailman/listinfo/openstack
>>>>>
>>>>>
>>>>
>>>
>>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] [Fuel] Cannot access Fuel 10.0 UI because of unavailable Nailgun server

2017-02-10 Thread Evgeniy L
The problem is for some reasons your Fuel Master installation was not
finished successfully, there are logs which you can check to figure out
what went wrong (see my previous message), also send a full output of
`bootstrap_admin_node.sh` command execution. It may make sense to try to
install from scratch, if you did a lot of manual changes and
configurations, to ensure there are no overlapping problems.

Thanks,

On Fri, Feb 10, 2017 at 9:42 AM, Vincent Jahjah 
wrote:

> Hello,
>
> Thank you for your advice!
>
>
> Curl did not work on the master node.
>
> It seems that nginx was not installed (service nginx status did not detect
> nginx).
>
> I used yum to install nginx, but doing this seems arbitrary and does not
> seem to do anything (was it not supposed to be there in the first place?)
>
>
> The bootstrap_admin_node logs suggested I use "fuel-bootstrap build
> --activate" once I had fixed the network.
>
> This command crashes on a Cobbler issue (first image).
>
> The configuration file of Cobbler has a comment suggesting I restart the
> cobbler demon. (second image)
>
> The command still fails after restarting the demon.
>
> This is the point where I begin to suspect httpd (apache) is in cause.
>
> When I restart httpd, I get a strange error explaining how there is a name
> duplication in the Cobbler configuration file inside the /etc/httpd
> folders. (two last images) Specifically:
>
>
> > # Use separate process group for wsgi
> > WSGISocketPrefix /var/run/wsgi
> > WSGIScriptAlias /cobbler_web /usr/share/cobbler/web/cobbler.wsgi
> > WSGIDaemonProcess cobbler_web display-name=%{GROUP}  /// ***This line***
> > WSGIProcessGroup cobbler_web
> > WSGIPassAuthorization On
>
>
> At this point, I am rather clueless and am starting to wonder if I am not
> breaking the OS further by stabbing in the dark. I wonder if this is
> leading anywhere, or whether I should just restart the Fuel installation
> from the CentOS image...
>
>
> Vincent
> --
> *De :* Evgeniy L 
> *Envoyé :* 7 février 2017 13:07:32
> *À :* Vincent Jahjah
> *Cc :* openstack@lists.openstack.org
> *Objet :* Re: [Openstack] [Fuel] Cannot access Fuel 10.0 UI because of
> unavailable Nailgun server
>
> Hi,
>
> Try to access UI using "curl" from your machine and from Fuel Master:
> 1. If it's not available from your machine but available from Fuel Master,
> make sure that your network is configured correctly use regular
> troubleshooting techniques for that ping/traceroute/tcpdump.
> 2. If it's not available from both, your machine and Fuel Master, verify
> that Nginx up and running and that it's configured correctly, there could
> be problems with installation see "/var/log/puppet/bootstrap_admin_node.log"
> for details.
>
> Thanks,
>
> On Sun, Feb 5, 2017 at 6:21 AM, Vincent Jahjah  > wrote:
>
>> Hello,
>>
>>
>> I have attempted installing Fuel on my IBM server for testing purposes.
>>
>> I currently find myself in a similar situation as the one described in
>> this Openstack ask post: https://ask.openstack.or
>> g/en/question/84510/fuel-ui-network-error/
>>
>>
>> I can ping to and from the server, and when I try to connect to the UI
>> from my web browser, the page does not load. The browser tells me I might
>> have too stringent security requirements, but this does not seem to be the
>> issue (deactivating the firewall does not change anything).
>>
>>
>> I cannot restart the Nailgun server simply because the dockerctl commands
>> are deprecated on my version, and I have not found anywhere the commands
>> that are meant to replace it.
>>
>> fuel-utils reveals no issues with Nailgun, but apparently something is
>> off with Cobbler (that's probably not relevant though).
>>
>>
>> When I check for the availability of the Nailgun server, I am told "Can't
>> connect to Nailgun server! Please modify "SERVER_ADDRESS" and "LISTEN_PORT""
>>
>>
>> My config.yaml file looks like this:
>>
>>
>> SERVER_ADDRESS:"10.12.99.34"
>> LISTEN_PORT:"8000"
>> SERVER_PORT:"8443"
>> KEYSTONE_USER:""
>> KEYSTONE_PASS:""
>> KEYSTONE_PORT:"5000"
>>
>> The IP is the host's IP as well as that advertised on the fuel console
>> launch; 8443 is the advertised port for login as well.
>>
>> I have added some of the following rules to the host's firewall, more or
>> less blindly following tutorial

Re: [Openstack] [Fuel] How to manage Puppet manifests, data

2017-02-10 Thread Evgeniy L
Hi Gregory,

What version of Fuel do you use?

I'm not that familiar with openstack puppet library, can help only with
last question, you can override parameters using fuel Nailgun extension
which allows to override settings generated by Nailgun [1], these changes
can be applied by redeploying the cluster (which ensures configs using
puppet).

Adding to the thread Fuel engineers who can help you with specific question
regarding to `os_service_default`.

Thanks,

[1] https://github.com/openstack/fuel-nailgun-extension-iac

On Tue, Feb 7, 2017 at 11:39 PM, Gregory Orange <
gregory.ora...@pawsey.org.au> wrote:

> Hi all,
>
> We'd like to be able to automate deploying changes from our Fuel master to
> our OpenStack cluster. Reading an architecture doc[1] I'm hopeful, but not
> sure of the mechanics. Hunting around in the Puppet modules and
> fuel/astute/etc files has helped a bit, but I'm hoping for some input from
> the community.
>
> I see there have been moves to change Puppet manifest defaults to
> ::os_service_default, so I have two questions (for now!):
> 1. Where are those os_service_default values defined?
> 2. Where should I enter settings to override those defaults or Fuel's
> values?
>
> One more question for good measure: Is there a recommended way to then
> push those changes out? I'm assuming we run the right mcollective command
> to call the rsync and puppet apply, but I'd love to hear someone say it out
> loud.
>
> TIA,
> Greg.
>
>
> [1] http://docs.openstack.org/developer/fuel-docs/devdocs/develo
> p/architecture.html
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] [OpenStack] [Fuel] Packing kernel drivers into target image.

2017-02-10 Thread Evgeniy L
You have several options:
1. Build new repository and configure your environment to use it (pay
attention to repositories priority).
2. Add package to existing repository, and rebuild the repo (to update
metadata about the packages).

1st option is more preferable, it would simplify for you further upgrades.

Thanks,

On Tue, Feb 7, 2017 at 5:35 PM, Eddie Yen  wrote:

> Hi Evgeniy, thanks for the reply first.
>
> According from your options, I have a idea about first option
>
> Since I already built a driver as DKMS module, I may try to put package
> into a repository that inside a Fuel Master node. And add package name into
> the installation list so that DKMS module will install during bootstrap
> image or environment image build.
>
> Is that feasible?
>
> Thanks,
> Eddie.
>
> 2017-02-08 2:18 GMT+08:00 Evgeniy L :
>
>> Hi,
>>
>> Bootstrap image is used only when node is in discovery state (before
>> provisioning is done), when you send nodes for provisioning, Fuel builds an
>> image using repository from environment configuration, after the image is
>> built, it reuses it for future deployments you can find details in
>> documentation, for example here [1] "Image building" section.
>> You have multiple options:
>> 1. Make sure that new kernel is available in configured repository,
>> remove image from "/var/www/nailgun/targetimages" run deployment of new
>> nodes, which would trigger image rebuild.
>> 2. More safe option would be to rebuild image in place
>> "/var/www/nailgun/targetimages", in this case don't forget to update
>> checksums in "env_1_ubuntu_1404_amd64.yaml" file.
>>
>> Thanks,
>>
>> [1] https://docs.mirantis.com/openstack/fuel/fuel-9.1/refere
>> nce-architecture/single/index.html
>>
>> On Sun, Feb 5, 2017 at 11:42 PM, Eddie Yen  wrote:
>>
>>> Hi everyone,
>>>
>>> I'm using Fuel 9.1 to deploy OpenStack, but I found that the kernel
>>> still too old to support Intel i219-LM NIC card.
>>>
>>> So I'm followed the instruction from OpenStack Documents and built the
>>> bootstrap kernel with latest e1000e driver. Then tested and it successfully
>>> catch i219-LM information in Fuel UI and bootstrap node.
>>>
>>> But after these, I thought a one problem. Even I successfully modify
>>> bootstrap kernel, it will got no changes and may cause issue after
>>> deployment if target node didn't use bootstrap kernel as environment kernel.
>>>
>>> So does target image will use bootstrap kernel as kernel image? If not,
>>> how can I modify target kernel image?
>>>
>>> Many thanks,
>>> Eddie.
>>>
>>> ___
>>> Mailing list: http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>> Post to : openstack@lists.openstack.org
>>> Unsubscribe : http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>>
>>>
>>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] [OpenStack] [Fuel] Packing kernel drivers into target image.

2017-02-07 Thread Evgeniy L
Hi,

Bootstrap image is used only when node is in discovery state (before
provisioning is done), when you send nodes for provisioning, Fuel builds an
image using repository from environment configuration, after the image is
built, it reuses it for future deployments you can find details in
documentation, for example here [1] "Image building" section.
You have multiple options:
1. Make sure that new kernel is available in configured repository, remove
image from "/var/www/nailgun/targetimages" run deployment of new nodes,
which would trigger image rebuild.
2. More safe option would be to rebuild image in place
"/var/www/nailgun/targetimages", in this case don't forget to update
checksums in "env_1_ubuntu_1404_amd64.yaml" file.

Thanks,

[1]
https://docs.mirantis.com/openstack/fuel/fuel-9.1/reference-architecture/single/index.html

On Sun, Feb 5, 2017 at 11:42 PM, Eddie Yen  wrote:

> Hi everyone,
>
> I'm using Fuel 9.1 to deploy OpenStack, but I found that the kernel still
> too old to support Intel i219-LM NIC card.
>
> So I'm followed the instruction from OpenStack Documents and built the
> bootstrap kernel with latest e1000e driver. Then tested and it successfully
> catch i219-LM information in Fuel UI and bootstrap node.
>
> But after these, I thought a one problem. Even I successfully modify
> bootstrap kernel, it will got no changes and may cause issue after
> deployment if target node didn't use bootstrap kernel as environment kernel.
>
> So does target image will use bootstrap kernel as kernel image? If not,
> how can I modify target kernel image?
>
> Many thanks,
> Eddie.
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] [Fuel] Cannot access Fuel 10.0 UI because of unavailable Nailgun server

2017-02-07 Thread Evgeniy L
Hi,

Try to access UI using "curl" from your machine and from Fuel Master:
1. If it's not available from your machine but available from Fuel Master,
make sure that your network is configured correctly use regular
troubleshooting techniques for that ping/traceroute/tcpdump.
2. If it's not available from both, your machine and Fuel Master, verify
that Nginx up and running and that it's configured correctly, there could
be problems with installation see
"/var/log/puppet/bootstrap_admin_node.log" for details.

Thanks,

On Sun, Feb 5, 2017 at 6:21 AM, Vincent Jahjah 
wrote:

> Hello,
>
>
> I have attempted installing Fuel on my IBM server for testing purposes.
>
> I currently find myself in a similar situation as the one described in
> this Openstack ask post: https://ask.openstack.
> org/en/question/84510/fuel-ui-network-error/
>
>
> I can ping to and from the server, and when I try to connect to the UI
> from my web browser, the page does not load. The browser tells me I might
> have too stringent security requirements, but this does not seem to be the
> issue (deactivating the firewall does not change anything).
>
>
> I cannot restart the Nailgun server simply because the dockerctl commands
> are deprecated on my version, and I have not found anywhere the commands
> that are meant to replace it.
>
> fuel-utils reveals no issues with Nailgun, but apparently something is off
> with Cobbler (that's probably not relevant though).
>
>
> When I check for the availability of the Nailgun server, I am told "Can't
> connect to Nailgun server! Please modify "SERVER_ADDRESS" and "LISTEN_PORT""
>
>
> My config.yaml file looks like this:
>
>
> SERVER_ADDRESS:"10.12.99.34"
> LISTEN_PORT:"8000"
> SERVER_PORT:"8443"
> KEYSTONE_USER:""
> KEYSTONE_PASS:""
> KEYSTONE_PORT:"5000"
>
> The IP is the host's IP as well as that advertised on the fuel console
> launch; 8443 is the advertised port for login as well.
>
> I have added some of the following rules to the host's firewall, more or
> less blindly following tutorials:
>
> *filter
> :INPUT DROP [0:0]
> :FORWARD DROP [0:0]
> :OUTPUT ACCEPT [243:14376]
> :ext-filter-forward - [0:0]
> :ext-filter-input - [0:0]
> -A INPUT -i lo -m comment --comment "000 allow loopback" -j ACCEPT
> -A INPUT -p tcp -m state --state NEW --dport 23 -j ACCEPT
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 8000 -j ACCEPT
> -A INPUT -s 10.12.99.0/24 -p tcp -m multiport --dports 22 -m comment
> --comment "010 ssh" -m state --state NEW -j ACCEPT
>
> I do "service iptable restart" and I restart firewalld after modifying
> this file.
> I restart the network before trying to access the fuel UI.
> I do all of my modifications on my client machine, on PuTTy using Telnet.
>
> I've been stuck on this issue and have been on the lookout for support,
> hence my joining this email list.
> This is not the only issue I've run into, but that's the most pressing one
> right now.
> I know that I am attempting to join the right site on the browser because
> the tab icon on Chrome changes to the Fuel icon.
>
> Regards,
>
> Vincent
>
>
> fuel ui network error - Ask OpenStack: Q&A Site for ...
> 
> ask.openstack.org
> Hi All I am trying Mirantis Fuel 7 or OpenStack deployment. Environment:
> Fuel Master - 2 IP (10.20.0.2, 192.168.x.y, Gateway - 192.168.x.z) Fuel
> slaves - 2 Using ...
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack] [Fuel] Questions Around Error Handling In Fuel

2016-11-16 Thread Evgeniy L
Hi Russel,

Sorry for late response, there are different types of errors in 8.0 Fuel
(nodes->error_type field in db), if error caused by provisioning, those
nodes which have state=error, error_type=provision, will be re-provisioned,
with possible data lose, those node which failed to deploy state=error,
error_type=deploy will be only redeployed, which means Fuel just reruns
`puppet apply` second time, which should be pretty safe operation to do.
But don't forget to do backups and check your changes on staging (it's a
good thing to do anyway).

Thanks,


On Tue, Nov 8, 2016 at 4:12 PM, Russell Holloway <
russell.hollo...@hotmail.com> wrote:

> Hi all,
>
>
> I'm working with Fuel 8 and am wondering if anyone can help me understand
> how errors are handled in Fuel and deployment in general. I have a cluster
> that I'm having issues deploying a second controller to and upon failure it
> originally flagged all existing nodes + the new node as 'error' in Fuel.
>
>
> When this happens, the Fuel UI unlocks configuration of the nodes in
> 'error' state as if to let me reconfigure / adjust them and
> reprovision+deploy, and I can hit deploy again on the dashboard. However,
> what happens if I do hit deploy? Will it wipe my existing nodes and
> rebuild? That would not be ideal, especially for storage nodes. Or, will it
> re-run puppet scripts against the nodes without removing anything such as
> data, just copying over configs and making sure they are in line with what
> Fuel has / restart services?
>
>
> I wasn't sure, so I modified the states manually in Fuel database for
> cluster to operational, existing nodes to ready, and new node to
> discover (which probably isn't ideal either but hopefully I didn't break
> anything terribly). The only side affect I've noticed is the new node
> (node-10) is showing up in haproxy configuration on the existing controller
> even though it was removed from environment. There are probably other
> artifacts that may be whack.
>
>
> In any case, mostly curious how errors are handled and if Fuel has a way
> to re-deploy configs and existing services as needed to an existing cluster
> (either in ready state or error state) without causing data loss by wiping
> storage (ceph OSDs in my case) or other things that would not be great to
> lose.
>
>
> -Russ Holloway
>
>
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack