Ask Your Question

kashyapc's profile - activity

2015-05-26 03:18:48 -0500 received badge  Nice Answer (source)
2014-05-15 05:38:21 -0500 answered a question What is a correct RDO repository to setup AIO Havana on F20 ?

Some notes here from our discussion on rdo-list[1]. Here[2] is the repository.

[1] https://www.redhat.com/archives/rdo-l... [2] http://repos.fedorapeople.org/repos/o...

2014-03-19 23:51:48 -0500 commented question Getting only single echo reply from VM, from outside or inside network

You might want to look at this diagnostic tool to debug further.

2014-03-12 02:10:48 -0500 answered a question SOS!!cannot ping br-ex in networknode with havana

You ought to ensure you have your iptables rules are reflecting correctly. On a two node Icehouse-M1 set-up, with Neutron, GRE and OVS, here's what I have:

On Controller node:

$ cat /etc/sysconfig/iptables
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m multiport --dports 3260 -m comment --comment "001 cinder incoming" -j ACCEPT 
-A INPUT -p tcp -m multiport --dports 80 -m comment --comment "001 horizon incoming" -j ACCEPT 
-A INPUT -p tcp -m multiport --dports 9292 -m comment --comment "001 glance incoming" -j ACCEPT 
-A INPUT -p tcp -m multiport --dports 5000,35357 -m comment --comment "001 keystone incoming" -j ACCEPT
-A INPUT -p tcp -m multiport --dports 3306 -m comment --comment "001 mariadb incoming" -j ACCEPT
-A INPUT -p tcp -m multiport --dports 6080 -m comment --comment "001 novncproxy incoming" -j ACCEPT
-A INPUT -p tcp -m multiport --dports 8770:8780 -m comment --comment "001 novaapi incoming" -j ACCEPT
-A INPUT -p tcp -m multiport --dports 9696 -m comment --comment "001 neutron incoming" -j ACCEPT
-A INPUT -p tcp -m multiport --dports 5672 -m comment --comment "001 qpid incoming" -j ACCEPT 
-A INPUT -p tcp -m multiport --dports 8700 -m comment --comment "001 metadata incoming" -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 5900:5999 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A INPUT -p gre -j ACCEPT 
-A OUTPUT -p gre -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

On Compute node:

$ cat /etc/sysconfig/iptables
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 5900:5999 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -p gre -j ACCEPT 
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -p gre -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
2014-03-12 02:04:42 -0500 answered a question yum update in fedora 20 not working

You can try a few things:

  • See if you're able to _reach_ the network at all
  • Check if your proxy settings are enabled correctly
  • Check if your 'baseurl' and 'mirrorlist' in your yum.conf are conflicting
  • See if you're able to access the mirror list via curl
2014-03-05 20:25:03 -0500 received badge  Nice Answer (source)
2014-02-20 06:16:21 -0500 received badge  Nice Answer (source)
2014-02-18 05:01:17 -0500 commented question Deploying RDO using Foreman

Please be more specific and post relevant errors, issues you're encountering with clear details, unless it's unlikely you'll get further help from folks who deploy with Foreman regularly.

2014-02-18 04:57:14 -0500 commented answer Add LVM to RDO installation

As I mentioned on IRC, you're noticing that warning (not an error) because you're storing the instances on a non-standard location. Original libvirt patch that added this: http://www.redhat.com/archives/libvir-list/2012-October/msg01146.html

2014-01-24 05:26:18 -0500 answered a question Neutron command workflow

You can try a couple of things:

  1. Enabling debug/verbose logs by setting verbose = True and debug = True attributes in your /etc/neutron.conf to the see the flow of a Neutron API request originating from a CLI command. (Don't forget to restart Neutron services.)

  2. Use PDB to see the flow of a request -- http://kashyapc.com/2013/03/27/debugging-nova-a-small-illustration-with-pdb/

2013-12-24 02:34:37 -0500 answered a question Expecting an auth URL via either --os-auth-url or env[OS_AUTH_URL]

You're trying to create a tenant -- you must provide the URL of your Keystone authentication server for that command to complete successfully, that's what OS_AUTH_URL environment variable (or the CLI argument --os_auth_url ) is for. Assuming you have a single node installation, it would be along the lines of -- http://localhost:35357/v2.0

Reference -- http://docs.openstack.org/developer/keystone/configuration.html

Also, you can populate the Keystone authentication environment variables into an RC file:

$ cat keystonerc_admin
export OS_USERNAME=admin
export OS_TENANT_NAME=admin
export OS_PASSWORD=passwd
export OS_AUTH_URL=http://192.169.142.49:35357/v2.0/
export PS1='[\u@\h \W(keystone_admin)]$'

which needs to be sourced, so the environment variables take effect:

$ source keystonerc_admin
2013-12-23 06:45:18 -0500 commented answer Add LVM to RDO installation

Cristi is right. Also, I updated my answer with some more details about mount/permissions. I just took an example that mount point is on an NFS share. You need to adjust them accordingly. Hope that helps.

2013-12-23 05:44:47 -0500 answered a question Add LVM to RDO installation

The default location where Nova stores its guests is /var/lib/nova/instances. You can edit /etc/nova/nova.conf :

  • Change the instances_path attribute in nova.conf
  • Restart Nova services
     $ openstack-service restart nova 
  • Ensure you have the right SELinux context (if you're using Fedora or its derivative based infrastructure)

Update

You need to mount whatever block device to be used to store Nova instances.

Ensure the mount point has Nova specific SELinux context:

# For instance, if it's on an NFS share:
$ mount --verbose -t nfs xx.yy.www.zzz:/home/kashyap \
  /mnt -o "context=unconfined_u:object_r:nova_var_lib_t:s0"

Provide correct permissions on the mount point:

$ chown -R nova:nova /mnt/nova/
$ chgrp -R qemu /mnt/nova/instances/
$ chmod -R g+w /mnt/nova/instances

Ensure to have nova user own the QEMU instances:

$ grep nova /etc/libvirt/qemu.conf
user = "nova"
group = "nova"

Confirm your instances are indeed owned by nova user:

$ ps -ef | grep -i qemu-kvm | grep -i nova
2013-12-23 03:32:51 -0500 commented question create instance failed: too many values to unpack

If the problem is resolved, you might want to close the question, so it still won't appear as an unanswered question on the main page of ask.openstack.org.

2013-12-20 07:10:31 -0500 answered a question Openstack networking

Fixed/Private IP range can be anything - the one you mentioned should work just fine.

You can see in a bit more verbose detail by running:

$ nova --debug . . .

Also, you might want to check if you have something interesting in your nova network server logs in /var/log/nova/

That said, if possible, I'd suggest you try Neutron networking as Nova networking will be deprecated in favour of it.

Couple of related URLs:

2013-12-19 15:28:15 -0500 answered a question RDO quickstart installation question/issue.

It's answered here (by Pádraig) -- https://ask.openstack.org/en/question/9063/fedora-20-support-for-rdo/

"As for the related yum.theforeman.org issue above, I've asked for that to be fixed at their site and expect it to be in place for the soon to be released RDO icehouse version."

2013-12-13 11:34:39 -0500 received badge  Nice Answer (source)
2013-12-13 02:49:03 -0500 answered a question Getting error for token-get in keystone

You can investigate further:

2013-12-13 02:04:30 -0500 received badge  Enthusiast
2013-12-12 11:20:35 -0500 answered a question In havana-3, cannot ssh or ping to floating ips

I just took a look at your paste, you haven't specified iptables rules. Ensure you have the GRE INPUT/OUTPUT rules too (refer below).

In my two node setup, I have these iptables rules, and I could reach Floating IPs from inside the Nova instances just fine.

[1] iptables on Controller node:

[root@ostack-controller ~]# cat /etc/sysconfig/iptables
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m multiport --dports 3260 -m comment --comment "001 cinder incoming" -j ACCEPT 
-A INPUT -p tcp -m multiport --dports 80 -m comment --comment "001 horizon incoming" -j ACCEPT 
-A INPUT -p tcp -m multiport --dports 9292 -m comment --comment "001 glance incoming" -j ACCEPT 
-A INPUT -p tcp -m multiport --dports 5000,35357 -m comment --comment "001 keystone incoming" -j ACCEPT 
-A INPUT -p tcp -m multiport --dports 3306 -m comment --comment "001 mariadb incoming" -j ACCEPT 
-A INPUT -p tcp -m multiport --dports 6080 -m comment --comment "001 novncproxy incoming" -j ACCEPT 
-A INPUT -p tcp -m multiport --dports 8770:8780 -m comment --comment "001 novaapi incoming" -j ACCEPT 
-A INPUT -p tcp -m multiport --dports 9696 -m comment --comment "001 neutron incoming" -j ACCEPT 
-A INPUT -p tcp -m multiport --dports 5672 -m comment --comment "001 qpid incoming" -j ACCEPT 
-A INPUT -p tcp -m multiport --dports 8700 -m comment --comment "001 metadata incoming" -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 5900:5999 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A INPUT -p gre -j ACCEPT 
-A OUTPUT -p gre -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

[2] iptables rules on Compute node:

[root@ostack-compute ~(keystone_kashyap)]$ cat /etc/sysconfig/iptables
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 5900:5999 -j ACCEPT
-A INPUT -p tcp --dport 22 -j ACCEPT
-A INPUT -p gre -j ACCEPT 
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -p gre -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

Here are my working Neutron configurations with OVS and GRE, two node setup: http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-two-node.txt

And, alternatively, you can do some tcpdump analysis on your various network devices. Here's a recent trace of some analysis I've done -- https://gist.github.com/kashyapc/7926517

Some commands to try for ICMP here (once you invoke an ICMP request from inside the Nova instance):

  $ tcpdump -i br-ex -n icmp
  $ tcpdump -i eth0 -n icmp
  $ tcpdump -i any  -n ...
(more)
2013-12-12 07:32:07 -0500 answered a question Dependencies for Keystoneclient upgrade

Should be safe generally. However, if it's just a virtual machine, and you're running new enough libvirt on your host, maybe you can try it yourself by taking a snapshot of the VM, update the Keystone client, if something breaks, just revert the VM to sane state?

If you want to take an internal live snapshot, you can try:

$ virsh snapshot-create grizzlyvm
$ virsh snapshot-list grizzlyvm

Update the Keystone client to Havana, check if everything works for you.

In case something is broken and you can't debug further, just revert to your previous sane state:

$ virsh snapshot-revert grizzlyvm $SNAPSHOTID
2013-12-12 07:18:03 -0500 received badge  Editor (source)
2013-12-12 07:17:14 -0500 answered a question rdo - neutron - multinode - single nic ?

Just to note, I have a two node OpenStack RDO Havana set-up configured manually on two Fedora 20 VMs (running Nested KVM on Intel), and it's running pretty solid:

  • Controller node: Nova, Keystone, Cinder, Glance, Neutron (using Open vSwitch plugin and GRE tunneling).
  • Compute node: Nova (nova-compute), Neutron (openvswitch-agent)

Networking details:

2013-12-03 02:51:23 -0500 answered a question How to change the CA and private key of PKI token?

From your wording, it seems like you want to configure an external CA. If you know what you're doing with PKI, here are three sections related to external CA, you might want to refer from -- http://docs.openstack.org/trunk/config-reference/content//ch_configuring-openstack-identity.html

  • Sign certificate issued by external CA
  • Request a signing certificate from an external CA
  • Install an external signing certificate
2013-12-02 04:22:33 -0500 answered a question VM on controller node cannot get IP via DHCP

I'm just guessing, maybe you can do more tcpdump analysis on your Controller node to see where it's blocked. I'm assuming you're using GRE:

# On Controller node
$ tcpdump -envi eth0 | grep -i gre
$ tcpdump -i eth0 -n arp or icmp

# On your integration bridge
$ tcpdump -envi br-int

# On br-tun 
$ tcpdump -envi br-tun

Also, tcpdump on physical link used by GRE tunnels (on Controller node). This might isolate the problem to the compute node or the network node.

$ tcpdump -i eth0 -n ip proto gre

If you're using GRE, ensure to have these rules on both Compute & Controller nodes:

$ iptables -I OUTPUT -p gre -j ACCEPT
$ iptables -I INPUT -p gre -j ACCEPT
2013-11-27 10:51:21 -0500 received badge  Teacher (source)
2013-11-27 02:55:24 -0500 answered a question How do I add nics to an All In One packstack build?

It's a combination of both -- editing existing answer file and re-running packstack. Here's some notes for adding an extra compute node: http://openstack.redhat.com/Adding_a_compute_node

2013-11-25 14:17:00 -0500 commented question how to connect to a container