Hi, team, I clicked Project/Instances, got this Error: Error: Unable to retrieve instance size information.
then the Instance's "Size" went to "Not available", Instance became unaccessible Anyone help? Thanks! FYI: Version: Icehouse Yours sincerely, -Brant -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Monday, September 8, 2014 08:00 PM To: [email protected]; [email protected] Subject: OpenStack-operators Digest, Vol 47, Issue 9 Send OpenStack-operators mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenStack-operators digest..." Today's Topics: 1. Re: Neutron metering agent (George Shuklin) 2. Re: Neutron metering agent (Xav Paice) 3. Glance vmware backend (Baruch, Ohad) ---------------------------------------------------------------------- Message: 1 Date: Sun, 07 Sep 2014 15:06:46 +0300 From: George Shuklin <[email protected]> To: [email protected] Subject: Re: [Openstack-operators] Neutron metering agent Message-ID: <[email protected]> Content-Type: text/plain; charset=windows-1252; format=flowed Yep, it is bug. I report it, and one guy close in (hate you, devstack), but now it seems be in the process of fixing. But there is an 25% chance it will be ported to icehouse and 5% change for havana. This bug happens if you got more than one network node. If routers are in database, but not present on network node running metering agent, it will fail to do anything. We manage to scramble patch to work with problem, but it is rather drastic - we skip all errors in that place of code and continue. If you want I cant post patch, but you gonna need to rebuild neutron package (rather annoying process). Here my bugreport: https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1286209 On 09/07/2014 10:06 AM, Xav Paice wrote: > Hi, > > A quick query if anyone is using the neutron metering agent to measure > traffic in/out of routers: > > When adding the metering label and rules, on some, but not all, of our > routers, I get a traceback in the metering_agent.log pointing at > "TRACE neutron.openstack.common.rpc.amqp TypeError: cannot concatenate > 'str' and 'NoneType' objects". > > After that error, the router no longer passes traffic other than ping > until we stop the metering agent, and restart the L3 agent. > > This doesn't seem to affect routers with only one subnet, and only one > router in the tenant - but I may be completely misunderstanding the > whole thing here. It appears as soon as we get a router with more > than one network (plus gateway) we get trouble. > > We're using Havana on Trusty, and the current Cloud Archive packages. > > The rules are a simple egress and ingress, 0.0.0.0/0, both on the same > meter-label. > > Anyone had similar experiences, or got tips for diagnosing this? > > I will be reading the code over the next few days :) > > _______________________________________________ > OpenStack-operators mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operator > s ------------------------------ Message: 2 Date: Mon, 08 Sep 2014 13:04:12 +1200 From: Xav Paice <[email protected]> To: [email protected] Subject: Re: [Openstack-operators] Neutron metering agent Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 On 08/09/14 00:06, George Shuklin wrote: > Yep, it is bug. > > I report it, and one guy close in (hate you, devstack), but now it > seems be in the process of fixing. But there is an 25% chance it will > be ported to icehouse and 5% change for havana. > > This bug happens if you got more than one network node. If routers are > in database, but not present on network node running metering agent, > it will fail to do anything. > > We manage to scramble patch to work with problem, but it is rather > drastic - we skip all errors in that place of code and continue. > > If you want I cant post patch, but you gonna need to rebuild neutron > package (rather annoying process). > > Here my bugreport: > https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1286209 Thanks George, although that's not quite the same behaviour we're seeing it's one that is going to hit us when we switch on the second L3 node (currently we're using Pacemaker but it's too slow to re-schedule the routers during failover). Having seen your bug report I don't think we'll do any changes in that respect till after our upgrade to Icehouse at least. In our particular case, we have just one (running) L3 agent, and it appears fine when we add metering labels right up to one of our special tenants/routers, and somehow the iptables rules are not being applied correctly. My biggest trouble with this is reproducing it in our test environment - so far: - create a bunch of tenants, routers and networks, and attach instances to the networks - start neutron-metering-agent - add metering label for each tenant (one per tenant) - add 2 x metering rules for each metering label, one for ingress and one for egress, both to/from 0.0.0.0/0 In most cases this works fine, and I can see samples in ceilometer plus traffic is forwarded correctly. In some cases, I can get ICMP to the instances but no other traffic (e.g. http or ssh). When there is a problem, the metering agent log gets the error listed below. I guess I'd better open a bug report at least, if noone else is seeing this. I was kind of hoping someone might tell me I'm an idiot and doing it wrong :) > > On 09/07/2014 10:06 AM, Xav Paice wrote: >> Hi, >> >> A quick query if anyone is using the neutron metering agent to >> measure traffic in/out of routers: >> >> When adding the metering label and rules, on some, but not all, of >> our routers, I get a traceback in the metering_agent.log pointing at >> "TRACE neutron.openstack.common.rpc.amqp TypeError: cannot >> concatenate 'str' and 'NoneType' objects". >> >> After that error, the router no longer passes traffic other than ping >> until we stop the metering agent, and restart the L3 agent. >> >> This doesn't seem to affect routers with only one subnet, and only >> one router in the tenant - but I may be completely misunderstanding >> the whole thing here. It appears as soon as we get a router with >> more than one network (plus gateway) we get trouble. >> >> We're using Havana on Trusty, and the current Cloud Archive packages. >> >> The rules are a simple egress and ingress, 0.0.0.0/0, both on the >> same meter-label. >> >> Anyone had similar experiences, or got tips for diagnosing this? >> >> I will be reading the code over the next few days :) >> >> _______________________________________________ >> OpenStack-operators mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operato >> rs > > > _______________________________________________ > OpenStack-operators mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operator > s ------------------------------ Message: 3 Date: Mon, 8 Sep 2014 08:12:32 +0000 From: "Baruch, Ohad" <[email protected]> To: "[email protected]" <[email protected]> Subject: [Openstack-operators] Glance vmware backend Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" Hi all, I configured my glance backend to use a Vmware datastore, and added the cluster that sees this datastore as a hypervisor to the compute node. I then deployed an instance using an ISO image I uploaded to the datastore via Glance, but I saw something weird. The Glance service kinda ignores the situation and still copies the whole image to the designated instance datastore, and after that he deploys the instance and mounts the ISO. 1) Why not just deploy the instance and mount the ISO straight from the other datastore? 2) Is there a way to make glance not copy the whole image to the other datastore and simply deploy over the network? 3) Does anyone know how to make glance know that the images are stored on a Vmware datastore and that it deploys those images to a Vmware datastore in such a level that he can leverage the VAAI functionality, or does he always deploy through the networking? Best regards, Ohad -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/201409 08/bb6d4c89/attachment-0001.html> ------------------------------ _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators End of OpenStack-operators Digest, Vol 47, Issue 9 ************************************************** _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
