Okay, so hello everybody. We're here today to talk about the InfraCloud, which is a community cloud managed by the project Infrastructure team. Next slide. So who are we? So hi, i'm Ricardo Carrillo, many call me just ricky. So i work as a no-pistak software engineer at hb, and i do mostly Infra and uncivil stuff. So my name is paul Balange, i work at redhat, and i fortunate enough to work day-to-day upstream in the openstack infrastructure project. My name is Colleen Murphy, and i've been working about two years in openstack on the openstack public modules team and the infrastructure team. So for people who do not know, the infrastructure team or Infra is responsible for all of these things that you see online, or on the screen. That's everything from Zool no-pool, Garrett. So if you are a developer or contributor to openstack, we are the humans behind all the services that help keep that running. And our talk today is not really talking about that, we've talked about that before, but i just wanted to lay the ground rules, or sorry, lay the ground of what infrastructure is. So how infrastructure works, there's supposed to be a nice little graph there. Hey, there we go. So it's a very complex piece of machinery. We have node pool, we have Zool. These are parts that are used for the launching of the resources onto the clouds that are donated to us that we use in the CI pipeline. And those resources are spread across multi-clouds, such as OVH, intranap, the OSEC cloud and so on and so forth. So today we're going to talk about the cloud that we've built on some hardware to provide resources for that. So cloud resources, so at the moment like I was saying, we have Rackspace, OVH, Bluebox, Vexhost, intranap, they have donated all of these cloud resources and we're very appreciative to them for it. Basically our quota before InfraCloud was about 600 total VMs that we could run, and that's about 20,000 VMs a day where we're launching and creating on the clouds. So basically as it happened back about two and a half years ago HP had this hardware that they were willing to donate to the infrastructure project and basically I want to say in Portland, a mid-cycle, is where we kind of hatch the plan of maybe it's time for us to run our own cloud. So this is kind of the mission statement basically the InfraCloud's mission is to take donated, the raw donated hardware and expand the capacity of OpenStack Infra for the purpose of Zool, which is the testing nodes that developers use and consume and so on. It was basically in a HP data center is where the hardware lives and our secondary mission statement is basically to start dog fooding OpenStack in general. So basically the timelines, I'll just go through this quickly basically in Vancouver in 2015 we got the hardware, we inventoryed the hardware this isn't brand new hardware, this was used hardware so there was hard drives, you didn't replace misconfigured networks, boot loaders so on and so forth. In Tokyo we started hacking on everything that's running, writing public modules, Ansible manifests so on and so forth. Between Tokyo and Austin we had a mid-cycle where we brought the first cloud online and we ran a job on it, but not shortly thereafter we actually had to move the hardware to another data center. So by the time Austin came around unfortunately hardware was still relocating, we had a kind of a blip in the radar. So between Austin and now we had a mid-cycle in Germany and that's where we basically had our first cloud online which we refer to as vanilla and as we are today we have chocolate which is our second cloud online almost I would say two weeks ago is when we brought it online. And our third cloud which we're going to talk a little bit more is called strawberry which is pending and we're in the phase of bootstrapping that cloud to bring it online. So basically right now as it stands we have two clouds online, two regions with node pools already consuming those clouds. The next step is basically to upgrade to Newton because we're running Mataka and basically that's it right? We have all this and we're done. Well I mean I'm done speaking but I'm going to pass it off to Colleen to kind of dive a little deeper on the actual implementation on some of this stuff. So I'll talk a little bit about the technical details of water cloud kind of looks like we use pretty much the bare minimum as much as we can to get a basic compute cloud running. We use Ironic to do our bare metal provisioning and then Keystone, Nova, Neutron and Glance for the cloud itself and then we use basics like RabbitMQ and MySQL you know no fancy message cues and no replication for MySQL, just basics for that foundation. Some of the other config choices that we've made are things like using Linux bridge with provider networks or using config drive versus EC2 metadata services. Our choices are all about keeping things as simple as possible, running as few services as possible and minimizing that surface area of debugability. Some people have asked me why aren't you using Cinder or Swift, don't you need some sort of storage in this cloud? The answer is for our compute driven workload we really only need ephemeral storage. We use the file backend for Glance at some point we might want to try to use something more performant but for now it's working just great. We do have package mirrors but the mirror contents are stored in other clouds and we use a distributed file system called AFS to distribute that data into this info cloud. I don't understand how that works I think it's just magic but I'm told that it does work so for right now we don't need any storage in this cloud and we don't use anything like we don't use any HEA technologies either right now we don't have HEA proxy or pacemaker. Our high availability is based on having redundant clouds. We have lots of different clouds so if one cloud goes down we have other clouds that can still support the workload so it doesn't really matter if one node or one cloud goes down we have lots of other clouds so that's kind of why we're not focused immediately on making this cloud super robust that's obviously on the roadmap but it's not an immediate priority right now. So we'll talk a little bit about how we deploy the cloud. We have two basic deployment technologies the first is Bifrost and that is a deployer for Ironic written Ansible and it runs Ironic as a standalone service so we don't need Keystone credentials and we don't need the Compute API or the Neutron Compute API and what it does is it installs Ironic it builds images with disk image builder it rolls all the hardware into the Ironic inventory and then it does the deployment of Paul Inventory and if you're wondering this is a Minecraft representation of Bifrost from North Pathology it's a rainbow bridge so I thought that was fun and then our main control plane is deployed using the open stack public modules that's one of the deployment tools in the big tent the public modules by default use the Ubuntu cloud archive packages so we're using the stable versions of those packages just following the release based upgrade model right now not tracing master at the moment you might wonder like there's lots of different deployment tools under the big tent why would we choose puppet and I have a strong background in puppet and I could talk about all the great things about puppet but really the main reason we chose puppet is because that was what we were already using for the rest of our infrastructure we didn't want to choose a brand new technology or brand new distro or config management tool and have to learn that and also have to learn how to deal with running our own open stack so that was the main motivator for choosing puppet so I can go into a little bit of detail about how these two deployment tools fit together because we have Bifrost written in ansible and puppet so for we have for historical reasons a machine that's called the puppet master it doesn't actually run puppet though what it does is it is the orchestrator for ansible so what it does first is it calls out to the bare metal server runs puppet on the bare metal server which installs Bifrost Bifrost then is of course ansible so it is going to kick off a Bifrost run and that does the hard work of installing ironic building images and rolling all the hardware nodes and then deploying all the nodes and then once we have that we once again have ansible call out to puppet run puppet on our controller and that is going to start setting up our control plane with my sequel Rabatimq, Keystone, all the cloud services then after that is done we start running puppet on the computes and that installs the compute agent and the neutron agent and ansible is great because we have that ability to tell it run the controller first then the computes because the computes need the Rabatimq and the Keystone services and all that setup before they can start running properly and to dive a little bit deeper into how this is working, this is a simple version of the puppet code to deploy our Bifrost server and it is probably the most interesting of our puppet code because we wrote it all from scratch and all it is doing is installing ansible installing my sequel, installing Bifrost source code, setting up the config file setting up our bare metal inventory so that is that file and then it just runs a shell command to start off and kick off the Bifrost run and the actual cloud compute the controller plane is actually a lot less interesting because it is just gluing together the open stack puppet modules so what this is doing is it is just laying out some of the basics, setting up the package repository, setting up the databases and then setting up the basic services, our Keystone, our Neutron, our Glance, our Nova and then with the compute nodes it is even simpler, we are just setting up the compute service and our Linux bridge, Neutron agent and then after that we have just our ansible playbook which just kicks off everything one by one so it is really pretty simple ricky will tell us about how we actually use this cloud in our ci infrastructure now we have our input cloud but obviously we need to configure for some way to ci usage and as you can imagine we need to configure typical things like flavors, images, that kind of things we like to standardize as much as possible to treat all our clouds the same and that is the main reason why we wrote the tool just to do that to create open stack resources that will be used for our cloud for the ci and we call it cloud launcher it is actually just an ansible role that processes a YAML file that it models all the resources you want in your cloud and it allows you to define those resources in a per cloud fashion or you can also create a profile containing resources and then you call that profile on your cloud so you can reuse the same layout of resources in multiple clouds and this is how it looks like that YAML model file so we have a profile section where you can have a list of profiles in this example so we have a profile for creating projects this is a standard in all our clouds so we have two projects one for the ci plane that contains our mirrors and then we have a project just for node pool to spin up the beams that will run tests and in this other example so we have a profile that defines our flavors in this case so this is how our node pool vms look like from the flavor perspective so this ram, this vcp use so this is the same flavor for all our clouds so that's what i said before we try to standardize everything and then we have a section about okay so what are our clouds and what resources we want in those clouds so in this case so we have our info cloud vanilla which is made of the resources defined on the profiles of the show day earlier obviously i mean i could go too much detail into this we could also have per cloud specific resources but i'm just keeping it simple for this talk and how you run it is super simple so we have this big YAML modeling all our clouds and we just fit it into our launcher run from our puppet master which is really our untold control machine and it sets the state of all the resources in all our clouds which really means that we have a repeatable way to set the state of our clouds in any time and it's really a good way to configure them also so once we have that we want to monitor our clouds and we use cacti it's really basic monitoring we monitor stuff like you know network interfaces swap usage disk space so on and so forth we also have analytics and metrics for our clouds and info cloud is not an exception if you go to reflana.opstack.org you will see a lot of dashboards and we have dashboards specific to our node pool and fair provider in our node pool this is how it looks like for info cloud so we have metrics for how long it takes to create the server to delete the server listing that kind of operations and now when we have that everything configured we're monitoring we have metrics we have you know the boot strapping of resources in our clouds we need to configure that cloud for node pool usage so node pool is not black magic so every time that you developers you push a change the test runs and beams that they are created by node pool so node pool is a multi-cloud application that talks to multiple clouds and it maintains a pool of defined resources and nodes that it has you know access to obviously node pool has access to the cloud providers that all mentioned that we are donated ova, intranet, rack space i do not want to really forget any of them they're all great and we're very grateful the node pool service yeah so we have all the authentication details to those clouds so they can access and spin up nodes and how it really you know looks like it's not really super complex i really you know simplified how it looks like for the basic things in node pool it's just a yaml file it's made of three main sections we have a label section where we define okay so what are our nodes that we want to test this stuff so we want to test the stuff in zineo we want to test the stuff in centOS in precise or trusty whatever so in this section we define okay these are our nodes and we want the minimum of these nodes in the whole node pool capacity and we want them bound into these cloud providers then we have a disk images section this is where we define okay so we define in our labels what are our nodes but how we want those nodes to look like so we use this image builder to create those images and here we define what elements we want those images to be made of and finally we have a provider section which is where we glue together to our clouds so in our case we have the infra cloud vanilla with the OSCC infra cloud vanilla containing the authentication details the maximum service it can spin and what the images is made of and how it can connect to those images you know the private key and that kind of stuff this is kind of an historical screenshot obviously we do not have Jenkins anymore but back when we were hacking on the infra cloud in the Fort Collins mid cycle i think it was February this is actually the first run we ever got in production in infra cloud which is why we're keeping obviously yeah today we have a telnet interface to show the the job progress and if you want to know more about open stack ci i really recommend that you do not miss this sessions there's a great keynote session tomorrow about demoing how notebook works that our colleague elizabeth she's going to be presenting and also we have jimbler on thursday who's going to talk about the roadmap of zoo and noble which are the main parts of our ci and i really recommend that you attend that because it's quite a bit of a change and it will simplify a lot the way developers can test their code and now i'm handing over to Paul who's going to talk about the current status of the infra cloud right make sure to take a look at that. So basically just to kind of wrap things up here this is how it kind of looks today so this is just a very simple graph and graphon that kind of represents what infra cloud did over a period of time of i want to say a bit of week so you can see on the bottom right here or the middle bottom is vanilla which was the existing cloud that was in production it's not really busy right now because we were i guess taking breaks because after they've done a release or something on the left hand side what i wanted to show here is this is the representation of when we brought infra chocolate online so you can see i should look down here on october 15th is when rickardo flipped the switch to bring it online for ten nodes and then about four or five days later we said okay we haven't run anything on it because we just have too many cloud resources now let's kick it up to a hundred and let's start building stuff so you can see we started running some jobs you know on the top left is all of our launches and when things are coming in line so at some point in time yeah we had about a hundred nodes going at one given snapshot period top middle is basically the representation of error and failures these are the things that we have to dive in deeper to say why didn't we launch a node we're kind of getting into the ops side of things right and then finally top right is time to ready how long it takes us to actually launch a node what i found interesting here but this one you can see sometimes we're taking about three minutes or four minutes to launch a vm this kind of leads into like the next slide you know these are things that we're seeing in open stack so because we launch or we upload images every day when you first launch a new vm a new compute node you know you have to go to glance to download load these images which may constrict your bandwidth or you know timeouts and services and nine times at a time for us it fails the first time so as i'm talking about this i'm looking at people in the audience going yes i know what you're talking about we as operators and since this is all open would love to go back to the community and help us as a team and as a project kind of fix some of these things so something that we didn't really talk about in the beginning of why we do it this way is all of our configuration is open like the open stack way everything's in garret everything's under code review all of our changes go through the same testing pipelines that open stack does so anybody in this room today could see a problem that we're probably glazing over and you can propose a patch to fix it maybe in puppet or an ansible or in our configurations for node pool but yeah to the future these are some of the things that we want to talk about like obviously we want to upgrade to newton data collection we really don't do data collection using open stack you know i know Colleen has some things that she'd like to see us do with info cloud some of some of the one of the earlier goals was to start chasing master and actually do the more ci CD approach things like that are things that we like to to do to help bring our use of open stack and the developers closer together and rickardo so i'm looking forward to take food even more stuff in our you know info cloud because this is the good thing about this that is that we took food everything so whenever we find a problem we can fit that fit back into the teams whether it's nova neutron so i would like to maybe i don't know check out you know the monitoring projects and use you know some open stack projects in that area and yeah yeah and i mean i'm sure other info team members have certain areas that they want to focus on but i think the real thing is is that there's a lot of opportunity for us to do it and if somebody in the community wants to kind of help in that effort or things that we should be doing something else you know you know how can i help kind of sets up perfectly for this slide you know who was doing this one yes everything we do is an infrastructure as code is done with an infrastructure as code approach so if you you're thinking well you know you should really be using this new feature or you guys are doing this all wrong let me fix it for you or you know every time my job runs on info cloud it breaks in a weird way so much that you can go fix that we have everything up as code and it's all open except for passwords and private keys so and donate i mean if you have some cloud to your employers to donate hardware please you know talk to us we would love to have more resources so we can run you know even more regions grow the current regions and really make this you know even bigger you know initiative within the info team and i think that's about it so i i think we're right on time so i don't know how many more minutes we have but if there's questions we're cut wow we shot your hand up really fast yep can you repeat your question oh forward oh you want this one sorry can you ask your question again in your environment right and how old is the hardware that you receive as a nation and do you plan do you plan to substitute the hardware after how many years and you know all the cycle of receiving the hardware using it and then get rid of it and if you have any any plan about how to get rid of it properly and you know where do you where do you take where do you take it yeah basically and you know all these sort of questions so in terms of how to tackle the variants of hardware so right now the info cloud is made of three different server models so one of the reasons why we're spinning up strawberry is because we want to have one region per model so we don't have you know some fluctuation of performance because maybe your job went through you know faster server maybe you know next job when you know the slower server in terms of life cycle of hardware i can really respond to that because we don't really deal with it we were given that and we're hosting it we're happy to have it and i mean we do not have any kind of information whether we're going to get that bumped or you know an upgrade on the hardware so i would expect that we're going to get what we have now though i mean i would be more than happy to have hardware vendors that are in the ecosystem to donate more hardware to the project yes i'm asking because you know i would like to do something like that you know i was wondering how old is a piece of hardware to be considered you know to be donated and anyway the other question if if there is any link between this working group and the the massive open-stack deployment working group no but we would be happy to sync up yeah i mean a lot it goes back to i think colleen's point of why we chose the tooling that we've chose it's because that's kind of how infra has done it and in the past infras really had some unique ways of like we're using ansible to launch puppet to then launch ansible to then launch puppet and i seen some eyebrows of people like what you know why would you do that but it me as crazy it sounds it kind of works in our process because all of that change management is open and allows us to you know stage things properly but i think that's part of the interesting thing is we now have this clouds i mean i'm not a cloud operator by any means i would love to work with existing cloud operators or installers to hey this is our version dot oh one how does it compare to your version dot one what should we do so if you can get us in touch with those folks and you know you know people from that group we would be happy to talk to you if there's any other questions yeah we can get a mic okay since you had my class you get to run it to the guy i do so i'm actually expected you guys to use something like a clean or cloud in it to configure networking other than the htp so what did you go with the htp for ip addressing yeah we do use glean yes we can talk about that yeah so which part of ip addressing are you referring to so the htp you have the so you have the htp for for vms to pick other ip addresses right now it's not configured config drive for instance so if you're talking about the control plane like the compute when we deploy them we have a static ip assignment so if you go to our system config repo and you go to our hyra folder you will find there an infra cloud that contains the bare method of json blob and you will find for every single compute the ip address for public and the the provisioning or private ip address for that we that we assign to it when we when we provision the machine okay so it's a static dhcp assignment for the control plane yeah and then i think calling at the vms is dhcp v at neutron right right hi guys i was kind of curious if so calling mentioned that you were chasing you weren't chasing masters you were just using like a stable deployment is there any kind of trickiness if you have multiple clouds like let's say chocolate was on neutron and vanilla was on the taco or something like that it is no pool just not care i don't think we're using any such advanced features of an open stack that it really that zool or no pool really cares which cloud we're running on because we have different public clouds too and they're also writing slightly different versions so as long as we have the basics you know we can get a compute note up with the same api and we can get an ip address it doesn't matter that much which versions are which following that so that's i mean personally one of the cool things that i see that you know we have logically split that the the servers in two three different regions but though they were in the same data center is that we could keep you know vanilla for production running in no pool and maybe we could have the newest strawberry that is coming to maybe do what clean suggested of hey let's have you know i a cd pipeline of master we can certainly you know experiment a lot of things because i mean we're managing that hard so okay thank you how much longer do we have to ask questions because five more minutes five more minutes is that right or okay so i have a question so obviously using these scripts you must deploy some sort of reference architecture right do you guys have any slides or any documentation as to like what that looks like and in terms of like what you guys use for packaging or anything else right is it just pipped the regular pipeline packages or do you use like a distribution specific package what do you guys have for that we use the distribution specific packages from ubuntu and then yeah everything everything in and these code repositories is kind of what makes up the reference for yeah gotcha okay so is it like flat l2 like one rack or like what's it like yeah we had so our implementation is very basic like we have a single controller and the rest are compute nodes i think but we actually have a spec an infra cloud spec that we started with to kind of drive all of this and what's it called it's like specs dot open stack dot org slash open stack infra it's not up here that kind of explains how we wanted to do our reference implementation but like calling said it's very basic because our needs of redundancy are we'll just go to another cloud you know right and i think your need specifically for open stack infra is testing out the open stack code not so much as reference architecture yeah exactly and yeah i think that's a secondary but i mean i think that's some of the things that call in and rickardo i mean we're going to have sessions about the infra cloud this week and definitely the ch part of things is going to be you know a topic i know for example nfp folks over there you know they're interested and you know i'm happy to talk about the ch so i mean it's not like it's set in stone i mean we wanted to you know i was just trying to ask to see if there's a direction you're heading right yeah where would you want us to head because that's kind of the approach i think we're taking okay so i'll give you some background you know my colleague you're from AT&T and we have our own cscd infrastructure that we've open sourced yep and it involves burn metal and dpdk and some of our own stn technologies and stuff but it may perhaps be a little too specific for our nfp cloud use case right so in terms of something that runs directly on master right one of the difficulties that we have is in terms of packaging right it's a little difficult but no we just wanted to talk and see what the community had in mind but definitely for large operators like multi region multi rack right depending on how you do your underlay fabric it all makes a difference and yeah specifically with open stack it's never really the python code that kills you right it's everything under that so yeah my advice is that you talk to that girl on that guy with glasses third row you can say hi patty so they are nfp folks and they're using our code for deploying their clouds and i also encourage you that you attend our infracessions about the infracloud i think we'll call this one the last one because i think we're so my question was there are quite a few installer projects inside open stack triple low fuel etc is there any plans to use dog food one of those rather than doing your own unsupportable combination of wizardry great i would love to i think so i can tell you my personal opinion and i think everybody has personal opinions on this so i'm not talking on infraclubs we have i think that would be a really cool thing because when we first talked about this the infracloud we were really short on cloud resources so the mission statement was we need more cloud resources for developers now we're pretty plush with resources like we were up to i think about 2,000 vms now we've doubled if not tripled i think those are very because those help the open stack community but there's also projects like the osik cloud i think that's kind of their Purpose is to give you the hardware and then as a team you Would but i think infras policy has always been not to Bless a project in open stack and say this is the way to do It you know like triple low this is the we should be using Triple low or we should be using cola i can never say Them right but i mean that's my opinion but i think it's All bound to the resources that we have i mean we have a good Amount of service but you know it's not a massive if we had More hardware i would personally love to maintain an Infracloud for prod and maybe have you know some subset of Another infracloud region that a so this is we deploy it With the triple low this one we do with open stack and Cable or with cola so because my my main interest is that The cool thing about this is that we are duck fooding so we could Go to the triple folks open stack and say hey we're hitting This issue i mean is this a bag or something so it's all about Resources yep my feelings are that we have a thing that Works and it's done in puppet and ansible and that is Something that the whole infr team knows and it's Consistent with how we do everything else so if we had a Ton of people resources yeah we could try to use triple low and Fuel and try out all these things we don't have that many people Resources so as long as we have a thing that works and everyone's Pretty comfortable with it this is probably what we're going to Stick with for a while. And i think that's the most valid is we'd love to but we're Resource constrained let's say. Yeah i think now that we have a cloud working we've had people In the past say we want to give hardware for bare metal and our Response usually has been we have we're struggling to get this Cloud online like let's have that conversation after well it's After now so i think it's all about history also i mean when We as paul said when we started this we have a really Limited ci you know capacity and all of a sudden you know we Have trillion nodes so it's more okay in front of the Cloud it's cool but you know we have you know this capacity so What are we going to do forward within the cloud so questions I think just about out of time thank you all yep


You know, over the last few years, the UK co-op sector has seen some really good progress. Specific sectors such as agriculture, social care and energy have become much more co-operative. Community shares have helped co-ops raise the finance they need for new start-ups while taking cooperation to new communities. The Hive, a new business support program, has launched to great excitement with ambition to help new co-op start-ups, existing co-ops to grow and regular businesses transition to a co-op model. But there's so much more we can do. What if more people could breathe new life into their local high streets, libraries and landmarks by owning and running them together? What if staff not only had a say in what their organisation did, but they owned and controlled it together? What if people had a real stake in the businesses and organisations they use from supermarkets to social care services? Ultimately, we need more of the economy to be in co-operative hands by making it easier for people to take control of the things that matter to them, their work, their shops, their local areas. To do this, we need a strategy. And we need this strategy to be owned, supported and promoted by the whole UK co-op sector. So we need to write the strategy with you. We'll be asking your opinion through interviews, discussion at Congress and online engagement. We'll be looking at overseas innovation as well as great examples from the UK. And we'll be conducting a census. The UK's first ever census of the co-operative movement. To give us more information about where you are now, where you'd like to be and how the sector might help you to get there. You know, this is an exciting project that will set the agenda for the future. But we need you to work with us. Please do get involved. Thank you.


Hello, I'm Anne-Marie Burkle, Acting Chairman of the Consumer Product Safety Commission. I want to remind you, you have the power to prepare and stay safe during whatever weather may come your way. After a storm knocks out power, the risk of carbon monoxide poisoning increases. Carbon monoxide, or CO, is called the invisible killer. You cannot see it or smell it. Now is the time to make sure that your CO and your smoke alarms are working properly. Install carbon monoxide alarms on every level of your home and outside your sleeping areas. If you own a portable generator, here are a few safety tips to keep in mind.  Keep your generator outside of your home at least 20 feet away from any window, doors, or vents. If you experience a headache, fatigue, nausea, or vomiting, get outside immediately for fresh air, and then call 911. Here are some other hazards to look out for after a storm. Never use charcoal indoors. Burning charcoal in an enclosed space can produce lethal levels of carbon monoxide. If you must use candles, do not burn them on or near anything that can catch fire, and never leave burning candles unattended. Do not use electric or gas appliances that have been wet or damaged in a hurricane or flood. These appliances could cause electric shock, fire, or an explosion hazard. You have the power to prepare.


Hi my name is Bella from Philippines and I'm one of the young innovators. My innovation is a mobile and web application for emergency and disaster and we aim to teach people how to be prepared in case of emergency before, during and after and we guide people if there's like a incoming or upcoming events or disaster and we point to the right direction for the evacuation sites, nearest hospitals and clinics. So we wanted to offer a more accurate, effective and community-based platform. Thank you.


How to increase the price of your products without losing customers is a big challenge. Price has a significant influence on our profits, our sales volumes and our customers, and we're all barred in with messages about charging what our products are worth, but also often it feels easier said than done, doesn't it? So let me help you with implementing your product price increases, which you need to get the retailers to agree to. I'm going to let you in on seven secrets on how the experts deliver a price increase as part of their retail pricing strategy. And then towards the end of the video, as a bonus, if you like, I'm going to give you two options to use in an emergency only that will help land that increase but still keep the customer happy. My name is Anna Taylor and I've spent 20 years working on pricing in multinational companies such as Cabri, Peroni, Asahi and Unilever. We worked alongside sales and marketing teams, successfully creating and launching a range of new products and selling and negotiating them into key retailers. Now if you're new to this channel, Enhance Stop Trading provides online business courses to help professionals, managers and business owners improve their performance. If you like this video, please give it a thumbs up, subscribe and share it with friends. Now many of us don't like talking about money or pricing in the first place, so talking about increasing product prices can seem even harder, but let me reassure you, price increases are nothing new. They're expected. It's common to be reluctant to put up your prices. So if this is you, please don't worry because we can all overcome it. It comes from perhaps a fear of avoidance or of confrontation or perhaps a rejection, but there are things you can do when thinking about how to increase the price of your products, which will make success much more likely. So let's start with the first secret to product price increases and that is confidence. And yes, I know this might sound obvious, but hear me out because it is about believing in the value of your product and the value of your product price increase. This is the element that's firmly in your control, yet it can also be one of the hardest. So let me share three pricing tips to increase your confidence and chance of delivering a price increase successfully. First of all, you need to believe in your product price increase. Now product price increases often fail not because the customer doesn't accept the increase, but because the salesperson fails to believe in that price increase. Now it may sound like a cheesy mantra to believe in yourself, but any lack of confidence will come across in the meeting with the customer. Of course, once the by sense is a lack of confidence or uncertainty, then they're free to use this insecurity in negotiating a discount. On the other hand, if you're confident in your words, your body language and attitude, then this will also shine through and the customer is much more likely to believe in that price increase too. Now a sales director for a top drinks company described how to increase the price of your products like this. He says, there is a mindset with price increase. You should have confidence in what you're asking or you will never achieve it. So whether you're in sales and have been told to sell in a price increase or you're making the decision for yourself and your own products, you must believe in it. Banish the negative thoughts and you can do all you can to increase your confidence and resolve. I mean, these next two tips should also help because the second secret on how to increase the price of your products is to think about an even higher product price increase. This will help you put things into perspective. So let's say you were planning, say a 5% price increase, I'd like you to plan for a 10% price increase. Now you're not actually going to sell in the higher price increase, but it will help in your preparation because if you could justify a 10% increase, detaining the reasons, the value that you're giving is worth 10% more than you've been charging, then the 5% will seem relatively small and increase your confidence to deliver the price increase successfully. Now the third secret of how to increase the price of your products is to go into the meeting with one price only.  Be confident so the buyer doesn't get any signals they can negotiate. Now I'm not suggesting arrogance nor extreme stubbornness, and I'm not against offering things to make the price more palatable. What I'm saying here is not to go into the meeting thinking that you'll never get your target price. Let me give you a real life example. Yeah, a buyer for a big four supermarket told me they were delighted every time somebody started their price discussions with the words, well, this is my starting price. Now she said this was great, and she would simply ask, well, what's your end price? And the price was lowered without any effort at all. Do not make the buyer's life too easy. Preparation for product price increases is crucial. And the first step is to believe in what you're doing, to have confidence and to plan for and expect the best outcome. So now we have confidence and belief in our product price increase. We can now focus on the fourth secret of how to increase the price of your products, and that is understanding the value you offer in addition to the product. So increasing the perception of value provided to the customer will help you deliver a price increase successfully. So what you need to do, create a list of all the things you or your company have done for that customer. Focus on the value that you brought that customer since the last price increase. It could be all the times you've gone the extra mile and yet did not charge your customer extra. Did you perhaps run initiatives to get more customers into their stores? Did you deliver an urgent order the next day but only charge them standard delivery price? Or did you recommend them to others or feature them on your social media? You don't need to share your list with your customer, although, well, yes, it might come in handy. But you do need to understand the value that you provide. Do you've earned that price increase? Do you deserve to be paid for the value you're providing to your customers? Keep in mind all your examples of adding value and helping this customer when you speak to them about increasing the price of your products. Now, the fifth secret of how to raise product prices is to understand the value the product offers to the customers. So revisit your sales numbers. Show what your product has done to drive sales for the customer and how your plans will continue to do so. Make sure you know your customer's objectives so you can talk about how your product can deliver those objectives. That same sales director I spoke about earlier also told me when planning how to increase the price of your products that you should be able to push for the maximum price and sell the benefit, but without ever justifying the price increase or pinning it on market forces. Always remember, the price increase allows you to work better and invest in your product and brand, which in turn will benefit your customer and allow them to grow too. The sixth secret for how to increase the price of your product successfully requires you to present your price increase in a favorable context for your customer. Do your homework on your customer and research what they've done over the past year also or since your last price increase. For example, have they put up other or competing product prices? Find out the percentage price increase so you can frame your price increase within their pricing strategy. Let me give you another real-life example. So a customer we sold to had put their product prices up to their consumers by one pound during the year. So we proposed to increase our price to them by 50p. All we were proposing was splitting the benefit of the increase that our customer had already put through. Doing our homework showed our customers able to successfully increase the price of the consumer thanks to the strength of our brand and the value our product provided. Now the final and seventh secret for how to increase the price of your product successfully is to provide a favorable context for the customer. Now there's different ways to provide a favorable context, such as framing your increase to get something big so your product price increase looks proportionally smaller. An example might be the increased spend of your product per year compared to the cost of purchasing a cup of coffee each day for a year, something like that. This type of comparison will give you confidence that your customer can afford it, but will also help you demonstrate the insignificance of the increase should you need to. So there you have seven secrets for how to increase the price of your product successfully. What if after all that, you're still met with resistance? Because you all should also prepare for what you will say if the customer refuses or is unwilling to accept the increase despite the great value you and your product provide. So what else can you do to deliver the price increase successfully? Well, let me give you a couple of options that I promised you at the start of this video. It's all about preparing for making the price increase easier or less painful for the customer. But I'm certainly not going to tell you, well, just to reduce the price straight away or to discount any increase away, it's all about offering alternatives to help the customer and to support them. Now, one option when working out how to deliver retail product price increases is to provide a lower value product offer to match the customer's desire for a smaller product price increase. Now, by offering your customer an alternative option at a lower price that they are happier to pay, their reaction will show you whether your customer cares more about the cost to them or the value they get. Because if they care more about the value they receive and getting the original product, they're more likely to accept that original price increase. But if they're driven more by cost over anything else, then they'll accept the cheaper and lower value alternative product. This should still be a positive outcome for you. After all, if they're so cost driven, the cheaper product is likely to be a better fit for their store and consumers. And additionally, as long as you've priced your alternative product correctly, you should still be making strong margins on these cheaper products. Now, a second option when working out how to increase the price of your products is to offer your customer perhaps a transition period such as a pre-price increase stock buying. A stock buying gives the customer a chance to buy a limited quantity of products before the price increase. Now, you can present this as an opportunity for them, a favor, as they can buy more stock than they normally would, but still at the current price which would then last them longer before running out. Now, you do need to do your calculations and planning in advance so you know how much you'll offer them, how long that stock should last, and the monetary benefit to them of taking that deal. That way, you know that you can afford it and whether you've got enough stock available. Overall, in this scenario, the customer will still get the price increase, albeit a bit later than first communicated, and you'll get an increase in revenue from the stock buying. And as for your customer, well, they'll be happy that they got the chance to buy extra stock at the original price before that price increase kicks in. So, we've gone through seven secrets of how to increase the price of your products. If you've designed and made a product that is valued by its consumers, you deserve to get a price that relates to that value. Over the lifespan of a product, there will always be price increases, and you shouldn't fear product price increases, you should just prepare for them. Be confident, focus on the value you create for the customer and consumer, and present the price increase in a favorable context and you'll be able to deliver product price increases successfully. Good luck with your next price increase meeting. Do drop me a note and let me know how you get on because I love hearing all your stories and your feedback. If you liked this video, please hit the thumbs up button below and subscribe. Thank you for watching and I look forward to seeing you again soon.