147
I Use This!
Very High Activity

News

Analyzed 1 day ago. based on code collected 2 months ago.
Posted 1 day ago by ihrachyshka
This post is the sixth, and the last, in a series that covers gratuitous ARP and its relation to OpenStack. In the previous posts, we discussed what gratuitous ARP is and how it’s implemented in OpenStack Neutron L3 agent. We also introduced the ... [More] Failure, covered its initial triaging, looked at traffic captured during failed test runs, and digged through Linux … Continue reading The Failure, part 4: Summary → [Less]
Posted 2 days ago by Superuser
How to use command-line tool Snapper to redeploy OpenStack in this tutorial from CloudEnablers. The post Deploying and redeploying OpenStack in a physical server appeared first on OpenStack Superuser.
Posted 2 days ago by ihrachyshka
This post is the fifth in a series that covers gratuitous ARP and its relation to OpenStack. In the previous posts, we discussed what gratuitous ARP is and how it’s implemented in OpenStack Neutron L3 agent. We also introduced the Failure, covered ... [More] its initial triaging, and looked at traffic captured during failed test runs. All previous attempts to figure out … Continue reading The Failure, part 3: Diggin’ the Kernel → [Less]
Posted 3 days ago by hastexo
SUSE, Global Player in Open Source Software, Collaborates with hastexo to leverage OpenStack for Learning Management and Courseware Development Madrid, Spain (2017 Open edX Conference) May 24, 2017 Coinciding with the annual gathering of users and ... [More] developers of the Open edX Platform, the 2017 Open edX Conference (https://con.openedx.org/), hastexo is happy to announce that SUSE (www.suse.com) has selected Open edX as the basis of its platform for learning systems management and courseware development. The announcement comes at a time when hundreds of information technology companies are dealing with the rapidly progressing development of increasingly complex platforms across the industry. Technologies like OpenStack, Ceph, Kubernetes, and many others are inherently built for speed, scale, and cost savings — but the most important challenge that organizations face in relation to these technologies is skill building. Innovative companies like SUSE realize that skill development and training — of employees and partners alike — must match the pace of technology. As such, organizations are trending toward fully autonomous, self-paced, on-line training, and Open edX is a perfect platform for that purpose. hastexo, SUSE's partner in this endeavor, is an active contributor to the Open edX project and has developed an open source solution that enables SUSE learners to spin up arbitrarily complex distributed lab environments, on demand, in an OpenStack private or public cloud. SUSE has launched the on-demand platform to both its employees and partners. About hastexo hastexo is an independent professional services organization specializing in open source solutions for cloud computing, distributed storage, and self-paced on-line training. The company is heavily involved in the OpenStack, Ceph, and Open edX communities and offers its services world-wide. hastexo currently serves customers on five continents, and continuously expands its customer base. hastexo’s web site is www.hastexo.com, and its self-paced learning courses are offered from academy.hastexo.com. [Less]
Posted 3 days ago by Jessica Field
The post OpenStack Australia Day Melbourne: Innovation, Donuts and the chance to win a FREE pass to the Sydney OpenStack Summit! appeared first on Aptira Cloud Solutions.
Posted 3 days ago by Superuser
The total cost of ownership for an OpenStack private cloud can be half of other infrastructure alternatives.  The key to achieving such a goal is to capture relevant metrics and watch them closely say the team at Verizon Wireless.  At the recent ... [More] OpenStack Summit Boston, Billy Felton and Andrew Hendrickson of Verizon along with Sanjay […] The post OpenStack Verizon case study: The illusion of infinite capacity appeared first on OpenStack Superuser. [Less]
Posted 4 days ago by ihrachyshka
This post is the fourth in a series that covers gratuitous ARP and its relation to OpenStack. In the previous posts, we discussed what gratuitous ARP is and how it’s implemented in OpenStack Neutron L3 agent. We also set the stage for the Failure ... [More] , and dismissed easier causes of it. This post will continue discussion of the Failure beyond … Continue reading The Failure, part 2: Beyond OpenStack → [Less]
Posted 4 days ago by Major Hayden
I merged some initial Debian support into the openstack-ansible-security role and ran into an issue enabling AppArmor. The apparmor service failed to start and I found this output in the system journal: [crayon-5925b291f0e40455780248/] Digging in ... [More] That was unexpected. I was using the Debian jessie cloud image and it uses extlinux as the bootloader. The file […] The post Enable AppArmor on a Debian Jessie cloud image appeared first on major.io. [Less]
Posted 4 days ago by Nicole Martinelli
"Your technology should be woven in...if it’s woven in, you remove all the friction traditionally associated with selling to the enterprise.” The post Shuttleworth on what it takes for open source startups to succeed now appeared first on OpenStack Superuser.
Posted 4 days ago by Chris Dent
With the advent Thierry's weekly status reports1 on the proposals currently under review by the TC and the optionality of the weekly TC meetings, this report becomes less about meeting minutes and more about reporting on the things that crossed my TC ... [More] radar that seemed important and/or that seemed like they could do with more input. This week has no TC meeting. The plan is that discussion will occur either asynchronously in mailing list threads on the "opentack-dev" list or in gerrit reviews in the governance project2 or for casual chats use IRC and the #openstack-dev channel3. Pending Stuff The need to talk about postgreSQL There's ongoing discussion about how to deal with the position of postgreSQL in the attention of the community. There are deployments that use it and the documentation mentions it, but the attention of most developers and all tests is not upon it. It is upon MySQL (and its variants) instead. There's agreement that this needs to be dealt with, but the degree of change is debated, if not hotly then at least verbosely. An initial review was posted proposing we clear up the document and indicate a path forward that recognized an existing MySQL orientation: https://review.openstack.org/#/c/427880/ I felt this was too wordy, too MySQL oriented, and left out an important step: agitate with the board. It was easier to explain this in an alternative version resulting in: https://review.openstack.org/#/c/465589/ Meanwhile discussion had begun (and still continues) in an email thread: http://lists.openstack.org/pipermail/openstack-dev/2017-May/116642.html Observing all this, Monty noticed that there is a philosophical chasm that must be bridged before we can truly resolve this issue, so he started yet another thread: http://lists.openstack.org/pipermail/openstack-dev/2017-May/117148.html The outcome of that thread and these resolutions is likely to have a fairly significant impact on how we think about managing dependent services in OpenStack. There's a lot to digest behind those links but on the scale of "stuff the TC is doing that will have impact" this is probably one of them. Draft Vision for the TC The draft vision for the TC4 got feedback on the review, via survey5 and at the forum6. Effort is now in progress to incorporate that feedback and create something that is easier to comprehend and will make the actual vision more clear. One common bit of feedback was that the document needs a preamble and other structural cues so that people get what it is trying to do. johnthetubaguy, dtroyer and I (cdent) are on the hook for doing this next phase of work. Feel free to contact one of us (or leave a comment on the review, or send some email) if you feel like you have something to add. Dropped Stuff A section with reminders of things that were happening or were going to happen then either stopped without resolution or never started in the first place. OpenStack moving too fast and too slow A thread was started on this7. It got huge. While there were many subtopics, one of the larger ones was the desire for there to be a long term support release. There were a few different reactions to this, inaccurately paraphrased as: That we have any stable releases at all in the upstream is pretty amazing, some global projects don't bother, it's usually a downstream problem. Great idea, please provide some of the resources required to make it happen, the OpenStack community is not an unlimited supply of free labor. Then summit happened, people moved on to other things and there wasn't much in the way of resolution. Is there anything we could or should be doing here? If having LTS is that much of a big deal, then it is something which the Foundation Board of Directors must be convinced is a priority. Early in this process I had suggested we at least write a resolution that repeats (in nicer form) the second bullet point above. We could do that. There's also a new plan to create a top 5 help wanted list8. Doing LTS is probably too big for that, but "stable branch reviews" is not. http://lists.openstack.org/pipermail/openstack-dev/2017-May/117047.html ↩ https://review.openstack.org/#/q/project:openstack/governance+status:open ↩ The concept of office hours is being introduced: https://review.openstack.org/#/c/467256/ ↩ https://review.openstack.org/#/c/453262/ ↩ https://docs.google.com/spreadsheets/d/1YzHPP2EQh2DZWGTj_VbhwhtsDQebAgqldyi1MHm6QpE ↩ https://www.openstack.org/videos/boston-2017/the-openstack-technical-committee-vision-for-2019-updates-stories-and-q-and-a ↩ http://lists.openstack.org/pipermail/openstack-dev/2017-May/116298.html ↩ https://review.openstack.org/#/c/466684/ ↩ [Less]