Re: [openstack-dev] Dynamic VM Consolidation Agent as part of Nova
I'd be interested in the opposite, the ability to rebalance the vm's across the fleet to even out load. Agreed it should live outside of Nova tho BR, Stuart On Nov 19, 2014 12:15 AM, "Mehdi Sheikhalishahi" wrote: > Where do you suggest as the best place for such a service? > > On Tue, Nov 18, 2014 at 11:49 PM, Joe Gordon > wrote: > >> >> >> On Tue, Nov 18, 2014 at 7:40 AM, Mehdi Sheikhalishahi < >> mehdi.alish...@gmail.com> wrote: >> >>> Hi, >>> >>> I would like to bring Dynamic VM Consolidation capability into Nova. >>> That is I would like to check compute nodes status periodically (let's say >>> every 15 minutes) and consolidate VMs if there is any opportunity to turn >>> off some compute nodes. >>> >>> Any hints on how to get into this development process as part of nova? >>> >> >> While I like the idea of having dynamic VM consolidation capabilities >> somewhere in OpenStack, it doesn't belongs in Nova. This service should >> live outside of Nova and just consume Nova's REST APIs. If there is some >> piece of information that this service would need that isn't made available >> via the REST API, we can fix that. >> >> >>> >>> Thanks, >>> Mehdi >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] [UX] Curvature interactive virtual network design
+1 from me Also, can you get Cisco to opensource Avos? It was demo'd at Atlanta On Sun, Nov 9, 2014 at 6:45 AM, Chris Dent wrote: > On Fri, 7 Nov 2014, John Davidge (jodavidg) wrote: > > We’d like to gauge interest from the community on whether this is >> something people want. >> > > When I go to the existing network topology maps in horizon I > frequently find myself wanting to drag stuff around. > > So +1 from me. > > -- > Chris Dent tw:@anticdent freenode:cdent > https://tank.peermore.com/tanks/cdent > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- BR, Stuart ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] disambiguating the term "discovery"
Having written/worked on a few DC automation tools, Ive typically broken down the process of getting unknown hardware into production in to 4 distinct stages. 1) Discovery (The discovery of unknown hardware) 2) Normalising (Push initial configs like drac/imm/ilo settings, flashing to known good firmware etc etc) 3) Analysis (Figure out what the hardware is and what its constituent parts are cpu/ram/disk/IO caps/serial numbers etc) 4) Burnin (run linpack or equiv tests for 24hrs) At the end of stage 4 the hardware should be ready for provisioning. Hope that helps Stuart On Tue, Oct 21, 2014 at 2:38 AM, Lucas Alvares Gomes wrote: > On Tue, Oct 21, 2014 at 10:27 AM, Sam Betts (sambetts) > wrote: > > I agree with Devananda's definition of Œhardware discovery¹ and other > > tools similar to Ironic use the term discovery in this way, however I > have > > found that these other tools often bundle the gathering of the system > > properties together with the discovery of the hardware as a single step > > from a user perspective. I also agree that in Ironic there needs to be a > > separate term for that (at least from a dev perspective) and I think > > Lucas¹s suggestion of Œhardware interrogation¹ or something like > Œhardware > > inventory¹ would be more explanatory at first glance than > Œintrospection¹. > > Thanks for the suggestion but no "inventory" please, this is another > taboo word in Ironic. This is because when we say hardware inventory > it kinda suggests that Ironic could be used as a CMDB, which is not > the case. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- BR, Stuart ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Neutron router and nf_conntrack performance problems
Hey neutron dev! Im having a serious problem with my neutron router getting spin locked in nf_conntrack_tuple_taken. Has anybody else experienced it? "perf top" shows nf_conntrack_tuple_taken at 75% As the incoming request rate goes up, so nf_conntrack_tuple_taken runs very hot on CPU0 causing ksoftirqd/0 to run at 100%. At that point internal pings on the GRE network go sky high and its game over. Pinging from a vm to the subnet default gateway on the neutron goes from 0.2ms to 11s! pinging from the same vm to another vm in the same subnet stays constant at 0.2ms. Very much indicates to me that the neutron router is having serious problems. No other part of the system seems under pressure. ipv6 is disabled, and nf_conntrack_max/nf_conntrack_hash are set to 256k. We've tried the default 3.13 and the utopic 3.16 kernel (3.16 has lots of work on removing spinlocks around nf_conntrack). 3.16 survives a little longer but still gets in the same state Neutron router 1 x Ubuntu 14.04/Icehouse 2014.1.1 on an ibm x3550 with 4 10G intel nics. eth0 - Mgt eth1 - GRE eth2 - Public eth3 - unused Compute/controller nodes 43 x Ubuntu 14.04/Icehouse 2014.1.1 ibm x240 flex blades with 4 emulex nics eth0 Mgt eth2 GRE Any help very much appreciated! Replace the l2/l3 functions with hardware is very much an option if thats a better solution. Im running out of time before my client decides to stay on AWS. BR, Stuart ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Networking Docs Swarm - Brisbane 9 August
Cant make it to Brisbane but this doc is so needed. Any chamce you could put round a questionaire or sethomg similar to get input from those who cant make it? -- BR, Stuart On 14-08-04 8:05 PM Lana Brindley wrote: Hi everyone, I just wanted to let you all know about the OpenStack Networking Docs Swarm being held in Brisbane on 9 August. Currently, there is no OpenStack Networking Guide, so the focus of this swarm is to combine the existing networking content into a single doc so that it can be updated, reviewed, and hopefully completed for the Juno release. We need both tech writers and OpenStack admins for the event to be a success. Even if you can only make it for half an hour, your presence would be greatly appreciated! RSVP here: http://www.meetup.com/Australian-OpenStack-User-Group/events/198867972/?gj=rcs.b&a=co2.b_grp&rv=rcs.b More information here: http://www.meetup.com/Australian-OpenStack-User-Group/events/198867972/?gj=rcs.b&a=co2.b_grp&rv=rcs.b See you on Saturday! Lana -- Lana Brindley Technical Writer Rackspace Cloud Builders Australia http://www.meetup.com/Australian-OpenStack-User-Group/events/198867972/?gj=rcs.b&a=co2.b_grp&rv=rcs.b ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://www.meetup.com/Australian-OpenStack-User-Group/events/198867972/?gj=rcs.b&a=co2.b_grp&rv=rcs.b ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Mission Statement
Hey * Does ironic fall under the Compute banner? If so, the statement needs a little tweek. - BR, Stuart Fox Manager, Systems Engineering Demonware +7783753701 On 2013-11-18 5:55 PM, "Russell Bryant" wrote: > Greetings, > > Every OpenStack program is supposed to have a mission statement. The > Compute program does not have one yet [1]. Here is a first attempt at > it. Let me know what you think. > > To implement services and associated libraries to provide massively > scalable, on demand, self service access to compute resources, > including both virtual machines and containers. > > [1] > > http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml > > -- > Russell Bryant > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Introducing the new OpenStack service for Containers
Hey all Not having been at the summit (maybe the next one), could somebody give a really short explanation as to why it needs to be a separate service? It sounds like it should fit within the Nova area. It is, after all, just another hypervisor type, or so it seems. (I can’t find the justification on the OS site) --- BR, Stuart Fox Manager, Systems Engineering Demonware +17783753701 On Nov 18, 2013, at 2:05 PM, Sam Alba wrote: > Hello everyone, > > As some of you already know - in Hong-Kong during the last OpenStack > Summit - we ran a design session in the Nova topic titled "Docker > support in OpenStack". The session concluded in developing a new > OpenStack service for supporting containers instead of modifying Nova > to support both VMs and containers. > > As said earlier, I am proposing a first draft of the spec for the > service. I've explicitly CC'ed all people who signed up at the end of > the design session. > > Here is it: https://etherpad.openstack.org/p/containers-service > > Once we agree on the HTTP API and on the plugin API, the idea is to > implement a first simple version that would support mono-host. Then it > would evolve in multi-host really quickly by adding a scheduler and a > messaging layer (more details in the etherpad). > > Please have a look if you're interested in using Containers (and > Docker) in OpenStack. > > Thanks Russell for giving some early feedback. > > Also, Krishna Raman from RedHat already gave a first shot at drafting > the Rest API: > > https://etherpad.openstack.org/p/containers-service-api > > > Sam > > -- > @sam_alba > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
