Re: [Openstack] DHCP for IPv6

2017-09-26 Thread Jorge Luiz Correa 
Hi Steve!

I don’t remember if when I did all configurations here this combination was 
available (dhcpv6-stateful and dhcpv6-stateful). Anyway, I can tell I couldn't 
do dhcpv6 work well. I`m using Mitaka and dhcpv6-stateless - dhcpv6-stateless. 

Everything works when configuring manually. The addresses works well here 
because I'm using prefix delegation and slaac generates them. However, the 
dhcpv6 options didn`t work because virtual machines never ask for them. If I 
run dhcpv6 request manually, yes, it works. I`ve asked for help in a topic 
about cloud-init but no fix, just another member with the same problem. 

https://ask.openstack.org/en/question/107308/how-to-use-ipv6_ra_mode-dhcpv6-stateless-ipv6_address_mode-dhcpv6-stateless/

Test if your VMs are really asking for something! Maybe you have to use tcpdump 
inside "net ns ... namespace ... exec ... tcpdump  etc” … 
Or not, because you are using linuxbridge. 

Regards.

> On 26 Sep 2017, at 20:58, Sterdnot Shaken  wrote:
> 
> Openstack version: Ocata
> Mech driver: OVS
> Security: Linuxbridge
> 
> Hello! 
> 
> Anyone have any idea why DHCP for IPv4 works fine but DHCP for IPv6 doesn't? 
> With Stateless or just SLAAC, the VM's calculate a correct IPv6 address from 
> the IPv6 prefix I've assigned, but (for stateless) the instances doesn't get 
> any of the options, like DNS, etc...  Stateful doesn't work at all. I 
> configure a stateful network using a command like this:
> 
> openstack subnet create --allocation-pool 
> start=2604:::::2,end=2604::::::: 
> --ip-version 6 --ipv6-address-mode dhcpv6-stateful --ipv6-ra-mode 
> dhcpv6-stateful --dns-nameserver 2620:0:ccc::2 --network cust01-v6_net0 
> --subnet-range 2604:::::/64 cust01-v6_sub0 
> 
> But none of the instances added to that network acquire a v6 address ever. I 
> can statically assign the selected IPv6 address to the respective instance 
> and it can then ping out using v6 just fine. I can also add IPv6 DNS 
> addresses to resolv.conf and the instance can correctly resolve as well. This 
> issue happens on both Linux and Windows instances...
> 
> Any ideas?
> 
> Thanks in advance!
> 
> Steve
> ___
> 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

[Openstack] DHCP for IPv6

2017-09-26 Thread Sterdnot Shaken 
Openstack version: Ocata
Mech driver: OVS
Security: Linuxbridge

Hello!

Anyone have any idea why DHCP for IPv4 works fine but DHCP for IPv6
doesn't? With Stateless or just SLAAC, the VM's calculate a correct IPv6
address from the IPv6 prefix I've assigned, but (for stateless) the
instances doesn't get any of the options, like DNS, etc...  Stateful
doesn't work at all. I configure a stateful network using a command like
this:

openstack subnet create --allocation-pool
start=2604:::::2,end=2604:::::::
--ip-version 6 --ipv6-address-mode dhcpv6-stateful --ipv6-ra-mode
dhcpv6-stateful --dns-nameserver 2620:0:ccc::2 --network cust01-v6_net0
--subnet-range 2604:::::/64 cust01-v6_sub0

But none of the instances added to that network acquire a v6 address ever.
I can statically assign the selected IPv6 address to the respective
instance and it can then ping out using v6 just fine. I can also add IPv6
DNS addresses to resolv.conf and the instance can correctly resolve as
well. This issue happens on both Linux and Windows instances...

Any ideas?

Thanks in advance!

Steve
___
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] node name issue

2017-09-26 Thread Jim Okken 
also I should add, I dont have the original hard drives in the system so it
isn't because it is booting the old OS where these node names were set.
this is definitely the newly installed OS being given the wroing hostname



is there a database this is all kept in? maybe I could look around and find
where these old node names are being saved?

thanks!

-- Jim

On Mon, Sep 25, 2017 at 6:03 PM, Jim Okken  wrote:

> hi all,
>
> I am using Fuel 10.
>
> i have 2 nodes I am trying to deploy as compute nodes. at one time in the
> past I was attempting to deploy them too. I assume back then their node
> names were node-11 and node-20.
>
> they were never successfully deploy and now I've worked out their hardware
> issues and are attempting to deploy them again. now Fuel has given them the
> names node-80 and node-81.
> (i may be at 80 in my node names but I only have 17 nodes so far)
>
> the deploy of these 2 nodes does not get past installing Ubuntu. The nodes
> reboot after Ubuntu is installed and come up incorrectly as node-11 and
> node-20. After that Fuel sits for a long while and then gives an error
> (pasted at the end of email). I assume the nodes come up with the wrong
> name/ip/ssh-key and Fuel can't contact them.
>
> I'm a novice at using the fuel and fuel2 cli's but I've tried deleting
> these nodes and removing from database. Then re-PXE boot the nodes and
> start a fresh deploy just to have them named node11 and 20 again. Fuel cli
> does show the correct host name for these nodes, but I've tried anyway to
> (re)set the host name for these node with no affect.
>
> If I try to delete node-11 and node-20 I get this error
> 404 Client Error: Not Found for url: http://10.20.243.1:8000/api/
> v1/nodes/?ids=11 (NodeCollection not found)
>
> what can I do to get past this please?
>
>
>
> Errors from the Fuel Astute log:
> 2017-09-25 21:06:28 ERROR [1565] Error running provisioning:
> # ,
> trace: ["/usr/share/gems/gems/astute-10.0.0/lib/astute/mclient.rb:178:in
> `rescue in initialize_mclient'", "/usr/share/gems/gems/astute-
> 10.0.0/lib/astute/mclient.rb:161:in `initialize_mclient'",
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/mclient.rb:51:in
> `initialize'", 
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/nailgun_hooks.rb:421:in
> `new'", "/usr/share/gems/gems/astute-10.0.0/lib/astute/nailgun_hooks.rb:421:in
> `run_shell_without_check'", "/usr/share/gems/gems/astute-
> 10.0.0/lib/astute/nailgun_hooks.rb:449:in `update_node_status'",
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/nailgun_hooks.rb:313:in
> `reboot_hook'", 
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/nailgun_hooks.rb:38:in
> `block in process'", "/usr/share/gems/gems/astute-
> 10.0.0/lib/astute/nailgun_hooks.rb:26:in `each'",
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/nailgun_hooks.rb:26:in
> `process'", 
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/image_provision.rb:117:in
> `reboot'", "/usr/share/gems/gems/astute-10.0.0/lib/astute/provision.rb:273:in
> `soft_reboot'", 
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/provision.rb:240:in
> `provision_piece'", "/usr/share/gems/gems/astute-
> 10.0.0/lib/astute/provision.rb:126:in `block (3 levels) in
> provision_and_watch_progress'", "/usr/share/gems/gems/astute-
> 10.0.0/lib/astute/provision.rb:309:in `call'",
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/provision.rb:309:in
> `sleep_not_greater_than'", "/usr/share/gems/gems/astute-
> 10.0.0/lib/astute/provision.rb:120:in `block (2 levels) in
> provision_and_watch_progress'", "/usr/share/gems/gems/astute-
> 10.0.0/lib/astute/provision.rb:119:in `loop'",
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/provision.rb:119:in `block
> in provision_and_watch_progress'", "/usr/share/gems/gems/astute-
> 10.0.0/lib/astute/provision.rb:118:in `catch'",
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/provision.rb:118:in
> `provision_and_watch_progress'", "/usr/share/gems/gems/astute-
> 10.0.0/lib/astute/provision.rb:52:in `provision'",
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/orchestrator.rb:109:in
> `provision'", 
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/server/dispatcher.rb:46:in
> `provision'", 
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/server/dispatcher.rb:37:in
> `image_provision'", 
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/server/server.rb:172:in
> `dispatch_message'", "/usr/share/gems/gems/astute-
> 10.0.0/lib/astute/server/server.rb:131:in `block in dispatch'",
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/server/task_queue.rb:64:in
> `call'", 
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/server/task_queue.rb:64:in
> `block in each'", "/usr/share/gems/gems/astute-
> 10.0.0/lib/astute/server/task_queue.rb:56:in `each'",
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/server/task_queue.rb:56:in
> `each'", 
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/server/server.rb:128:in
> `each_with_index'", 
> "/usr/share/gems/gems/astute-10.0.0/lib/astute/server/server.rb:128:in
> `disp

Re: [Openstack] extend attached volumes

2017-09-26 Thread Erik McCormick 
On Sep 26, 2017 11:03 AM, "Jay Pipes"  wrote:

On 09/26/2017 10:20 AM, Volodymyr Litovka wrote:

> Hi Jay,
>
> I know about this way :-) but Pike introduced ability to resize attached
> volumes:
>
> "It is now possible to signal and perform an online volume size change as
> of the 2.51 microversion using the|volume-extended|external event. Nova
> will perform the volume extension so the host can detect its new size. It
> will also resize the device in QEMU so instance can detect the new disk
> size without rebooting." -- https://docs.openstack.org/rel
> easenotes/nova/pike.html
>

I think using Ceph is your issue. From those release notes:

"Currently only the libvirt compute driver with iSCSI and FC volumes
supports the online volume size change."

-Erik


Apologies, Volodymyr, I wasn't aware of that ability!

Best,
-jay


___
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] extend attached volumes

2017-09-26 Thread Jay Pipes 

On 09/26/2017 10:20 AM, Volodymyr Litovka wrote:

Hi Jay,

I know about this way :-) but Pike introduced ability to resize attached 
volumes:


"It is now possible to signal and perform an online volume size change 
as of the 2.51 microversion using the|volume-extended|external event. 
Nova will perform the volume extension so the host can detect its new 
size. It will also resize the device in QEMU so instance can detect the 
new disk size without rebooting." -- 
https://docs.openstack.org/releasenotes/nova/pike.html


Apologies, Volodymyr, I wasn't aware of that ability!

Best,
-jay

___
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] extend attached volumes

2017-09-26 Thread Volodymyr Litovka 
As far as I understood, the chain is the same - admin extend volume by 
using Cinder, but unlike earlier implementation, if volume is in-use, 
Cinder will ask Nova whether Nova support extending attached volumes (by 
checking Nova's API microversion) and if yes, will resize volume 
informing Nova using "volume-extended" call. On Nova's side, it will 
inform QEMU about this change... then either user can manually resize or 
it will happen on next reboot.


I can be wrong, of course, but there is no neither "nova volume-extend" 
nor word "extend" in "nova --help" :-)


On 9/26/17 5:35 PM, John Petrini wrote:
I think this feature is actually implemented in nova. So you have to 
use the nova volume-extend option to do what you want. This is just my 
interpretation of the release notes though. I haven't tried it.



On Tue, Sep 26, 2017 at 10:20 AM, Volodymyr Litovka > wrote:


Hi Jay,

I know about this way :-) but Pike introduced ability to resize
attached volumes:

"It is now possible to signal and perform an online volume size
change as of the 2.51 microversion using
the|volume-extended|external event. Nova will perform the volume
extension so the host can detect its new size. It will also resize
the device in QEMU so instance can detect the new disk size
without rebooting." --
https://docs.openstack.org/releasenotes/nova/pike.html


On 9/26/17 5:04 PM, Jay Pipes wrote:

Detach the volume, then resize it, then re-attach.

Best,
-jay

On 09/26/2017 09:22 AM, Volodymyr Litovka wrote:

Colleagues,

can't find ways to resize attached volume. I'm on Pike.

As far as I understand, it required to be supported in Nova,
because Cinder need to check with Nova whether it's possible to
extend this volume.

Well,
- Nova's API microversion is 2.51, which seems to be enough to
support "volume-extended" API call
- Properties of image are *hw_disk_bus='scsi'* and
*hw_scsi_model='virtio-scsi'*, type bare/raw, located in Cinder
- hypervisor is KVM
- volume is bootable, mounted as root, created as snapshot from
Cinder volume
- Cinder's backend is CEPH/Bluestore

and both "cinder extend" and "openstack volume set --size"
returns "Volume status must be '{'status': 'available'}' to
extend, currently in-use".

I did not find any configuration options neither in nova nor in
cinder config files, which can help with this functionality.

What I'm doing wrong?

Thank you.

-- 
Volodymyr Litovka

   "Vision without Execution is Hallucination." -- Thomas Edison



___
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



-- 
Volodymyr Litovka

   "Vision without Execution is Hallucination." -- Thomas Edison


___
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





--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

___
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] extend attached volumes

2017-09-26 Thread John Petrini 
I think this feature is actually implemented in nova. So you have to use
the nova volume-extend option to do what you want. This is just my
interpretation of the release notes though. I haven't tried it.


On Tue, Sep 26, 2017 at 10:20 AM, Volodymyr Litovka  wrote:

> Hi Jay,
>
> I know about this way :-) but Pike introduced ability to resize attached
> volumes:
>
> "It is now possible to signal and perform an online volume size change as
> of the 2.51 microversion using the volume-extendedexternal event. Nova
> will perform the volume extension so the host can detect its new size. It
> will also resize the device in QEMU so instance can detect the new disk
> size without rebooting." -- https://docs.openstack.org/
> releasenotes/nova/pike.html
>
> On 9/26/17 5:04 PM, Jay Pipes wrote:
>
> Detach the volume, then resize it, then re-attach.
>
> Best,
> -jay
>
> On 09/26/2017 09:22 AM, Volodymyr Litovka wrote:
>
> Colleagues,
>
> can't find ways to resize attached volume. I'm on Pike.
>
> As far as I understand, it required to be supported in Nova, because
> Cinder need to check with Nova whether it's possible to extend this volume.
>
> Well,
> - Nova's API microversion is 2.51, which seems to be enough to support
> "volume-extended" API call
> - Properties of image are *hw_disk_bus='scsi'* and
> *hw_scsi_model='virtio-scsi'*, type bare/raw, located in Cinder
> - hypervisor is KVM
> - volume is bootable, mounted as root, created as snapshot from Cinder
> volume
> - Cinder's backend is CEPH/Bluestore
>
> and both "cinder extend" and "openstack volume set --size" returns "Volume
> status must be '{'status': 'available'}' to extend, currently in-use".
>
> I did not find any configuration options neither in nova nor in cinder
> config files, which can help with this functionality.
>
> What I'm doing wrong?
>
> Thank you.
>
> --
> Volodymyr Litovka
>"Vision without Execution is Hallucination." -- Thomas Edison
>
>
>
> ___
> 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
>
>
> --
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison
>
>
> ___
> 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] extend attached volumes

2017-09-26 Thread Volodymyr Litovka 

Hi Jay,

I know about this way :-) but Pike introduced ability to resize attached 
volumes:


"It is now possible to signal and perform an online volume size change 
as of the 2.51 microversion using the|volume-extended|external event. 
Nova will perform the volume extension so the host can detect its new 
size. It will also resize the device in QEMU so instance can detect the 
new disk size without rebooting." -- 
https://docs.openstack.org/releasenotes/nova/pike.html


On 9/26/17 5:04 PM, Jay Pipes wrote:

Detach the volume, then resize it, then re-attach.

Best,
-jay

On 09/26/2017 09:22 AM, Volodymyr Litovka wrote:

Colleagues,

can't find ways to resize attached volume. I'm on Pike.

As far as I understand, it required to be supported in Nova, because 
Cinder need to check with Nova whether it's possible to extend this 
volume.


Well,
- Nova's API microversion is 2.51, which seems to be enough to 
support "volume-extended" API call
- Properties of image are *hw_disk_bus='scsi'* and 
*hw_scsi_model='virtio-scsi'*, type bare/raw, located in Cinder

- hypervisor is KVM
- volume is bootable, mounted as root, created as snapshot from 
Cinder volume

- Cinder's backend is CEPH/Bluestore

and both "cinder extend" and "openstack volume set --size" returns 
"Volume status must be '{'status': 'available'}' to extend, currently 
in-use".


I did not find any configuration options neither in nova nor in 
cinder config files, which can help with this functionality.


What I'm doing wrong?

Thank you.

--
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison



___
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


--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

___
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] extend attached volumes

2017-09-26 Thread Jay Pipes 

Detach the volume, then resize it, then re-attach.

Best,
-jay

On 09/26/2017 09:22 AM, Volodymyr Litovka wrote:

Colleagues,

can't find ways to resize attached volume. I'm on Pike.

As far as I understand, it required to be supported in Nova, because 
Cinder need to check with Nova whether it's possible to extend this volume.


Well,
- Nova's API microversion is 2.51, which seems to be enough to support 
"volume-extended" API call
- Properties of image are *hw_disk_bus='scsi'* and 
*hw_scsi_model='virtio-scsi'*, type bare/raw, located in Cinder

- hypervisor is KVM
- volume is bootable, mounted as root, created as snapshot from Cinder 
volume

- Cinder's backend is CEPH/Bluestore

and both "cinder extend" and "openstack volume set --size" returns 
"Volume status must be '{'status': 'available'}' to extend, currently 
in-use".


I did not find any configuration options neither in nova nor in cinder 
config files, which can help with this functionality.


What I'm doing wrong?

Thank you.

--
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison



___
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

[Openstack] extend attached volumes

2017-09-26 Thread Volodymyr Litovka 

Colleagues,

can't find ways to resize attached volume. I'm on Pike.

As far as I understand, it required to be supported in Nova, because 
Cinder need to check with Nova whether it's possible to extend this volume.


Well,
- Nova's API microversion is 2.51, which seems to be enough to support 
"volume-extended" API call
- Properties of image are *hw_disk_bus='scsi'* and 
*hw_scsi_model='virtio-scsi'*, type bare/raw, located in Cinder

- hypervisor is KVM
- volume is bootable, mounted as root, created as snapshot from Cinder 
volume

- Cinder's backend is CEPH/Bluestore

and both "cinder extend" and "openstack volume set --size" returns 
"Volume status must be '{'status': 'available'}' to extend, currently 
in-use".


I did not find any configuration options neither in nova nor in cinder 
config files, which can help with this functionality.


What I'm doing wrong?

Thank you.

--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

___
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