Re: [Openstack-doc-core] Boolean fields (=True or not?)

[Anne Gentle]

Thanks for the clarification - the latest review copy of the install
guide has force_dhcpelease=True in the nova.conf file. When I tested
the nova.conf the old way, it didn't work anyway, so great catch!

Anne

On Fri, Jun 1, 2012 at 12:48 AM, Tom Fifield fifie...@unimelb.edu.au wrote:
 Speaking as someone who's deployed OpenStack and had a lot of fun with the
 negation, I agree with you on Format #1, especially as the 'default value'
 can be made clearer.

 Regards,

 Tom


 On 06/01/2012 02:18 AM, Lorin Hochstein wrote:

 The config files (helpfully?) support two different formats for
 specifying boolean flags:


 Format 1:

 force_dhcpelease=True
 force_dhcpelease=False


 Format 2:

 force_dhcpelease
 noforce_dhcpelease


 I think we should standardize on one of these conventions for the docs
 (with a note in the docs about the alternate construction).

 I vote for the =True/False because it's more explicit and consistent
 with the other flags.

 Take care,

 Lorin
 --
 Lorin Hochstein
 Lead Architect - Cloud Services
 Nimbis Services, Inc.
 www.nimbisservices.com https://www.nimbisservices.com/









 --
 Mailing list: https://launchpad.net/~openstack-doc-core
 Post to     : openstack-doc-core@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack-doc-core
 More help   : https://help.launchpad.net/ListHelp

-- 
Mailing list: https://launchpad.net/~openstack-doc-core
Post to : openstack-doc-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-doc-core
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Understanding shutdown VM behavior

[Vaze, Mandar]

 But the pickle is the case where a user initiates a shutdown
 inside the VM. What's the expected behavior after it's detected?
 Should it respect the shutdown_terminate flag or work more like an OS
 API?  Right now when a shutdown in a VM is detected, the vm state is
 updated to SHUTOFF and that's pretty much it..

If you are referring to _sync_power_states periodic task, I think current 
behavior
is correct - All it does it matches the real vm state with that in DB.

The task is not invoked in response to any user action , just housekeeping task.

-Mandar


__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data.  If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] openstack.common inside swiftclient and RPM

[Mark McLoughlin]

Hi Pete,

On Thu, 2012-05-31 at 17:48 -0600, Pete Zaitcev wrote:
 Hi, Monty:
 
 The python-swiftclient has something that I believe you added:
 
 [zaitcev@lembas python-swiftclient-tip]$ git log 
 swiftclient/openstack/__init__.py 
 commit 7df012329f0b22e19f878cee2602407cb23042ef
 Author: Monty Taylor mord...@inaugust.com
 Date:   Wed May 16 17:30:46 2012 -0400
 
 Add openstack project infrastructure.
 
 Now, I am wondering, why is it necessary to keep this inside the
 swiftclient/ directory?
 
 My problem is that if I do nothing too crazy, the following RPM
 .spec packages the aforementioned directory, too:
 
 %{python_sitelib}/swiftclient
 
 For now I resorted to running this after python setup.py install:
 
 rm -r %{buildroot}%{python_sitelib}/swiftclient/openstack
 
 Still... As an experiement, I moved the openstack/ one level up,
 changed swiftclient.openstack.common to openstack.common in setup.py,
 and everything seems to be working.

It's not clear what problem you're seeing, but projects are intended to
include openstack-common in this way. See the Incubation section here:

  http://wiki.openstack.org/CommonLibrary

Cheers,
Mark.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] dhcp is not leasing an ip address in vlan mode

[Vishvananda Ishaya]

do you see sent and received packets on the vlan?  I would suspect that you 
actually don't have the vlans trunked on the ports so the packets aren't making 
it across the switch.

Vish

On May 31, 2012, at 9:53 AM, Vijay wrote:

 Thanks for the reply. Network controller assigns a private ip address to the 
 vm launched on compute node. However, I still cannot ping this ip address 
 from the network(controller node). I am running nova-network service only on 
 the controller.
  
 Thanks,
 -vj
 From: Narayan Desai narayan.de...@gmail.com
 To: Vijay vija...@yahoo.com 
 Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net 
 Sent: Wednesday, May 30, 2012 5:28 PM
 Subject: Re: [Openstack] dhcp is not leasing an ip address in vlan mode
 
 This sounds like it might be working properly. In VLAN mode, all
 instances are connected to one of the project vlans. The .1 address
 (gateway, dhcp, etc) exists on an interface on the nova-network node
 (or one of them, in the case that you are running multiple. This
 interface is bridged to a tagged interface on the appropriate vlan
 tag. On the nova-compute nodes, a vnet interface for the instance is
 bridged to the vlan tagged interface. On the compute node, there isn't
 an IP interface on this network, so the private IP for instances isn't
 reachable, even if the instance is running on the same node.
 
 The canonical test for correct network function is if an instance is
 reachable via ping from the nova-network server that is currently
 serving the instance's project network.
 hth
 -nld
 
 On Wed, May 30, 2012 at 5:42 PM, Vijay vija...@yahoo.com wrote:
  Hello,
  I am trying install Essex in VLAN mode on multiple compute nodes.
 
  I am able to lauch instances on controller (which also runs nova-compute)
  and ping/ssh those instances.
  I am able to launch instances on compute only node. However, I cannot ping
  the VM launched  on compute only node.
  When i did the euca-get-console-output on that instance, I see that it is
  not getting an IP leased from DHCP .. Because of that it is not able to
  reach metadata server.
  Any help is appreciated.
 
  Console output is
  udhcpc (v1.17.2) started
  Sending discover...
  Sending discover...
  Sending discover...
  No lease, forking to background
  starting DHCP forEthernet interface eth0  [  OK  ]
  cloud-setup: checking
  http://169.254.169.254/2009-04-04/meta-data/instance-id
  wget: can't connect to remote host (169.254.169.254): Network is unreachable
  cloud-setup: failed 1/30: up 17.71. request failed
  nova.conf:
  --dhcpbridge_flagfile=/etc/nova/nova.conf
  --dhcpbridge=/usr/local/bin/nova-dhcpbridge
  --logdir=/var/log/nova
  --state_path=/var/lib/nova
  --lock_path=/var/lock/nova
  --force_dhcp_release=True
  --use_deprecated_auth
  --iscsi_helper=tgtadm
  --verbose
  --vncserver_listen=0.0.0.0
  --sql_connection=mysql://novadbadmin:novasecret@192.168.198.85/nova
  --daemonize
  --s3_host=192.168.198.85
  --rabbit_host=192.168.198.85
  --cc_host=192.168.198.85
  --ospi_host=192.168.198.85
  --ec2_host=192.168.198.85
  --ec2_url=http://192.168.198.85:8773/services/Cloud
  --nova_url=http://192.168.198.85:8774/v1.1/
 
  # VLAN mode
  --flat_interface=eth1
  --flat_injected=False
  --flat_network_bridge=br100
  --flat_network_dhcp_start=192.168.4.2
 
  --network_manager=nova.network.manager.VlanManager
  --vlan_interface=eth1
  --public_interface=vlan100
  --allow_same_net_traffic=True
  --fixed_range=192.168.4.0/24
  --network_size=256
  --FAKE_subdomain=ec2
  --routing_source_ip=192.168.198.85
  --glance_api_servers=192.168.198.85:9292
  --image_service=nova.image.glance.GlanceImageService
  --iscsi_ip_prefix=192.168.
  --connection_type=libvirt
  --libvirt_type=qemu
 
  # Keystone
  --auth_strategy=keystone
  --api_paste_config=/etc/nova/api-paste.ini
  --keystone_ec2_url=http://192.168.198.85:5000/v2.0/ec2tokens
 
 
 
 
  Thanks,
  -vj
 
  ___
  Mailing list: https://launchpad.net/~openstack
  Post to : openstack@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~openstack
  More help   : https://help.launchpad.net/ListHelp
 
 
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] inter vm communication issue

[Vishvananda Ishaya]

Ideas inline.

Vish

On May 31, 2012, at 1:41 PM, Bram De Wilde wrote:

 Hi all,
 
 Can I request some help in resolving a vlan networking issue we are 
 encountering in the final stages of our openstack installation?
 
 We have installed a multi host vlan network configuration on 3 hosts all 
 running ubuntu 12.04 (openstack essex ).
 
 One of these hosts is a public host running the compute and network 
 services, the other 2 hosts are on a private vlan and are running compute and 
 network as well as all other components of the openstack installation.
 All physical hosts have 2 nic's in a bond (for redundancy) configured with an 
 ip in the 10.0.0.0/24 range as a private network.
 
 The vm networks we have created are in the 192.168.0.0/16 range and the 
 appropriate vlan tagged networks have been created on the switch.
 
 All openstack components are running fine as we can create, run and live 
 migrate instances with no issues. All vm's can contact all physical hosts in 
 the 10.0.0.0/24 range as well as the outside word using a proxy running on 
 the 10.0.0.254 ip.
 
 The problem arrises when we try to communicate in between vm's running on 
 different hosts:
 - name resolution is not working for vm's running on different physical hosts 
 ( I suppose dns should work, no? )

This is expected in multihost mode. The copy of dnsmasq that runs on each host 
only knows about its own vms.  You will need to set up a shared dns if you 
really need this to work.

 - all packages of communication performed using the ip of the vm directly ( 
 ping, ssh, ...) are arriving on the bridge interface of the physical host 
 running the vm we are tying to reach, but the vm itself is not picking up or 
 responding to the requests...

Have you set up security group rules to allow the traffic? That is the only 
reason I can think that packets wouldn't be getting into the vnet if it is 
showing up on the bridge.  There is also a possiblity that bonding + bridging + 
vlans has some sort of an issue.

 
 The weird thing is, when we start 2 vm's on the same physical host, name 
 resolution and networking are working fine. When we then live-migrate one of 
 the vm's to a new physical host, the networking will continue to work for a 
 varying amount of time after the live migration has completed! A variable 
 amount of the packages start getting lost until we end up with no 
 communication being possible in between the virtual machines. ( after new 
 dhcp lease? arp table getting flushed?... )
 
 As no errors are appearing in any of the nova logs (all on verbose...) or in 
 the syslog (from the dnsmasq) I really have no clue as to what might be 
 causing this issue... or is it a bug?
 
 My feeling is the per physical host vm gateway is not performing as it should 
 and not routing the packages correctly in between physical hosts but I have 
 no idea on how to check this other than capture the packages on the bridge 
 interface and observe the requests not getting answered...
 Another option is the problem residing with the 2 physical interfaces in the 
 network bond... but wireshark is showing all packages are arriving on the 
 bridge interface where the vm we are trying to reach is residing so this 
 seems unlikely?
 
 I have included the nova.conf the ifconfig and the iptables (+nat) of one of 
 the physical hosts in this mail but can provide any other output if this 
 might be helpful.
 
 Kind regards,
 Bram
 
 ###
 #  /etc/nova/nova.conf
 ###
 
 --dhcpbridge_flagfile=/etc/nova/nova.conf
 --dhcpbridge=/usr/bin/nova-dhcpbridge
 --logdir=/var/log/nova
 --state_path=/var/lib/nova
 --lock_path=/var/lock/nova
 ##--force_dhcp_release
 ##--iscsi_helper=tgtadm
 --libvirt_use_virtio_for_bridges
 --connection_type=libvirt
 --root_helper=sudo nova-rootwrap
 --verbose
 --ec2_private_dns_show_ip
 --auth_strategy=keystone
 --rabbit_host=10.0.0.100
 --nova_url=http://10.0.0.100:8774/v1.1/
 --floating_range=999.999.999.0/24
 --fixed_range=192.168.0.0/16
 --routing_source_ip=10.0.0.103
 --sql_connection=postgresql://clouddbadmin:password@10.0.0.100/nova
 --glance_api_servers=10.0.0.100:9292
 --image_service=nova.image.glance.GlanceImageService
 --network_manager=nova.network.manager.VlanManager
 --vlan_interface=bond0
 --public_interface=eth0
 --multi-host=true
 
 ###
 #  ifconfig
 ###
 
 bond0 Link encap:Ethernet  HWaddr bc:30:5b:dd:0c:8a  
  inet addr:10.0.0.103  Bcast:10.0.0.255  Mask:255.255.255.0
  inet6 addr: fe80::be30:5bff:fedd:c8a/64 Scope:Link
  UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
  RX packets:1400289 errors:0 dropped:67725 overruns:0 frame:0
  TX packets:2414277 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:1288957456 (1.2 GB)  TX bytes:3217320483 (3.2 GB)
 
 br1997Link encap:Ethernet  HWaddr fa:16:3e:50:1f:3f  
  inet addr:192.168.1.1  

Re: [Openstack] question about security

[Vishvananda Ishaya]

Generally I handle this by using a different eth device (or vlan) for the 
instance network.  Then you make sure that no services on compute are listening 
on 0.0.0.0

If you have only one interface for example, you can run three vlans across it

eth0:10 - public network public ip address for routing and floating ips and 
such. Nothing should listen here
eth0:11 - management network 192.168.0.0/24 range Rabbit and mysql run on 
this network. All services (ssh, etc.) run here
eth0:12 - vm network 10.0.0.0/8 range for vms. Nothing should listen here 
(except dnsmasq obviously)

Vish

On May 31, 2012, at 7:35 PM, William Herry wrote:

 We use FlatDHCP network mode, all thing work fine, instance has 10.0.0.x ip 
 and 10.0.0.1 as gateway
 Our problem is that service(most time compute node) has little restrict from 
 instance, 
 which instance can see a lot opened port on service, I am thinking if this is 
 a security problem
 
 restrict service on compute node not listen on 10.0.0.x ip is the way I can 
 thing to solve this, any other ways?
 
 Thanks
 
 -- 
 
 
 
 William Herry
 
 williamherrych...@gmail.com
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Understanding shutdown VM behavior

[Vishvananda Ishaya]

I did some cleanup of stop and power_off in the review here.

https://review.openstack.org/#/c/8021/

I removed the weird  shutdown_terminate handling. Honestly I feel like
that is compatibility we don't need. It should be up to the provider whether
a stop_instances counts as a terminate. In my mind they are two different 
things.

Comments welcome on the review.

Vish

On May 31, 2012, at 6:40 PM, Yun Mao wrote:

 shutdown, stop, are power_off are synonym in this discussion. They all
 mean to stop the VM from running, but keep the disk image and network,
 so that the VM could be started back on again.
 
 There are three ways to do it: 1) using EC2 stop-instance API. 2) use
 OS API stop-server. 3) inside the VM, execute halt or equivalent.
 However, the devil is in the details.
 
 In EC2 API, a shutdown_terminate flag is checked when a stop-instance
 call is issued. If it's true, then stop-instances actually means
 terminate instances. The flag is true by default unless there is block
 device mapping provided, and it doesn't appear to be configurable by a
 user.
 
 In OS API, it's defined in v1.1, neither the specification nor the
 implementation check the shutdown_terminate flag at all. It will
 always do stop instead of terminate.
 
 So, when shutdown_terminate is true (default), the OS API and the EC2
 API will behave differently. If we accept this, it might still be
 acceptable. After all they are different APIs and could have different
 behavior. But the pickle is the case where a user initiates a shutdown
 inside the VM. What's the expected behavior after it's detected?
 Should it respect the shutdown_terminate flag or work more like an OS
 API?  Right now when a shutdown in a VM is detected, the vm state is
 updated to SHUTOFF and that's pretty much it..
 
 To summarize, there are 3 ways of doing the same thing, each now has a
 different behavior. I'd vote to patch the code to be a little more
 consistent. But what should be the right behavior?
 
 Yun
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] inter vm communication issue

[Bram De Wilde]

Thanx Vish,

On the name resolution: would you consider this a bug (I can file one if you 
would like) or a feature? Could this be fixed by changing the 
/usr/bin/nova-dhcpbridge script to load all mac, hostname, ip combinations for 
the database instead of just the physical hosts one? Or would this create other 
issues?

Security rules are setup correctly I guess, as all traffic to and from vm's 
running on the same host is not experiencing any issues.
nova secgroup-list-rules default
+-+---+-+---+--+
| IP Protocol | From Port | To Port |  IP Range | Source Group |
+-+---+-+---+--+
| icmp| -1| -1  | 0.0.0.0/0 |  |
| tcp | 22| 22  | 0.0.0.0/0 |  |
+-+---+-+---+--+


The bonding might indeed be an issue, we are currently running a adaptive load 
balancing bond, thus the physical traffic can jump for one physical interface 
to the other at any time...
I will try an disable the bonds and get back to you ass soon as I have done 
that.

Kind regards
bram



On 1-jun-2012, at 09:04, Vishvananda Ishaya wrote:

 Ideas inline.
 
 Vish
 
 On May 31, 2012, at 1:41 PM, Bram De Wilde wrote:
 
 Hi all,
 
 Can I request some help in resolving a vlan networking issue we are 
 encountering in the final stages of our openstack installation?
 
 We have installed a multi host vlan network configuration on 3 hosts all 
 running ubuntu 12.04 (openstack essex ).
 
 One of these hosts is a public host running the compute and network 
 services, the other 2 hosts are on a private vlan and are running compute 
 and network as well as all other components of the openstack installation.
 All physical hosts have 2 nic's in a bond (for redundancy) configured with 
 an ip in the 10.0.0.0/24 range as a private network.
 
 The vm networks we have created are in the 192.168.0.0/16 range and the 
 appropriate vlan tagged networks have been created on the switch.
 
 All openstack components are running fine as we can create, run and live 
 migrate instances with no issues. All vm's can contact all physical hosts in 
 the 10.0.0.0/24 range as well as the outside word using a proxy running on 
 the 10.0.0.254 ip.
 
 The problem arrises when we try to communicate in between vm's running on 
 different hosts:
 - name resolution is not working for vm's running on different physical 
 hosts ( I suppose dns should work, no? )
 
 This is expected in multihost mode. The copy of dnsmasq that runs on each 
 host only knows about its own vms.  You will need to set up a shared dns if 
 you really need this to work.
 
 - all packages of communication performed using the ip of the vm directly ( 
 ping, ssh, ...) are arriving on the bridge interface of the physical host 
 running the vm we are tying to reach, but the vm itself is not picking up or 
 responding to the requests...
 
 Have you set up security group rules to allow the traffic? That is the only 
 reason I can think that packets wouldn't be getting into the vnet if it is 
 showing up on the bridge.  There is also a possiblity that bonding + bridging 
 + vlans has some sort of an issue.
 
 
 The weird thing is, when we start 2 vm's on the same physical host, name 
 resolution and networking are working fine. When we then live-migrate one of 
 the vm's to a new physical host, the networking will continue to work for a 
 varying amount of time after the live migration has completed! A variable 
 amount of the packages start getting lost until we end up with no 
 communication being possible in between the virtual machines. ( after new 
 dhcp lease? arp table getting flushed?... )
 
 As no errors are appearing in any of the nova logs (all on verbose...) or in 
 the syslog (from the dnsmasq) I really have no clue as to what might be 
 causing this issue... or is it a bug?
 
 My feeling is the per physical host vm gateway is not performing as it 
 should and not routing the packages correctly in between physical hosts but 
 I have no idea on how to check this other than capture the packages on the 
 bridge interface and observe the requests not getting answered...
 Another option is the problem residing with the 2 physical interfaces in the 
 network bond... but wireshark is showing all packages are arriving on the 
 bridge interface where the vm we are trying to reach is residing so this 
 seems unlikely?
 
 I have included the nova.conf the ifconfig and the iptables (+nat) of one of 
 the physical hosts in this mail but can provide any other output if this 
 might be helpful.
 
 Kind regards,
 Bram
 
 ###
 #  /etc/nova/nova.conf
 ###
 
 --dhcpbridge_flagfile=/etc/nova/nova.conf
 --dhcpbridge=/usr/bin/nova-dhcpbridge
 --logdir=/var/log/nova
 --state_path=/var/lib/nova
 --lock_path=/var/lock/nova
 ##--force_dhcp_release
 ##--iscsi_helper=tgtadm
 

Re: [Openstack] cfg usage - option registration, global objects

[Gary Kotton]

On 06/01/2012 12:47 AM, Russell Bryant wrote:

On 05/31/2012 04:21 PM, Mark McLoughlin wrote:

I expect to do a pretty detailed review of the patch to add rpc to
openstack-common and make some API design recommendations. But I think
we'll have to balance some of those design ideas between stuff we
really should fix before it goes into openstack-common vs stuff that
would need to be fixed before the API comes out of incubation.

  I've been pushing the code with a goal that the submission to
openstack-common is *only* a matter of changing the imports.  Up to this
point, it has mostly been a matter of removing dependencies on other
parts of nova.  We are actually at that point now ... unless there are
other changes that are going to block it.

I'd rather just work on improvements people would like to see while the
code is in incubation in openstack-common.  People are already copying
it (in a feature branch for Quantum, Cinder, the Heat project, at
least), so moving it as is will leave us in a better spot than we are now.
I agree with Russell. On the Quantum side we are waiting for the code so 
that we can move ahead with a number of blueprints. I understand that 
there is also a solution for versioning.

Thanks
Gary

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Please approve Allow [:print:] chars for security group names

[Vishvananda Ishaya]

It doesn't have 2 +2 from core members, and it has a -1 from Sandy which will 
block it.  Hopefully he can pop in and change it.

Vish

On Jun 1, 2012, at 12:09 AM, Alexey Ababilov wrote:

 Hi!
 Please, could someone approve https://review.openstack.org/#/c/7584/ ? It 
 passed two code reviews and is verified.
 It's about validating security group names in EC2 API.
 
 -- 
 Alessio Ababilov
 Software Engineer
 Grid Dynamics
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] inter vm communication issue

[Vishvananda Ishaya]

On Jun 1, 2012, at 12:46 AM, Bram De Wilde wrote:

 Thanx Vish,
 
 On the name resolution: would you consider this a bug (I can file one if you 
 would like) or a feature?

Bug if it is an easy fix :)

 Could this be fixed by changing the /usr/bin/nova-dhcpbridge script to load 
 all mac, hostname, ip combinations for the database instead of just the 
 physical hosts one? Or would this create other issues?

We would have to do some investigation into special settings. We want to make 
sure that the host doesn't respond to dhcp requests from other hosts. If it is 
possible to set up dnsmasq to do name resolution for the other hosts without 
handing ip addresses then we could do it this way. Someone will have to look 
into it.  It might have to be something a little more complicated like writing 
out a hosts file in addition to the dhcp file and telling dnsmasq to use it. If 
you want to investigate the easiest way to configure dnsmasq to do this, that 
would be a big help.

Vish


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] search on the mailing list

[Massimo Canonico]

Hi,
I'm having a problem deleting my running instance and I would like to 
search on the mailing list in order to figure out if someone had already 
had this problem (i'm quite sure).


So I went to https://lists.launchpad.net/openstack/ with my credentials, 
but I did not find any search button.


Am I wrong?

M

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] how to forbid the instances communicating on the same host but different bridges and vlans?

[romi zhang]

Hi,

 

I use following command to create 2 NICs for the instances of adminTenant
and 1 NICs for aipuTenant:

 

nova-manage network create --label=admin_web --fixed_range_v4=192.168.2.0/28
--num_networks=1 --vlan=200 --bridge=br200 --bridge_interface=eth1
--network_size=16 --multi_host=T
--project_id=5f9281bca6854fe3974a457d81afd78c

 

nova-manage network create --label=admin_ssl
--fixed_range_v4=192.168.21.0/28 --num_networks=1 --vlan=201 --bridge=br201
--bridge_interface=eth2 --network_size=16 --multi_host=T
--project_id=5f9281bca6854fe3974a457d81afd78c

 

nova-manage network create --label=aipu_web --fixed_range_v4=192.168.3.0/28
--num_networks=1 --vlan=300 --bridge=br300 --bridge_interface=eth1
--network_size=16 --multi_host=T
--project_id=ee29f5730caa40958bf4812a0fbec3d9

 

But the result is:

1.   the instance of admin03(192.168.2.3 192.168.21.3,belong
adminTenant) could successfully ping aipu01(192.168.3.3,belong aipuTenant)
on the same compute node(NC01,network+compute service) .

2.   Of course,admin03 could not ping successfully aipu03(192.168.3.6)
on the another compute node(NC02,network+compute service).

 

Is there a way or setting to forbid the IP touching between the instances of
different tenant in different bridges and VLANs on the same compute node?

 

Romi

 

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] XCP with DevStack

[Takaaki Suzuki]

Hi all.

I need your knowledge. :)
I prepared XCP plus OpenvSwitch with Ubuntu precise on own environment.

And I want to prepare DevStack for XCP(Ubuntu).
https://github.com/openstack-dev/devstack/blob/master/tools/xen/README.md
I don't understand localrc network settings part.
The script launched DevStackOSDomU. after that network settings part failed.

If you know any other DevStack/OpenStack for XCP installation or
configuration document.
Please let me know.

Thanks!
--
Midokura Japan
Suzuki

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack][Nova] deference between live-migration and migrate

[John Garbutt]

 From: Vishvananda Ishaya [mailto:vishvana...@gmail.com] 
 Keep in mind that we actually have three options
Good point, I forgot about resize.

I guess we have:
- Live Migrate (with/without block migrate)
- (Non-live) Migrate
- Resize

I guess the more general way of looking at this is having an optional 
scheduler hint:
- user might want to live-migrate to a different availability zone
- user might want to resize to same availability zone
- admin might what to migrate (live or otherwise) to a specific server

 Yun actually suggested that resize/migrate be simplified to do the following 
 instead of scping the file over:
 * snapshot to glance
 * boot new image from snapshot
 This would definitely simplify the code, unfortunately it could have 
 billing/metering repercussions.
Forgot about that, I like that too. To get the same semantics, I guess it would 
be:
stop VM, snapshot VM, start new VM, destroy old VM, allow user to delete 
snapshot.
Rollback just resumes VM and deletes snapshot.

I guess you could have something like this will use data warning you get on 
mobiles, but something like:
This operation involves you being billed for a snapshot. You may delete the 
snapshot once the operation has completed

What do people think about the billing issues from this change?

Cheers,
John

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] search on the mailing list

[Hua ZZ Zhang]

you can try google search with site prefix like: YourKeyWord
site:lists.launchpad.net/openstack/.  perhaps it is not so perfect, but it
is better to have none. :-)

- Edward



   
 Massimo Canonico  
 m...@di.unipmn.it 
   To 
 Sent by:  openstack@lists.launchpad.net,  
 openstack-bounces  cc 
 +zhuadl=cn.ibm.co 
 m@lists.launchpad Subject 
 .net  [Openstack] search on the mailing   
   list
   
 2012-06-01 下午   
 04:05 
   
   
   




Hi,
I'm having a problem deleting my running instance and I would like to
search on the mailing list in order to figure out if someone had already
had this problem (i'm quite sure).

So I went to https://lists.launchpad.net/openstack/ with my credentials,
but I did not find any search button.

Am I wrong?

M

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

inline: graycol.gifinline: pic22416.gifinline: ecblank.gif___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Not able to delete a running instance

[Massimo Canonico]

Hi,
I have a running instance and I'm not able to delete it. It is the tty 
img proposed here:

https://fedoraproject.org/wiki/Getting_started_with_OpenStack_Nova#Images

Note that new instances of this image work (can start-up and shutting-down).

Now the problem is that I'm not able to delete it.
- several time euca-terminate-instance did not work without any error 
message


[mex@minicloud cred]$ euca-describe-instances
RESERVATION r-6xvr06s5  mex default
INSTANCEi-0004  ami-000310.0.0.3
10.0.0.3running nova_key (mex, minicloud.di.unipmn.it)  
0   m1.small2012-05-30T13:21:27Znova
aki-0001ari-0002

[mex@minicloud cred]$ euca-terminate-instances i-0004
[mex@minicloud cred]$ euca-describe-instances
RESERVATION r-6xvr06s5  mex default
INSTANCEi-0004  ami-000310.0.0.3
10.0.0.3running nova_key (mex, minicloud.di.unipmn.it)  
0   m1.small2012-05-30T13:21:27Znova
aki-0001ari-0002



- several time nova delete id without success:

[mex@minicloud cred]$ nova list
++--++--+
| ID |   Name   | Status |   Networks   |
++--++--+
| 4  | Server 4 | ACTIVE | mex=10.0.0.3 |
++--++--+
[mex@minicloud cred]$ nova delete 4
[mex@minicloud cred]$ nova list
++--++--+
| ID |   Name   | Status |   Networks   |
++--++--+
| 4  | Server 4 | ACTIVE | mex=10.0.0.3 |
++--++--+

- reboot: right now, I have openstack installed/configured in one 
machine. I tried to reboot it and nothing has changed.


Any suggestion, please?

Massimo


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] search on the mailing list

[Michael J Fork]

Searchable archives are available at

http://www.mail-archive.com/openstack@lists.launchpad.net/

http://openstack.markmail.org/


Michael

-
Michael Fork
Cloud Architect, Emerging Solutions
IBM Systems  Technology Group



From:   Massimo Canonico m...@di.unipmn.it
To: openstack@lists.launchpad.net,
Date:   06/01/2012 04:50 AM
Subject:[Openstack] search on the mailing list
Sent by:openstack-bounces+mjfork=us.ibm@lists.launchpad.net



Hi,
I'm having a problem deleting my running instance and I would like to
search on the mailing list in order to figure out if someone had already
had this problem (i'm quite sure).

So I went to https://lists.launchpad.net/openstack/ with my credentials,
but I did not find any search button.

Am I wrong?

M

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

inline: graycol.gif___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] search on the mailing list

[Christopher B Ferris]

Could we get these links added to the splash onhttps://launchpad.net/openstack? I'm sure this is a rather common problem.e.g.:Mailing list - openstack@lists.launchpad.net	-seehttps://launchpad.net/~openstackto join	- searchable archives:		http://www.mail-archive.com/openstack@lists.launchpad.net/  http://openstack.markmail.org/We might also consider adding to the FAQ.Cheers,Christopher FerrisIBM Distinguished Engineer, CTO Industry and Cloud StandardsMember, IBM Academy of TechnologyIBM Software Group, Standards Strategyemail: chris...@us.ibm.comTwitter: christo4ferrisphone: +1 508 234 2986-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -To: Massimo Canonico m...@di.unipmn.itFrom: Michael J Fork/Rochester/IBM@IBMUSSent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.netDate: 06/01/2012 06:47AMCc: openstack-bounces+mjfork=us.ibm@lists.launchpad.net, openstack@lists.launchpad.netSubject: Re: [Openstack] search on the mailing list
Searchable archives are available at 

http://www.mail-archive.com/openstack@lists.launchpad.net/

http://openstack.markmail.org/


Michael

-
Michael Fork
Cloud Architect, Emerging Solutions
IBM Systems  Technology Group

Massimo Canonico ---06/01/2012 04:50:25 AM---Hi, I'm having a problem deleting my running instance and I would like to

From:Massimo Canonico m...@di.unipmn.it
To:openstack@lists.launchpad.net, 
Date:06/01/2012 04:50 AM
Subject:[Openstack] search on the mailing list
Sent by:openstack-bounces+mjfork=us.ibm@lists.launchpad.netHi,
I'm having a problem deleting my running instance and I would like to 
search on the mailing list in order to figure out if someone had already 
had this problem (i'm quite sure).

So I went to https://lists.launchpad.net/openstack/with my credentials, 
but I did not find any "search" button.

Am I wrong?

M

___
Mailing list: https://launchpad.net/~openstack
Post to   : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help  : https://help.launchpad.net/ListHelp___Mailing list: https://launchpad.net/~openstackPost to   : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore help  : https://help.launchpad.net/ListHelpinline: Image.1__=0ABBF083DFA932B88f9e8a93df938@us.ibm.com.gif___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] search on the mailing list

[Emilien Macchi]

Hi Massimo,

You can have a look here :

http://openstack.markmail.org


Good luck !


Regards


On Fri, Jun 1, 2012 at 10:05 AM, Massimo Canonico m...@di.unipmn.it wrote:

 Hi,
 I'm having a problem deleting my running instance and I would like to
 search on the mailing list in order to figure out if someone had already
 had this problem (i'm quite sure).

 So I went to 
 https://lists.launchpad.net/**openstack/https://lists.launchpad.net/openstack/with
  my credentials, but I did not find any search button.

 Am I wrong?

 M

 __**_
 Mailing list: 
 https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : 
 https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack
 More help   : 
 https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp




-- 
Emilien Macchi
*SysAdmin (Intern)*
*www.stackops.com* | emilien.mac...@stackops.com**
*

*

 ADVERTENCIA LEGAL 
Le informamos, como destinatario de este mensaje, que el correo electrónico
y las comunicaciones por medio de Internet no permiten asegurar ni
garantizar la confidencialidad de los mensajes transmitidos, así como
tampoco su integridad o su correcta recepción, por lo que STACKOPS
TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias.
Si no consintiese en la utilización del correo electrónico o de las
comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro
conocimiento de manera inmediata. Este mensaje va dirigido, de manera
exclusiva, a su destinatario y contiene información confidencial y sujeta
al secreto profesional, cuya divulgación no está permitida por la ley. En
caso de haber recibido este mensaje por error, le rogamos que, de forma
inmediata, nos lo comunique mediante correo electrónico remitido a nuestra
atención y proceda a su eliminación, así como a la de cualquier documento
adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o
utilización de este mensaje, o de cualquier documento adjunto al mismo,
cualquiera que fuera su finalidad, están prohibidas por la ley.

* PRIVILEGED AND CONFIDENTIAL 
We hereby inform you, as addressee of this message, that e-mail and
Internet do not guarantee the confidentiality, nor the completeness or
proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L.
does not assume any liability for those circumstances. Should you not agree
to the use of e-mail or to communications via Internet, you are kindly
requested to notify us immediately. This message is intended exclusively
for the person to whom it is addressed and contains privileged and
confidential information protected from disclosure by law. If you are not
the addressee indicated in this message, you should immediately delete it
and any attachments and notify the sender by reply e-mail. In such case,
you are hereby notified that any dissemination, distribution, copying or
use of this message or any attachments, for any purpose, is strictly
prohibited by law.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Metering] Meeting agenda for Thursday at 16:00 UTC (May 31th, 2012)

[Julien Danjou]

On Wed, May 30 2012, Julien Danjou wrote:

 The metering project team holds a meeting in #openstack-meeting,
 Thursdays at 1600 UTC
 http://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=0.

 Everyone is welcome.

 http://wiki.openstack.org/Meetings/MeteringAgenda
 Topic: API message format

   * Discuss API message format
   * Open discussion (if we have any time left)

The meeting took place yesterday, a summary follows.

==
#openstack-meeting Meeting
==


Meeting started by jd___ at 16:02:40 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-31-16.02.log.html
.



Meeting summary
---

* LINK: https://lists.launchpad.net/openstack/msg12501.html  (jd___,
  16:02:40)
* actions from previous meetings  (jd___, 16:03:09)
  * jd___ and dhellmann opened a bunch of bugs on Launchpad to track
things https://bugs.launchpad.net/ceilometer  (jd___, 16:03:21)
  * ACTION: dhellmann to report on outcome of demo at DreamHost
(dhellmann, 16:07:44)
  * ACTION: dhellmann to report on outcome of demo at DreamHost  (jd___,
16:07:58)

* API message format  (jd___, 16:08:24)
  * ACTION: nijaba to comment on bug 1006990 for anti spoofing of
messages  (nijaba, 16:15:28)
  * ACTION: nijaba to define a configuration mechanism on a per agent
basis  (nijaba, 16:18:10)
  * AGREED: on the proposal from dhellmann
https://gist.github.com/2844410 for API messaging format, pending
the 2 modifications discussed during the meeting  (nijaba, 16:47:10)

* other topics  (nijaba, 16:49:05)



Meeting ended at 16:50:36 UTC.



Action items, by person
---

* dhellmann
  * dhellmann to report on outcome of demo at DreamHost
  * dhellmann to report on outcome of demo at DreamHost
* nijaba
  * nijaba to comment on bug 1006990 for anti spoofing of messages
  * nijaba to define a configuration mechanism on a per agent basis



People present (lines said)
---

* dhellmann (52)
* nijaba (41)
* jd___ (39)
* flacoste (11)
* uvirtbot (5)
* openstack (4)
* dachary (2)
* zykes- (2)

-- 
Julien Danjou
// eNovance  http://enovance.com
// ✉ julien.dan...@enovance.com  ☎ +33 1 49 70 99 81

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] dhcp is not leasing an ip address in vlan mode

[Sergio Ariel de la Campa Saiz]

Hi:

I had a similar problem as Vijay:

Network controller assigns a private ip address to the vm launched on compute 
node. However, I still cannot ping this ip address from the network(controller 
node). I am running nova-network service only on the controller.

can't connect to remote host (169.254.169.254): Network is unreachable
I solved it when I installed nova-network in all my compute nodes.
I don´t use NAT but only routing, so each node is the default gateway to 
instances that are running on it.

I don´t know if this workaround is good for you, but it is the best I got.

Regards
Sergio Ariel
de la Campa Saiz
GMV-SES Infraestructura /
GMV-SES Infrastructure





GMV
Isaac Newton, 11
P.T.M. Tres Cantos
E-28760 Madrid
Tel.
+34 91 807 21 00
Fax
+34 91 807 21 99
 www.gmv.comhttp://www.gmv.com/













De: openstack-bounces+sacampa=gmv@lists.launchpad.net 
[openstack-bounces+sacampa=gmv@lists.launchpad.net] En nombre de 
Vishvananda Ishaya [vishvana...@gmail.com]
Enviado el: viernes, 01 de junio de 2012 8:35
Para: Vijay
CC: openstack@lists.launchpad.net
Asunto: Re: [Openstack] dhcp is not leasing an ip address in vlan mode

do you see sent and received packets on the vlan?  I would suspect that you 
actually don't have the vlans trunked on the ports so the packets aren't making 
it across the switch.

Vish

On May 31, 2012, at 9:53 AM, Vijay wrote:

Thanks for the reply. Network controller assigns a private ip address to the vm 
launched on compute node. However, I still cannot ping this ip address from the 
network(controller node). I am running nova-network service only on the 
controller.

Thanks,
-vj
From: Narayan Desai narayan.de...@gmail.commailto:narayan.de...@gmail.com
To: Vijay vija...@yahoo.commailto:vija...@yahoo.com
Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net 
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Sent: Wednesday, May 30, 2012 5:28 PM
Subject: Re: [Openstack] dhcp is not leasing an ip address in vlan mode

This sounds like it might be working properly. In VLAN mode, all
instances are connected to one of the project vlans. The .1 address
(gateway, dhcp, etc) exists on an interface on the nova-network node
(or one of them, in the case that you are running multiple. This
interface is bridged to a tagged interface on the appropriate vlan
tag. On the nova-compute nodes, a vnet interface for the instance is
bridged to the vlan tagged interface. On the compute node, there isn't
an IP interface on this network, so the private IP for instances isn't
reachable, even if the instance is running on the same node.

The canonical test for correct network function is if an instance is
reachable via ping from the nova-network server that is currently
serving the instance's project network.
hth
-nld

On Wed, May 30, 2012 at 5:42 PM, Vijay 
vija...@yahoo.commailto:vija...@yahoo.com wrote:
 Hello,
 I am trying install Essex in VLAN mode on multiple compute nodes.

 I am able to lauch instances on controller (which also runs nova-compute)
 and ping/ssh those instances.
 I am able to launch instances on compute only node. However, I cannot ping
 the VM launched  on compute only node.
 When i did the euca-get-console-output on that instance, I see that it is
 not getting an IP leased from DHCP .. Because of that it is not able to
 reach metadata server.
 Any help is appreciated.

 Console output is
 udhcpc (v1.17.2) started
 Sending discover...
 Sending discover...
 Sending discover...
 No lease, forking to background
 starting DHCP forEthernet interface eth0  [  OK  ]
 cloud-setup: checking
 http://169.254.169.254/2009-04-04/meta-data/instance-id
 wget: can't connect to remote host (169.254.169.254): Network is unreachable
 cloud-setup: failed 1/30: up 17.71. request failed
 nova.conf:
 --dhcpbridge_flagfile=/etc/nova/nova.conf
 --dhcpbridge=/usr/local/bin/nova-dhcpbridge
 --logdir=/var/log/nova
 --state_path=/var/lib/nova
 --lock_path=/var/lock/nova
 --force_dhcp_release=True
 --use_deprecated_auth
 --iscsi_helper=tgtadm
 --verbose
 --vncserver_listen=0.0.0.0
 --sql_connection=mysql://novadbadmin:novasecret@192.168.198.85/novahttps://mail.gmv.com/owa/UrlBlockedError.aspx
 --daemonize
 --s3_host=192.168.198.85
 --rabbit_host=192.168.198.85
 --cc_host=192.168.198.85
 --ospi_host=192.168.198.85
 --ec2_host=192.168.198.85
 --ec2_url=http://192.168.198.85:8773/services/Cloud
 --nova_url=http://192.168.198.85:8774/v1.1/

 # VLAN mode
 --flat_interface=eth1
 --flat_injected=False
 --flat_network_bridge=br100
 --flat_network_dhcp_start=192.168.4.2

 --network_manager=nova.network.manager.VlanManager
 --vlan_interface=eth1
 --public_interface=vlan100
 --allow_same_net_traffic=True
 --fixed_range=192.168.4.0/24
 --network_size=256
 --FAKE_subdomain=ec2
 --routing_source_ip=192.168.198.85
 --glance_api_servers=192.168.198.85:9292
 --image_service=nova.image.glance.GlanceImageService
 --iscsi_ip_prefix=192.168.
 

Re: [Openstack] metadata and file injection

[Pádraig Brady]

On 06/01/2012 10:55 AM, William Herry wrote:
 I have been spend all days to search metadata and file injection related info 
 with Google,
 there are few doc or blog about this topic (or I am not use the proper 
 keyword)
 I know about this is only pieces
 
 what I know now is:
 cloud-init can inject files to instance and a lot other things, seems only on 
 ubuntu, 

cloud-init is available for Fedora now.
There is also a test package available for RHEL and derivatives:
http://pbrady.fedorapeople.org/cloud-init-el6/

 I can inject ssh key with qemu-nbd

If you can do that, you can also inject 'metadata',
'files' and root 'passwords'. Note only failure to
inject 'files' will result in a failure to boot the guest.

 my question is:
 what is in metadata, how can I use matadata
 there is no injection related sub command in nova
 
 any related URL will be very appreciate

The `nova` command interface is defined in:
https://github.com/openstack/python-novaclient/blob/master/novaclient/v1_1/shell.py
It would be good to have a man page for the `nova`
command that you could reference.

Anyway here is what you get when executing the
help for the 'boot' command:


# nova help boot
usage: nova boot [--flavor flavor] [--image image] [--meta key=value]
 [--file dst-path=src-path] [--key_name key_name]
 [--user_data user-data]
 [--availability_zone availability-zone]
 [--security_groups security_groups]
 [--block_device_mapping dev_name=mapping]
 [--hint key=value]
 [--nic net-id=net-uuid,v4-fixed-ip=ip-addr]
 [--config-drive value] [--poll]
 name

Boot a new server.

Positional arguments:
  nameName for the new server

Optional arguments:
  --flavor flavor Flavor ID (see 'nova flavor-list').
  --image image   Image ID (see 'nova image-list').
  --meta key=valueRecord arbitrary key/value metadata. May be give
multiple times.
  --file dst-path=src-path
Store arbitrary files from src-path locally to dst-
path on the new server. You may store up to 5 files.
  --key_name key_name
Key name of keypair that should be created earlier
with the command keypair-add
  --user_data user-data
user data file to pass to be exposed by the metadata
server.
  --availability_zone availability-zone
The availability zone for instance placement.
  --security_groups security_groups
comma separated list of security group names.
  --block_device_mapping dev_name=mapping
Block device mapping in the format dev_name=id:typ
e:size(GB):delete_on_terminate.
  --hint key=valueSend arbitrary key/value pairs to the scheduler for
custom use.
  --nic net-id=net-uuid,v4-fixed-ip=ip-addr
Create a NIC on the server. Specify option multiple
times to create multiple NICs. net-id: attach NIC to
network with this UUID (optional) v4-fixed-ip: IPv4
fixed address for NIC (optional).
  --config-drive value
Enable config drive
  --pollBlocks while instance builds so progress can be
reported.


Here are the related APIs that are used by the command above:
http://docs.openstack.org/api/openstack-compute/2/content/CreateServers.html

So what happens when you present --meta options above?
That will bubble through the API to:
https://github.com/openstack/nova/blob/master/nova/virt/disk/api.py
If you look at _inject_metadata_into_fs() there, you can see
that a 'meta.js' file is written to the / directory.
Logic within the guest can then inspect that as required.

cheers,
Pádraig.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] XCP with DevStack

[John Garbutt]

Hi,

I assume you are using xcp-xapi in Ubuntu. First of all, is it all running 
correctly (i.e. xe vm-list is returning correctly):
http://wiki.xen.org/wiki/Using_XCP_-_preparing_the_toolstack

It turns out the current DevStack will not work with this, but I have pushed 
some changes to support it:
https://review.openstack.org/#/c/7673/

The networking configuration can be a little confusing, there is an overview on 
the wiki:
http://wiki.openstack.org/XenServer/NetworkingFlags

The DevStack flags are there to configure each of the VIFs on the DomU, the 
defaults can be seen here:
https://github.com/openstack-dev/devstack/blob/master/tools/xen/xenrc

If things are still un clear, do ask some more questions.
I have plans to document this exact setup in some detail in the near future.
Feel free to add to these docs on the wiki.

Thanks,
John

 -Original Message-
 From: openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net
 [mailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net]
 On Behalf Of Takaaki Suzuki
 Sent: 01 June 2012 10:12
 To: openstack@lists.launchpad.net
 Cc: dev
 Subject: [Openstack] XCP with DevStack
 
 Hi all.
 
 I need your knowledge. :)
 I prepared XCP plus OpenvSwitch with Ubuntu precise on own environment.
 
 And I want to prepare DevStack for XCP(Ubuntu).
 https://github.com/openstack-
 dev/devstack/blob/master/tools/xen/README.md
 I don't understand localrc network settings part.
 The script launched DevStackOSDomU. after that network settings part failed.
 
 If you know any other DevStack/OpenStack for XCP installation or
 configuration document.
 Please let me know.
 
 Thanks!
 --
 Midokura Japan
 Suzuki
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] detect hypervisor

[Massimo Canonico]

Hi all,
since I'm having problem with my machine where I have installed 
openstack following this procedure:

http://fedoraproject.org/wiki/Getting_started_with_OpenStack_Nova

I'm wondering if this is the correct procedure for a machine with xen as 
supervisor. The procedure seems to me hypervisor agnostic but I'm not sure.


Is there a command to know which hypervisor is being used by openstack?

Cheers,
 Massimo

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] dhcp is not leasing an ip address in vlan mode

[Vijay]

I did have a problem in vlan trunking on the switch. I fixed it. Now, I am able 
to ping and ssh the instance that is launched on the compute node from the 
controller. However, when I look into euca-get-console-output of that instance 
on compute node, I still see that it is not able to connect to 169.254.169.254 
(metadata service). But, I see a private ip address getting leased correctly. 
Because of this I am able to ping and ssh successfully from CONTROLLER ONLY 
(not from compute node).
I am not sure if this is the correct behavior. But, in case of flatDHCP this 
metadata connection should be successful. Otherwise, instances cannot be 
pinged/sshed in flatDHCP mode.
 
Can VLAN be run in multi-host mode like it is done in flatDHCP mode as 
suggested by Sergio Ariel below? (with multi_host set to true and running 
nova-network running)
 
 
euca-get-console-output log
 
Sending discover...
Sending select for 192.168.4.5...
Lease of 192.168.4.5 obtained, lease time 120
starting DHCP forEthernet interface eth0  [  OK  ]
cloud-setup: checking http://169.254.169.254/2009-04-04/meta-data/instance-id
wget: can't connect to remote host (169.254.169.254): Connection timed out
cloud-setup: failed 1/30: up 9.84. request failed


Thanks,
-vj



From: Sergio Ariel de la Campa Saiz saca...@gmv.com
To: Vishvananda Ishaya vishvana...@gmail.com; Vijay vija...@yahoo.com 
Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net 
Sent: Friday, June 1, 2012 5:12 AM
Subject: RE: [Openstack] dhcp is not leasing an ip address in vlan mode

Hi:
 
I had a similar problem as Vijay:
 
Network controller assigns a private ip address to the vm launched on compute 
node. However, I still cannot ping this ip address from the network(controller 
node). I am running nova-network service only on the controller.
 
can't connect to remote host (169.254.169.254): Network is unreachable

I solved it when I installed nova-network in all my compute nodes. 
I don´t use NAT but only routing, so each node is the 
default gateway to instances that are running on it.
 
I don´t know if this workaround is good for you, but it is the best I got.
 
Regards
Sergio Ariel 
de la Campa Saiz
GMV-SES Infraestructura / 
GMV-SES Infrastructure  
 
  GMV 
Isaac Newton, 11
P.T.M. Tres Cantos
E-28760 Madrid
Tel. 
+34 91 807 21 00
Fax 
+34 91 807 21 99
 www.gmv.com   

  
  
 
 


De: openstack-bounces+sacampa=gmv@lists.launchpad.net 
[openstack-bounces+sacampa=gmv@lists.launchpad.net] En nombre de 
Vishvananda Ishaya [vishvana...@gmail.com]
Enviado el: viernes, 01 de junio de 2012 8:35
Para: Vijay
CC: openstack@lists.launchpad.net
Asunto: Re: [Openstack] dhcp is not leasing an ip address in vlan mode

do you see sent and received packets on the vlan?  I would suspect that you 
actually don't have the vlans trunked on the ports so the packets aren't making 
it across the switch. 
Vish
On May 31, 2012, at 9:53 AM, Vijay wrote:
Thanks for the reply. Network controller assigns a private ip address to the vm 
launched on compute node. However, I still cannot ping this ip address from the 
network(controller node). I am running nova-network service only on the 
controller.


Thanks,-vj


From: Narayan Desai narayan.de...@gmail.com
To: Vijay vija...@yahoo.com 
Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net 
Sent: Wednesday, May 30, 2012 5:28 PM
Subject: Re: [Openstack] dhcp is not leasing an ip address in vlan mode
This sounds like it might be working properly. In VLAN mode, allinstances are 
connected to one of the project vlans. The .1 address(gateway, dhcp, etc) 
exists on an interface on the nova-network node(or one of them, in the case 
that you are running multiple. Thisinterface is bridged to a tagged interface 
on the appropriate vlantag. On the nova-compute nodes, a vnet interface for 
the instance isbridged to the vlan tagged interface. On the compute node, 
there isn'tan IP interface on this network, so the private IP for instances 
isn'treachable, even if the instance is running on the same node.The canonical 
test for correct network function is if an instance isreachable via ping from 
the nova-network server that is currentlyserving the instance's project 
network.hth-nldOn Wed, May 30, 2012 at 5:42 PM, Vijay vija...@yahoo.com 
wrote: Hello, I am trying install Essex in VLAN mode on multiple compute 
nodes. I am able to lauch instances on controller
 (which also runs nova-compute) and ping/ssh those instances. I am able to 
launch instances on compute only node. However, I cannot ping the VM launched  
on compute only node. When i did the euca-get-console-output on that instance, 
I see that it is not getting an IP leased from DHCP .. Because of that it is 
not able to reach metadata server. Any help is appreciated. Console output 
is udhcpc (v1.17.2) started Sending discover... Sending discover... Sending 
discover... No 

Re: [Openstack] search on the mailing list

[Stefano Maffulli]

On 06/01/2012 04:21 AM, Christopher B Ferris wrote:
 Could we get these links added to the splash
 on https://launchpad.net/openstack? 

Good idea. Done.

thanks,
stef

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] hidden / phasing out instance_types/flavors

[Doug Davis]

Just wondering, is there any reason flavors are not limited to just 
create-time?  Meaning, use it to create a new instance and then copy all 
of the flavor data into the new instance's data. This breaks the 
relationship between the instance and the flavor, allow each to be changed 
independently - or even deleted.  Doing this would mean you wouldn't need 
to add a disabled flag at all - just delete the flavor if you don't want 
anyone to use it.   This would also allow for an easier modification of 
existing instances - just modify the instance's property that needs to 
change w/o creating a whole new flavor (avoids the proliferation of 
flavors too).

thanks
-Doug
__
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  d...@us.ibm.com
The more I'm around some people, the more I like my dog.



Matthew Sherborne matt.sherbo...@rackspace.com 
Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net
06/01/2012 10:41 AM

To
openstack@lists.launchpad.net
cc

Subject
[Openstack] hidden / phasing out instance_types/flavors






Hi Openstack community,

We recently uploaded this change: https://review.openstack.org/#/c/8007/

It adds a 'disabled' field to the 'instance_type' or 'flavor' concept.

The usage scenario we had in mind was to phase out a flavor that's already 
in use; people shouldn't be able to build new instances from that flavor, 
nor should customers see it in the list of available flavors. But when 
they view an existing instance with that flavor type, they should still be 
able to see the name of it at least. But should you change your mind later 
and wish to re-enable it, it's easy to just flip the flag.

We'd appreciate feedback on the added field and the use of the namespace 
in the core code. (Line 56 here: 
https://review.openstack.org/#/c/8007/1/nova/api/openstack/compute/views/flavors.py
 )

The reasoning behind this is:
 * If we did it as an extension, it would greatly complicate the code. The 
code is much simpler being right in the core code.
 * We can't just add a field to the API quickly, so we need to use the 
namespace.
 * The hope is that eventually it would be accepted into the  main API 
anyway, then the coding would be just removing the namespace.

Many thanks in for reading. All feedback appreciated.

Kind Regards,
Matthew Sherborne___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Not able to delete a running instance

[Vishvananda Ishaya]

it looks like you are running a very old version of openstack (perhaps 
diablo?), so it might be harder to figure out the problem.
Please check:

a) if your compute worker is still up and running
b) if there is an error message in the nova-api.log or the nova-compute.log

Vish

On Jun 1, 2012, at 3:30 AM, Massimo Canonico wrote:

 Hi,
 I have a running instance and I'm not able to delete it. It is the tty img 
 proposed here:
 https://fedoraproject.org/wiki/Getting_started_with_OpenStack_Nova#Images
 
 Note that new instances of this image work (can start-up and shutting-down).
 
 Now the problem is that I'm not able to delete it.
 - several time euca-terminate-instance did not work without any error 
 message
 
 [mex@minicloud cred]$ euca-describe-instances
 RESERVATION r-6xvr06s5  mex default
 INSTANCEi-0004  ami-000310.0.0.310.0.0.3  
   running nova_key (mex, minicloud.di.unipmn.it)  0   m1.small
 2012-05-30T13:21:27Znovaaki-0001ari-0002
 [mex@minicloud cred]$ euca-terminate-instances i-0004
 [mex@minicloud cred]$ euca-describe-instances
 RESERVATION r-6xvr06s5  mex default
 INSTANCEi-0004  ami-000310.0.0.310.0.0.3  
   running nova_key (mex, minicloud.di.unipmn.it)  0   m1.small
 2012-05-30T13:21:27Znovaaki-0001ari-0002
 
 
 - several time nova delete id without success:
 
 [mex@minicloud cred]$ nova list
 ++--++--+
 | ID |   Name   | Status |   Networks   |
 ++--++--+
 | 4  | Server 4 | ACTIVE | mex=10.0.0.3 |
 ++--++--+
 [mex@minicloud cred]$ nova delete 4
 [mex@minicloud cred]$ nova list
 ++--++--+
 | ID |   Name   | Status |   Networks   |
 ++--++--+
 | 4  | Server 4 | ACTIVE | mex=10.0.0.3 |
 ++--++--+
 
 - reboot: right now, I have openstack installed/configured in one machine. I 
 tried to reboot it and nothing has changed.
 
 Any suggestion, please?
 
 Massimo
 
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] search on the mailing list

[Christopher B Ferris]

Cool! ThanksCheers,Christopher FerrisIBM Distinguished Engineer, CTO Industry and Cloud StandardsMember, IBM Academy of TechnologyIBM Software Group, Standards Strategyemail: chris...@us.ibm.comTwitter: christo4ferrisphone: +1 508 234 2986-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -To: openstack@lists.launchpad.netFrom: Stefano Maffulli Sent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.netDate: 06/01/2012 12:23PMSubject: Re: [Openstack] search on the mailing listOn 06/01/2012 04:21 AM, Christopher B Ferris wrote: Could we get these links added to the splash on https://launchpad.net/openstack?Good idea. Done.thanks,stef___Mailing list: https://launchpad.net/~openstackPost to   : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore help  : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] 401 Not Authorized from glance - How to fix ?

[Mandar Vaze / मंदार वझे]

Hi,

I'm working on python program that needs to get images detail from glance.
I was using get_admin_context earlier to do all the work in nova side,
but this doesn't seem to work when I query glance.
I get 401 Not Authorized error.

I think I need to get auth_token from keystone, and use it when creating
RequestContext object - then glance query might work. (Is this assumption
correct, in the first place)  But I do not know how to do this
programatically, I looked at nova image-list command, but I didn't get
clear picture on how this should be done.

Can you point to any existing code that authenticates with keystone and
then uses the auth-token to talk to glance ?

Thanks,
-Mandar
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] 401 Not Authorized from glance - How to fix ?

[Anne Gentle]

Several thoughts to ponder. One is, the nova image-list command is
using the Compute API, not the Image API. You can turn on --debug to
see the curl statement issued from the nova client (very handy, that).
Do:
nova --debug image-list
to see what I mean.

Also note there's a new bugfix for python-novaclient
(https://review.openstack.org/#/c/7200/) that fixes a problem with
prettyprint 0.6 removing printt (so it uses get_string now with the
latest version).

Also, I'd definitely point you to this guide as it has drop-in python
code for requesting a token:
http://docs.openstack.org/api/openstack-compute/programmer/content/using-python-to-obtain-the-authentication-token.html

Usually when I get an error from the Image API (Glance) it's because I
didn't put the proper paste-deploy filter in one of the Glance conf
files. If you're the cloud admin in this case, double-check your
glance config with:
http://docs.openstack.org/trunk/openstack-compute/install/content/configure-glance-files.html

If you're not the cloud admin, also know that the Image API isn't
publicly available on many public clouds such as TryStack.

Hope this is helpful.
Anne

On Fri, Jun 1, 2012 at 12:20 PM, Mandar Vaze / मंदार वझे
mandarv...@gmail.com wrote:
 Hi,

 I'm working on python program that needs to get images detail from glance.
 I was using get_admin_context earlier to do all the work in nova side, but
 this doesn't seem to work when I query glance.
 I get 401 Not Authorized error.

 I think I need to get auth_token from keystone, and use it when creating
 RequestContext object - then glance query might work. (Is this assumption
 correct, in the first place)  But I do not know how to do this
 programatically, I looked at nova image-list command, but I didn't get
 clear picture on how this should be done.

 Can you point to any existing code that authenticates with keystone and then
 uses the auth-token to talk to glance ?

 Thanks,
 -Mandar

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to     : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] New Quantum Meeting Time: Monday 21:00 UTC

[Dan Wendlandt]

Starting this monday June 4th.  See you there!

Dan

http://wiki.openstack.org/Network/Meetings

-- 
~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] XCP snapshotting with volumes attached failure

[Vishvananda Ishaya]

On Jun 1, 2012, at 7:40 AM, John Garbutt wrote:

 Hi,
  
 Sorry, not had chance to look at the bugs in the last few days.
  
 It should be possible to just snapshot the root VDI. I guess that is what 
 makes the most sense, what does the API say should happen?

+1 Snapshots should only be of the root drive

Volume snapshots should be done through the volume api (currently there is no 
way to back these snapshots up into glance or some such but that should be 
added)


 I guess we want the snapshot operation on the volume. I am not sure how well 
 this plays with boot from volume.

The only case where i can see a compute snapshot doing a snapshot of a volume 
is if we have booted from a volume. The semantics are a little unclear though. 
Does it snapshot the volume and turn it into a bootable image? (that is what 
compute snapshots currently do)

  
 The error of SR_OPERATION_NOT_SUPPORTED is because you are using LVM over 
 iSCSI (I guess the nova-volume default). If you used the SM integration and 
 did something like VHD over iSCSI you should get the snapshots working. But I 
 guess you don’t want the snapshots sitting un-managed on your storage array?
  
 Cheers,
 John
  
 From: openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net 
 [mailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net] On 
 Behalf Of Roman Sokolkov
 Sent: 01 June 2012 14:38
 To: openstack@lists.launchpad.net
 Subject: [Openstack] XCP snapshotting with volumes attached failure
  
 Hello, openstack developers!
  
 We are using openstack on XCP. And if we tried to snapshot VM with iscsi 
 volumes attached nova fails with http://paste.openstack.org/show/18205/
  
 I filled a bug report few days ago 
 https://bugs.launchpad.net/nova/+bug/1005950 , but there is no answer.
  
 Also, as I could see qemu,kvm snapshotting was refactored 
 https://github.com/openstack/nova/commit/7dbf9c7de23623223ef60c0566d9330797c5f87e
  in favor snap ONLY root devices instead of libvirt snapshotting
  
 We could use some small hacks to prevent snapshoting with attached volumes, 
 but it would be better if xen(xcp) snapshotting will refactored likewise a 
 libvirt one. Is it possible?
 
  
 -- 
 Regards, Roman Sokolkov
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] hidden / phasing out instance_types/flavors

[Chris Behrens]

Doug,

That's the behavior I'd like to see and think it makes the most sense.  It's 
really a requirement if we want a great cells implementation.  instance_types 
table should only be used at the top level API cell.   The data contained in 
the table is passed in the messaging and stored with the newly built, re-built, 
or re-sized instance.  I brought this up a couple days ago internally at 
Rackspace while this current patch was being developed and I think we were 
going to start to look at that next…. assuming everyone loves the idea. :)

- Chris


On Jun 1, 2012, at 9:54 AM, Doug Davis wrote:

 
 Just wondering, is there any reason flavors are not limited to just 
 create-time?  Meaning, use it to create a new instance and then copy all of 
 the flavor data into the new instance's data. This breaks the relationship 
 between the instance and the flavor, allow each to be changed independently - 
 or even deleted.  Doing this would mean you wouldn't need to add a disabled 
 flag at all - just delete the flavor if you don't want anyone to use it.   
 This would also allow for an easier modification of existing instances - just 
 modify the instance's property that needs to change w/o creating a whole new 
 flavor (avoids the proliferation of flavors too). 
 
 thanks
 -Doug
 __
 STSM |  Standards Architect  |  IBM Software Group
 (919) 254-6905  |  IBM 444-6905  |  d...@us.ibm.com
 The more I'm around some people, the more I like my dog. 
 
 
 Matthew Sherborne matt.sherbo...@rackspace.com 
 Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net
 06/01/2012 10:41 AM
 
 To
 openstack@lists.launchpad.net
 cc
 Subject
 [Openstack] hidden / phasing out instance_types/flavors
 
 
 
 
 
 Hi Openstack community, 
 
 We recently uploaded this change: https://review.openstack.org/#/c/8007/ 
 
 It adds a 'disabled' field to the 'instance_type' or 'flavor' concept. 
 
 The usage scenario we had in mind was to phase out a flavor that's already in 
 use; people shouldn't be able to build new instances from that flavor, nor 
 should customers see it in the list of available flavors. But when they view 
 an existing instance with that flavor type, they should still be able to see 
 the name of it at least. But should you change your mind later and wish to 
 re-enable it, it's easy to just flip the flag. 
 
 We'd appreciate feedback on the added field and the use of the namespace in 
 the core code. (Line 56 here: 
 https://review.openstack.org/#/c/8007/1/nova/api/openstack/compute/views/flavors.py
  ) 
 
 The reasoning behind this is: 
  * If we did it as an extension, it would greatly complicate the code. The 
 code is much simpler being right in the core code. 
  * We can't just add a field to the API quickly, so we need to use the 
 namespace. 
  * The hope is that eventually it would be accepted into the  main API 
 anyway, then the coding would be just removing the namespace. 
 
 Many thanks in for reading. All feedback appreciated. 
 
 Kind Regards,
 Matthew Sherborne___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] dhcp is not leasing an ip address in vlan mode

[Vishvananda Ishaya]

yes it can.  The best way is to run nova-api-metadata on every host so the 
request can go locally.  Alternatively you can set the metadata_host config 
option on your compute hosts to the ip of a nova-api server somewhere else.

you might have to be careful which interface the ip metadata_host is on. It 
defaults to my_ip, but i have seen it do odd things if the metadata_host is on 
a different ethernet device than the vms, so you might have to manually set it 
to a different ip.

Vish

On Jun 1, 2012, at 9:11 AM, Vijay wrote:

 I did have a problem in vlan trunking on the switch. I fixed it. Now, I am 
 able to ping and ssh the instance that is launched on the compute node from 
 the controller. However, when I look into euca-get-console-output of that 
 instance on compute node, I still see that it is not able to connect to 
 169.254.169.254 (metadata service). But, I see a private ip address getting 
 leased correctly. Because of this I am able to ping and ssh successfully from 
 CONTROLLER ONLY (not from compute node).
 I am not sure if this is the correct behavior. But, in case of flatDHCP this 
 metadata connection should be successful. Otherwise, instances cannot be 
 pinged/sshed in flatDHCP mode.
  
 Can VLAN be run in multi-host mode like it is done in flatDHCP mode as 
 suggested by Sergio Ariel below? (with multi_host set to true and running 
 nova-network running)
  
  
 euca-get-console-output log
  
 Sending discover...
 Sending select for 192.168.4.5...
 Lease of 192.168.4.5 obtained, lease time 120
 starting DHCP forEthernet interface eth0  [  OK  ]
 cloud-setup: checking http://169.254.169.254/2009-04-04/meta-data/instance-id
 wget: can't connect to remote host (169.254.169.254): Connection timed out
 cloud-setup: failed 1/30: up 9.84. request failed
  
 Thanks,
 -vj
 From: Sergio Ariel de la Campa Saiz saca...@gmv.com
 To: Vishvananda Ishaya vishvana...@gmail.com; Vijay vija...@yahoo.com 
 Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net 
 Sent: Friday, June 1, 2012 5:12 AM
 Subject: RE: [Openstack] dhcp is not leasing an ip address in vlan mode
 Hi:
  
 I had a similar problem as Vijay:
  
 Network controller assigns a private ip address to the vm launched on 
 compute node. However, I still cannot ping this ip address from the 
 network(controller node). I am running nova-network service only on the 
 controller.
  
 can't connect to remote host (169.254.169.254): Network is unreachable
 I solved it when I installed nova-network in all my compute nodes.
 I don´t use NAT but only routing, so each node is the default gateway to 
 instances that are running on it.
  
 I don´t know if this workaround is good for you, but it is the best I got.
  
 Regards
  
  
 Sergio Ariel
 de la Campa Saiz
 GMV-SES Infraestructura / 
 GMV-SES Infrastructure
  
  
  
 GMV
 Isaac Newton, 11
 P.T.M. Tres Cantos
 E-28760 Madrid
 Tel.
 +34 91 807 21 00
 Fax
 +34 91 807 21 99
  www.gmv.com
  
 
  
  
 De: openstack-bounces+sacampa=gmv@lists.launchpad.net 
 [openstack-bounces+sacampa=gmv@lists.launchpad.net] En nombre de 
 Vishvananda Ishaya [vishvana...@gmail.com]
 Enviado el: viernes, 01 de junio de 2012 8:35
 Para: Vijay
 CC: openstack@lists.launchpad.net
 Asunto: Re: [Openstack] dhcp is not leasing an ip address in vlan mode
 do you see sent and received packets on the vlan?  I would suspect that you 
 actually don't have the vlans trunked on the ports so the packets aren't 
 making it across the switch.
 Vish
 On May 31, 2012, at 9:53 AM, Vijay wrote:
 Thanks for the reply. Network controller assigns a private ip address to the 
 vm launched on compute node. However, I still cannot ping this ip address 
 from the network(controller node). I am running nova-network service only on 
 the controller.
  
 Thanks,-vj
 From: Narayan Desai narayan.de...@gmail.com
 To: Vijay vija...@yahoo.com 
 Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net 
 Sent: Wednesday, May 30, 2012 5:28 PM
 Subject: Re: [Openstack] dhcp is not leasing an ip address in vlan mode
 This sounds like it might be working properly. In VLAN mode, allinstances 
 are connected to one of the project vlans. The .1 address(gateway, dhcp, 
 etc) exists on an interface on the nova-network node(or one of them, in the 
 case that you are running multiple. Thisinterface is bridged to a tagged 
 interface on the appropriate vlantag. On the nova-compute nodes, a vnet 
 interface for the instance isbridged to the vlan tagged interface. On the 
 compute node, there isn'tan IP interface on this network, so the private IP 
 for instances isn'treachable, even if the instance is running on the same 
 node.The canonical test for correct network function is if an instance 
 isreachable via ping from the nova-network server that is currentlyserving 
 the instance's project network.hth-nldOn Wed, May 30, 2012 at 5:42 PM, Vijay 
 vija...@yahoo.com wrote: Hello, I am trying install Essex in VLAN mode 
 on multiple compute 

Re: [Openstack] hidden / phasing out instance_types/flavors

[Doug Davis]

Glad to hear that.  Just FYI, CIMI [1]  does this type of thing so if we 
ever do manage to harmonize the two APIs this might be a good place to 
start.

[1] 
http://dmtf.org/sites/default/files/standards/documents/DSP0263_1.0.0d.pdf

thanks
-Doug
__
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  d...@us.ibm.com
The more I'm around some people, the more I like my dog.



Chris Behrens cbehr...@codestud.com 
06/01/2012 02:42 PM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
Chris Behrens cbehr...@codestud.com, Matthew Sherborne 
matt.sherbo...@rackspace.com, openstack@lists.launchpad.net
Subject
Re: [Openstack] hidden / phasing out instance_types/flavors






Doug,

That's the behavior I'd like to see and think it makes the most sense. 
It's really a requirement if we want a great cells implementation. 
instance_types table should only be used at the top level API cell.   The 
data contained in the table is passed in the messaging and stored with the 
newly built, re-built, or re-sized instance.  I brought this up a couple 
days ago internally at Rackspace while this current patch was being 
developed and I think we were going to start to look at that next?. 
assuming everyone loves the idea. :)

- Chris


On Jun 1, 2012, at 9:54 AM, Doug Davis wrote:


Just wondering, is there any reason flavors are not limited to just 
create-time?  Meaning, use it to create a new instance and then copy all 
of the flavor data into the new instance's data. This breaks the 
relationship between the instance and the flavor, allow each to be changed 
independently - or even deleted.  Doing this would mean you wouldn't need 
to add a disabled flag at all - just delete the flavor if you don't want 
anyone to use it.   This would also allow for an easier modification of 
existing instances - just modify the instance's property that needs to 
change w/o creating a whole new flavor (avoids the proliferation of 
flavors too). 

thanks
-Doug
__
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  d...@us.ibm.com
The more I'm around some people, the more I like my dog. 


Matthew Sherborne matt.sherbo...@rackspace.com 
Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net
06/01/2012 10:41 AM 


To
openstack@lists.launchpad.net 
cc

Subject
[Openstack] hidden / phasing out instance_types/flavors








Hi Openstack community, 

We recently uploaded this change: https://review.openstack.org/#/c/8007/ 

It adds a 'disabled' field to the 'instance_type' or 'flavor' concept. 

The usage scenario we had in mind was to phase out a flavor that's already 
in use; people shouldn't be able to build new instances from that flavor, 
nor should customers see it in the list of available flavors. But when 
they view an existing instance with that flavor type, they should still be 
able to see the name of it at least. But should you change your mind later 
and wish to re-enable it, it's easy to just flip the flag. 

We'd appreciate feedback on the added field and the use of the namespace 
in the core code. (Line 56 here: 
https://review.openstack.org/#/c/8007/1/nova/api/openstack/compute/views/flavors.py
 
) 

The reasoning behind this is: 
 * If we did it as an extension, it would greatly complicate the code. The 
code is much simpler being right in the core code. 
 * We can't just add a field to the API quickly, so we need to use the 
namespace. 
 * The hope is that eventually it would be accepted into the  main API 
anyway, then the coding would be just removing the namespace. 

Many thanks in for reading. All feedback appreciated. 

Kind Regards,
Matthew Sherborne___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] 401 Not Authorized from glance - How to fix ?

[Rafael Durán Castañeda]

El 01/06/12 19:43, Anne Gentle escribió:

Several thoughts to ponder. One is, the nova image-list command is
using the Compute API, not the Image API. You can turn on --debug to
see the curl statement issued from the nova client (very handy, that).
Do:
nova --debug image-list
to see what I mean.

Also note there's a new bugfix for python-novaclient
(https://review.openstack.org/#/c/7200/) that fixes a problem with
prettyprint 0.6 removing printt (so it uses get_string now with the
latest version).

Also, I'd definitely point you to this guide as it has drop-in python
code for requesting a token:
http://docs.openstack.org/api/openstack-compute/programmer/content/using-python-to-obtain-the-authentication-token.html

Usually when I get an error from the Image API (Glance) it's because I
didn't put the proper paste-deploy filter in one of the Glance conf
files. If you're the cloud admin in this case, double-check your
glance config with:
http://docs.openstack.org/trunk/openstack-compute/install/content/configure-glance-files.html

If you're not the cloud admin, also know that the Image API isn't
publicly available on many public clouds such as TryStack.

Hope this is helpful.
Anne

On Fri, Jun 1, 2012 at 12:20 PM, Mandar Vaze / मंदार वझे
mandarv...@gmail.com  wrote:

Hi,

I'm working on python program that needs to get images detail from glance.
I was using get_admin_context earlier to do all the work in nova side, but
this doesn't seem to work when I query glance.
I get 401 Not Authorized error.

I think I need to get auth_token from keystone, and use it when creating
RequestContext object - then glance query might work. (Is this assumption
correct, in the first place)  But I do not know how to do this
programatically, I looked at nova image-list command, but I didn't get
clear picture on how this should be done.

Can you point to any existing code that authenticates with keystone and then
uses the auth-token to talk to glance ?

Thanks,
-Mandar

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Using python-keystoneclient on glance server:

 import keystoneclient.v2_0.client as k_client
 kc = 
k_client.Client(username='user',password='pass',tenant_name='tenant',auth_url=http://url:35357/v2.0;)

 kc.auth_token
u'07faf8d1e2b140aa9da3079949af7de6'
 import glance.client as g_client
 gc = g_client.Client(host='localhost', auth_tok=kc.auth_token)
 gc.get_images()
[{u'name': u'tty-linux-kernel', u'container_format': u'aki', 
u'disk_format': u'aki', u'checksum': 
u'79427f585fcc90792ea2df8f476df79e', u'id': 
u'ad11d686-d893-4379-a89f-1dd3e8ee79a2', u'size': 4438032}, {u'name': 
u'tty-linux', u'container_format': u'ami', u'disk_format': u'ami', 
u'checksum': u'911439879a8f1fdb83aa7e2480520661', u'id': 
u'5ce20d5d-4dee-492f-be87-e66dc2a84290', u'size': 25165824}, {u'name': 
u'ubuntu-12.04-server-cloudimg-amd64-official', u'container_format': 
u'bare', u'disk_format': u'qcow2', u'checksum': 
u'df4256e6c361380cb7613c74130feca9', u'id': 
u'34599355-bed1-4e16-b0c0-2695d92a3e22', u'size': 226426880}, {u'name': 
u'ubuntu-precise-40GB-amd64', u'container_format': u'bare', 
u'disk_format': u'qcow2', u'checksum': 
u'91a014dd7483eaaabe55074342c748f3', u'id': 
u'57bcd266-8831-465f-b76f-2aeb8736584c', u'size': 622460928}, {u'name': 
u'tty-linux-kernel', u'container_format': u'aki', u'disk_format': 
u'aki', u'checksum': u'79427f585fcc90792ea2df8f476df79e', u'id': 
u'4744184b-e7c3-4ee1-af2f-f77a9ef65e5b', u'size': 4438032}, {u'name': 
u'tty-linux', u'container_format': u'ami', u'disk_format': u'ami', 
u'checksum': u'911439879a8f1fdb83aa7e2480520661', u'id': 
u'01a5bdb2-b41b-48ee-a571-7c517f1fde07', u'size': 25165824}, {u'name': 
u'tty-linux', u'container_format': u'ami', u'disk_format': u'ami', 
u'checksum': u'911439879a8f1fdb83aa7e2480520661', u'id': 
u'df244f77-e868-4473-bee6-fe5f1f513c5f', u'size': 25165824}, {u'name': 
u'tty-linux-kernel', u'container_format': u'aki', u'disk_format': 
u'aki', u'checksum': u'79427f585fcc90792ea2df8f476df79e', u'id': 
u'2902fc1d-cb32-4cf2-ac69-fecf611a620d', u'size': 4438032}]


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] the right way to deprecate a config option?

[Sean Dague]

I'm reworking the virt driver loading so that it's using importutils 
(and thus looking more like the other driver interfaces), which means 
eventually connection_type parameter in nova.conf goes away, and 
computer_driver is used directly (the support is already there, but it's 
not currently used by default).


Is there a standard mechanism for deprecating a conf option like this? 
Right now I'm just triggering a LOG.error() with a deprecation message, 
but it seems like there should be something more standard for that, 
especially as we get into a deprecate in N, remove in N+1. I'm assuming 
this is a deprecation in Folsom (where the docs are changed to the new 
method), then remove the backwards compat in G.


-Sean

--
Sean Dague
IBM Linux Technology Center
email: sda...@linux.vnet.ibm.com
alt-email: slda...@us.ibm.com


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Signed Tokens

[Adam Young]

The signed tokens work has been updated.  I think this is the final 
architecture.


https://github.com/admiyo/keystone/commits/signed-tokens-5

Not all of the unit tests run. Some of the Memcache tests are suspect, 
and I wonder if we even need memcache support for tokens in the middle 
ware.  I think we don't.


Also,  the Diablo tokens are not supported.  I think we can safely 
deprecate them for Folsom.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] OpenStack Community Newsletter — May 25

[Stefano Maffulli]

Highlights of the week


Mark your calendars: Bug triage day on June 7th
http://markmail.org/message/6qaxhvey3bamdj3f

Short on the heels of folsom-1 publication and the upcoming Swift 1.5.0
release, it sounds like a good moment to spend some time sanitizing the
*bug* databases for OpenStack projects. This can be achieved by
completing the tasks described on the BugTriage
http://wiki.openstack.org/BugTriage page.


How to setup and use the OpenStack VNC console

https://www.ibm.com/developerworks/mydeveloperworks/blogs/e93514d3-c4f0-4aa0-8844-497f370090f5/entry/openstack_vnc_console18?lang=en

Yong Sheng Gong
http://pipes.yahoo.com/pipes/pipe.info?_id=bb3905a64a08b9d8167502028410a1e8
reports on how to use the Virtual Network Computing (VNC) in Nova. VNC
is a very convenient tool for end user to access the VMs by GUI.  Nova
provides two kinds of VNC proxies: noVNC and nova-xvpvncproxy.


Want to install OpenStack Swift? Here’s how to do it!

http://www.hastexo.com/blogs/martin/2012/05/29/want-install-openstack-swift-heres-how-do-it

Martin Loschwitz
http://www.hastexo.com/blogs/martin/tag/openstack/feed took some time
to update the OpenStack installation guide.The guide covers SQL-backed
Keystone and VNC support in the Dashboard now. And: It explains how to
install OpenStack Swift now, too! If you want to install Swift and need
a step-by-step howto, then this is what you are looking for.


Caimito – WebDAV frontend for OpenStack Swift Cloud Storage
http://markmail.org/message/olk4yfthbuiek5r4

Caimito is now on github: https://github.com/ngasiproj/caimito


* OpenStack’s Jenkins Job Filler
http://www.linuxjedi.co.uk/2012/05/openstacks-jenkins-job-filler.html*

Andrew Hutchings http://www.linuxjedi.co.uk/search/label/openstack
describes the new tool to manage OpenStack’s Jenkins server, with its
~300 jobs. Jenkins Job Filler is the solution developed by the CI team
to keep the jobs under control.


New git-based jenkins jobs and pre-approval check jobs
http://markmail.org/message/am7lkomqyfhckgnm

Monty Taylor announced that now we have the basic jobs for all of the
projects (except Horizon) applied to jenkins based on some scripts and
some yaml files that are in a git repo.anybody could conceivably do some
hacking and submit a change to gerrit, instead of the current status quo
which is that you have to be a jenkins admin to touch anything. Also the
CI team is now running merge checks, pep8 checks and unittest jobs on
the patch-uploaded event and reporting the results into the code review
so that people can skip code reviewing patches that don’t work yet.


Work in progress on Openstack provider for Juju
http://markmail.org/message/qccflsi5iaryispa

Robbie Williamson reported work in progress to add an OpenStack API
provider to complement the existing set of EC2 and LXC (local dev)
providers.


Nodejs in horizon? Not at the moment
http://markmail.org/message/hxla3exawr2s76na

A long discussion on the mailing list about adding dependencies to the
project, picking the best tools for the job, the Not Invented Here and
Reinventing The Wheel syndrome. A very good read. The community of
developers agreed taht we will work to make node.js an optional build
time component and leave it as an distro packaging issue. Node.js was
being evaluated as a potential solution to
https://blueprints.launchpad.net/horizon/+spec/realtime-communication,
but that blueprint isn’t targeted for Folsom, so it’s very future. There
will be time to evaluate python based alternatives.


A good list of opportunites for Industry Conferences 
Sponsorship  on OpenStack Events Update
http://www.openstack.org/blog/2012/05/openstack-events-update/

  * **OSCON http://www.oscon.com/oscon2012 | July 16-20 | Portland, OR
  * Linux Foundation CloudOpen
https://events.linuxfoundation.org/events/cloudopen | August 29-31
| San Diego, CA
  * Gartner Symposium  ITxpo
http://www.gartner.com/technology/symposium/orlando/ | October
21-25 | Orlando, FL

And the next OpenStack Conference and Summit on October 16-20
(destination TBD).


Facebook for Social Support? I like.

http://justwriteclick.com/2012/06/01/facebook-for-social-support-i-like/

Anne Gentle reports about the experience of using the Facebook group for
people to ask questions specific to TryStack. Checkout the video:
http://www.youtube.com/watch?feature=player_embeddedv=yNdIRCn6Mo8
http://www.youtube.com/watch?feature=player_embeddedv=yNdIRCn6Mo8


Reports from past OpenStack events

  * OpenStack Meetup Apr 26 in Los Angeles
http://www.openstack.org/blog/2012/05/recap-openstack-meetup-apr-26/


Upcoming Events

  * OpenShift + OpenStack + Fedora = Awesome!
http://www.meetup.com/CloudTalk/events/58242322/ Jun 05, 2012 –
Redmond, WA Details http://www.meetup.com/CloudTalk/events/58242322/
  

Re: [Openstack] dhcp is not leasing an ip address in vlan mode

[Narayan Desai]

Along these lines, it seemed simplest if we just ran nova-api-metadata on
each nova-network server. That way we could get rid of the awful ospf setup
for metadata and just let the network aggregation do its job.
 -nld

On Fri, Jun 1, 2012 at 1:58 PM, Vishvananda Ishaya vishvana...@gmail.comwrote:

 yes it can.  The best way is to run nova-api-metadata on every host so the
 request can go locally.  Alternatively you can set the metadata_host config
 option on your compute hosts to the ip of a nova-api server somewhere else.

 you might have to be careful which interface the ip metadata_host is on.
 It defaults to my_ip, but i have seen it do odd things if the metadata_host
 is on a different ethernet device than the vms, so you might have to
 manually set it to a different ip.

 Vish

 On Jun 1, 2012, at 9:11 AM, Vijay wrote:

 I did have a problem in vlan trunking on the switch. I fixed it. Now, I am
 able to ping and ssh the instance that is launched on the compute node from
 the controller. However, when I look into euca-get-console-output of that
 instance on compute node, I still see that it is not able to connect
 to 169.254.169.254 (metadata service). But, I see a private ip address
 getting leased correctly. Because of this I am able to ping and ssh
 successfully from CONTROLLER ONLY (not from compute node).
 I am not sure if this is the correct behavior. But, in case of flatDHCP
 this metadata connection should be successful. Otherwise, instances cannot
 be pinged/sshed in flatDHCP mode.

 Can VLAN be run in multi-host mode like it is done in flatDHCP mode as
 suggested by Sergio Ariel below? (with multi_host set to true and running
 nova-network running)


 euca-get-console-output log

 Sending discover...
 Sending select for 192.168.4.5...
 Lease of 192.168.4.5 obtained, lease time 120
 starting DHCP forEthernet interface eth0  [  OK  ]
 cloud-setup: checking
 http://169.254.169.254/2009-04-04/meta-data/instance-id
 wget: can't connect to remote host (169.254.169.254): Connection timed out
 cloud-setup: failed 1/30: up 9.84. request failed

 Thanks,
 -vj
   *From:* Sergio Ariel de la Campa Saiz saca...@gmv.com
 *To:* Vishvananda Ishaya vishvana...@gmail.com; Vijay vija...@yahoo.com

 *Cc:* openstack@lists.launchpad.net openstack@lists.launchpad.net
 *Sent:* Friday, June 1, 2012 5:12 AM
 *Subject:* RE: [Openstack] dhcp is not leasing an ip address in vlan mode
 **
  Hi:

 I had a similar problem as Vijay:

 Network controller assigns a private ip address to the vm launched oncompute 
 node.
 However, I still cannot ping this ip address from the network(controllernode).
 I am running nova-network service only on the controller.

 can't connect to remote host (169.254.169.254): Network is unreachable
 I solved it when I installed nova-network in all my compute nodes.
 I don´t use NAT but only routing, so each node is the default gateway to
  instances that are running on it.

 I don´t know if this workaround is good for you, but it is the best I got.

 Regards


   *Sergio Ariel *
 *de la Campa Saiz*
 GMV-SES Infraestructura /
 GMV-SES Infrastructure



  *GMV*
 Isaac Newton, 11
 P.T.M. Tres Cantos
 E-28760 Madrid
 Tel.
 +34 91 807 21 00
 Fax
 +34 91 807 21 99
  www.gmv.com




  *De:* openstack-bounces+sacampa=gmv@lists.launchpad.net [
 openstack-bounces+sacampa=gmv@lists.launchpad.net] En nombre de
 Vishvananda Ishaya [vishvana...@gmail.com]
 *Enviado el:* viernes, 01 de junio de 2012 8:35
 *Para:* Vijay
 *CC:* openstack@lists.launchpad.net
 *Asunto:* Re: [Openstack] dhcp is not leasing an ip address in vlan mode
 **
  do you see sent and received packets on the vlan?  I would suspect that
 you actually don't have the vlans trunked on the ports so the packets
 aren't making it across the switch.
 **
 Vish
 **
 On May 31, 2012, at 9:53 AM, Vijay wrote:
 **

  Thanks for the reply. Network controller assigns a private ip address to
 the vm launched on compute node. However, I still cannot ping this ip
 address from the network(controller node). I am running nova-network
 service only on the controller.

 Thanks,**-vj**
   *From:* Narayan Desai narayan.de...@gmail.com
 *To:* Vijay vija...@yahoo.com
 *Cc:* openstack@lists.launchpad.net openstack@lists.launchpad.net
 *Sent:* Wednesday, May 30, 2012 5:28 PM
 *Subject:* Re: [Openstack] dhcp is not leasing an ip address in vlan mode
 **This sounds like it might be working properly. In VLAN mode, all**instances
 are connected to one of the project vlans. The .1 address**(gateway,
 dhcp, etc) exists on an interface on the nova-network node**(or one of
 them, in the case that you are running multiple. This**interface is
 bridged to a tagged interface on the appropriate vlan**tag. On the
 nova-compute nodes, a vnet interface for the instance is**bridged to the
 vlan tagged interface. On the compute node, there isn't**an IP interface
 on this network, so the private IP for instances isn't**reachable, even
 if the instance is running on the same 

Re: [Openstack] how to forbid the instances communicating on the same host but different bridges and vlans?

[romizhang1968]

Vish,


Thanks for your replay.
Yes,I allowed icmp ping from 0.0.0.0/0, but the question is , i think the 
different instance in different tenant and vlan on the same compute node should 
not touch each other, admin03(192.168.2.3) in VLAN 200 and 201 should only 
could get ip touch to the same tenant instance, should not can touch 
aipu01(192.168.3.3) in VLAN 300 and aipuTenant even on the same compute node.
I check the route table, openstack creates route item to each bridge on the 
node, but in admin03,the route table only shows about how to go 192.168.2.0 and 
192.168.21.0, have no way to touch the net of 192.168.3.0. but in admin03,it 
could ping aipu01, that means it use the node route table, i did not know why.
so I want to know is there a way in openstack command to stop this situation, 
not replay me to delete the compute node route item. and I think, each VM 
should connect to the access port and go through trunk port(eth1 or eth2) to 
communicate with others.
here is my wants. 
regards,
Romi




At 2012-06-02 00:47:49,Vishvananda Ishaya vishvana...@gmail.com wrote:
Broadcast traffic should be blocked via the vlan separation and direct traffic 
should be blocked via security groups. Do you have a security group that allows 
ping traffic from 0.0.0.0/0?


Vish


On Jun 1, 2012, at 1:38 AM, romi zhang wrote:


Hi,
 
I use following command to create 2 NICs for the instances of adminTenant and 1 
NICs for aipuTenant:
 
nova-manage network create --label=admin_web --fixed_range_v4=192.168.2.0/28 
--num_networks=1 --vlan=200 --bridge=br200 --bridge_interface=eth1 
--network_size=16 --multi_host=T --project_id=5f9281bca6854fe3974a457d81afd78c
 
nova-manage network create --label=admin_ssl --fixed_range_v4=192.168.21.0/28 
--num_networks=1 --vlan=201 --bridge=br201 --bridge_interface=eth2 
--network_size=16 --multi_host=T --project_id=5f9281bca6854fe3974a457d81afd78c
 
nova-manage network create --label=aipu_web --fixed_range_v4=192.168.3.0/28 
--num_networks=1 --vlan=300 --bridge=br300 --bridge_interface=eth1 
--network_size=16 --multi_host=T --project_id=ee29f5730caa40958bf4812a0fbec3d9
 
But the result is:
1.   the instance of admin03(192.168.2.3 192.168.21.3,belong adminTenant) 
could successfully ping aipu01(192.168.3.3,belong aipuTenant) on the same 
compute node(NC01,network+compute service) .
2.   Of course,admin03 could not ping successfully aipu03(192.168.3.6) on 
the another compute node(NC02,network+compute service).
 
Is there a way or setting to forbid the IP touching between the instances of 
different tenant in different bridges and VLANs on the same compute node?
 
Romi
 
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp