myfile.xml

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title type="text">Fedora Planet</title>
  <id>http://fedoraplanet.org/</id>
  <updated>2015-12-03T07:45:42Z</updated>
  <link href="http://fedoraplanet.org/" />
  <link href="http://fedoraplanet.org/" rel="self" />
  <author>
    <name></name>
  </author>
  <subtitle type="text">http://fedoraplanet.org/</subtitle>
  <generator>PyAtom</generator>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Mumble ready for testing</title>
    <id>http://fedoraplanet.org/2/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/2/" />
    <author>
      <name>Justin W. Flory</name>
    </author>
    <content type="html/text">Mumble is back in Fedora
Mumble, a free and open-source VoIP program</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Understanding the kernel release cycle</title>
    <id>http://fedoraplanet.org/3/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/3/" />
    <author>
      <name>Josh Boyer</name>
    </author>
    <content type="html/text">A few days ago, a Fedora community member was asking if there was a 4.3 kernel for F23 yet (there isn't).  When pressed for why, it turns out they were asking for someone that wanted newer support but thought a 4.4-rc3 kernel was too new.  This was surprising to me.  The assumption was being made that 4.4-rc3 was unstable or dangerous, but that 4.3 was just fine even though Fedora hasn't updated the release branches with it yet.  This led me to ponder the upstream kernel release cycle a bit, and I thought I would offer some insights as to why the version number might not represent what most people think it does.First, I will start by saying that the upstream kernel development process is amazing.  The rate of change for the 4.3 kernel was around 8 patches per hour, by 1600 developers, for a total of 12,131 changes over 63 days total[1].  And that is considered a fairly calm release by kernel standards.  The fact that the community continues to churn out kernels of such quality with that rate of change is very very impressive.  There is actually quite a bit of background coordination that goes on between the subsystem maintainers, but I'm going to focus on how Linus' releases are formed for the sake of simplicity for now.A kernel release is broken into a set of discrete, roughly time-based chunks.  The first chunk is the 2 week merge window.  This is the timeframe where the subsystem maintainers send the majority of the new changes for that release to Linus.  He takes them in via git pull requests, grumbles about a fair number of them, refuses a few others.  Most of the pull requests are dealt with in the first week, but there are always a few late ones so Linus waits the two weeks and then "closes" the window.  This culminates in the first RC release being cut.From that point on, the focus for the release is fixes.  New code being taken at this point is fairly rare, but does happen in the early -rc releases.  These are cut roughly every Sunday evening, making for a one week timeframe per -rc.  Each -rc release tends to be smaller in new changesets than the previous, as the community becomes much more picky on what is acceptable the longer the release has gone on.  Typically it gets to -rc7, but occasionally it will go to -rc8.  One week after -rc7 is released, the "final" release is cut, which maps nicely with the 63 day timeframe quoted above.Now, here is where people start getting confused.  They see a "final" release and immediately assume it's stable.  It's not.  There are bugs.  Lots and lots of bugs.  So why would Linus release a kernel with a lot of bugs?  Because finding them all is an economy of scale.  Let's step back a second into the development and see why.During the development cycle, people are constantly testing things.  However, not everyone is testing the same thing.  Each subsystem maintainer is often testing their own git tree for their specific subsystem.  At the same time, they've opened their subsystem trees for changes for the next version of the kernel, not the one still in -rcX state.  So they have new code coming in before the current code is even released.  This is how they sustain that massive rate of change.Aside from subsystem trees, there is the linux-next tree.  This is daily merge of all the subsystem maintainer trees that have already opened up to new code on top of whatever Linus has in his tree.  A number of people are continually testing linux-next, mostly through automated bots but also in VMs and running fuzzers and such.  In theory and in practice, this catches bugs before they get to Linus the next round.  But it is complicated because the rate of change means that if an issue is hit, it's hard to see if it's in the new new code only found in linux-next, or if it's actually in Linus' tree.  Determining that usually winds up being a manual process via git-bisect, but sometimes the testing bots can determine the offending commit in an automated fashion.If a bug is found, the subsystem maintainer or patch author or whomever must track which tree the bug is, whether it's a small enough fix to go into whatever -rcX state  Linus' tree is in, and how to get it there.  This is very much a manual process, and often involves multiple humans.  Given that humans are terrible at multitasking in general, and grow ever more cautious the later the -rcX state is, sometimes fixes are missed or simply queued for the next merge window.  That's not to say important bugs are not fixed, because clearly there are several weeks of -rcX releases where fixing is the primary concern.  However, with all the moving parts, you're never going to find all the bugs in time.In addition to the rate of change/forest of trees issue, there's also the diversity and size of the tester pool.  Most of the bots test via VMs.  VMs are wonderful tools, but they don't test the majority of the drivers in the kernel.  The kernel developers themselves tend to have higher end laptops.  Traditionally this was of the Thinkpad variety and a fair number of those are still seen, but there is some variance here now which is good.  But it isn't good enough to cover all possible firmware, device, memory, and workload combinations.  There are other testers to be sure, but they only cover a tiny fraction of the end user machines.It isn't hard to see how bugs slip through, particularly in drivers or on previous generation hardware.  I wouldn't even call it a problem really.  No software project is going to cut a release with 0 bugs in it.  It simply doesn't happen.  The kernel is actually fairly high quality at release time in spite of this.  However, as I said earlier, people tend to make assumptions and think it's good enough for daily use on whatever hardware they have.  Then they're surprised when it might not be.To combat this problem, we have the upstream stable trees.  These trees backport fixes from the current development kernels that also apply to the already released kernels.  Hence, 4.3.1 is Linus' 4.3 release, plus a number of fixes that were found "too late".  This, in my opinion, is where the bulk of the work on making a kernel usable happens.  It is also somewhat surprising when you look at it.The first stable release of a kernel, a .1 release, is actually very large.  It is often comprised of 100-200 individual changes that are being backported from the current development kernel.  That means there are 100-200 bugs immediately being fixed there.  Whew, that's a lot but OK maybe expected with everything above taken into account.  Except the .2 release is often also 100-200 patches.  And .3.  And often .4.  It isn't until you start getting into .5, .6, .7, etc that the patch count starts getting smaller.  By the .9 release, it's usually time to retire the whole tree (unless it's a long-term stable) and start the fun all over again.In dealing with the Fedora kernel, the maintainers take all of this into account.  This is why it is very rare to see us push a 4.x.0 kernel to a stable release, and often it isn't until .2 that you see a build.  For those thinking that this article is somehow deriding the upstream kernel development process, I hope you now realize the opposite is true.  We rely heavily on upstream following through and tagging and fixing the issues it finds, either while under development or via the stable process.  We help the stable process as well by reporting back fixes if they aren't already found.So hopefully next time you're itching for a new kernel just because it's been released upstream, you'll pause and think about this.  And if you really want to help, you'll grab a rawhide kernel and pitch in by reporting any issues when you find them.  The only way to get the stable kernel releases smaller, and reduce the number of bugs still found in freshly released kernels, is to broaden the tester pool and let the upstream developers know as soon as possible.  In this way, we're all part of the upstream kernel community and we can all keep making it awesome and impressive.(4.3.y will likely be coming to F23 the first week of January.  Greg-KH seems to have gone on some kind of walkabout the past few weeks so 4.3.1 hasn't been released yet.  To be honest, it's a break well deserved.  Or maybe he found 4.3 to be even more buggy as usual.  Who knows!)[1] https://lwn.net/Articles/661978/  (Of course I was going to link to lwn.net.  If you aren't already subscribed to it, you really should be.  They have amazing articles and technical content.  They make my stuff look like junk even more than it already is.  I'm kinda jealous at the energy and expertise they show in their writing.)</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Git, binary files, and patches</title>
    <id>http://fedoraplanet.org/4/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/4/" />
    <author>
      <name>Laura Abbott</name>
    </author>
    <content type="html/text">$ mkdir test_repo
$ cd test_repo/
$ git init
Initialized empty Git repository in /home/labbott/test_repo/.git/
$ touch foo
$ git add foo
$ git commit -m "this file"
[   master (root-commit) c51ba67] this file
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 foo
$ cp ~/a.out .
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter
/lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
BuildID[sha1]=96d6131eb203b850d42b53a7f5ebc512056ec739, not stripped
$ git add a.out
$ git commit -m "A binary file"
[master d5bdd17] A binary file
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100755 a.out
$ git rm a.out
rm 'a.out'
$ git commit -m "no binary"
[master 9dd9f2b] no binary
1 file changed, 0 insertions(+), 0 deletions(-)
delete mode 100755 a.out
$ git format-patch -1 --no-binary HEAD
0001-no-binary.patch
$ git reset --hard HEAD^
HEAD is now at d5bdd17 A binary file
$ patch -p1 &amp;lt; 0001-no-binary.patch
patching file a.out
Not deleting file a.out as content differs from patch
$ echo $?
1
$ cat 0001-no-binary.patch
From 9dd9f2b6c717d4125d790610941f258bdb573ee4 Mon Sep 17 00:00:00 2001
From: Laura Abbott &amp;lt;labbott@fedoraproject.org&amp;gt;
Date: Wed, 2 Dec 2015 10:45:33 -0800
Subject: [PATCH] no binary

---
a.out | Bin 8784 -&amp;gt; 0 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
delete mode 100755 a.out

diff --git a/a.out b/a.out
deleted file mode 100755
index 3772793..0000000
Binary files a/a.out and /dev/null differ
-- 
2.5.0
$

This is the story behind
a recent bugzilla.
The patches generated on kernel.org only say that the binary files changed
so they can't actually be applied as diffs.
Git deals with binary files just fine though so it's possible to sneak
some in and end up with a tree that can't be easily expressed in patches.
Binary files usually don't have a place in the kernel, but some
did come in with a staging driver. The staging driver was
deleted
this merge window. Everything that isn't an official x.y kernel release (e.g.
4.3-rc4, 4.2.3) comes in as a patch file so all patches are going to be
unappliable until that commit makes it into an official release. The workaround
right now is to modify the patch to get rid of the binary file deletion. This
does mean the checksums aren't going to match against kernel.org but this is
only going to be the case until the next official release in rawhide which
should be sometime at the beginning of January. You'll just have to
trust the Fedora kernel team in the mean time.</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">FESCo Elections: Interview with Kevin Fenzi (kevin / nirik)</title>
    <id>http://fedoraplanet.org/5/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/5/" />
    <author>
      <name>Fedora Community Blog</name>
    </author>
    <content type="html/text">Fedora Engineering Steering Council badge</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">FAmSCo Elections: Interview with Abdel Martínez (potty)</title>
    <id>http://fedoraplanet.org/6/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/6/" />
    <author>
      <name>Fedora Community Blog</name>
    </author>
    <content type="html/text">Fedora Ambassador Steering Committee badge</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Three years and counting</title>
    <id>http://fedoraplanet.org/7/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/7/" />
    <author>
      <name>Andrea Veri</name>
    </author>
    <content type="html/text">It’s been a while since my last “what’s been happening behind the scenes” e-mail so I’m here to report on what has been happening within the GNOME Infrastructure, its future plans and my personal sensations about a challenge that started around three (3) years ago when Sriram Ramkrishna and Jeff Schroeder proposed my name as a possible candidate for coordinating the team that runs the systems behind the GNOME Project. All this followed by the official hiring achieved by Karen Sandler back in February 2013.
The GNOME Infrastructure has finally reached stability both in terms of reliability and uptime, we didn’t have any service disruption this and the past year and services have been running smoothly as they were expected to in a project like the one we are managing.
As many of you know service disruptions and a total lack of maintenance were very common before I joined back in 2013, I’m so glad the situation has dramatically changed and developers, users, passionates are now able to reach our websites, code repositories, build machines without experiencing slowness, downtimes or
unreachability. Additionally all these groups of people now have a reference point they can contact in case they need help when coping with the infrastructure they daily use. The ticketing system allows users to get in touch with the members of the Sysadmin Team and receive support right away within a very short period of time (Also thanks to Pagerduty, service the Foundation is kindly sponsoring)
Before moving ahead to the future plans I’d like to provide you a summary of what has been done during these roughly three years so you can get an idea of why I define the changes that happened to the infrastructure a complete revamp:

Recycled several ancient machines migrating services off of them while consolidating them by placing all their configuration on our central configuration management platform ran by Puppet. This includes a grand total of 7 machines that were replaced by new hardware and extended warranties the Foundation kindly sponsored.
We strenghten our websites security by introducing SSL certificates everywhere and recently replacing them with SHA2 certificates.
We introduced several services such as Owncloud, the Commits Bot, the Pastebin, the Etherpad, Jabber, the GNOME Github mirror.
We restructured the way we backup our machines also thanks to the Fedora Project sponsoring the disk space on their backup facility. The way we were used to handle backups drastically changed from early years where a magnetic tape facility was in charge of all the burden of archiving our data to today where a NetApp is used together with rdiff-backup.
We upgraded Bugzilla to the latest release, a huge thanks goes to Krzesimir Nowak who kindly helped us building the migration tools.
We introduced the GNOME Apprentice program open-sourcing our internal Puppet repository and cleansing it (shallow clones FTW!) from any sensitive information which now lives on a different repository with restricted access.
We retired Mango and our OpenLDAP instance in favor of FreeIPA which allows users to modify their account information on their own without waiting for the Accounts Team to process the change.
We documented how our internal tools are customized to play together making it easy for future Sysadmin Team members to learn how the infrastructure works and supersede existing members in case they aren’t able to keep up their position anymore.
We started providing hosting to the GIMP and GTK projects which now completely rely on the GNOME Infrastructure. (DNS, email, websites and other services infrastructure hosting)
We started providing hosting not only to the GIMP and GTK projects but to localized communities as well such as GNOME Hispano and GNOME Greece
We configured proper monitoring for all the hosted services thanks to Nagios and Check-MK
We migrated the IRC network to a newer ircd with proper IRC services (Nickserv, Chanserv) in place.
We made sure each machine had a configured management (mgmt) and KVM interface for direct remote access to the bare metal machine itself, its hardware status and all the operations related to it. (hard reset, reboot, shutdown etc.)
We upgraded MoinMoin to the latest release and made a substantial cleanup of old accounts, pages marked as spam and trashed pages.
We deployed DNSSEC for several domains we manage including gnome.org, guadec.es, gnomehispano.es, guadec.org, gtk.org and gimp.org
We introduced an account de-activation policy which comes into play when a contributor not committing to any of the hosted repositories at git.gnome.org since two years is caught by the script. The account in question is marked as inactive and the gnomecvs (from the old cvs days) and ftpadmin groups are removed.
We planned mass reboots of all the machines roughly every month for properly applying security and kernel updates.
We introduced Mirrorbrain (MB), the mirroring service serving GNOME and related modules tarballs and software all over the world. Before introducing MB GNOME had several mirrors located in all the main continents and at the same time a very low amount of users making good use of them. Many organizations and companies behind these mirrors decided to not host GNOME sources anymore as the statistics of usage were very poor and preferred providing the same service to projects that really had a demand for these resources. MB solved all this allowing a proper redirect to the closest mirror (through mod_geoip) and making sure the sources checksum matched across all the mirrors and against the original tarball uploaded by a GNOME maintainer and hosted at master.gnome.org.

I can keep the list going for dozens of other accomplished tasks but I’m sure many of you are now more interested in what the future plans actually are in terms of where the GNOME Infrastructure should be in the next couple of years.
One of the main topics we’ve been discussing will be migrating our Git infrastructure away from cgit (which is mainly serving as a code browsing tool) to a more complete platform that is surely going to include a code review tool of some sort. (Gerrit, Gitlab, Phabricator)
Another topic would be migrating our mailing lists to Mailman 3 / Hyperkitty. This also means we definitely need a staging infrastructure in place for testing these kind of transitions ideally bound to a separate Puppet / Ansible repository or branch. Having a different repository for testing purposes will also mean helping apprentices to test their changes directly on a live system and not on their personal computer which might be running a different OS / set of tools than the ones we run on the GNOME Infrastructure.
What I also aim would be seeing GNOME Accounts being the only authentication resource in use within the whole GNOME Infrastructure. That means one should be able to login to a specific service with the same username / password in use on the other hosted services. That’s been on my todo list for a while already and it’s probably time to push it forward together with Patrick Puiterwijk, responsible of Ipsilon‘s development at Red Hat and GNOME Sysadmin.
While these are the top priority items we are soon receiving new hardware (plus extended warranty renewals for two out of the three machines that had their warranty renewed a while back) and migrating some of the VMs off from the current set of machines to the new boxes is definitely another task I’d be willing to look at in the next couple of months (one machine (ns-master.gnome.org) is being decommissioned giving me a chance to migrate away from BIND into NSD).
The GNOME Infrastructure is evolving and it’s crucial to have someone maintaining it. On this side I’m bringing to your attention the fact the assigned Sysadmin funds are running out as reported on the Board minutes from the 27th of October. On this side Jeff Fortin started looking for possible sponsors and
came up with the idea of making a brochure with a set of accomplished tasks that couldn’t have been possible without the Sysadmin fundraising campaign launched by Stormy Peters back in June 2010 being a success. The Board is well aware of the importance of having someone looking at the infrastructure that runs the GNOME Project and is making sure the brochure will be properly reviewed and published.
And now some stats taken from the Puppet Git Repository:$ cd /git/GNOME/puppet &amp;amp;&amp;amp; git shortlog -ns

3520 Andrea Veri
506 Olav Vitters
338 Owen W. Taylor
239 Patrick Uiterwijk
112 Jeff Schroeder
71 Christer Edwards
4 Daniel Mustieles
4 Matanya Moses
3 Tobias Mueller
2 John Carr
2 Ray Wang
1 Daniel Mustieles García
1 Peter Baumgartenand from the Request Tracker database (52388 being my assigned ID):mysql&amp;gt; select count(*) from Tickets where LastUpdatedBy = '52388';
+----------+
| count(*) |
+----------+
| 3613 |
+----------+
1 row in set (0.01 sec)

mysql&amp;gt; select count(*) from Tickets where LastUpdatedBy = '52388' and Status = 'Resolved';
+----------+
| count(*) |
+----------+
| 1596 |
+----------+
1 row in set (0.03 sec)It’s been a long run which made me proud, for the things I learnt, for the tasks I’ve been able to accomplish, for the great support the GNOME community gave me all the time and most of all for the same fact of being part of the team responsible of the systems hosting the GNOME Project. Thank you GNOME community for your continued and never ending backing, we daily work to improve how the services we host are delivered to you and the support we receive back is fundamental for our passion and enthusiasm to remain high!
 </content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Is giving money to Conservancy the best course of action?</title>
    <id>http://fedoraplanet.org/8/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/8/" />
    <author>
      <name>Daniel Pocock</name>
    </author>
    <content type="html/text">There has been a lot of discussion lately about Software Freedom Conservancy's fundraiser.
Various questions come to my mind:
Is this the only way to achieve goals such as defending copyright?  (There are other options, like corporate legal insurance policies)
When all the options are compared, is Conservancy the best one?  Maybe it is, but it would be great to confirm why we reached that conclusion.
Could it be necessary to choose two or more options that complement each other? Conservancy may just be one part of the solution and we may get a far better outcome if money is divided between Conservancy and insurance and something else.
What about all the other expenses that developers incur while producing free software?  Many other professionals, like doctors, do work that is just as valuable for society but they are not made to feel guilty about asking for payment and reimbursement. (In fact, for doctors, there is no shortage of it from the drug companies).
There seems to be an awkwardness about dealing with money in the free software world and it means many projects continue to go from one crisis to the next.  Just yesterday on another mailing list there was discussion about speakers regularly asking for reimbursement to attend conferences and at least one strongly worded email appeared questioning whether people asking about money are sufficiently enthusiastic about free software or if they are only offering to speak in the hope their trip will be paid.
The DebConf team experienced one of the more disappointing examples of a budget communication issue when developers who had already volunteered long hours to prepare for the event then had to give up valuable time during the conference to wash the dishes for 300 people.  Had the team simply insisted that the high cost of local labor was known when the country was selected then the task could have been easily outsourced to local staff.  This came about because some members of the community felt nervous about asking for budget and other people couldn't commit to spend.
Rather than stomping on developers who ask about money or anticipate the need for it in advance, I believe we need to ask people if money was not taboo, what is the effort they could contribute to the free software world and how much would they need to spend in a year for all the expenses that involved.  After all, isn't that similar to the appeal from Conservancy's directors?  If all developers and contributors were suitably funded, then many people would budget for contributions to Conservancy, other insurances, attending more events and a range of other expenses that would make the free software world operate more smoothly.
In contrast, the situation we have now (for event-related expenses) is that developers funding themselves or with tightly constrained budgets or grants often have to spend hours picking through AirBNB and airline web sites trying to get the best deal while those few developers who do have more flexible corporate charge cards just pick a convenient hotel and don't lose any time reading through the fine print to see if there are charges for wifi, breakfast, parking, hidden taxes and all the other gotchas because all of that will be covered for them.
With developer budgets/wishlists documented, where will the money come from?  Maybe it won't appear, maybe it will.  But if we don't ask for it at all, we are much less likely to get anything.  Mozilla has recently suggested that developers need more cash and offered to put $1 million on the table to fix the problem, is it possible other companies may see the benefit of this and put up some cash too?
The time it takes to promote one large budget and gather donations is probably far more efficient than the energy lost firefighting lots of little crisis situations.
Being more confident about money can also do a lot more to help engage people and make their participation sustainable in the long term.  For example, if a younger developer is trying to save the equivalent of two years of their salary to paying a deposit on a house purchase, how will they feel about giving money to Conservancy or pay their own travel expenses to a free software event?  Are their families and other people they respect telling them to spend or to save and if our message is not compatible with that, is it harder for us to connect with these people?
One other thing to keep in mind is that budgeting needs to include the costs of those who may help the fund-raising and administration of money.  If existing members of our projects are not excited about doing such work we have to be willing to break from the "wait for a volunteer or do-it-yourself" attitude.  There are so many chores that we are far more capable of doing as developers that we still don't have time for, we are only fooling ourselves if we anticipate that effective fund-raising will take place without some incentives going back to those who do the work.
</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">OpenHardware and code signing (update)</title>
    <id>http://fedoraplanet.org/9/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/9/" />
    <author>
      <name>Richard Hughes</name>
    </author>
    <content type="html/text">I posted a few weeks ago about the difficulty of providing device-side verification of firmware updates, at the same time remaining OpenHardware and thus easily hackable. The general consensus was that allowing anyone to write any kind of firmware to the device without additional authentication was probably a bad idea, even for OpenHardware devices. I think I’ve come up with an acceptable compromise I can write up as a recommendation, as per usual using the ColorHug+ as an example. For some background, I’ve sold nearly 3,000 original ColorHug devices, and in the last 4 years just three people wanted help writing custom firmware, so I hope you can see the need to protect the majority is so much larger than making the power users happy.
ColorHug+ will be supplied with a bootloader that accepts only firmware encrypted with the secret XTEA key I that I’m using for my devices. XTEA is an acceptable compromise between something as secure as ECC, but that’s actually acceptable in speed and memory usage for a 8-bit microcontroller running at 6MHz with 8k of ROM. Flashing a DIY or modified firmware isn’t possible, and by the same logic flashing a malicious firmware will also not work.
To unlock the device (and so it stays OpenHardware) you just have to remove the two screws, and use a paper-clip to connect TP5 and GND while the device is being plugged into the USB port. Both lights will come on, and stay on for 5 seconds and then the code protection is turned off. This means you can now flash any home-made or malicious firmware to the device as you please.
There are downsides to unlocking; you can’t re-lock the hardware so it supports official updates again. I don’t know if this is a huge problem; flashing home-made firmware could damage the device (e.g. changing the pin mapping from input to output and causing something to get hot). If this is a huge problem I can fix CH+ to allow re-locking and fix up the guidelines, although I’m erring on unlocking being a one way operation.
Comments welcome.</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">FAmSCo Elections: Interview with Dan Mossor (danofsatx)</title>
    <id>http://fedoraplanet.org/10/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/10/" />
    <author>
      <name>Fedora Community Blog</name>
    </author>
    <content type="html/text">Fedora Ambassador Steering Committee badge</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Automatic Upstream Dependency Testing</title>
    <id>http://fedoraplanet.org/11/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/11/" />
    <author>
      <name>Alexander Todorov</name>
    </author>
    <content type="html/text">Ever since
RHEL 7.2 python-libs broke s3cmd
I've been pondering an age old problem: How do I know if my software works with the
latest upstream dependencies ? How can I pro-actively monitor for new versions
and add them to my test matrix ?
Mixing together my previous experience with
Difio
and monitoring upstream sources,
and Forbes Lindesay's GitHub Automation talk
at DEVit Conf I came
together with a plan:

Make an application which will execute when new upstream version is available;
Automatically update .travis.yml
for the projects I'm interested in;
Let Travis-CI execute my test suite for all available upstream versions;
Profit!

How Does It Work
First we need to monitor upstream! RubyGems.org has nice
webhooks interface,
you can even trigger on individual packages. PyPI however doesn't have anything
like this :(. My solution is to run a cron job every hour and parse their RSS
stream for newly released packages. This has been working previously for Difio
so I re-used one function from the code.
After finding anything we're interested in comes the hard part - automatically
updating .travis.yml using the GitHub API. I've described this in more detail
here. This time
I've slightly modified the code to update only when needed and accept more
parameters so it can be reused.
Travis-CI has a clean interface to specify environment variables and
defining several
of them crates a test matrix. This is exactly what I'm doing.
.travis.yml is updated with a new ENV setting, which determines the upstream
package version. After commit new build is triggered which includes the expanded
test matrix.
Example

Imagine that our Project 2501 depends on FOO version 0.3.1. The
build log illustrates what
happened:

Build #9 is what we've tested with FOO-0.3.1 and released to production.
Test result is PASS!
Build #10 - meanwhile upstream releases FOO-0.3.2 which causes our project
to break. We're not aware of this and continue developing new features
while all test results still PASS! When our customers upgrade their systems
Project 2501 will break ! Tests didn't catch it because test matrix wasn't
updated. Please
ignore the actual commit message in the example! I've used the same repository
for the dummy dependency package.
Build #11 - the monitoring solution finds FOO-0.3.2 and updates the test
matrix automatically. The build immediately breaks! More precisely the
test with version 0.3.2 fails!
Build #12 - we've alerted FOO.org about their problem and they've released
FOO-0.3.3. Our monitor has found that and updated the test matrix.
However the 0.3.2 test job still fails!
Build #13 - we decide to workaround the 0.3.2 failure or simply handle the
error gracefully. In this example I've removed version 0.3.2 from the test
matrix to simulate that. In reality I wouldn't touch .travis.yml but instead
update my application and tests to check for that particular version.
All test results are PASS again!

Btw Build #11 above was triggered manually (./monitor.py) while Build #12
came from OpenShit, my hosting environment.
At present I have this monitoring enabled for my
new Markdown extensions
and will also add it to django-s3-cache
once it migrates to Travis-CI (it uses drone.io now).
Enough Talk, Show me the Code
monitor.py#!/usr/bin/env python

import os
import sys
import json
import base64
import httplib
from pprint import pprint
from datetime import datetime
from xml.dom.minidom import parseString

def get_url(url, post_data = None):
    # GitHub requires a valid UA string
    headers = {
        'User-Agent' : 'Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120601 Firefox/10.0.5',
    }

    # shortcut for GitHub API calls
    if url.find("://") == -1:
        url = "https://api.github.com%s" % url

    if url.find('api.github.com') &amp;gt; -1:
        if not os.environ.has_key("GITHUB_TOKEN"):
            raise Exception("Set the GITHUB_TOKEN variable")
        else:
            headers.update({
                'Authorization': 'token %s' % os.environ['GITHUB_TOKEN']
            })

    (proto, host_path) = url.split('//')
    (host_port, path) = host_path.split('/', 1)
    path = '/' + path

    if url.startswith('https'):
        conn = httplib.HTTPSConnection(host_port)
    else:
        conn = httplib.HTTPConnection(host_port)


    method = 'GET'
    if post_data:
        method = 'POST'
        post_data = json.dumps(post_data)

    conn.request(method, path, body=post_data, headers=headers)
    response = conn.getresponse()

    if (response.status == 404):
        raise Exception("404 - %s not found" % url)

    result = response.read().decode('UTF-8', 'replace')
    try:
        return json.loads(result)
    except ValueError:
        # not a JSON response
        return result

def post_url(url, data):
    return get_url(url, data)


def monitor_rss(config):
    """
        Scan the PyPI RSS feeds to look for new packages.
        If name is found in config then execute the specified callback.

        @config is a dict with keys matching package names and values
        are lists of dicts
            {
                'cb' : a_callback,
                'args' : dict
            }
    """
    rss = get_url("https://pypi.python.org/pypi?:action=rss")
    dom = parseString(rss)
    for item in dom.getElementsByTagName("item"):
        try:
            title = item.getElementsByTagName("title")[0]
            pub_date = item.getElementsByTagName("pubDate")[0]

            (name, version) = title.firstChild.wholeText.split(" ")
            released_on = datetime.strptime(pub_date.firstChild.wholeText, '%d %b %Y %H:%M:%S GMT')

            if name in config.keys():
                print name, version, "found in config"
                for cfg in config[name]:
                    try:
                        args = cfg['args']
                        args.update({
                            'name' : name,
                            'version' : version,
                            'released_on' : released_on
                        })

                        # execute the call back
                        cfg['cb'](**args)
                    except Exception, e:
                        print e
                        continue
        except Exception, e:
            print e
            continue

def update_travis(data, new_version):
    travis = data.rstrip()
    new_ver_line = "  - VERSION=%s" % new_version
    if travis.find(new_ver_line) == -1:
        travis += "\n" + new_ver_line + "\n"
    return travis


def update_github(**kwargs):
    """
        Update GitHub via API
    """
    GITHUB_REPO = kwargs.get('GITHUB_REPO')
    GITHUB_BRANCH = kwargs.get('GITHUB_BRANCH')
    GITHUB_FILE = kwargs.get('GITHUB_FILE')

    # step 1: Get a reference to HEAD
    data = get_url("/repos/%s/git/refs/heads/%s" % (GITHUB_REPO, GITHUB_BRANCH))
    HEAD = {
        'sha' : data['object']['sha'],
        'url' : data['object']['url'],
    }

    # step 2: Grab the commit that HEAD points to
    data = get_url(HEAD['url'])
    # remove what we don't need for clarity
    for key in data.keys():
        if key not in ['sha', 'tree']:
            del data[key]
    HEAD['commit'] = data

    # step 4: Get a hold of the tree that the commit points to
    data = get_url(HEAD['commit']['tree']['url'])
    HEAD['tree'] = { 'sha' : data['sha'] }

    # intermediate step: get the latest content from GitHub and make an updated version
    for obj in data['tree']:
        if obj['path'] == GITHUB_FILE:
            data = get_url(obj['url']) # get the blob from the tree
            data = base64.b64decode(data['content'])
            break

    old_travis = data.rstrip()
    new_travis = update_travis(old_travis, kwargs.get('version'))

    # bail out if nothing changed
    if new_travis == old_travis:
        print "new == old, bailing out", kwargs
        return

    ####
    #### WARNING WRITE OPERATIONS BELOW
    ####

    # step 3: Post your new file to the server
    data = post_url(
                "/repos/%s/git/blobs" % GITHUB_REPO,
                {
                    'content' : new_travis,
                    'encoding' : 'utf-8'
                }
            )
    HEAD['UPDATE'] = { 'sha' : data['sha'] }

    # step 5: Create a tree containing your new file
    data = post_url(
                "/repos/%s/git/trees" % GITHUB_REPO,
                {
                    "base_tree": HEAD['tree']['sha'],
                    "tree": [{
                        "path": GITHUB_FILE,
                        "mode": "100644",
                        "type": "blob",
                        "sha": HEAD['UPDATE']['sha']
                    }]
                }
            )
    HEAD['UPDATE']['tree'] = { 'sha' : data['sha'] }

    # step 6: Create a new commit
    data = post_url(
                "/repos/%s/git/commits" % GITHUB_REPO,
                {
                    "message": "New upstream dependency found! Auto update .travis.yml",
                    "parents": [HEAD['commit']['sha']],
                    "tree": HEAD['UPDATE']['tree']['sha']
                }
            )
    HEAD['UPDATE']['commit'] = { 'sha' : data['sha'] }

    # step 7: Update HEAD, but don't force it!
    data = post_url(
                "/repos/%s/git/refs/heads/%s" % (GITHUB_REPO, GITHUB_BRANCH),
                {
                    "sha": HEAD['UPDATE']['commit']['sha']
                }
            )

    if data.has_key('object'): # PASS
        pass
    else: # FAIL
        print data['message']


if __name__ == "__main__":
    config = {
        "atodorov-test" : [
            {
                'cb' : update_github,
                'args': {
                    'GITHUB_REPO' : 'atodorov/bztest',
                    'GITHUB_BRANCH' : 'master',
                    'GITHUB_FILE' : '.travis.yml'
                }
            }
        ],
        "Markdown" : [
            {
                'cb' : update_github,
                'args': {
                    'GITHUB_REPO' : 'atodorov/Markdown-Bugzilla-Extension',
                    'GITHUB_BRANCH' : 'master',
                    'GITHUB_FILE' : '.travis.yml'
                }
            },
            {
                'cb' : update_github,
                'args': {
                    'GITHUB_REPO' :  'atodorov/Markdown-No-Lazy-Code-Extension',
                    'GITHUB_BRANCH' : 'master',
                    'GITHUB_FILE' : '.travis.yml'
                }
            },
            {
                'cb' : update_github,
                'args': {
                    'GITHUB_REPO' :  'atodorov/Markdown-No-Lazy-BlockQuote-Extension',
                    'GITHUB_BRANCH' : 'master',
                    'GITHUB_FILE' : '.travis.yml'
                }
            },
        ],
    }

    # check the RSS to see if we have something new
    monitor_rss(config)
</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">All systems go</title>
    <id>http://fedoraplanet.org/12/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/12/" />
    <author>
      <name>Fedora Infrastructure Status</name>
    </author>
    <content type="html/text">New status good: Everything seems to be working. for services: Zodbot IRC bot, FedoraHosted.org Services, Mailing Lists</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Netflix and Linux: The First 60 Seconds</title>
    <id>http://fedoraplanet.org/13/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/13/" />
    <author>
      <name>Justin W. Flory</name>
    </author>
    <content type="html/text">Netflix and Linux may not agree on the desktop, but they do in the cloud. Source: blockless.com</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">There are scheduled downtimes in progress</title>
    <id>http://fedoraplanet.org/14/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/14/" />
    <author>
      <name>Fedora Infrastructure Status</name>
    </author>
    <content type="html/text">New status scheduled: Scheduled maintenance in progress for services: Zodbot IRC bot, Mailing Lists, FedoraHosted.org Services</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Mumble ready for testing</title>
    <id>http://fedoraplanet.org/15/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/15/" />
    <author>
      <name>Fedora Community Blog</name>
    </author>
    <content type="html/text">Mumble is back
Mumble, a free and open-source VoIP program</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">lsns(8) new command to list Linux namespaces</title>
    <id>http://fedoraplanet.org/16/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/16/" />
    <author>
      <name>Karel Zak</name>
    </author>
    <content type="html/text">The namespaces are commonly used way how to isolate global (ipc, mount, net, ...) resource instances. Unfortunately, we have no command line tool to list namespaces. The new command lsns(8) tries to fill this gap.  Examples:# lsns        NS TYPE  NPROCS   PID USER   COMMAND4026531836 pid      276     1 root   /usr/lib/systemd/systemd --system --deserialize 154026531837 user     276     1 root   /usr/lib/systemd/systemd --system --deserialize 154026531838 uts      276     1 root   /usr/lib/systemd/systemd --system --deserialize 154026531839 ipc      276     1 root   /usr/lib/systemd/systemd --system --deserialize 154026531840 mnt      269     1 root   /usr/lib/systemd/systemd --system --deserialize 154026531857 mnt        1    63 root   kdevtmpfs4026531963 net      275     1 root   /usr/lib/systemd/systemd --system --deserialize 154026532189 mnt        1   545 root   /usr/lib/systemd/systemd-udevd4026532390 net        1   776 rtkit  /usr/libexec/rtkit-daemon4026532478 mnt        1   776 rtkit  /usr/libexec/rtkit-daemon4026532486 mnt        1   847 colord /usr/libexec/colord4026532518 mnt        3  6500 root   -bash and list namespace content:# lsns 4026532518  PID  PPID USER COMMAND 6500  6372 root -bash19572  6500 root └─/usr/bin/mc -P /tmp/mc-root/mc.pwd.650019575 19572 root   └─bash -rcfile .bashrc help output with columns description:  # lsns -h  Usage: lsns [options] [namespace]  List system namespaces.  Options: -J, --json             use JSON output format -l, --list             use list format output -n, --noheadings       don't print headings -o, --output list      define which output columns to use -p, --task pid         print process namespaces -r, --raw              use the raw output format -u, --notruncate       don't truncate text in columns -t, --type name        namespace type (mnt, net, ipc, user, pid, uts)   -h, --help     display this help and exit -V, --version  output version information and exit  Available columns (for --output):          NS  namespace identifier (inode number)        TYPE  kind of namespace        PATH  path to the namespace      NPROCS  number of processes in the namespace         PID  lowers PID in the namespace        PPID  PPID of the PID     COMMAND  command line of the PID         UID  UID of the PID        USER  username of the PID  For more details see lsns(8). The important detail is that you can see only namespaces accessible from currently mounted /proc filesystem. The lsns(8) is not able to list persistent namespaces without processes where the namespace instance is hold by bind mounts of the /proc/[pid]/ns/[type] files and the output may be affected by unshared PID namespace and unshared /proc (see unshare(8) for more details). ... it will be probably available in util-linux v2.28 (~ January 2016).</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">FAmSCo Elections: Interview with Gabriele Trombini (mailga)</title>
    <id>http://fedoraplanet.org/17/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/17/" />
    <author>
      <name>Fedora Community Blog</name>
    </author>
    <content type="html/text">Fedora Ambassador Steering Committee badge</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Hosting Multiple Python WSGI Scripts on OpenShift</title>
    <id>http://fedoraplanet.org/18/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/18/" />
    <author>
      <name>Alexander Todorov</name>
    </author>
    <content type="html/text">With OpenShift you can host WSGI Python
applications. By default the Python cartridge comes with a simple WSGI app
and the following directory layout
./
./.openshift/
./requirements.txt
./setup.py
./wsgi.py
</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Commit a file with the GitHub API and Python</title>
    <id>http://fedoraplanet.org/19/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/19/" />
    <author>
      <name>Alexander Todorov</name>
    </author>
    <content type="html/text">How do you commit changes to a file using the GitHub API ?
I've found
this post
by Levi Botelho which explains the necessary steps but without any code.
So I've used it and created a
Python example.
I've rearranged the steps so that all write operations follow after a certain
section in the code and also added an intermediate section which creates the
updated content based on what is available in the repository.
I'm just appending
versions of Markdown to the .travis.yml (I will explain why in my next post)
and this is hard-coded for the sake of example. All content related operations
are also based on the GitHub API because I want to be independent of the source
code being around when I push this script to a hosting provider.
I've tested this script against itself. In the
commits log
you can find the Automatic update to Markdown-X.Y messages. These are
from the script. Also notice the Merge remote-tracking branch 'origin/master'
messages, these appeared when I pulled to my local copy. I believe the
reason for this is that I have some dangling trees and/or commits from
the time I was still experimenting with a broken script. I've tested on another
clean repository and there are
no such merges.
IMPORTANT
For this to work you need to properly authenticate with GitHub. I've crated
a new token at https://github.com/settings/tokens with the public_repo
permission and that works for me.</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">podlators-4.00 in Rawhide</title>
    <id>http://fedoraplanet.org/20/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/20/" />
    <author>
      <name>Perl SIG</name>
    </author>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Trying Talky.io</title>
    <id>http://fedoraplanet.org/21/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/21/" />
    <author>
      <name>Luya Tshimbalanga</name>
    </author>
    <content type="html/text">Talky.io have updated their website featuring their WebRTC chat. One of intriguing feature is the support up to 15 people highlighted below.Revamped Talky.io website featuring WebRTCIt appears their systems is a worthy alterntive of Google HangOut. It will be nice project like Empathy carries more love.</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Virtualbox on Fedora</title>
    <id>http://fedoraplanet.org/22/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/22/" />
    <author>
      <name>Carlos Morel-Riquelme</name>
    </author>
    <content type="html/text">Make simpleFirst update your kernel and later reboot your machine[root@new-host-5 asleqia]# dnf -y update kernel &amp;amp;&amp;amp; rebootNow we need install the dependencies and some kernel modules[root@new-host-5
 asleqia]# dnf -y install binutils gcc make patch libgomp glibc-headers 
glibc-devel dkms kernel-devel kernel-core kernel-headers kernel-modules 
kernel-modules-extraNow we need download and install Virtualbox32 bits[root@new-host-5 asleqia]# dnf -y install http://download.virtualbox.org/virtualbox/5.0.10/VirtualBox-5.0-5.0.10_104061_fedora22-1.i686.rpm64 bits[root@new-host-5 asleqia]# dnf -y install http://download.virtualbox.org/virtualbox/5.0.10/VirtualBox-5.0-5.0.10_104061_fedora22-1.x86_64.rpmRun virtualbox script[root@new-host-5 asleqia]# sudo /etc/init.d/vboxdrv setupStopping VirtualBox kernel modules                         [  OK  ]Uninstalling old VirtualBox DKMS kernel modules            [  OK  ]Trying to register the VirtualBox kernel modules using DKMS[  OK  ]Starting VirtualBox kernel modules                         [  OK  ][root@new-host-5 asleqia]# Add your username to the virtualbox group[root@new-host-5 asleqia]# usermod -a -G vboxusers $USERit’s all.</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">How Is Fossaegean Doing?</title>
    <id>http://fedoraplanet.org/23/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/23/" />
    <author>
      <name>Giannis Konstantinidis</name>
    </author>
    <content type="html/text">I have been enrolled at the University of the Aegean for more than two years so far. It is a multi-campus university located in six (6) Greek islands: Chios, Lemnos, Lesvos, Rhodes, Samos and Syros. The Dept. of Information &amp;amp; Communication Systems Engineering, where I'm studying, is based in the town of Karlovassi in Samos.

Since I moved into the island, one of the first things I did was to find out if there were any people around interested in free &amp;amp; open source technologies. Luckily, there was this community called fossaegean, which pretty much stands for Free &amp;amp; Open Source Software Community of the University of the Aegean. However, it was not that active back then.

Let me tell you something: I'm not just passionate about free &amp;amp; open source software, I'm crazy about it. And I certainly enjoy spreading the word about things I value. That is why, together with other people, we decided to put some effort and bring the community back to life.

Over the last two academic years, we have organized more than fourteen (14) events (mostly workshops and presentations). For this academic year we had set a goal of ten (10) events, and within three (3) months we are already past seven (7). This probably makes us one of the most (if not the most) active tech-related student communities in our university.

 During our "Intro to HTML" workshop (photo by Zacharias Mitzelos, CC BY-NC-ND).

Some of our very recent activities include: Intros to HTML &amp;amp; CSS (part of our web dev series of workshops), a Fedora 23 Release Party, an Arduino workshop and not-to-forget those great OpenBBQs. For more info regarding our Events, you can have a look at this page in our wiki. Where do all these take place? Thankfully, we have our own space provided by the university. A soon-to-be fully-equiped hackerspace I would say!

 Greek Fedora contributors, alongside people from our community, during FOSSCOMM 2015 (photo by Zacharias Mitzelos, CC BY-NC-ND).

What could you expect in the near future? Plenty of workshops, for sure. We have some interesting topics, including Android, Arduino, BASH, Bitcoin, Fedora, Firefox OS, JavaScript, Jekyll, Ruby/Ruby on Rails and many more. But it's not just about the workshops; our goal is to bring students together and do stuff. There are quite a few projects we have in mind and I really can't wait to share more details with you.

Our people are the ones that make things possible and keep the space running. A big shoutout to Christos Sotirelis, George Makrakis, Vicky Tsima, Zacharias Mitzelos and many more, who currently act as the backbone of our community.

Exciting times ahead, wish us the best of luck! :)</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Virtualbox en Fedora 23</title>
    <id>http://fedoraplanet.org/24/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/24/" />
    <author>
      <name>Carlos Morel-Riquelme</name>
    </author>
    <content type="html/text">Házlo simple.Primero actualiza tu kernel y luego reinicia[root@new-host-5 asleqia]# dnf -y update kernel &amp;amp;&amp;amp; rebootAhora instalamos las dependecias y los módulos necesarios del kernel[root@new-host-5 asleqia]# dnf -y install binutils gcc make patch libgomp glibc-headers glibc-devel dkms kernel-devel kernel-core kernel-headers kernel-modules kernel-modules-extraPaso seguido descargamos e instalamos Virtualbox32 bits[root@new-host-5 asleqia]# dnf -y install http://download.virtualbox.org/virtualbox/5.0.10/VirtualBox-5.0-5.0.10_104061_fedora22-1.i686.rpm64 bits[root@new-host-5 asleqia]# dnf -y install http://download.virtualbox.org/virtualbox/5.0.10/VirtualBox-5.0-5.0.10_104061_fedora22-1.x86_64.rpmEjecutamos el script de virtualbox ( OJO que cada vez que actualizen el kernel y los módulos deberán de volver a ejecutar el script. [root@new-host-5 asleqia]# sudo /etc/init.d/vboxdrv setupStopping VirtualBox kernel modules                         [  OK  ]Uninstalling old VirtualBox DKMS kernel modules            [  OK  ]Trying to register the VirtualBox kernel modules using DKMS[  OK  ]Starting VirtualBox kernel modules                         [  OK  ][root@new-host-5 asleqia]# Agregamos nuestro usuario al grupo de Virtualbox[root@new-host-5 asleqia]# usermod -a -G vboxusers $USERListo.</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">All systems go</title>
    <id>http://fedoraplanet.org/25/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/25/" />
    <author>
      <name>Fedora Infrastructure Status</name>
    </author>
    <content type="html/text">Service 'COPR Build System' now has status: good: Everything seems to be working.</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">A look at the kernel bisection scripts</title>
    <id>http://fedoraplanet.org/26/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/26/" />
    <author>
      <name>Laura Abbott</name>
    </author>
    <content type="html/text">I've been hacking on the bisection scripts for quite some time now.
Things got stalled for a bit in October/November. I introduced
several bugs which caused me to lose multiple days of testing verification so
I took a break and worked on other things to relieve my frustrations.
They are now at the point where they could use some testing besides my own.
Here's a walk through of what I have
F21 is going to be going EOL soon. The current (and final) kernel is
4.1.13-101.fc21. An upgrade to F23 might put you at 4.2.6-300.fc23. Upgrades
between major versions are a common point at which things break. Let's
pretend that something in the kernel broke between those two versions.
Grab a copy of the bisect scripts
$ git clone https://pagure.io/fedbisect.git
$ cd fedbisect

This contains the scripts. In order to bisect, we need copies of the git trees.
The bisect scripts will take care of this. Everything will be stored in a
subidrectory. This allows multiple
bisects to be going on at the same time. Each command will take the target
directory as an arguemnt. Generally the form will be ./fedbisect.sh &amp;lt;command&amp;gt;
&amp;lt;target dir&amp;gt;. For this example, the target name will be broken-things. The
first step is to sync the trees
$ ./fedbisect.sh sync broken-things
&amp;lt;take a  break while this syncs, it may take a while&amp;gt;

a directory named broken-things is now present. Inside the directory:
$ ls broken-things/
bisect-step  kernel  pkg-git  step-0

kernel is a clone of the tree from kernel.org, pkg-git is the fedora
repository. bisect-step and step-0 are part of the state for bisection. To
actually start a bisect between the two kernel versions
$ ./fedbisect.sh start broken-things 4.2.6-300 4.1.13-101

Note the order, it's bad tag first followed by good tag.
Behinds the scenes, this is setting up the kernel tree to run git bisect. If
you look at the kernel tree you will see exactly that:
$ cd broken-things/kernel
$ git bisect log
# bad: [1c02865136fee1d10d434dc9e3616c8e39905e9b] Linux 4.2.6
# good: [1f2ce4a2e7aea3a2123b17aff62a80553df31e21] Linux 4.1.13
git bisect start 'v4.2.6' 'v4.1.13'

Now you can build
$ ./fedbisect.sh build broken-things

This is another command that will take a long time to run. In order for these
scripts to be better than a regular bisect, the patches from Fedora need to
be applied. Figuring out which set of patches to be applied is tricky as noted
previously and brute force is still the best solution. With the exception of
a few commits in the merge window, most commits will build but if for some
reason no appropriate patches can be found, an RPM will be generated of just
the upstream version. At the end there will be a message such as
Got a build that built! Check in /home/labbott/fedbisect/broken-things/step-0 for rpms

and in that folder there will be RPMs to install (there will also be a number
of logs showing what exactly failed. Those can be ignored).
$ ls broken-things/step-0/*.rpm
broken-things/step-0/kernel-9.9.9-0.x86_64.rpm
broken-things/step-0/kernel-devel-9.9.9-0.x86_64.rpm
broken-things/step-0/kernel-headers-9.9.9-0.x86_64.rpm

The RPMs are generated from a custom kernel.spec. It's mostly the same as
the regular one but lots of stuff has been ripped out (perf, debug options,
cpu power util etc.) and it's just one big package. This was mostly for ease
of generation of the RPM. When generating snapshots, it turned out to be
a pain to figure out which filters to apply, especially if module names
changed. Copying over parts and editing where necessary seemed like an uphill
battle for not much value. The lifespan of these bisection images is going
to be very short so making the trade off for build ease and time (copying
modules takes a loooong time) seemed reasonable.  In order
to make sure the kernel will always install the version number is 9.9.9-bisect_step
so each installation step should be increasing.
Once the kernel is installed, tests can be run. When there is a result,
the build can be marked as good
$ ./fedbisect.sh good broken-things

or bad
$ ./fedbisect.sh bad broken-things

or it can be skipped if the build is untestable
$ ./fedbisect.sh skip broken-things

Now you can build again
$ ./fedbisect.sh build broken-things

and repeat marking the build as good or bad until the bisect scripts
indicate that a broken commit is found.
These scripts are still in the testing states so there may be problems.
I suspect most of them will be in the setup phase. The scripts are
available on pagure . Feedback/bug
reports/pull requests are very welcome. Suggestions for future
extensions are also welcome although I have my own list there as well.</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">There are scheduled downtimes in progress</title>
    <id>http://fedoraplanet.org/27/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/27/" />
    <author>
      <name>Fedora Infrastructure Status</name>
    </author>
    <content type="html/text">Service 'COPR Build System' now has status: scheduled: Scheduled cloud outage in progress</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">DNS for your Vagrant needs: with Landrush, libvirt and dnsmasq</title>
    <id>http://fedoraplanet.org/28/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/28/" />
    <author>
      <name>Josef Strzibny</name>
    </author>
    <content type="html/text">Have you ever needed a DNS server that would be visible both on your host and your Vagrant guests? Landrush is one of those things that can pretty much save you. Unfortunately it was designed around VirtualBox and Mac OS, so it does not work on Linux out-of-the-box. And it does not work with libvirt provider at all. Until of course recently since I added the support there. Here is how to make all that work together on Fedora.
First things first — my libvirt patch is not yet merged, so you will have to build Landrush yourself. Check out my fork of Landrush and build the plugin with rake build, than you can install it with vagrant plugin install command:
$ bundle
$ bundle exec rake build
$ vagrant plugin install ./pkg/landrush-0.18.0.gem

This expects you to have Bundler and Vagrant installed. If you don’t, check Fedora Developer Portal and learn how to do it.
Now you should be able to run Landrush and it should work just fine for your guests. To confirm that Landrush is running run vagrant landrush status. Let’s make it work on Linux host too! On Mac OS Landrush adds entries in /etc/resolver, unfortunately that won’t work on Linux. That’s why I put dnsmasq in the title of this post.
We can tell dnsmasq to listen on 127.0.0.1 (localhost) and make an entry to redirect requested domain names (such as all ending with .dev or .local for example) to our Landrush DNS server (which runs on localhost too, but on port 10053 instead of standard 53). Let’s do it:
Add the following to /etc/dnsmasq.conf:
listen-address=127.0.0.1

And create a following file to redirect our .local domains traffic to Landrush:
$ cat /etc/dnsmasq.d/vagrant-landrush 
address=/.local/127.0.0.1#10053

Now let’s try to start dnsmasq service:
$ sudo systemctl start dnsmasq.service 
$ sudo systemctl status dnsmasq.service 
● dnsmasq.service - DNS caching server.
   Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sun 2015-11-29 10:13:17 CET; 4s ago
  Process: 26654 ExecStart=/usr/sbin/dnsmasq -k (code=exited, status=2)
 Main PID: 26654 (code=exited, status=2)

Nov 29 10:13:17 strzibny-x1 systemd[1]: Started DNS caching server..
Nov 29 10:13:17 strzibny-x1 systemd[1]: Starting DNS caching server....
Nov 29 10:13:17 strzibny-x1 dnsmasq[26654]: dnsmasq: failed to create listening socket for port 53: Address already in use
Nov 29 10:13:17 strzibny-x1 systemd[1]: dnsmasq.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Nov 29 10:13:17 strzibny-x1 systemd[1]: Unit dnsmasq.service entered failed state.
Nov 29 10:13:17 strzibny-x1 systemd[1]: dnsmasq.service failed.

Oh no. It seems that we have a conflict here. This is because libvirt actually starts dnsmasq for your domains as well automatically.
We can fix it by telling the system version of dnsmasq to bind to specific interfaces. Open the /etc/dnsmasq.conf again and list only the interfaces you need (and don’t conflict):
listen-address=127.0.0.1
...
# on my system
interface=wlp4s0
bind-interfaces

The service should start just fine afterwards. Let’s see if we can resolve our host:
$ host site.local
Host site.local not found: 3(NXDOMAIN)

We have dnsmasq set up, but it’s not used. For that we need to edit /etc/resolv.conf and add our new name server:
nameserver 127.0.0.1
...

Is this working?
$ host site.local
site.local has address 127.0.0.1

Great! Can we ping it yet? Yes and no. If you went with .dev domain name, you are fine, but if you went with my changes and setup .local instead, ping won’t see your new settings. This is because of Avahi.
To change the domain for Avahi from .local, edit the avahi-daemon.conf configuration file and restart avahi-daemon:
$ cat /etc/avahi/avahi-daemon.conf
[server]
domain-name=.something_else_than_local
...

$ sudo systemctl restart avahi-daemon

If you don’t really need Avahi, you can also change the following in nsswitch.conf:
$ cat /etc/nsswitch.conf
...
#hosts:          files mdns4_minimal [NOTFOUND=return] dns
hosts:          files dns

Now you can ping your development hostnames and they should be redirected to your VM by dnsmasq and Landrush.
If you want to check that it works alongside port forwarding, you can tell Vagrant to forward port 8080 from your host to 8000 on your guest and run simple HTTP server there:
# cat Vagrantfile
...
  config.vm.network "forwarded_port", guest: 8000, host: 8080

  # Fedora 23 example
  config.vm.provision "shell", inline: &amp;lt;&amp;lt;-SHELL
     python3 -m http.server &amp;amp;
  SHELL
...

Afterwards you can open your browser or use curl:
$ curl http://site.local:8080
&amp;lt;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"&amp;gt;
&amp;lt;html&amp;gt;
&amp;lt;head&amp;gt;
&amp;lt;meta http-equiv="Content-Type" content="text/html; charset=utf-8"&amp;gt;
&amp;lt;title&amp;gt;Directory listing for /&amp;lt;/title&amp;gt;
&amp;lt;/head&amp;gt;
&amp;lt;body&amp;gt;
&amp;lt;h1&amp;gt;Directory listing for /&amp;lt;/h1&amp;gt;
&amp;lt;hr&amp;gt;
&amp;lt;ul&amp;gt;
&amp;lt;li&amp;gt;&amp;lt;a href=".bash_history"&amp;gt;.bash_history&amp;lt;/a&amp;gt;&amp;lt;/li&amp;gt;
&amp;lt;li&amp;gt;&amp;lt;a href=".bash_logout"&amp;gt;.bash_logout&amp;lt;/a&amp;gt;&amp;lt;/li&amp;gt;
&amp;lt;li&amp;gt;&amp;lt;a href=".bash_profile"&amp;gt;.bash_profile&amp;lt;/a&amp;gt;&amp;lt;/li&amp;gt;
&amp;lt;li&amp;gt;&amp;lt;a href=".bashrc"&amp;gt;.bashrc&amp;lt;/a&amp;gt;&amp;lt;/li&amp;gt;
&amp;lt;li&amp;gt;&amp;lt;a href=".ssh/"&amp;gt;.ssh/&amp;lt;/a&amp;gt;&amp;lt;/li&amp;gt;
&amp;lt;/ul&amp;gt;
&amp;lt;hr&amp;gt;
&amp;lt;/body&amp;gt;
&amp;lt;/html&amp;gt;
</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">FESCo Elections: Interview with Adam Miller (maxamillion)</title>
    <id>http://fedoraplanet.org/29/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/29/" />
    <author>
      <name>Fedora Community Blog</name>
    </author>
    <content type="html/text">Fedora Engineering Steering Council badge</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Freeswitch vs. Asterisk?</title>
    <id>http://fedoraplanet.org/30/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/30/" />
    <author>
      <name>Jonathan Dieter</name>
    </author>
    <content type="html/text">VOIP of the highest quality</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">FESCo Elections: Interview with Justin Forbes (jforbes)</title>
    <id>http://fedoraplanet.org/31/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/31/" />
    <author>
      <name>Fedora Community Blog</name>
    </author>
    <content type="html/text">Fedora Engineering Steering Council badge</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">FAmSCo Elections: Interview with Ben Williams (Southern_Gentlem / kk4ewt)</title>
    <id>http://fedoraplanet.org/32/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/32/" />
    <author>
      <name>Fedora Community Blog</name>
    </author>
    <content type="html/text">Fedora Ambassador Steering Committee badge</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Install SimpleScreenRecorder in Fedora</title>
    <id>http://fedoraplanet.org/33/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/33/" />
    <author>
      <name>Carlos Morel-Riquelme</name>
    </author>
    <content type="html/text">Make simpleAdd the russianfedora repositorysudo
 dnf install 
http://mirror.yandex.ru/fedora/russianfedora/russianfedora/free/fedora/russianfedora-free-release-stable.noarch.rpm
 
http://mirror.yandex.ru/fedora/russianfedora/russianfedora/nonfree/fedora/russianfedora-nonfree-release-stable.noarch.rpmNow install SSRsudo dnf install -y simplescreenrecorderit’s all.</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Instala Simplescreenrecorder en Fedora</title>
    <id>http://fedoraplanet.org/34/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/34/" />
    <author>
      <name>Carlos Morel-Riquelme</name>
    </author>
    <content type="html/text">Simple.Agreguen el repositorio del remix ruso de Fedorasudo dnf install http://mirror.yandex.ru/fedora/russianfedora/russianfedora/free/fedora/russianfedora-free-release-stable.noarch.rpm http://mirror.yandex.ru/fedora/russianfedora/russianfedora/nonfree/fedora/russianfedora-nonfree-release-stable.noarch.rpmInstalen SSRsudo dnf install -y simplescreenrecorderEs todo.</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Where is the physical trust boundary?</title>
    <id>http://fedoraplanet.org/35/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/35/" />
    <author>
      <name>Josh Bressers</name>
    </author>
    <content type="html/text">There's a story of a toothbrush security advisory making the rounds.This advisory is pretty funny but it matters. The actual issue with the toothbrush isn't a huge deal, an attacker isn't going to do anything exciting with the problems. The interesting issue here is we're at the start of many problems like this we're going to see.Today some engineers built a clever toothbrush. Tomorrow they're going to build new things, different things. Security will matter for some of them. It won't matter for most of them.Boundaries of trust</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">I support Software Freedom Conservancy</title>
    <id>http://fedoraplanet.org/36/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/36/" />
    <author>
      <name>Ben Cotton</name>
    </author>
    <content type="html/text">If you’ve read this blog for any length of time, you know that free and open source software is important to me. It’s important to Software Freedom Conservancy as well. Conservancy is a 501(c)(3) organization dedicated to supporting software projects.
Conservancy provides a lot of services to member projects, including financial and administrivia. Conservancy also provides license enforcement services, including support of a high-profile suit against VMWare. Although Conservancy uses litigation as a last resort, it’s sometimes necessary. However, this has lead to some corporate sponsors pulling their funding.
In order to continue their efforts, Conservancy is moving to an individual-supporter model. I first became a Conservancy supporter last year, and when it’s shortly time to renew my support, I will contribute double. Free and open source software is important to my personal and professional lives, and the services Conservancy provide to projects is invaluable.
If you use computers at all, a Conservancy project is probably an important part of your daily life. Please join me in supporting the Software Freedom Conservancy with a tax-deductible* donation today.
*Consult your tax professional to see if donations are tax-deductible in your jurisdiction.</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Blivet-gui 1.0 in Fedora 23</title>
    <id>http://fedoraplanet.org/37/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/37/" />
    <author>
      <name>Vojtech Trefny</name>
    </author>
    <content type="html/text">Blivet-gui, a graphical tool for storage management, reached an important milestone -- version 1.0 (blivet-gui 1.0 was actually already released in September and it took me more than two months to write this blog post, the latest version available in rawhide is 1.2).
So what's new since the previous blog post? Obviously, there is the new UI. The visualization in case of more complicated storage configuration is still not as good as I want, but so far I have not found any solution that would make it less complicated for configurations working with many devices. My testing machine has 25 disks with more than 20 different LVM volume groups, software RAIDs and BTRFs volumes and it's sometimes quite hard not to be confused even with the new UI.

New UI -- visualization of disk with an extended partition and "c" LVM volume group

New UI -- visualization of physical volumes of "c" LVM volume group
If you have any ideas that would make the UI and visualization better, feel free to contact me.
Other new features besides the new UI were added - some more visible, some less:

It is now possible to "force" create extended or primary partition. In previous versions of blivet-GIU, the fourth partition was always created as logical inside an extended partition.


Added support for LVM snapshots and LVM ThinProvisioning.


Simple progress is displayed when running scheduled actions.


You can specify PE size when creating an LVM Volume Group.


Blivet-gui is now Python 3 only.


I have created an (temporary) icon for blivet-gui. And I have also added AppData for blivet-gui, so it will be available in GNOME Software.

Future of blivet-gui
Blivet-gui now has all planned features. There are some small "nice-to-have" things, but new features for future versions of blivet-gui will depend on new features of blivet. Blivet now prepares for a new big release "2.0" with a lot of changes in API and code and many new features. Already implemented ones include support for LVM cache and LVM RAID (thanks to Vratislav Podzimek for implementing these). The LVM cache support is actually implemented in blivet-gui (but not yet released).

Adding cached LVM logical volume in blivet-gui
Daily builds
If you'd like to keep track with new features, you can use my Copr repo with daily builds of blivet-gui, blivet and other projects of our team (including Anaconda).
As always, if you'd like to help, the source code is available on GitHub. New ideas and bug reports are welcome as well. Visit Zanata if you'd like to help with blivet-gui localization.
</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Creating a laser light show with Fedora</title>
    <id>http://fedoraplanet.org/38/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/38/" />
    <author>
      <name>Fedora Magazine</name>
    </author>
    <content type="html/text">Every day, people are making all kinds of incredible software powered by Fedora. The Fedora user community is broad and diverse, and sometimes, we hear about things that we never imagined possible. Rochester Institute of Technology student and Fedora user Brendan Whitfield developed an open-source library for interfacing with laser projectors to create all kinds of awesome images and animations using lasers (including the Fedora logo)! We wanted to know more about the work Brendan was doing and interviewed him about his project, LZR.

Impacting laser development with open-source
Brendan has always had a fascination for lasers.</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Gotta Badge ‘Em All: Telegraphist</title>
    <id>http://fedoraplanet.org/39/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/39/" />
    <author>
      <name>Justin W. Flory</name>
    </author>
    <content type="html/text">Telegraphist: What is it?
“You mapped an upstream project to a Fedora package on release-monitoring.org“</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Support Software Freedom Conservancy</title>
    <id>http://fedoraplanet.org/40/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/40/" />
    <author>
      <name>Emmanuel Seyman</name>
    </author>
    <content type="html/text">As some of you may know, Software Freedom
Conservancy (SFC) has announced a "Supporter"
program, allowing individuals to make a donation to SFC's general operating
fund, helping them to do the things they do. Since I'm a huge fan of the work
that SFC does, I've decided to become a supporter and I encourage others to do
the same.</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">What is hacker culture?</title>
    <id>http://fedoraplanet.org/41/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/41/" />
    <author>
      <name>Matthew Garrett</name>
    </author>
    <content type="html/text">Eric Raymond, author of The Cathedral and the Bazaar (an important work describing the effectiveness of open collaboration and development), recently wrote a piece calling for "Social Justice Warriors" to be ejected from the hacker community. The primary thrust of his argument is that by calling for a removal of the "cult of meritocracy", these SJWs are attacking the central aspect of hacker culture - that the quality of code is all that matters.This argument is simply wrong.Eric's been involved in software development for a long time. In that time he's seen a number of significant changes. We've gone from computers being the playthings of the privileged few to being nearly ubiquitous. We've moved from the internet being something you found in universities to something you carry around in your pocket. You can now own a computer whose CPU executes only free software from the moment you press the power button. And, as Eric wrote almost 20 years ago, we've identified that the "Bazaar" model of open collaborative development works better than the "Cathedral" model of closed centralised development.These are huge shifts in how computers are used, how available they are, how important they are in people's lives, and, as a consequence, how we develop software. It's not a surprise that the rise of Linux and the victory of the bazaar model coincided with internet access becoming more widely available. As the potential pool of developers grew larger, development methods had to be altered. It was no longer possible to insist that somebody spend a significant period of time winning the trust of the core developers before being permitted to give feedback on code. Communities had to change in order to accept these offers of work, and the communities were better for that change.The increasing ubiquity of computing has had another outcome. People are much more aware of the role of computing in their lives. They are more likely to understand how proprietary software can restrict them, how not having the freedom to share software can impair people's lives, how not being able to involve themselves in software development means software doesn't meet their needs. The largest triumph of free software has not been amongst people from a traditional software development background - it's been the fact that we've grown our communities to include people from a huge number of different walks of life. Free software has helped bring computing to under-served populations all over the world. It's aided circumvention of censorship. It's inspired people who would never have considered software development as something they could be involved in to develop entire careers in the field. We will not win because we are better developers. We will win because our software meets the needs of many more people, needs the proprietary software industry either can not or will not satisfy. We will win because our software is shaped not only by people who have a university degree and a six figure salary in San Francisco, but because our contributors include people whose native language is spoken by so few people that proprietary operating system vendors won't support it, people who live in a heavily censored regime and rely on free software for free communication, people who rely on free software because they can't otherwise afford the tools they would need to participate in development.In other words, we will win because free software is accessible to more of society than proprietary software. And for that to be true, it must be possible for our communities to be accessible to anybody who can contribute, regardless of their background.Up until this point, I don't think I've made any controversial claims. In fact, I suspect that Eric would agree. He would argue that because hacker culture defines itself through the quality of contributions, the background of the contributor is irrelevant. On the internet, nobody knows that you're contributing from a basement in an active warzone, or from a refuge shelter after escaping an abusive relationship, or with the aid of assistive technology. If you can write the code, you can participate.Of course, this kind of viewpoint is overly naive. Humans are wonderful at noticing indications of "otherness". Eric even wrote about his struggle to stop having a viscerally negative reaction to people of a particular race. This happened within the past few years, so before then we can assume that he was less aware of the issue. If Eric received a patch from someone whose name indicated membership of this group, would there have been part of his subconscious that reacted negatively? Would he have rationalised this into a more critical analysis of the patch, increasing the probability of rejection? We don't know, and it's unlikely that Eric does either.Hacker culture has long been concerned with good design, and a core concept of good design is that code should fail safe - ie, if something unexpected happens or an assumption turns out to be untrue, the desirable outcome is the one that does least harm. A command that fails to receive a filename as an argument shouldn't assume that it should modify all files. A network transfer that fails a checksum shouldn't be permitted to overwrite the existing data. An authentication server that receives an unexpected error shouldn't default to granting access. And a development process that may be subject to unconscious bias should have processes in place that make it less likely that said bias will result in the rejection of useful contributions.When people criticise meritocracy, they're not criticising the concept of treating contributions based on their merit. They're criticising the idea that humans are sufficiently self-aware that they will be able to identify and reject every subconscious prejudice that will affect their treatment of others. It's not a criticism of a desirable goal, it's a criticism of a flawed implementation. There's evidence that organisations that claim to embody meritocratic principles are more likely to reward men than women even when everything else is equal. The "cult of meritocracy" isn't the belief that meritocracy is a good thing, it's the belief that a project founded on meritocracy will automatically be free of bias.Projects like the Contributor Covenant that Eric finds so objectionable exist to help create processes that (at least partially) compensate for our flaws. Review of our processes to determine whether we're making poor social decisions is just as important as review of our code to determine whether we're making poor technical decisions. Just as the bazaar overtook the cathedral by making it easier for developers to be involved, inclusive communities will overtake "pure meritocracies" because, in the long run, these communities will produce better output - not just in terms of the quality of the code, but also in terms of the ability of the project to meet the needs of a wider range of people.The fight between the cathedral and the bazaar came from people who were outside the cathedral. Those fighting against the assumption that meritocracies work may be outside what Eric considers to be hacker culture, but they're already part of our communities, already making contributions to our projects, already bringing free software to more people than ever before. This time it's Eric building a cathedral and decrying the decadent hordes in their bazaar, Eric who's failed to notice the shift in the culture that surrounds him. And, like those who continued building their cathedrals in the 90s, it's Eric who's now irrelevant to hacker culture.(Edited to add: for two quite different perspectives on why Eric's wrong, see Tim's and Coraline's posts) comments</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Software Freedom Conservancy</title>
    <id>http://fedoraplanet.org/42/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/42/" />
    <author>
      <name>Mark J. Wielaard</name>
    </author>
    <content type="html/text">I support the Software Freedom Conservancy because they provide a virtual home for Free Software communities. In their own words:
Software Freedom Conservancy is a not-for-profit organization that helps promote, improve, develop, and defend Free, Libre, and Open Source Software (FLOSS) projects. Conservancy provides a non-profit home and infrastructure for FLOSS projects. This allows FLOSS developers to focus on what they do best — writing and improving FLOSS for the general public — while Conservancy takes care of the projects’ needs that do not relate directly to software development and documentation.
Some projects receive support from or are managed by companies or trade associations that benefit from the software the community produces. That is great as long as the community objectives and the company profit motives are aligned. Free Software is a good way for companies to work together. The services that the Conservancy provides allows projects to define their own terms and conditions for the community to work together. And companies can then join on equal terms. Making sure the project and community will work together for the public benefit.
Please support the Software Freedom Conservancy by donating so they will be able to provide a home to many more communities. A donation of 10 US dollars a month will make you an official sponsor. Or donate directly to one of their many member projects.
Software Freedom Conservancy Member Projects</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Inspecting Method Arguments in Python</title>
    <id>http://fedoraplanet.org/43/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/43/" />
    <author>
      <name>Alexander Todorov</name>
    </author>
    <content type="html/text">How do you execute methods from 3rd party classes in a backward compatible
manner when these methods change their arguments ?
s3cmd's PR #668 is an example
of this behavior, where python-libs's httplib.py added a new parameter
to disable hostname checks. As a result of this
s3cmd broke.
One solution is to use try-except and nest as much blocks as you need to cover
all of the argument variations. In s3cmd's case we needed two nested try-except
blocks.
Another possibility is to use the
inspect module and create the argument
list passed to the method dynamically, based on what parameters are supported.
Depending on the number of parameters this may or may not be more elegant than
using try-except blocks although it looks to me a bit more human readable.
The argument list is a member named co_varnames of the code object. If you
want to get the members for a function then
inspect.getmembers(my_function.__code__)
</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Qt testing packages for Fedora and Epel on copr</title>
    <id>http://fedoraplanet.org/44/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/44/" />
    <author>
      <name>Helio Chissini de Castro</name>
    </author>
    <content type="html/text">We’re ( kde-sig ) trying slowly improve the quality of Fedora KDE and Qt, and is a lot of work. Some of the members even got to new jobs reducing the time to deal as “life” happens, which makes the work harder. Rex Dieter, our fearless ( and reasonable ) leader do a fantastic 100 people work, but still, we have enough to 100+n persons. So anything that can reduce the test time and the burden on the process are a necessary solution.
Some can arg that rawhide is a test place, and they are right, but is for a devel future, not for a soon to be stable set of packages. And we’re hardly see people using rawhide on production aside us in some very very very restricted cases and most of all, in virtual machines, not bare metal.
Then we can go to the -testing repo, which leads to Fedora buildsystem, that not helps much as every new package submitted need rely of someone say’s ok to testing stage or worst, wait minimum 7 days until reach the servers.
And is not testing per se, as if we wait for 7 days without anyone really tested the package and reach the stable with a bad version, so we’re be double screwed.
So, for example, in a few days we will have Qt 5.6.0 rc and we want that people have it as soon as possible in their machines as soon it reaches the final if possible on the release day been in our default repositories, and avoid the now more common annoyed people saying that the other ** distro already has it or why it takes so long blaming us lazy packagers.
The solution ? kde-sig Copr group ! The recent upgrade on copr allow us to have groups instead of individuals, and now this leads to current Qt repo.
With the blessing of Dan Vratil, i took his original repository and recreated over Qt5 KDE Sig Copr Repo with most current Qt possible.
You will find now 5.6.0 beta available for rawhide, f23, f22 and Epel-7 restricted on f23 and f22 to x86_64 due a build bug on i386 chroots from copr ( a segfault that we’re not managed to find ).
Still missing the qtwebengine package due the work to remove included 3rdparty source to bind to Fedora policies, and this is a hard work, even simplified a lot by Qt devs ( thanks to Allan )
So, we’re open to “business” and if you think we can improve Fedora, any ideas are welcome. 
Reinforcing: KDE Sig Copr place</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Setting up IPA with a specific CA cert subject</title>
    <id>http://fedoraplanet.org/45/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/45/" />
    <author>
      <name>Luc de Louw</name>
    </author>
    <content type="html/text">If you are doing experiments with IPA where you install and reinstall IPA servers, you may notice SSL certificate errors when connecting to an IPA server using Firefox. The reason is that always the same Organization and serial is used when the CA cert is created. Normal users are usually only affected when using the […]</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">QElectroTech version 0.5</title>
    <id>http://fedoraplanet.org/46/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/46/" />
    <author>
      <name>Remi Collet</name>
    </author>
    <content type="html/text">RPM of QElectroTech version 0.5, an application to design electric diagrams, are available in remi for Fedora and Enterprise Linux 7.    Only 9 months after the version 0.4 release, the project have just released a new major version of their electric diagrams editor.Official web site : http://qelectrotech.org/ and version announcement.Installation by YUM :yum --enablerepo=remi install qelectrotechRPM (version 0.50-1) are available for Fedora ≥ 19 and Enterprise Linux 7 (RHEL, CentOS, ...)Updates are also on the road to official repositoriesFedora 23Fedora 22RHEL / CentOS 7Notice :a Copr / Qelectrotech repository also exists, which provides "development" versions (also 0.5 for now).</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Disabling Dynamic Currency Conversion (DCC) in Airbnb</title>
    <id>http://fedoraplanet.org/47/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/47/" />
    <author>
      <name>Daniel Pocock</name>
    </author>
    <content type="html/text">In many travel-related web sites for airlines and hotels, there is some attempt to sting the customer with an extra fee by performing a currency conversion at an inflated exchange rate.  Sometimes it is only about five percent and this may not appear to be a lot but in one case a hotel was trying to use a rate that increased the cost of my booking by 30%.  This scheme/scam is referred to as Dynamic Currency Conversion (DCC).  Sometimes the website says that they are making it "easy" for you by giving you a "guaranteed" exchange rate that "might" be better than the rate from your bank.  Sometimes a hotel or restaurant in a tourist location insists that you have to pay in a currency that is not the same as the currency on your booking receipt or their menu card, this is also a DCC situation.
Reality check: these DCC rates are universally bad.  Last time I checked, my own credit card only has a 0.9% fee for currency conversion.  Credit card companies have become a lot more competitive but the travel industry hasn't.
Airbnb often claims that they want to help the little guy and empower people, at least that is the spin they were using when New York city authorities were scrutinizing their business model.  Their PR blog tries to boast about the wonderful economic impact of Airbnb.
But when it comes to DCC, the economic impact is universally bad for the customer and good for Airbnb's bosses.  Most sites just turn on DCC by default and add some little opt-out link or checkbox that you have to click every time you book.  Airbnb, however, is flouting regulations and deceiving people by trying to insist that you can't manually choose the currency you'll use for payment.
Fortunately, Visa and Mastercard have insisted that customers do have the right to know the DCC exchange rate and choose not to use DCC.
What are the rules?
Looking at the Visa system, the Visa Product and Service Rules, page 371, s5.9.7.4 include the statement that the merchant (Airbnb) must "Inform the Cardholder that Dynamic Currency Conversion is optional".
The same section also says that Airbnb must "Not use any language or procedures that may cause the Cardholder to choose Dynamic Currency Conversion by default".  When you read the Airbnb help text about currencies, do you think the language and procedures there comply with Visa's regulations?
What does Airbnb have to say about it?
I wrote to Airbnb to ask about this.  A woman called Eryn H replied "As it turns out we cannot provide our users with the option to disable currency conversion."
She went on to explain "When it comes to currency converting, we have to make sure that the payments and payouts equal to be the same amount, this is why we convert it as well as offer to convert it for you. We took it upon ourselves to do this for our users as a courtesy, not so that we can inconvenience any users.".  That, and the rest of Eryn's email, reads like a patronizing copy-and-paste response that we've all come to dread from some poorly trained customer service staff these days.
Miss H's response also includes this little gem: "Additionally, if you pay in a currency that’s different from the denominated currency of your payment method, your payment company (for example, your credit or bank card issuer) or third-party payment processor may apply a currency conversion rate or fees to your payment. Please contact your provider for information on what rates and fees may apply as these are not controlled by or known to Airbnb." and what this really means is that if Airbnb forces you to use a particular currency, with their inflated exchange rate and that is not the currency used by your credit card then you will have another currency conversion fee added by your bank, so you suffer the pain of two currency conversions.  This disastrous scenario comes about because some clever person at Airbnb wanted to show users a little "courtesy", as Miss H describes it.
What can users do?
As DCC is optional and as it is not clear on the booking page, there are other things a user can do.
At the bottom of the Airbnb page you can usually find an option to view prices in a different currency.  You can also change your country of residence in the settings to ensure you view prices in the host currency.  This allows you to see the real price, without the DCC steal.
People have been able to email or call Airbnb and have DCC disabled for their account.  Not all their telephone staff seem to understand these requests and apparently it is necessary to persist and call more than once.  In the long term, the cost savings outweigh the time it may take even if you spend 20 minutes on the phone getting it fixed.
Whatever you do, with any travel site, print a copy of the information page showing the price in host currency.  After doing that for an Airbnb booking and before making any payment, send a message to the host quoting the total price in their currency and stating DCC is not authorized.  If Airbnb does wrongly convert the currency, send a letter to the credit card company asking for a full refund/chargeback on the basis that the transaction in the wrong currency was not an authorized transaction.  It is important to ensure that you do not agree to the payment using Verified-by-Visa or Mastercard Securecode and do not pay with a debit card as these things can undermine your chances of a successful chargeback.
The chargeback rules are very clear about this.  On the Visa website, the Guide for the Lodging Industry describes all the chargeback reason codes.  On page 46, reason code 76 is described for cases such as these:
Cardholder was not advised that Dynamic Currency Conversion (DCC) would occur
Cardholder was refused the choice of paying in the merchant’s local currency
If you feel that Airbnb's web site was not operating in compliance with these rules, while many other web sites have made the effort to do so, why shouldn't you demand a correction by your bank?  Once enough people do this, don't be surprised if Airbnb fixes their site.
</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Custom keyboard shortcuts for Evolution in GNOME</title>
    <id>http://fedoraplanet.org/48/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/48/" />
    <author>
      <name>Major Hayden</name>
    </author>
    <content type="html/text">I’ve been a big fan of Thunderbird for years, but it lacks features in some critical areas.  For example, I need Microsoft Exchange and Google Apps connectivity for my mail and contacts, but Thunderbird needs some extensions to make that connectivity easier.  There are some great extensions available, but they lack polish since they’re not part of the core product.
My muscle memory for keyboard shortcuts in Thunderbird left me fumbling in Evolution.  Some of the basics that I used regularly, such as writing a new email or collapsing/expanding threads, were wildly different.  For example, there’s no keyboard shortcut for expanding threads in Evolution by default.
The search
In my quest to adjust some of the default keyboard shortcuts for Evolution, I found lots of documentation about previous versions of GNOME in documentation and countless forum posts.  None of the old tricks, like editable menus and easily adjusted dconf settings, work any longer.
I stumbled onto an email thread from August 2015 on this very topic and I was eager to find out if GNOME 3.18’s Evolution would look at the same .config/evolution/accels file as the one mentioned in the thread.
First, I started Evolution with strace so I could review the system calls made during its startup:

strace -q -o evolution-trace.out -s 1500 evolution</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">The goats have strayed into GNOME</title>
    <id>http://fedoraplanet.org/49/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/49/" />
    <author>
      <name>Debarshi Ray</name>
    </author>
    <content type="html/text">Here is a glimpse of what I have been doing lately.


The screenshots feature the photo please wait… by Garrett LeSage available under a Creative Commons Attribution-ShareAlike license.   </content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Hurry up, only a few days left to do the 2015 Gluster Community Survey</title>
    <id>http://fedoraplanet.org/50/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/50/" />
    <author>
      <name>Niels de Vos</name>
    </author>
    <content type="html/text">The Gluster Community provides packages for Fedora, CentOS, Debian, Ubuntu, NetBSD and other distributions. All users are important to us, and we really like to hear how Gluster is (not?) working out for you, or what improvements are most wanted. It is easy to pass this information (anonymously) along through this years survey (it's a Google form). If you would like to comment on the survey itself, please get in touch with Amye.</content>
  </entry>
  <entry xml:base="http://fedoraplanet.org/">
    <title type="text">Forum PHP in Paris 2015</title>
    <id>http://fedoraplanet.org/51/</id>
    <updated>2015-12-03T07:45:42Z</updated>
    <link href="http://fedoraplanet.org/51/" />
    <author>
      <name>Remi Collet</name>
    </author>
    <content type="html/text">Back from Forum PHP Paris 2015.First, a huge thanks to AFUP for the organization of this great event, as always, reception was beyond reproach.This event was, once more, a great opportunity for many and rewarding meetings with lot of  PHP developers and users.This year was exceptional, because PHP is 20 years old, AFUP is 15 years old and of course because of upcoming  PHP version 7:&amp;lt;figure style="{figureStyle}"&amp;gt;&amp;lt;figcaption&amp;gt; &amp;lt;/figcaption&amp;gt;&amp;lt;/figure&amp;gt;On the photo : (top) Derick Rethans, Anatol Belski, me, Zeev Suraski, (bottom) Pierre Joye, Rasmus Lerdorf, Bob Weinand and Nikita Popov.More photos on Flickr.I had the change to give a talk about collaboration between upstream (projects) and downstream (distribution) with an important part about QA management by the Fedora project.Read the slides: Paris2015.pdf.Feedback seems good, see joind.id.I waiting for next meetings.</content>
  </entry>
</feed>
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title type="text">Planet gnhome</title>
  <id>http://planet.gnome.org/</id>
  <updated>2015-12-03T07:45:44Z</updated>
  <link href="http://planet.gnome.org/" />
  <link href="http://planet.gnome.org/" rel="self" />
  <author>
    <name></name>
  </author>
  <subtitle type="text">http://planet.gnome.org/</subtitle>
  <generator>PyAtom</generator>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Fighting For Social Justice Is a Major Contribution to Society</title>
    <id>http://fedoraplanet.org/2/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/2/" />
    <author>
      <name>Bradley M. Kuhn(bkuhn)</name>
    </author>
    <content type="html/text">I have something to say that I'm sure everyone is going to consider
          controversial.  I've been meaning to say it for some time, and I realize
          that it's going to get some annoyance from all sides of this debate.
          Conservancy may lose
          Supporters over this,
          even though this is my personal blog and my personal opinion, and views
          expressed here aren't necessarily Conservancy's views.  I've actually been
          meaning to write this publicly for a year.  I just have to say it now,
          because there's yet another event on this issue caused yet another a war of
          words in our community.
        
        If you follow the types of Free Software politics and issues that I do
          (which you probably do if you read my blog) you have heard the phrase
          — which has become globally common in general politics —
          “Social Justice Warrior”, often abbreviated SJW.  As anyone who
          reads my blog probably already knows, SJW is used as a derogatory catch-all
          phrase referring to anyone who speaks up to on any cause, but particularly
          on racial or gender inequality.  While the derogatory part seems
          superficially to refer to tactics rather than strategic positions,
          nevertheless many critics who use the phrase conflate (either purposely or
          not) some specific, poorly-chosen tactic (perhaps from long ago) of the few
          with the strategic goals of an entire movement.
        
        Anyway, my argument in this post, which is why I expect it to annoy
          everyone equally, is not about some specific issue in any cause, but on a
          meta-issue.  The meta-issue is the term “SJW” itself.  The
          first time I heard the phrase (which, given my age, feels recent, even
          though it was probably four years ago), I actually thought it was something
          good; I first thought that SJW was a compliment.  In fact, I've
          more-or-less spent my entire adult life wanting to be a
          social justice warrior, although I typically called it being a
          “social justice activist”.
        
        First of all, I believe deeply in social justice causes.  I care about
          equality, fairness, and justice for everyone.  I believe software freedom is a
          social justice cause, and I personally have proudly called software freedom
          a social justice cause for more than a decade.
        
        Second, I also believe in the zealous pursuit of causes that matter.  I've
          believed fully and completely in non-violence since the mid-1980s, but I
          nevertheless believe there is a constant war of words in the politics
          surrounding any cause or issue, including software freedom.  I am,
          therefore — for lack of a better word — a warrior, in those
          politics.
        
        So, when I look at the three words on their face: Social.  Justice.
        Warrior.  Well, denotively, it describes my lifelong work exactly.
        
        Connotatively, a warped and twisted manipulation of words has occurred.
          Those who want to discredit the validity that various social justice causes
          have bestowed a negative connotation on the phrase to create a social
          environment that makes anyone who wants to speak out about a cause
          automatically wrong and easily branded.
        
        I've suggested to various colleagues privately over the last two years
          that we should coopt the phrase back to mean something good.  Most
          have said that's a waste of time and beside the point.  I still wonder
          whether they're right.
        
        By communicating an idea that these social justice people are fighting
          against me and oppressing me, the messenger accusing a so-called SJW
          has a politically powerful, well-coopted message, carefully constructed for
          concision and confirmation bias.  While I don't believe all that cooptive
          and manipulative power is wielded solely in the one three-word phrase, I do
          believe that the rhetorical trick that allows “SJW” to have a
          negative connotation is the same rhetorical power that has for centuries
          allowed the incumbent power structures to keep their control of those many
          social institutions that are governed chiefly by rhetoric.
        
        And this is precisely why I just had to finally post something about this.
          I won a cultural power jackpot, merely by being born a middle-class
          Caucasian boy in the USA.  Having faced some adversity in my life despite
          that luck, and then seeing how easy I had it compared to the adversity that
          others have faced, I become furious at how the existing power structures
          can brand people with — let's call it what is — a sophisticated
          form of name-calling that coopts a phrase like “social
          justice”, which until that time had a history of describing some of
          the greatest, most selfless, and most important acts of human history.
        
        Yes, I know there are bigger issues at stake than just the words people
          use.  But words matter.  No matter how many people use the phrase
          negatively, I continue to strive to be a social justice warrior.  I believe
          that's a good thing, in the tradition of all those who have fought for a
          cause they believed was right, even when it wasn't popular.
        
        				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">content apps hackfest 2015 day 1</title>
    <id>http://fedoraplanet.org/3/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/3/" />
    <author>
      <name>Bastian Ilsø Hougaard(bastianilso)</name>
    </author>
    <content type="html/text">Thanks to GNOME I’m attending the content apps hackfest. Today started with some introductionary some discussion on  the individual applications, Documents, Books, Videos, Photos and Music. GNOME contributors also attended through hangouts and we managed to cover quite some ground in terms of what the content apps needs and their scope. We are around 13 in total sitting at Medialab, typing away on the keyboards now.
One of the bullets this hackfest is about which I am particularly interested in is how we attract more contributors to the content apps. IMO first step is to make it easy for new developers to start contributing. So I spent the afternoon revamping GNOME Documents’ wiki app page. Photos and Music are also listed as newcomer-friendly apps and would likely need a similar makeover.

For tomorrow I want to start looking into what newcomer bugs are filed against the content apps and possibly file more primarily, though. 
Outside of the hackfest I have also worked a bit Polari. In the airport I sat down to revamp my status hiding branch which is almost fully working. I was also super pleased to hear that Carlos Garnacho had worked on a tracker miner for Polari’s chat logs which means we hopefully can implement some much-needed search history functionality.
Hugs to GNOME Foundation for sponsoring my trip to here!
				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Three years and counting</title>
    <id>http://fedoraplanet.org/4/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/4/" />
    <author>
      <name>Andrea Veri(av)</name>
    </author>
    <content type="html/text">It’s been a while since my last “what’s been happening behind the scenes” e-mail so I’m here to report on what has been happening within the GNOME Infrastructure, its future plans and my personal sensations about a challenge that started around three (3) years ago when Sriram Ramkrishna and Jeff Schroeder proposed my name as a possible candidate for coordinating the team that runs the systems behind the GNOME Project. All this followed by the official hiring achieved by Karen Sandler back in February 2013.
The GNOME Infrastructure has finally reached stability both in terms of reliability and uptime, we didn’t have any service disruption this and the past year and services have been running smoothly as they were expected to in a project like the one we are managing.
As many of you know service disruptions and a total lack of maintenance were very common before I joined back in 2013, I’m so glad the situation has dramatically changed and developers, users, passionates are now able to reach our websites, code repositories, build machines without experiencing slowness, downtimes or
unreachability. Additionally all these groups of people now have a reference point they can contact in case they need help when coping with the infrastructure they daily use. The ticketing system allows users to get in touch with the members of the Sysadmin Team and receive support right away within a very short period of time (Also thanks to Pagerduty, service the Foundation is kindly sponsoring)
Before moving ahead to the future plans I’d like to provide you a summary of what has been done during these roughly three years so you can get an idea of why I define the changes that happened to the infrastructure a complete revamp:

Recycled several ancient machines migrating services off of them while consolidating them by placing all their configuration on our central configuration management platform ran by Puppet. This includes a grand total of 7 machines that were replaced by new hardware and extended warranties the Foundation kindly sponsored.
We strenghten our websites security by introducing SSL certificates everywhere and recently replacing them with SHA2 certificates.
We introduced several services such as Owncloud, the Commits Bot, the Pastebin, the Etherpad, Jabber, the GNOME Github mirror.
We restructured the way we backup our machines also thanks to the Fedora Project sponsoring the disk space on their backup facility. The way we were used to handle backups drastically changed from early years where a magnetic tape facility was in charge of all the burden of archiving our data to today where a NetApp is used together with rdiff-backup.
We upgraded Bugzilla to the latest release, a huge thanks goes to Krzesimir Nowak who kindly helped us building the migration tools.
We introduced the GNOME Apprentice program open-sourcing our internal Puppet repository and cleansing it (shallow clones FTW!) from any sensitive information which now lives on a different repository with restricted access.
We retired Mango and our OpenLDAP instance in favor of FreeIPA which allows users to modify their account information on their own without waiting for the Accounts Team to process the change.
We documented how our internal tools are customized to play together making it easy for future Sysadmin Team members to learn how the infrastructure works and supersede existing members in case they aren’t able to keep up their position anymore.
We started providing hosting to the GIMP and GTK projects which now completely rely on the GNOME Infrastructure. (DNS, email, websites and other services infrastructure hosting)
We started providing hosting not only to the GIMP and GTK projects but to localized communities as well such as GNOME Hispano and GNOME Greece
We configured proper monitoring for all the hosted services thanks to Nagios and Check-MK
We migrated the IRC network to a newer ircd with proper IRC services (Nickserv, Chanserv) in place.
We made sure each machine had a configured management (mgmt) and KVM interface for direct remote access to the bare metal machine itself, its hardware status and all the operations related to it. (hard reset, reboot, shutdown etc.)
We upgraded MoinMoin to the latest release and made a substantial cleanup of old accounts, pages marked as spam and trashed pages.
We deployed DNSSEC for several domains we manage including gnome.org, guadec.es, gnomehispano.es, guadec.org, gtk.org and gimp.org
We introduced an account de-activation policy which comes into play when a contributor not committing to any of the hosted repositories at git.gnome.org since two years is caught by the script. The account in question is marked as inactive and the gnomecvs (from the old cvs days) and ftpadmin groups are removed.
We planned mass reboots of all the machines roughly every month for properly applying security and kernel updates.
We introduced Mirrorbrain (MB), the mirroring service serving GNOME and related modules tarballs and software all over the world. Before introducing MB GNOME had several mirrors located in all the main continents and at the same time a very low amount of users making good use of them. Many organizations and companies behind these mirrors decided to not host GNOME sources anymore as the statistics of usage were very poor and preferred providing the same service to projects that really had a demand for these resources. MB solved all this allowing a proper redirect to the closest mirror (through mod_geoip) and making sure the sources checksum matched across all the mirrors and against the original tarball uploaded by a GNOME maintainer and hosted at master.gnome.org.

I can keep the list going for dozens of other accomplished tasks but I’m sure many of you are now more interested in what the future plans actually are in terms of where the GNOME Infrastructure should be in the next couple of years.
One of the main topics we’ve been discussing will be migrating our Git infrastructure away from cgit (which is mainly serving as a code browsing tool) to a more complete platform that is surely going to include a code review tool of some sort. (Gerrit, Gitlab, Phabricator)
Another topic would be migrating our mailing lists to Mailman 3 / Hyperkitty. This also means we definitely need a staging infrastructure in place for testing these kind of transitions ideally bound to a separate Puppet / Ansible repository or branch. Having a different repository for testing purposes will also mean helping apprentices to test their changes directly on a live system and not on their personal computer which might be running a different OS / set of tools than the ones we run on the GNOME Infrastructure.
What I also aim would be seeing GNOME Accounts being the only authentication resource in use within the whole GNOME Infrastructure. That means one should be able to login to a specific service with the same username / password in use on the other hosted services. That’s been on my todo list for a while already and it’s probably time to push it forward together with Patrick Puiterwijk, responsible of Ipsilon‘s development at Red Hat and GNOME Sysadmin.
While these are the top priority items we are soon receiving new hardware (plus extended warranty renewals for two out of the three machines that had their warranty renewed a while back) and migrating some of the VMs off from the current set of machines to the new boxes is definitely another task I’d be willing to look at in the next couple of months (one machine (ns-master.gnome.org) is being decommissioned giving me a chance to migrate away from BIND into NSD).
The GNOME Infrastructure is evolving and it’s crucial to have someone maintaining it. On this side I’m bringing to your attention the fact the assigned Sysadmin funds are running out as reported on the Board minutes from the 27th of October. On this side Jeff Fortin started looking for possible sponsors and
came up with the idea of making a brochure with a set of accomplished tasks that couldn’t have been possible without the Sysadmin fundraising campaign launched by Stormy Peters back in June 2010 being a success. The Board is well aware of the importance of having someone looking at the infrastructure that runs the GNOME Project and is making sure the brochure will be properly reviewed and published.
And now some stats taken from the Puppet Git Repository:$ cd /git/GNOME/puppet &amp;amp;&amp;amp; git shortlog -ns

3520 Andrea Veri
506 Olav Vitters
338 Owen W. Taylor
239 Patrick Uiterwijk
112 Jeff Schroeder
71 Christer Edwards
4 Daniel Mustieles
4 Matanya Moses
3 Tobias Mueller
2 John Carr
2 Ray Wang
1 Daniel Mustieles García
1 Peter Baumgartenand from the Request Tracker database (52388 being my assigned ID):mysql&amp;gt; select count(*) from Tickets where LastUpdatedBy = '52388';
+----------+
| count(*) |
+----------+
| 3613 |
+----------+
1 row in set (0.01 sec)

mysql&amp;gt; select count(*) from Tickets where LastUpdatedBy = '52388' and Status = 'Resolved';
+----------+
| count(*) |
+----------+
| 1596 |
+----------+
1 row in set (0.03 sec)It’s been a long run which made me proud, for the things I learnt, for the tasks I’ve been able to accomplish, for the great support the GNOME community gave me all the time and most of all for the same fact of being part of the team responsible of the systems hosting the GNOME Project. Thank you GNOME community for your continued and never ending backing, we daily work to improve how the services we host are delivered to you and the support we receive back is fundamental for our passion and enthusiasm to remain high!
 				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">OpenHardware and code signing (update)</title>
    <id>http://fedoraplanet.org/5/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/5/" />
    <author>
      <name>Richard Hughes(hughsie)</name>
    </author>
    <content type="html/text">I posted a few weeks ago about the difficulty of providing device-side verification of firmware updates, at the same time remaining OpenHardware and thus easily hackable. The general consensus was that allowing anyone to write any kind of firmware to the device without additional authentication was probably a bad idea, even for OpenHardware devices. I think I’ve come up with an acceptable compromise I can write up as a recommendation, as per usual using the ColorHug+ as an example. For some background, I’ve sold nearly 3,000 original ColorHug devices, and in the last 4 years just three people wanted help writing custom firmware, so I hope you can see the need to protect the majority is so much larger than making the power users happy.
ColorHug+ will be supplied with a bootloader that accepts only firmware encrypted with the secret XTEA key I that I’m using for my devices. XTEA is an acceptable compromise between something as secure as ECC, but that’s actually acceptable in speed and memory usage for a 8-bit microcontroller running at 6MHz with 8k of ROM. Flashing a DIY or modified firmware isn’t possible, and by the same logic flashing a malicious firmware will also not work.
To unlock the device (and so it stays OpenHardware) you just have to remove the two screws, and use a paper-clip to connect TP5 and GND while the device is being plugged into the USB port. Both lights will come on, and stay on for 5 seconds and then the code protection is turned off. This means you can now flash any home-made or malicious firmware to the device as you please.
There are downsides to unlocking; you can’t re-lock the hardware so it supports official updates again. I don’t know if this is a huge problem; flashing home-made firmware could damage the device (e.g. changing the pin mapping from input to output and causing something to get hot). If this is a huge problem I can fix CH+ to allow re-locking and fix up the guidelines, although I’m erring on unlocking being a one way operation.
Comments welcome.				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Prioritizing volunteer contributions in free software development</title>
    <id>http://fedoraplanet.org/6/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/6/" />
    <author>
      <name>Andre Klapper(andre)</name>
    </author>
    <content type="html/text">Wikimedia is an organization which has both volunteers and paid folks working together in software development, with many software projects and different stakeholders involved.
In Wikimedia, there is currently some discussion how to improve the code review process. One aspect is reducing our code review queues and waiting times, with a focus on contributions provided by volunteers.
There are numerous successful free and open source software projects with a similar setup of companies and volunteers involved (Mozilla, Openstack, …) so I’m curious if your project has also investigated similar questions and if there is some knowledge and experience to share.

In your project, do maintainers commit to review contributed patches in a certain timeframe, like “all patches receive a first review comment within four days”? How is this process implemented? Do you think it is successful?
With an existing backlog of patches that did not manage to attract a review, what do you with ancient and rotting patches? Do you just abandon them after a certain timeframe in your code review tool to get a “cleaner slate”? Or do you leave them open to (theoretically) allow someone to find them and them pick up?
Do you have any specific workflow in place that provides feedback to patch authors who contribute a patch to a rather unmaintained repositories that noone feels responsible for (anymore)? Do you signal the lack of maintainers and encourage contributors to step up as maintainers? How?
Do you have a workflow in place to specifically prioritize the review of patches contributed by volunteers? How efficient is it?

I’d be very interested in hearing how your project handles these issues. Needless to say, links to documents are welcome. Thanks!				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">glibmm: Deprecated Glib::Threads</title>
    <id>http://fedoraplanet.org/7/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/7/" />
    <author>
      <name>Murray Cumming(murrayc)</name>
    </author>
    <content type="html/text">As of glibmm 2.47 (currently unstable), we have deprecated the glibmm threads API, which wrapped the glib threads API. That’s because C++11 finally has its own standard threading API, and in C++14 its complete enough to replace all of Glib::Threads.
Here’s what replaces what:

Glib::Threads::Thread: Use std::thread.
Glib::Threads::Mutex: Use std::mutex.
Glib::Threads::RecMutex: Use std::recursive_mutex.
Glib::Threads::Lock: Use std::lock_guard or std::unique_lock.
Glib::Threads::RWLock: Use std::lock_guard or std::unique_lock.with std::shared_timed_mutex, available in C+14.
Glib::Threads::Cond: Use std::condition_variable.
Glib::Threads::Private: Use the thread_local keyword.
Glib::ThreadPool: I suspect that std::async() solves much the same problems, but I guess you might sometimes need to implement your own thread pool. This seems to be an ongoing discussion among C++ developers.

We’ve replaced use of Glib::Threads in our example code and tests, such as the example in our multithreading chapter in the gtkmm book.
This is quite a relief because we never wanted to be in the concurrency API business anyway, and having a standard C++ concurrency API makes it far easier to write cross-platform code. Now if we could just have a standard C++ network IO API and maybe a file structure API, that would be nice.
 				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Accessing a JSON webservice using libsoup and JSON-GLib</title>
    <id>http://fedoraplanet.org/8/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/8/" />
    <author>
      <name>Robert Ancell(robert_ancell)</name>
    </author>
    <content type="html/text">A lot of web services use the JSON format. If you are working a GLib based project and need to access a service like this there are two great libraries to help you - libsoup and JSON-Glib.For my example, I'm going to grab some review data from Ubuntu (API) which looks something like this:[    {        "ratings_total": 229,         "ratings_average": "3.84",         "app_name": "",         "package_name": "simple-scan",         "histogram": "[35, 13, 22, 42, 117]"    },     {        "ratings_total": 546,         "ratings_average": "4.66",         "app_name": "",         "package_name": "audacity",         "histogram": "[17, 7, 17, 63, 442]"    },    ... ]The data is a single array of objects that contain the statistics for each package. For this example I'll print out the number of ratings for each package by getting the package_name and ratings_total members from each object.Firstly, I need to download the data. The data is retrieved using a HTTP GET request; in libsoup you can do this with:    SoupSession *session = soup_session_new_with_options (SOUP_SESSION_USER_AGENT, "test-json", NULL);    SoupMessage *message = soup_message_new (SOUP_METHOD_GET, "https://reviews.ubuntu.com/reviews/api/1.0/review-stats/any/any");    soup_session_send_message (session, message);Now I have the server text in message-&amp;gt;response_body-&amp;gt;data but it needs to be decoded. JSON-GLib can parse it with:    JsonParser *parser = json_parser_new ();    json_parser_load_from_data (parser, message-&amp;gt;response_body-&amp;gt;data, -1, NULL);    JsonNode *root = json_parser_get_root (parser);Now I have an in-memory tree of the JSON data which can be traversed. After checking the root node is an array as expected I'll iterate over each object:    g_assert (JSON_NODE_HOLDS_ARRAY (root));    array = json_node_get_array (root);    for (i = 0; i &amp;lt; json_array_get_length (array); i++)    {        JsonNode *node = json_array_get_element (array, i);        /* do stuff... */     }For each object, I extract the required data:        g_assert (JSON_NODE_HOLDS_OBJECT (node));        JsonObject *object = json_node_get_object (node);        const gchar *package_name = json_object_get_string_member (object, "package_name");        gint64 ratings_total = json_object_get_int_member (object, "ratings_total");        if (package_name)            g_print ("%s: %" G_GUINT64_FORMAT "\n", package_name,   Combined into a program, I can print out the number of reviews for each package:simple-scan: 229audacity: 546...The full program:// gcc -g -Wall example-json.c -o example-json `pkg-config --cflags --libs libsoup-2.4 json-glib-1.0`#include #include int main (int argc, char **argv){    SoupSession *session;    SoupMessage *message;    guint status_code;    JsonParser *parser;    gboolean result;    JsonNode *root;    JsonArray *array;    gint i;    /* Get the data using a HTTP GET */    session = soup_session_new_with_options (SOUP_SESSION_USER_AGENT, "test-json", NULL);    message = soup_message_new (SOUP_METHOD_GET, "https://reviews.ubuntu.com/reviews/api/1.0/review-stats/any/any");    g_assert (message != NULL);    status_code = soup_session_send_message (session, message);    g_assert (status_code == SOUP_STATUS_OK);    /* Parse the data in JSON format */    parser = json_parser_new ();    result = json_parser_load_from_data (parser, message-&amp;gt;response_body-&amp;gt;data, -1, NULL);    g_assert (result);    /* The data should contain an array of JSON objects */    root = json_parser_get_root (parser);    g_assert (JSON_NODE_HOLDS_ARRAY (root));    array = json_node_get_array (root);    for (i = 0; i &amp;lt; json_array_get_length (array); i++)    {        JsonNode *node;        JsonObject *object;        const gchar *package_name;        gint64 ratings_total;        /* Get the nth object, skipping unexpected elements */        node = json_array_get_element (array, i);        if (!JSON_NODE_HOLDS_OBJECT (node))            continue;        /* Get the package name and number of ratings from the object - skip if has no name */        object = json_node_get_object (node);        package_name = json_object_get_string_member (object, "package_name");        ratings_total = json_object_get_int_member (object, "ratings_total");        if (package_name)            g_print ("%s: %" G_GINT64_FORMAT "\n", package_name, ratings_total);    }    /* Clean up */    g_object_unref (session);      g_object_unref (message);    g_object_unref (parser);    return 0;}And to show you can do the same thing with GIR bindings, here's the same in Vala:// valac example-json.vala --pkg soup-2.4 --pkg json-glib-1.0public int main (string[] args){    /* Get the data using a HTTP GET */    var session = new Soup.Session.with_options (Soup.SESSION_USER_AGENT, "test-json");    var message = new Soup.Message ("GET", "https://reviews.ubuntu.com/reviews/api/1.0/review-stats/any/any");    assert (message != null);    var status_code = session.send_message (message);    assert (status_code == Soup.Status.OK);    /* Parse the data in JSON format */    var parser = new Json.Parser ();    try    {        parser.load_from_data ((string) message.response_body.data);    }    catch (Error e)    {    }    /* The data should contain an array of JSON objects */    var root = parser.get_root ();    assert (root.get_node_type () == Json.NodeType.ARRAY);    var array = root.get_array ();    for (var i = 0; i     {        /* Get the nth object, skipping unexpected elements */        var node = array.get_element (i);        if (node.get_node_type () != Json.NodeType.OBJECT)            continue;        /* Get the package name and number of ratings from the object - skip if has no name */        var object = node.get_object ();        var package_name = object.get_string_member ("package_name");        var ratings_total = object.get_int_member ("ratings_total");        if (package_name != null)            stdout.printf ("%s: %" + int64.FORMAT + "\n", package_name, ratings_total);    }    return 0;}and Python:#!/usr/bin/pythonfrom gi.repository import Soupfrom gi.repository import Json# Get the data using a HTTP GETsession = Soup.Session.new ()session.set_property (Soup.SESSION_USER_AGENT, "test-json")message = Soup.Message.new ("GET", "https://reviews.ubuntu.com/reviews/api/1.0/review-stats/any/any")assert (message != None)status_code = session.send_message (message)assert (status_code == Soup.Status.OK)# Parse the data in JSON formatparser = Json.Parser ()parser.load_from_data (message.response_body.data, -1)# The data should contain an array of JSON objectsroot = parser.get_root ()assert (root.get_node_type () == Json.NodeType.ARRAY)array = root.get_array ()for i in xrange (array.get_length ()):    # Get the nth object, skipping unexpected elements    node = array.get_element (i)    if node.get_node_type () != Json.NodeType.OBJECT:        continue    # Get the package name and number of ratings from the object - skip if has no name    object = node.get_object ()    package_name = object.get_string_member ("package_name")    ratings_total = object.get_int_member ("ratings_total")    if package_name != None:        print ("%s: %d" % (package_name, ratings_total))				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">What is hacker culture?</title>
    <id>http://fedoraplanet.org/9/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/9/" />
    <author>
      <name>Matthew Garrett(mjg59)</name>
    </author>
    <content type="html/text">Eric Raymond, author of The Cathedral and the Bazaar (an important work describing the effectiveness of open collaboration and development), recently wrote a piece calling for "Social Justice Warriors" to be ejected from the hacker community. The primary thrust of his argument is that by calling for a removal of the "cult of meritocracy", these SJWs are attacking the central aspect of hacker culture - that the quality of code is all that matters.This argument is simply wrong.Eric's been involved in software development for a long time. In that time he's seen a number of significant changes. We've gone from computers being the playthings of the privileged few to being nearly ubiquitous. We've moved from the internet being something you found in universities to something you carry around in your pocket. You can now own a computer whose CPU executes only free software from the moment you press the power button. And, as Eric wrote almost 20 years ago, we've identified that the "Bazaar" model of open collaborative development works better than the "Cathedral" model of closed centralised development.These are huge shifts in how computers are used, how available they are, how important they are in people's lives, and, as a consequence, how we develop software. It's not a surprise that the rise of Linux and the victory of the bazaar model coincided with internet access becoming more widely available. As the potential pool of developers grew larger, development methods had to be altered. It was no longer possible to insist that somebody spend a significant period of time winning the trust of the core developers before being permitted to give feedback on code. Communities had to change in order to accept these offers of work, and the communities were better for that change.The increasing ubiquity of computing has had another outcome. People are much more aware of the role of computing in their lives. They are more likely to understand how proprietary software can restrict them, how not having the freedom to share software can impair people's lives, how not being able to involve themselves in software development means software doesn't meet their needs. The largest triumph of free software has not been amongst people from a traditional software development background - it's been the fact that we've grown our communities to include people from a huge number of different walks of life. Free software has helped bring computing to under-served populations all over the world. It's aided circumvention of censorship. It's inspired people who would never have considered software development as something they could be involved in to develop entire careers in the field. We will not win because we are better developers. We will win because our software meets the needs of many more people, needs the proprietary software industry either can not or will not satisfy. We will win because our software is shaped not only by people who have a university degree and a six figure salary in San Francisco, but because our contributors include people whose native language is spoken by so few people that proprietary operating system vendors won't support it, people who live in a heavily censored regime and rely on free software for free communication, people who rely on free software because they can't otherwise afford the tools they would need to participate in development.In other words, we will win because free software is accessible to more of society than proprietary software. And for that to be true, it must be possible for our communities to be accessible to anybody who can contribute, regardless of their background.Up until this point, I don't think I've made any controversial claims. In fact, I suspect that Eric would agree. He would argue that because hacker culture defines itself through the quality of contributions, the background of the contributor is irrelevant. On the internet, nobody knows that you're contributing from a basement in an active warzone, or from a refuge shelter after escaping an abusive relationship, or with the aid of assistive technology. If you can write the code, you can participate.Of course, this kind of viewpoint is overly naive. Humans are wonderful at noticing indications of "otherness". Eric even wrote about his struggle to stop having a viscerally negative reaction to people of a particular race. This happened within the past few years, so before then we can assume that he was less aware of the issue. If Eric received a patch from someone whose name indicated membership of this group, would there have been part of his subconscious that reacted negatively? Would he have rationalised this into a more critical analysis of the patch, increasing the probability of rejection? We don't know, and it's unlikely that Eric does either.Hacker culture has long been concerned with good design, and a core concept of good design is that code should fail safe - ie, if something unexpected happens or an assumption turns out to be untrue, the desirable outcome is the one that does least harm. A command that fails to receive a filename as an argument shouldn't assume that it should modify all files. A network transfer that fails a checksum shouldn't be permitted to overwrite the existing data. An authentication server that receives an unexpected error shouldn't default to granting access. And a development process that may be subject to unconscious bias should have processes in place that make it less likely that said bias will result in the rejection of useful contributions.When people criticise meritocracy, they're not criticising the concept of treating contributions based on their merit. They're criticising the idea that humans are sufficiently self-aware that they will be able to identify and reject every subconscious prejudice that will affect their treatment of others. It's not a criticism of a desirable goal, it's a criticism of a flawed implementation. There's evidence that organisations that claim to embody meritocratic principles are more likely to reward men than women even when everything else is equal. The "cult of meritocracy" isn't the belief that meritocracy is a good thing, it's the belief that a project founded on meritocracy will automatically be free of bias.Projects like the Contributor Covenant that Eric finds so objectionable exist to help create processes that (at least partially) compensate for our flaws. Review of our processes to determine whether we're making poor social decisions is just as important as review of our code to determine whether we're making poor technical decisions. Just as the bazaar overtook the cathedral by making it easier for developers to be involved, inclusive communities will overtake "pure meritocracies" because, in the long run, these communities will produce better output - not just in terms of the quality of the code, but also in terms of the ability of the project to meet the needs of a wider range of people.The fight between the cathedral and the bazaar came from people who were outside the cathedral. Those fighting against the assumption that meritocracies work may be outside what Eric considers to be hacker culture, but they're already part of our communities, already making contributions to our projects, already bringing free software to more people than ever before. This time it's Eric building a cathedral and decrying the decadent hordes in their bazaar, Eric who's failed to notice the shift in the culture that surrounds him. And, like those who continued building their cathedrals in the 90s, it's Eric who's now irrelevant to hacker culture.(Edited to add: for two quite different perspectives on why Eric's wrong, see Tim's and Coraline's posts) comments				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">FOSS System Software in 2015</title>
    <id>http://fedoraplanet.org/10/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/10/" />
    <author>
      <name>Sankar P(psankar)</name>
    </author>
    <content type="html/text">PreludeAbout an year ago, I was playing around with Cassandra for a quick prototype in then dayjob. It opened up the world of distributed systems to me and I was piqued. Audaciously, I decided to implement a simple distributed database, Keeri, to have a grasp of the fundamentals of the implementation of distributed databases. In the past, I have implemented a simple filesystem which has helped me immensely when I was working as a filesystem engineer. Also, I have always been fascinated by the theory behind the database internals right from college days, but did not get my hands dirty.After a few weeks of work, I was able to implement a recursive-descent SQL parser, which analysed the incoming SELECT queries, made a tree with the subqueries properly branched as sub-trees. I made a simple columnar store that appends data (via an API as opposed to SQL) but without any atomicity guarantees. In short, it was a rudimentary, in-memory system that functions decently. However, I was nowhere near the initial goal of implementing a distributed database.I realised that there were plenty of design choices in a distributed database implementation, right from architecture, replication, membership, consensus, CAP, etc. I even took a coursera course that helped me understand the basics in detail. As of today, I have enough confidence in my skills and knowledge to implement a distributed database which could serve as a good teaching material, if not as a production software. However, I have not made a single line of code in the past seven months to the project. Abandoning (at least temporarily) the project, hurts.Yesterday, my daughter decided to wake me up from my sleep after midnight, I spent the remaining night wide awake, while she slept, thinking why I have not made progress in keeri. I realised that I have been overwhelmed by the amount of things to do, that are not core to the system. For example, after I decided that the database has to be NEWSQL based, it is imperative that I needed a SQL parser. But there are a dozen types of parsing (LL, LR, Recursive Descent, ANTLR etc.) techniques. Understanding the pros and cons of the each type and finding the most suitable candidate is a non-trivial task. SQL Parsing is just one component of the system. There are other components such as the choice of datastructures (based on read/write ratio, type of load etc.) One approach is to proceed with the simplest choices for each component with well-defined borders. The individual components can be later replaced. By the time, I completed the SQL query to a decision tree code, I felt exhausted, even before I began the core database and distributed systems functionality.ObservationsFrom my past open source experience, I have known the synergic boost that developers experience in FOSS communities. It is always good to work in a like minded team of developers rather than individually when working on big problems. I started thinking what other FOSS projects exist for distributed databases (or any other large scale system software) that were created in the last 5-6 years. A few things that came to my mind were:Hadoop: An umbrella of projects, initially started by Yahoo, including core projects such as HDFS, HBase and a laundry list of supporting projects. Most of the code is now under the Apache project with a plenty of companies sponsoring the development and using the projects.Docker: The coolest kid in the town. Initially started by Solomon Hykes funded by dotCloud as a side project. Arguably the most active project to date used heavily by almost all tech companies worth their salt. This spawned off a series of other projects too.CoreOS: Linux re-thought for being a Cloud focussed distro. Backed by a company with the same name. Founded by ex SUSE, Rackspace people, collaborating with Greg KH himself.Redis: Started by antirez, funded by vmware, pivotal and most recently redis labs. Probably the most used k-v database, probably challenged only by the older memcached.Cassandra: Initially started by Facebook and later became an Apache project. Heavily used by companies like Netflix, Twitter, Applet etc. even after facebook has moved away.Kafka: Initially started by Linkedin and later became an Apache project. Used by linkedin and almost every company today. Most of the original team that created the project have now jumped off to a new company named Confluent working on the project full time.CockroachDB: A project that claims to be the open source equivalent for Google's Spanner. Started by ex-googlers. Development funded and managed by Cockroachlabs.As I kept thinking about these (and a few other) projects in a state of semi-sleep, I had a eureka moment when I realised that all these projects, even though are open source, began funded by a company / investor money. This is in complete contrast to the FOSS projects of the previous generation like GNU, Linux, GNOME etc. It is a welcome change that developers are now not scared of becoming C*Os and spend time in management or bootstrapping a company. Perhaps, only today, we have companies like Zenefits (disclaimer: employer ;) ) making it easy to start a company and so more developers find it easier to start companies. VCs being in a bullish mindset also helps.However, I have one concern. Unless the project usage explodes and gains contributors from multiple companies, there is a high chance that the projects may compromise on quality to accommodate a business need. For example, if Torvalds was working for Google, wakelocks *might* have merged into kernel much earlier to suit a Google release cycle. Torvalds being a neutral outsider, without having any commercial interests in any company (directly) has helped Linux immensely. If a FOSS project is started with a backing company in place, from day one, how high will the company's benefits influence the design / features / review processes of the FOSS project ?As I think more, I realised that, most of these new system software are developed to address the pains of a "as a service" providers. So unless there is a business case, it is perhaps difficult to create a new modern system software, as the era of one size fits all is over. This also makes the previous concern about, the chief maintainer being company neutral, irrelevant. Only when a software is made, backed by a company, with real use cases and customers, instead of theoretical / intellectual curiosities we will get live data. Personal pet projects may have to be satisfied with machine generated data, which may not be the best testsuite for data intensive software like databases.QuestionsTo sum up, I wonder if developers (students) any more interested / will be able to develop FOSS projects in their own hobby time, that could grow as big as Linux, without having a corporate backup, for the first few years at least, What do you think ?Also, if you think it is possible, any recommendations for developers with family and personal needs to spend time, off the regular day job, to persist with pet FOSS projects without exhaustion ? Are there any statistics available on contributor details for popular FOSS projects (similar to Kernel stats prepared by Greg KH and LWN) ?Any other aspects that I have missed ?P.S: I was sharing the gist of this post with a friend who shrugged off saying, "Get a job in the company which works on a project which appeals to you". However, it is not that simple, considering most of these young companies do not even have an office anywhere outside the developed world. Also after a certain point in life, switching jobs is not trivial and depends on various other factors.				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Inking an old friend</title>
    <id>http://fedoraplanet.org/11/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/11/" />
    <author>
      <name>Jean-François Fortin Tam(nekohayo)</name>
    </author>
    <content type="html/text">When I was young, I read a lot of comic books. One of my favorite séries was Cubitus:

Over fifteen years ago, Michel Grant, a local comic book artist passionate about teaching, made a quick sketch of Cubitus &amp;amp; Sénéchal for me, on a big sheet of paper. I liked it enough to have it laminated and kept in my room for nearly two decades. I don’t think Mr. Grant would have expected me to keep it so long and so preciously. It was drawn with a big, unrefined permanent marker (certainly not a Sakura micron or something of the sort), and here came the problem: after so many years, even if it was laminated and not put in direct sunlight, the ink had faded out significantly:

Recently, my mother suggested I just turn that piece of art into a coffee table, “Why not paint it entirely black?”. Yeah.

So one afternoon, I whipped up a Sharpie marker and started tracing the drawing.

The laminated surface (and overall lack of dynamic range of permanent markers) proved challenging for some parts like Cubitus’ nose:

But it went well overall.

Now, the drawing is contrasty enough to be hung up on a wall again. The speech balloon (at the top-right) and artist’s signature (bottom-right) were left untouched, for the vintage feel and to emphasize the characters. Quite a stark difference.
				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">2015-11-28 Saturday.</title>
    <id>http://fedoraplanet.org/12/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/12/" />
    <author>
      <name>Michael Meeks(michael)</name>
    </author>
    <content type="html/text"> 
	
		Up earlyish; tried (somehow) to get GStreamer to work on
	Miriam's OpenSUSE 13.1 - enabled packman, burned many unhappy
	minutes wrestling with different versions of different things,
	broken gst pipelines, switching packages incrementally between
	vendors, installing more and more bits. I used to like VLC because
	it was one big lump of download that "just worked" until they
	decided to go with the "one hundred pieces any developer with
	lots of time can just plug together and debug, while no user can
	install or use anymore". Eventually discovered that deleting my
	~/.cache/gstreamer, ~/.gstreamer* made things suddenly
	work: nice, sadly don't have the bad files now.
	
	
		Breakfast - cheering. Nicki over with kids - plugged at
	reading around SalGraphics usage; more horrors.
	
	
		Lunch, out to buy a new fireplace/surround in Cambridge.
	Anything to be rid of the 30's monstrosity we have; an interesting
	selection - left the esthetics to J.
	
	
		Home; back to SalGraphics - eventually discovered that
	(depending on backend) we can and do end up with multiple wrappers
	of the same underlying OS resources; which causes my issues. Something
	like a rampant mis-use of multiple fdopen's on the same
	underlying file; fun. At least it makes sense finally.
	
				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">2015-11-27 Friday.</title>
    <id>http://fedoraplanet.org/13/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/13/" />
    <author>
      <name>Michael Meeks(michael)</name>
    </author>
    <content type="html/text"> 
	
		Mail chew; hackery; lunch; interviews. Poked at the
	SalGraphics lifecycle - which is a complete mystery;
	inconclusively and at length; rather important if you want to
	key a cache/double-buffer of the screen contents on it.
	
				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">The goats have strayed into GNOME</title>
    <id>http://fedoraplanet.org/14/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/14/" />
    <author>
      <name>Debarshi Ray(rishi)</name>
    </author>
    <content type="html/text">Here is a glimpse of what I have been doing lately.


The screenshots feature the photo please wait… by Garrett LeSage available under a Creative Commons Attribution-ShareAlike license.   				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Do You Like What I Do For a Living?</title>
    <id>http://fedoraplanet.org/15/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/15/" />
    <author>
      <name>Bradley M. Kuhn(bkuhn)</name>
    </author>
    <content type="html/text"> [ A version of this blog  post
            was crossposted
              on Conservancy's blog. ]
        
        I'm quite delighted with my career choice.  As an undergraduate and even
          in graduate school, I still expected my career extend my earlier careers in
          the software industry: a mixture of software developer and sysadmin.  I'd
          probably be a DevOps person now, had I stuck with that career path.
        
        Instead, I picked the charity route: which (not financially, but
          work-satisfaction-wise) is like winning a lottery.  There are very few
          charities related to software freedom, and frankly, if (like me) you
          believe in universal software freedom and reject proprietary software
          entirely, there are two charities for you:
          the Free Software Foundation, where I used to
          work, and Software Freedom
          Conservancy, where I work now.
        
        But software freedom is not merely an ideology for me.  I believe the
          ideology matters because I see the lives of developers and users are better
          when they have software freedom.  I first got a taste of this
          IRL when I attended the earliest Perl
          conferences in the late 1990s.  My friend James and I stayed in dive motels
          and even slept in a rental car one night to be able to attend.  There was
          excitement in the Perl community (my first Free Software community).  I was
          exhilarated to meet in person the people I'd seen only as god-like hackers
          posting on perl5-porters.  James was so excited he asked me to take a
          picture of him jumping as high as he could with his fist in the air in
          front of the main conference banner.  At the time, I complained; I was
          mortified and felt like a tourist taking that picture.  But looking back, I
          remember that James and I felt that same excitement and just were
          expressing it differently.
        
        I channeled that thrill into finding a way that my day job would focus on
          software freedom.  As an activist since my teenage years, I concentrated
          specifically on how I could preserve, protect and promote this valuable
          culture and ideology in a manner that would assure the rights of developers
          and users to improve and share the software they write and use.
        
        I've enjoyed the work; I attend more great conferences than I ever
          imagined I would, where now people occasionally walk up to me with the same
          kind of fanboy reverence that I reserved for Larry Wall,
          RMS and the heroes of my
          Free Software generation.  I like my work.  I've been careful, however, to
          avoid a sense of entitlement.  Since I read it in 1991, I have never
          forgotten RMS' point
          in the GNU
          Manifesto:  Most of us cannot manage to get any money for
          standing on the street and making faces. But we are not, as a result,
          condemned to spend our lives standing on the street making faces, and
          starving. We do something else., a point he continues
          in his regular speeches,
          by adding: I [could] just … give up those principles and start
          … writing proprietary software.  I looked for another alternative,
          and there was an obvious one. I could leave the software field and do
          something else. Now I had no other special noteworthy skills, but I'm sure
          I could have become a waiter.  Not at a fancy restaurant; they wouldn’t
          hire me; but I could be a waiter somewhere.  And many programmers, they say
          to me, “the people who hire programmers demand [that I write
          proprietary software] and if I don’t do [it], I’ll starve”. It’s
          literally the word they use. Well, as a waiter, you’re not going to
          starve.
        
        RMS' point is not merely to expose the
          false dilemma
          inherent in I have to
          program, even it's proprietary, because that's what companies pay me to
          do, but also to expose the sense of entitlement in assuming a
          fundamental right to do the work you want.  This applies not just to
          software authorship (the work I originally trained for) but also the
          political activism and non-profit organizational work that I do now.
        
        I've spent most of my career at charities because I believe deeply that I
          should take actions that advance the public good, and because I have a
          strategic vision for the best methods to advance software freedom.  My
          strategic goals to advance software freedom include two basic tenets: (a)
          provide structure for Free Software projects in a charitable home (so that
          developers can focus on writing software, not administration, and so that
          the projects aren't unduly influenced by for-profit corporations) and (b)
          uphold and defend Free Software licensing, such
          as copyleft, to ensure software
          freedom.
        
        I don't, however, arrogantly believe that these two priorities are
          inherently right.  Strategic plans work toward a larger goal, and pursing
          success of a larger ideological mission requires open-mindedness regarding
          strategies.  Nevertheless, any strategy, once decided, requires zealous
          pursuit.  It's with this mindset that I teamed up with my
          colleague, Karen Sandler, to
          form Software Freedom
          Conservancy.
        
        Conservancy, like most tiny charities, survives on the determination of
          its small management staff. Karen Sandler, Conservancy's Executive
          Director, and I have a unique professional collaboration.  She and I share
          a commitment to promoting and defending
          moral
          principles in the context of software freedom, along with an
          unrelenting work ethic to match.  I believe fundamentally that she and I
          have the skills, ability, and commitment to meet these two key strategic
          goals for software freedom.
        
        Yet, I don't think we're entitled to do this work.  And, herein there's
          another great feature of a charity.  A charity not only serves the
          public good; the USA IRS also requires that a charity
          be funded primarily by donations from the public.
        
        I like this feature for various reasons.  Particularly, in the context of
          the fundraiser that
          Conservancy announced this week, I think about it terms of seeking a
          mandate from the public.  As Conservancy poises to begin its tenth year,
          Karen and I as its leaders stand at a crossroads.  For financial reasons of
          the organization's budget, we've been thrust to test this question: Does
          the public of Free Software users and developers actually want the
          work that we do?.
        
        While I'm nervous that perhaps the answer is no, I'm nevertheless
          not afraid to ask the question.  So, we've asked.  We asked all of you to
          show us that you want our work to continue.  We set two levels, matching
          the two strategic goals I mentioned.  (The second is harder and more
          expensive to do than the first, so we've asked many more of you to support
          us if you want it.)
        
        It's become difficult in recent years to launch a non-profit fundraiser
          (which have existed for generations) and not think of the relatively recent
          advent of gofundme, Kickstarter, and the like.  These new systems provide a
          (sadly, usually proprietary software) platform for people to ask the
          public: Is my business idea and/or personal goal worth your money?.
          While I'm dubious about those sites, I do believe in democracy
          enough to build my career on a structure that requires an election (of
          sorts).  Karen and I don't need you to go to the polls and cast your
          ballot, but we do ask you consider if what we do for a living at
          Conservancy is worth US$10 per month to you.  If it is, I hope you'll
          “cast a vote” for Conservancy
          and become a Conservancy
          supporter now.
        
        				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Ways to help the Board help you</title>
    <id>http://fedoraplanet.org/16/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/16/" />
    <author>
      <name>Rosanna Yuen(zana)</name>
    </author>
    <content type="html/text">
If you have read my previous post, you may have realized you need to ask the Board of Directors for help.  The next step is to send them a proposal via email for them to consider it.
Like many of us, the Directors receive more than their fair share of email. In order for your request to be considered, the Directors have to be able to quickly and easily understand what it is you want, why you are requesting it, and how it would benefit the GNOME Foundation. Below are some thoughts on how to increase the likelihood your request will be considered promptly.
Don’t bury the lead
Start your email with a quick and simple summary of what you want and why. Include a deadline for when you need a reply. For example:
I would like to request $50 for tea and snacks for a meeting of the GNOME reading club.  I need a reply by December 1 as to whether the Board will approve my request.
By putting this at the top, the Board Directors know right away what you want. If your request is further down in the email, the Directors may not realize there was an actionable item buried inside.
Having a deadline is very helpful as well. It gives the Board of Directors a time frame. Without it, the item may well slip through the cracks as the busy Directors will prioritize dealing with items that seem to be under more time pressure.
Explain who and what
Next you need to let the board know your bona fides.  If you are a GNOME Foundation member, tell them so. Knowing you are a member lets the Board know of your commitment to GNOME.  It is also important to explain why you are the one making the request and details of what exactly you want.  Continuing from my request above:
Having been a Foundation member for many years, I have noticed there being a lack of reviews from within our community for GNOME technical manuals.  I have discussed this with some members in the community and five of us (all members) plan on reading and then getting together to discuss and review these works.  I am requesting the $50 in order to serve tea and cakes during the break in the discussions.
If you have more supporting materials and explanations, please do add it here. The Board does want to have enough information to make an informed decision.
If you are asking for money
The GNOME Foundation does not have unlimited resources. As a non-profit, the Board of Directors works hard to ensure that the funds are spent wisely and towards our mission. Sometimes their budget cannot cover the amount of your request. Other times, you or your endeavor might be untested in which case the Board may not want to risk a large amount. If you give a detailed list of how you plan on spending the money in the order you would spend it, you are more likely to be able to get an amount you can work with. To continue our example:
List of how I would spend the $50 in order of priority
Tea          $10
Sandwiches   $25
Cakes        $15
================
Total        $50


If the Board can only approve $10, we will have a shorter event.
As a general rule, if the Board approves your budget, you will need to wait until after the event and submit receipts for reimbursement up to the approved amount. If, for financial reasons, you need the funds in advance, please put it up front in your request as that may affect the Board’s decision. Note that even if you do get approval to receive the funds early, you still need to submit all receipts to the Board as soon as possible after the event.
Be available for questions
The Board may have some questions for you that you may not have thought to cover in your email. Let them know how and when they can reach you quickly if need be. This is especially important if your deadline is near:
If the Board has any questions about this proposal, you can find me on IRC or by email this week.  Unfortunately, I will be unavailable next Monday through Thursday due to a prior commitment.

Thanks,
Rosanna
Make sure the subject heading is descriptive
Before you send in your request, please put a descriptive subject for the email. Oftentimes, Board members attempt to pull up email requests quickly during the discussion. If you use a generic subject, your email will be very hard to find. This may seem like a no-brainer, but sometimes it just gets forgotten.
subject: requesting $50 for refreshments for reading club meeting
Waiting
Once you have sent in your request, be patient.  The Board does meet regularly but often has a lot of business to attend to.  It is okay to ask after a couple of days to make sure the Board has received your request.  But after you receive confirmation that they are considering the matter, give them time to decide.
Good luck with your requests!
 				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Could I possibly ask the Board for help?</title>
    <id>http://fedoraplanet.org/17/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/17/" />
    <author>
      <name>Rosanna Yuen(zana)</name>
    </author>
    <content type="html/text">The GNOME Foundation exists to further the mission of the GNOME project.  The Board of Directors are elected by the Membership to carry out the necessary tasks.  I have had the opportunity to work with more than a few GNOME Boards, and while each year is different, there are many traits the Board Directors have in common.  The Directors are:

passionate about GNOME
happy to help
volunteers

Amongst the things they are not include:

omnipotent
infallible
mind readers

The Directors really want to help the GNOME Foundation members in their efforts to improve GNOME.  It is, after all, a big part of why they volunteer their time on the Board.  If you have an idea of something you can do to improve GNOME but could use some help, please contact them!  They may sit behind the imposing-sounding board-list@gnome.org email address, but they are very approachable.
Every one of them are eager to help!
Previously approved requests have included money for release parties, marketing materials, or hackfests; letters of recommendation or other paperwork; and help finding the right person to help with your problem.  If you have an issue that the Board can help with, please let them know.  They can’t help you if they don’t know about it!				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Attending the Web Engines Hackfest</title>
    <id>http://fedoraplanet.org/18/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/18/" />
    <author>
      <name>Mario Sanchez Prada(msanchez)</name>
    </author>
    <content type="html/text">It’s certainly been a while since I attended this event for the last time, 2 years ago, when it was a WebKitGTK+ only oriented hackfest, so I guess it was a matter of time it happened again…
It will be different for me this time, though, as now my main focus won’t be on accessibility (yet I’m happy to help with that, too), but on fixing a few issues related to the WebKit2GTK+ API layer that I found while working on our platform (Endless OS), mostly related to its implementation of accelerated compositing.
Besides that, I’m particularly curious about seeing how the hackfest looks like now that it has broaden its scope to include other web engines, and I’m also quite happy to know that I’ll be visiting my home town and meeting my old colleagues and friends from Igalia for a few days, once again.
Last, I’d like to thank my employer for sponsoring this trip, as well as Igalia for organizing this event, one more time.
See you in Coruña!				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Redmine analytics with Python, Pandas and iPython Notebooks</title>
    <id>http://fedoraplanet.org/19/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/19/" />
    <author>
      <name>Danielle Madeley(danni)</name>
    </author>
    <content type="html/text">ORIGINALLY POSTED ON IXA.IO
We use Redmine at Infoxchange to manage our product backlog using the Agile plugin from Redmine CRM. While this is generally good enough for making sure we don’t lose any cards and has features like burndown charting you still have to keep your own metrics. This is sort of annoying because you’re sure the data is in there somehow and what do you do when you want to explore a new metric?
This is where iPython Notebooks and the data analysis framework Pandas come in. iPython Notebooks are an interactive web-based workspace where you can intermix documentation and Python code, with graphs and tables you produce output directly into the document. Individual “cells” of the notebook are cached so you can work on part of the program, and experiment (great for data analysis) without having to run big slow number crunching or data download steps.
Pandas is a library for loading and manipulating data. It is based on the well-known numpy and scipy scientific packages and extends them to be able to load data from almost any file type or source (i.e. a Redmine CSV straight from your Redmine server) without having to know much programming. Your data becomes intuitively exposed. It also has built-in plotting and great integration with iPython Notebooks.&amp;lt;!–more–&amp;gt;The first metric I wanted to collect was to study the relationship between our story estimates (in points), our tasking estimates (in hours) and reality. First let’s plot our velocity. It is a matter of saving a custom query whose CSV export URL I can copy into my notebook. This means I can run the notebook at any time to get the latest data.
Remember that iPython notebooks cache the results of cells so I can place accessing Redmine into its own cell and I won’t have to constantly be downloading the data. I can even work offline if I want.
import pandas
data = pandas.read_csv('https://redmine/projects/devops/issues.csv?query_id=111&amp;amp;key={key}'.format(key=key))
Pandas exposes the result as a data frame, which is something we can manipulate in meaningful ways. For instance, we can extract all of the values of a column withdata['column name']. We can also select all of the rows that match a certain condition:
data[data['Target version'] != 'Backlog']
We can go a step further and group this data by the sprint it belongs to:
data[data['Target version'] != 'Backlog']\
    .groupby('Target version')
We can then even create a new series of data by summing the points column each group to find our velocity (as_index means we wish to make the sprint version the row identifier for each row, this will be useful when plotting the data):
data[data['Target version'] != 'Backlog']\
    .groupby('Target version', as_index=True)\
    ['Story Points'].sum()
If you’ve entered each of these into an iPython Notebook and executed them you’ll notice that the table appeared underneath your code block.
We can use this data series to do calculations. For example to find the moving average of our sprint velocity we can do this:
velocity = data[data['Target version'] != 'Backlog']\
    .groupby('Target version', as_index=True)\
    ['Story Points'].sum()

avg_velocity = pandas.rolling_mean(velocity, window=5, min_periods=1)
We can then plot our series together (note the passing of ax to the second plot, this allows us to share the graphs on one plot):
ax = velocity.plot(kind='bar', color='steelblue', label="Velocity",
                   legend=True, title="Velocity", figsize=(12,8))
avg_velocity.plot(ax=ax, color='r', style='.-', label="Average velocity (window=5)",
                  legend=True)
ax.xaxis.grid(False)
You can view the full notebook for this demo online. If you want to learn more about Pandas read 10 minutes to Pandas. Of course what makes iPython Notebooks so much more powerful than Excel, SPSS and R is our ability to use any 3rd party Python package we like. Another time I’ll show how we can use a 3rd party Python-Redmine API to load dataframes to extract metrics from the individual issues’ journals.				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Returning screenshots in Gitlab CI (and Travis CI)</title>
    <id>http://fedoraplanet.org/20/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/20/" />
    <author>
      <name>Danielle Madeley(danni)</name>
    </author>
    <content type="html/text">ORIGINALLY POSTED ON IXA.IO
Our code base includes a large suite of functional tests using Lettuce, Selenium and PhantomJS. When a test fails, we have a hook that captures the current screen contents and writes it to a file. In an ideal CI system these would be collected as a failure artifact (along with the stack trace, etc.) but that’s not currently possible withGitlab CI (hint hint Gitlab team, investigate Subunit for streaming test output).
Instead what we do on Gitlab is output our images as base64 encoded text:
if $SUCCESS; then
    echo "Success"
else
    echo "Failed ------------------------------------"
    for i in Test*.html; do echo $i; cat "$i"; done
    for i in Test*.png; do echo $i; base64 "$i"; echo "EOF"; done
fi

$SUCCESS
Of course now you have test output full of meaningless base64’ed data. Enter Greasemonkey.
// ==UserScript==
// @name View CI Images
// @namespace io.ixa.ci
// @description View CI Images
// @version 1
// @match https://gitlabci/projects/*/builds/*
// ==/UserScript==

(function ($) {
    var text = $('#build-trace').html();
    text = text.replace(/(Test_.+\.png)\n([A-Za-z0-9\n\/\+=]+)\nEOF\n/g,
                        '&amp;lt;h2&amp;gt;$1&amp;lt;/h2&amp;gt;&amp;lt;img src="data:image/png;base64,$2" ' +
                        'style="display:block; max-width:800px; width: auto; height: auto;" ' +
                        '/&amp;gt;');
 
    $('#build-trace').html(text);
})(jQuery);
Web browsers (handily) can already display base64’ed images. This little user script will match builds on the CI server you specify and then replace those huge chunks of base64 with the image they represent.
This technique could easily be replicated on Travis CI by updating the jQuery selector.				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">SDN/NFV DevRoom at FOSDEM: Deadline approaching!</title>
    <id>http://fedoraplanet.org/21/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/21/" />
    <author>
      <name>Dave Neary(bolsh)</name>
    </author>
    <content type="html/text">We extended the deadline for the SDN/NFV DevRoom at FOSDEM to Wednesday, November 25th recently – and we now have the makings of a great line-up!
To date, I have received proposals about open source VNFs, dataplane acceleration and accelerated virtual switching, an overview of routing on the internet that looks fascinating, open switch design and operating systems, traffic generation and testing, and network overlays.
I am still interested in having a few more NFV focussed presentations, and one or two additional SDN controller projects – and any other topics you might think would tickle our fancy! Just over 24 hours until the deadline.				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Fetching and Extending Update Access Key expiry date for IBM's POWER8 Firmware</title>
    <id>http://fedoraplanet.org/22/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/22/" />
    <author>
      <name>Chandni Verma(glassrose)</name>
    </author>
    <content type="html/text">On IBM's POWER8 systems there was no way to have Update Access Keys updated till now.After the updated POWER8 firmware, with my commits merged to upstream candidate "next" branch of powerpc-utils's activate_firmware utility last week, and with the ongoing efforts of the Electronic Service Agent team based on my work, it will soon be possible to make the update happen on the fly on provisioning a new update-access-key to the utility.IBM Power8 customers will also be able to look at the current UAK Expiry date to make a decision as to when to update the system with a new key and verify whether date has been updated after providing the key or not.Quoting the man page the options added to activate_firmware utility are:-e [keyfile]When used with this option, the command either fetches the current Update AccessKey expiry date or sets the Update Access Key expiry date if  isprovided.The activate_firmware utility will not directly be used by the end user but by an update_flash script to view or extend the firmware entitlement date by providing a new update-access-key.Enjoy!				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Concurso Universitario de Software Libre 2015-2016</title>
    <id>http://fedoraplanet.org/23/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/23/" />
    <author>
      <name>Aleksander Morgado(aleksander_m)</name>
    </author>
    <content type="html/text">Long time no post!

A quick reminder for students (*) in Spain interested in participating in this year’s CUSL, the deadline for the project proposals has been extended until December 1st:
https://www.concursosoftwarelibre.org/1516
You’re still on time to submit a proposal!
* Universidad, bachiller, ciclos de grado medio…Filed under: FreeDesktop Planet, GNOME Planet, GNU Planet, Meetings, Planets, Uncategorized   				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Improve Stratup time of Logs</title>
    <id>http://fedoraplanet.org/24/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/24/" />
    <author>
      <name>Jonathan Kang(jkang)</name>
    </author>
    <content type="html/text">It's been a long time that I haven't written a blog. :-(Recently(actually I a long time ago) I noticed that it take me a very long time to open Logs. I did use a timer to see how long it takes me exactly. And I was surprised to know it takes me more than 4 minutes! It's a lot. I really cannot stand it any more. Then I began to investigate what's wrong with Logs.I implemented a feature that viewing the latest five boots in this summer as part of my GSoC project. The commit can be found here. In this patch, to get the latest 5 boots, I fetched all the boots available in the system. Why I do this? I learned to do this from part of the source codes of journalctl. I have more than 700 boots in my laptop. So it takes quite a while for Logs to iterate those 700+ boots. And of course the same result for "journalctl --list-boots". It also takes me more than 4 minutes to get the output.Logs only show users the latest 5 boots. So obviously it's not necessary to fetch all available boots. Then I investigated the latest source code of journalctl and found a piece of improved source code.Well, the general idea to fix it is, to iterate boots from the latest boot to the earliest one. But we only iterate 5 times, and that's enough.Firstly, I used sd_journal_seek_tail() to seek to the end of the journal(that's also the last log entry of the latest boot) and get the realtime timestamp of the current log entry. Then get the latest boot's boot ID and sd_journal_add_match() to only filter log entries from the specific boot. sd_journal_seek_head() will be used to seek to the first log entry of the latest boot, then we get the realtime timestamp using sd_journal_get_realtime_usec(). So right now we finished the operations for a single boot, and then I use sd_journal_previous() to seek to the last log entry of the second latest boot. Then just follow step above to get the next few available boots.The commit for this can be found here.After this patch, the startup time of Logs for those who have hundreds of boots in their system has been improved significantly. At least it only takes me a few seconds to open Logs.				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">From “power on” to “gtk GUI usable” as fast as possible</title>
    <id>http://fedoraplanet.org/25/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/25/" />
    <author>
      <name>Olivier Sessink(Oli747)</name>
    </author>
    <content type="html/text">In my Raspberry Pi + Hifiberry-amp + Pitft project I’ve been looking how to speed up the boot process. 
[edit] I updated various parts of this post with suggestions from the comments. [/edit]
The original boot process took around 60 seconds from “power on” until my gtk app was visible and responding. I used the original (Wheezy based) raspbian, with autologon on tty1, and in the .bash_profile I called startx. In /home/pi/.xinitrc I started my application without starting a display manager:
#!/bin/sh
PYTHONIOENCODING=utf_8
export PYTHONIOENCODING
exec /usr/bin/python /home/pi/sqgui2.py
(b.t.w. the PYTHONIOENCODING is there otherwise python will give an exception when calling print with a non-ascii unicode character)
By removing a few services from the init process I removed 10 seconds from the boot process. Still 50 seconds. But further options on Raspbian Wheezy are limited.
Next step was to move to Raspbian Jessie, which has systemd. This gave an unwanted side effect: the hifiberry was detected correctly, but did not produce any sound anymore. Removing a line added for the pitft device_tree=bcm2708-rpi-b-plus.dtb from /boot/config.txt fixed this problem. And the pitft is still working.
In systemd I can start X11 as soon as userspace is running. However this generated an error – the touchscreen device has to be available first. The touchscreen input is in udev configured as /dev/input/touchscreen. I created /etc/systemd/system/xinit-login.service with the following content:
[Unit]
Wants=dev-input-touchscreen.device
After=dev-input-touchscreen.device
DefaultDependencies=false
[Service]
Type=simple
ExecStart=/bin/su pi -l -c /usr/bin/xinit -- VT08
WorkingDirectory=/home/pi/
[Install]
WantedBy=local-fs.target
[edit] with suggestions from the comments in now looks like: 
[Unit]
Wants=dev-input-touchscreen.device
After=dev-input-touchscreen.device
DefaultDependencies=false
[Service]
Type=simple
ExecStart=/usr/bin/xinit
WorkingDirectory=/home/pi/
User=pi
Group=Users
Environment=PYTHONIOENCODING=utf_8
[Install]
WantedBy=local-fs.target
and .xinitrc is now a hardlink to the gtk application sqgui.py [/edit]
This makes my xinit session start directly after the touchscreen device is available. This reduced the startup time to 28 seconds. Much better! (b.t.w. I haven’t look if all entries in xinit-login.service are correct, perhaps the contents can be improved).
Systemd has a good tool called systemd-analyze which analyzes the boot process. That way you can easily see which parts take too much time. That helped me to strip off another 2 seconds. An interesting question is how the udev config can be improved to create the touchscreen device earlier in the boot process. Another interesting question is how X11 can be configured to start faster, or how python + gtk3 can be configured to start faster. If you have any suggestions please leave them in the comments.
Next thing was to make the system readonly. I installed busybox-syslogd instead of rsyslogd, since it can do in-memory logging. [edit] I now switched to systemd-journald for in memory logging [/edit]
I analyzed which directories changed after a reboot, and moved those to a tmpfs in-memory filesystem. The /etc/fstab now looks like:
proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults,ro          0       2
/dev/mmcblk0p2  /               ext4    defaults,noatime,ro  0       1
tmpfs 		/tmp 	 	tmpfs 	defaults,noatime 	0 	0
tmpfs 		/var/lock 	tmpfs 	defaults,noatime 	0 	0
tmpfs 		/var/lib/dhcpcd5 	tmpfs 	defaults,noatime 	0 	0
tmpfs 		/var/log 	tmpfs 	defaults,noatime 0 0
Possibly this can be optimized with a single tmpfs mount and symlinks to reduce the mount time of 4 tmpfs filesystems. 
[edit] did that, they are all symlinks to /tmp now [/edit]
The only remaining issue that I didn’t solve yet is handling of /etc/resolv.conf when moving the setup to a different network. Because /etc/ is readonly the resolv.conf is now fixed for my local wifi network. 
[edit] disabling the UART, and moving from the debian networking scripts to systemd-networkd reduced the boot time to 21 seconds! [/edit]   				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Task-oriented desktop and applications?</title>
    <id>http://fedoraplanet.org/26/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/26/" />
    <author>
      <name>Sébastien Wilmet(swilmet)</name>
    </author>
    <content type="html/text">I wanted to add a comment to Allan’s blog post The next big thing, but too late! comments are already closed (side note, I think it’s a general problem on blogs.gnome.org or it’s a WordPress issue, or both).
So, at Flock 2014, Langdon White talked about “Fedora for Developers” (video), with the following idea, among other things: Desktop integration with “tasks” (with saved state).
It reminded me about a discussion that I had with gedit developers back in 2011. We talked about profiles: being able to create different gedit profiles, for example one for the C language and one for Vala. Different gedit instances could be launched with different profiles. They would behave as independent apps, with different settings, different plugins activated, a different UI state, and so on. Of course a profile could be created for each programming project, or… task.
But a task often involves launching several applications. So to resume a complete task quickly, in one step, it either needs some desktop integration, or another application could be responsible to create tasks and resume them. But either way it needs coordination with applications.				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">CMake: dependencies between targets and files and custom commands</title>
    <id>http://fedoraplanet.org/27/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/27/" />
    <author>
      <name>Sam Thursfield(ssam2)</name>
    </author>
    <content type="html/text">As I said in my last post about CMake, targets are everything in CMake. Unfortunately, not everything is a target though!
If you’ve tried do anything non-trivial in CMake using the add_custom_command() command, you may have got stuck in this horrible swamp of confusion. If you want to generate some kind of file at build time, in some manner other than compiling C or C++ code, then you need to use a custom command to generate the file. But files aren’t targets and have all sorts of exciting limitations to make you forget everything you ever new about dependency management.
What makes it so hard is that there’s not one limitation, but several. Here is a hopefully complete list of things you might want to do in CMake that involve custom commands and custom targets depending on each other, and some explainations as to why things don’t work the way that you might expect.
1. Dependencies between targets
This is CMake at its simplest (and best).
cmake_minimum_required(VERSION 3.2)

add_library(foo foo.c)

add_executable(bar bar.c)
target_link_libraries(bar foo)
You have a library, and a program that depends on it. When you run CMake, both of them get built. Ideal! This is great!
What is “all”, in the dependency graph to the left? It’s a built in target, and it’s the default target. There are also “install” and “test” targets built in (but no “clean” target).
2. Custom targets
If your project is a good one then maybe you use a documentation tool like GTK-Doc or Doxygen to generate documentation from the code.
This is where add_custom_command() enters your life. You may live to regret ever letting it in.
cmake_minimum_required(VERSION 3.2)

add_custom_command(
    OUTPUT
        docs/doxygen.stamp
    DEPENDS
        docs/Doxyfile
    COMMAND
        doxygen docs/Doxyfile
    COMMAND
        cmake -E touch docs/doxygen.stamp
    COMMENT
        "Generating API documentation with Doxygen"
    VERBATIM
    )
We have to create a ‘stamp’ file because Doxygen generates lots of different files, and we can’t really tell CMake what to expect. But actually, here’s what to expect: nothing! If you build this, you get no output. Nothing depends on the documentation, so it isn’t built.
So we need to add a dependency between docs/doxygen.stamp and the “all” target. How about using add_dependencies()? No, you can’t use that with any of the built in targets. But as a special case, you can use add_custom_target(ALL) to create a new target attached to the “all” target:
add_custom_target(
    docs ALL
    DEPENDS docs/doxygen.stamp
    )

In practice, you might also want to make the custom command depend on all your source code, so it gets regenerated every time you change the code. Or, you might want to remove the ALL from your custom target, so that you have to explicitly run make docs to generate the documentation.
This is also discussed here.
3. Custom commands in different directories
Another use case for add_custom_command() is generating source code files using 3rd party tools.
### Toplevel CMakeLists.txt
cmake_minimum_required(VERSION 3.2)

add_subdirectory(src)
add_subdirectory(tests)


### src/CMakeLists.txt
add_custom_command(
    OUTPUT
        ${CMAKE_CURRENT_BINARY_DIR}/foo.c
    COMMAND
        cmake -E echo "Generate my C code" &amp;gt; foo.c
    VERBATIM
    )


### tests/CMakeLists.txt
add_executable(
    test-foo
        test-foo.c ${CMAKE_CURRENT_BINARY_DIR}/../src/foo.c
    )

add_test(
    NAME test-foo
    COMMAND test-foo
    )
How does this work? Actually it doesn’t! You’ll see the following error when you run CMake:
CMake Error at tests/CMakeLists.txt:1 (add_executable):
  Cannot find source file:

    /home/sam/point3/build/src/foo.c

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx
CMake Error: CMake can not determine linker language for target: test-foo
CMake Error: Cannot determine link language for target "test-foo".
Congratulations, you’ve hit bug 14633! The fun thing here is that generated files don’t behave anything like targets. Actually they can only be referenced in the file that contains the corresponding add_custom_command() call. So when we refer to the generated foo.c in tests/CMakeLists.txt, CMake actually has no idea where it could come from, so it raises an error.

As the corresponding FAQ entry describes, there are two things you need to do to work around this limitation.
The first is to wrap your custom command in a custom target. Are you noticing a pattern yet? Most of the workarounds here are going to involve wrapping custom commands in custom targets. In src/CMakeLists.txt, you do this:
add_custom_target(
    generate-foo
    DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/../src/foo.c
    )
Then, in tests/CMakeLists.txt, you can add a dependency between “test-foo” and “generate-foo”:
add_dependency(test-foo generate-foo)
That’s enough to ensure that foo.c now gets generated before the build of test-foo begins, which is obviously important. If you try to run CMake now, you’ll hit the same error, because CMake still has no idea where that generated foo.c file might come from. The workaround here is to manually set the GENERATED target property:
set_source_files_properties(
    ${CMAKE_CURRENT_BINARY_DIR}/../src/foo.c
    PROPERTIES GENERATED TRUE
    )

Note that this is a bit of a contrived example. In most cases, the correct solution is to do this:
### src/CMakeLists.txt
add_library(foo foo.c)

### tests/CMakeLists.txt
target_link_libraries(test-foo foo)
Then you don’t have to worry about any of the nonsense above, because libraries are proper targets, and you can use them anywhere.
Even if it’s not practical to make a library containing ‘foo.c’, there must be some other target that links against it in the same directory that it is generated in. So instead of creating a “generate-foo” target, you can make “test-foo” depend on whatever other target links to “foo.c”.
4. Custom commands and parallel make
I came into this issue while doing something pretty unusual with CMake: wrapping a series of Buildroot builds. Imagine my delight at discovering that, when parallel make was used, my CMake-generated Makefile was running the same Buildroot build multiple times at the same time! That is not what I wanted!
It turns out this is a pretty common issue. The crux of it is that with the “Unix Makefiles” backend, multiple toplevel targets run as an independent, parallel make processes. Files aren’t targets, and unless something is a target then it doesn’t get propagated around like you would expect.
Here is the test case:
cmake_minimum_required(VERSION 3.2)

add_custom_command(
    OUTPUT gen
    COMMAND sleep 1
    COMMAND cmake -E echo Hello &amp;gt; gen
    )

add_custom_target(
    my-all-1 ALL DEPENDS gen
    )

add_custom_target(
    my-all-2 ALL DEPENDS gen
    )
If you generate a Makefile from this and run make -j 2, you’ll see the following:
Scanning dependencies of target my-all-2
Scanning dependencies of target my-all-1
[ 50%] Generating gen
[100%] Generating gen
[100%] Built target my-all-2
[100%] Built target my-all-1
If creating ‘gen’ takes a long time, then you really don’t want it to happen multiple times! It may even cause disasters, for example running make twice at once in the same Buildroot build tree is not pretty at all.

As explained in bug 10082, the solution is (guess what!) to wrap the custom command in a custom target!
add_custom_target(make-gen DEPENDS gen)



Then you change the custom targets to depend on “make-gen”, instead of the file ‘gen’. Except! Be careful when doing that — because there is another trap waiting for you!
5. File-level dependencies of custom targets are not propagated
If you read the documentation of add_custom_command() closely, and you look at the DEPENDS keyword argument, you’ll see this text:
If DEPENDS specifies any target (created by the add_custom_target(), add_executable(), or add_library() command) a target-level dependency is created to make sure the target is built before any target using this custom command. Additionally, if the target is an executable or library a file-level dependency is created to cause the custom command to re-run whenever the target is recompiled.
This sounds quite nice, like more or less what you would expect. But the important bit of information here is what CMake doesn’t do: when a custom target depends on another custom target, all the file level dependencies are completely ignored.
Here’s your final example for the evening:
cmake_minimum_required(VERSION 3.2)

set(SPECIAL_TEXT foo)

add_custom_command(
    OUTPUT gen1
    COMMAND cmake -E echo ${SPECIAL_TEXT} &amp;gt; gen1
    )

add_custom_target(
    gen1-wrapper
    DEPENDS gen1
    )

add_custom_command(
    OUTPUT gen2
    DEPENDS gen1-wrapper
    COMMAND cmake -E copy gen1 gen2
    )

add_custom_target(
    all-generated ALL
    DEPENDS gen2
    )
This is subtly wrong, even though you did what you were told, and wrapped the custom command in a custom target.
The first time you build it:
Scanning dependencies of target gen1-wrapper
[ 50%] Generating gen1
[ 50%] Built target gen1-wrapper
Scanning dependencies of target all-generated
[100%] Generating gen2
[100%] Built target all-generated
But then touch the file ‘gen1’, or overwrite it with something other text, or change the value of SPECIAL_TEXT in CMakeLists.txt to something else, and you will see this:
[ 50%] Generating gen1
[ 50%] Built target gen1-wrapper
[100%] Built target all-generated
There’s no file-level dependency created between ‘gen2’ and ‘gen1’, so ‘gen2’ never gets updated, and things get all weird.

You can’t just depend on gen1 instead of gen1-wrapper, because it may end up being built multiple times! See the previous point. Instead, you need to depend on the “gen1-wrapper” target and the file itself:
add_custom_command(
    OUTPUT gen2
    DEPENDS gen1-wrapper gen1
    COMMAND cmake -E copy gen1 gen2
    )
As the documentation says, this only applies to targets wrapping add_custom_command() output. If ‘gen1’ was a library created with add_library, things would work how you expect.

Conclusion
Maybe I just have a blunt head, but I found all of this quite difficult to work out. I can understand why CMake works this way, but I think there is plenty of room for improvement in the documentation where this is explained. Hopefully this guide has gone some way to making things clearer.
If you have any other dependency-related traps in CMake that you’ve hit, please comment and I’ll add them to this list…   				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Kubernetes from the ground up</title>
    <id>http://fedoraplanet.org/28/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/28/" />
    <author>
      <name>Ruben Vermeersch(rubenv)</name>
    </author>
    <content type="html/text">I really loved reading Git from the bottom up when I was learning Git, which starts by showing how all the pieces fit together. Starting with the basics and gradually working towards the big picture is a great way to understand any complex piece of technology.

Recently I’ve been working with Kubernetes, a fantastic cluster manager. Like Git it is tremendously powerful, but the learning curve can be quite steep.

But there is hope. Kamal Marhubi has written a great series of articles that take the same approach: start from the basic building blocks, build with those.

Currently available:


What even is a kubelet?
Kubernetes from the ground up: the API server
Kubernetes from the ground up: the scheduler


Highly recommended.


Comments | More on rocketeer.be | @rubenv on Twitter				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">gspell news</title>
    <id>http://fedoraplanet.org/29/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/29/" />
    <author>
      <name>Sébastien Wilmet(swilmet)</name>
    </author>
    <content type="html/text">
gspell is now fully hosted on gnome.org!
There is now a mailing list.
In addition to LaTeXila, gspell is now also used by gedit (5,800 lines removed, yay!).
The 0.1.x version has branched and is meant to be installed alongside GNOME 3.18.
If everything goes fine, the 1.0 version will be released at the same time as GNOME 3.20, with a stable API.

API reviews are more than welcome!
Stay tuned.				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Introducing sd-event</title>
    <id>http://fedoraplanet.org/30/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/30/" />
    <author>
      <name>Lennart Poettering(mezcalero)</name>
    </author>
    <content type="html/text">The Event Loop API of libsystemd
When we began working on
systemd we built
it around a hand-written ad-hoc event loop, wrapping Linux
epoll. The more
our project grew the more we realized the limitations of using raw
epoll:


As we used
  timerfd
  for our timer events, each event source cost one file descriptor and
  we had many of them! File descriptors are a scarce resource on UNIX,
  as
  RLIMIT_NOFILE
  is typically set to 1024 or similar, limiting the number of
  available file descriptors per process to 1021, which isn't
  particularly a lot.


Ordering of event dispatching became a nightmare. In many cases, we
  wanted to make sure that a certain kind of event would always be
  dispatched before another kind of event, if both happen at the same
  time. For example, when the last process of a service dies, we might
  be notified about that via a SIGCHLD signal, via an
  sd_notify() "STATUS="
  message, and via a control group notification. We wanted to get
  these events in the right order, to know when it's safe to process
  and subsequently release the runtime data systemd keeps about the
  service or process: it shouldn't be done if there are still events
  about it pending.


For each program we added to the systemd project we noticed we were
  adding similar code, over and over again, to work with epoll's
  complex interfaces. For example, finding the right file descriptor
  and callback function to dispatch an epoll event to, without running
  into invalidated pointer issues is outright difficult and requires
  non-trivial code.


Integrating child process watching into our event loops was much
  more complex than one could hope, and even more so if child process
  events should be ordered against each other and unrelated kinds of
  events.


Eventually, we started working on
sd-bus. At
the same time we decided to seize the opportunity, put together a
proper event loop API in C, and then not only port sd-bus on top of
it, but also the rest of systemd. The result of this is
sd-event. After
almost two years of development we declared sd-event stable in systemd
version 221, and published it as official API of libsystemd.
Why?
sd-event.h,
of course, is not the first event loop API around, and it doesn't
implement any really novel concepts. When we started working on it we
tried to do our homework, and checked the various existing event loop
APIs, maybe looking for candidates to adopt instead of doing our own,
and to learn about the strengths and weaknesses of the various
implementations existing. Ultimately, we found no implementation that
could deliver what we needed, or where it would be easy to add the
missing bits: as usual in the systemd project, we wanted something
that allows us access to all the Linux-specific bits, instead of
limiting itself to the least common denominator of UNIX. We weren't
looking for an abstraction API, but simply one that makes epoll usable
in system code.
With this blog story I'd like to take the opportunity to introduce you
to sd-event, and explain why it might be a good candidate to adopt as
event loop implementation in your project, too.
So, here are some features it provides:


I/O event sources, based on epoll's file descriptor watching,
  including edge triggered events (EPOLLET). See
  sd_event_add_io(3).


Timer event sources, based on timerfd_create(), supporting the
  CLOCK_MONOTONIC, CLOCK_REALTIME, CLOCK_BOOTIME clocks, as well
  as the CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM clocks that
  can resume the system from suspend. When creating timer events a
  required accuracy parameter may be specified which allows coalescing
  of timer events to minimize power consumption. For each clock only a
  single timer file descriptor is kept, and all timer events are
  multiplexed with a priority queue. See
  sd_event_add_time(3).


UNIX process signal events, based on
  signalfd(2),
  including full support for real-time signals, and queued
  parameters. See sd_event_add_signal(3).


Child process state change events, based on
  waitid(2). See
  sd_event_add_child(3).


Static event sources, of three types: defer, post and exit, for
  invoking calls in each event loop, after other event sources or at
  event loop termination. See
  sd_event_add_defer(3).


Event sources may be assigned a 64bit priority value, that controls
  the order in which event sources are dispatched if multiple are
  pending simultanously. See
  sd_event_source_set_priority(3).


The event loop may automatically send watchdog notification messages
  to the service manager. See sd_event_set_watchdog(3).


The event loop may be integrated into foreign event loops, such as
  the GLib one. The event loop API is hence composable, the same way
  the underlying epoll logic is. See
  sd_event_get_fd(3)
  for an example.


The API is fully OOM safe.


A complete set of documentation in UNIX man page format is
  available, with
  sd-event(3)
  as the entry page.


It's pretty widely available, and requires no extra
  dependencies. Since systemd is built on it, most major distributions
  ship the library in their default install set.


After two years of development, and after being used in all of
  systemd's components, it has received a fair share of testing already,
  even though we only recently decided to declare it stable and turned
  it into a public API.


Note that sd-event has some potential drawbacks too:


If portability is essential to you, sd-event is not your best
  option. sd-event is a wrapper around Linux-specific APIs, and that's
  visible in the API. For example: our event callbacks receive
  structures defined by Linux-specific APIs such as signalfd.


It's a low-level C API, and it doesn't isolate you from the OS
  underpinnings. While I like to think that it is relatively nice and
  easy to use from C, it doesn't compromise on exposing the low-level
  functionality. It just fills the gaps in what's missing between
  epoll, timerfd, signalfd and related concepts, and it does not hide
  that away.


Either way, I believe that sd-event is a great choice when looking for
an event loop API, in particular if you work on system-level software
and embedded, where functionality like timer coalescing or
watchdog support matter.
Getting Started
Here's a short example how to use sd-event in a simple daemon. In this
example, we'll not just use sd-event.h, but also sd-daemon.h to
implement a system service.
#include &amp;lt;alloca.h&amp;gt;
#include &amp;lt;endian.h&amp;gt;
#include &amp;lt;errno.h&amp;gt;
#include &amp;lt;netinet/in.h&amp;gt;
#include &amp;lt;signal.h&amp;gt;
#include &amp;lt;stdbool.h&amp;gt;
#include &amp;lt;stdio.h&amp;gt;
#include &amp;lt;stdlib.h&amp;gt;
#include &amp;lt;string.h&amp;gt;
#include &amp;lt;sys/ioctl.h&amp;gt;
#include &amp;lt;sys/socket.h&amp;gt;
#include &amp;lt;unistd.h&amp;gt;

#include &amp;lt;systemd/sd-daemon.h&amp;gt;
#include &amp;lt;systemd/sd-event.h&amp;gt;

static int io_handler(sd_event_source *es, int fd, uint32_t revents, void *userdata) {
        void *buffer;
        ssize_t n;
        int sz;

        /* UDP enforces a somewhat reasonable maximum datagram size of 64K, we can just allocate the buffer on the stack */
        if (ioctl(fd, FIONREAD, &amp;amp;sz) &amp;lt; 0)
                return -errno;
        buffer = alloca(sz);

        n = recv(fd, buffer, sz, 0);
        if (n &amp;lt; 0) {
                if (errno == EAGAIN)
                        return 0;

                return -errno;
        }

        if (n == 5 &amp;amp;&amp;amp; memcmp(buffer, "EXIT\n", 5) == 0) {
                /* Request a clean exit */
                sd_event_exit(sd_event_source_get_event(es), 0);
                return 0;
        }

        fwrite(buffer, 1, n, stdout);
        fflush(stdout);
        return 0;
}

int main(int argc, char *argv[]) {
        union {
                struct sockaddr_in in;
                struct sockaddr sa;
        } sa;
        sd_event_source *event_source = NULL;
        sd_event *event = NULL;
        int fd = -1, r;
        sigset_t ss;

        r = sd_event_default(&amp;amp;event);
        if (r &amp;lt; 0)
                goto finish;

        if (sigemptyset(&amp;amp;ss) &amp;lt; 0 ||
            sigaddset(&amp;amp;ss, SIGTERM) &amp;lt; 0 ||
            sigaddset(&amp;amp;ss, SIGINT) &amp;lt; 0) {
                r = -errno;
                goto finish;
        }

        /* Block SIGTERM first, so that the event loop can handle it */
        if (sigprocmask(SIG_BLOCK, &amp;amp;ss, NULL) &amp;lt; 0) {
                r = -errno;
                goto finish;
        }

        /* Let's make use of the default handler and "floating" reference features of sd_event_add_signal() */
        r = sd_event_add_signal(event, NULL, SIGTERM, NULL, NULL);
        if (r &amp;lt; 0)
                goto finish;
        r = sd_event_add_signal(event, NULL, SIGINT, NULL, NULL);
        if (r &amp;lt; 0)
                goto finish;

        /* Enable automatic service watchdog support */
        r = sd_event_set_watchdog(event, true);
        if (r &amp;lt; 0)
                goto finish;

        fd = socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0);
        if (fd &amp;lt; 0) {
                r = -errno;
                goto finish;
        }

        sa.in = (struct sockaddr_in) {
                .sin_family = AF_INET,
                .sin_port = htobe16(7777),
        };
        if (bind(fd, &amp;amp;sa.sa, sizeof(sa)) &amp;lt; 0) {
                r = -errno;
                goto finish;
        }

        r = sd_event_add_io(event, &amp;amp;event_source, fd, EPOLLIN, io_handler, NULL);
        if (r &amp;lt; 0)
                goto finish;

        (void) sd_notifyf(false,
                          "READY=1\n"
                          "STATUS=Daemon startup completed, processing events.");

        r = sd_event_loop(event);

finish:
        event_source = sd_event_source_unref(event_source);
        event = sd_event_unref(event);

        if (fd &amp;gt;= 0)
                (void) close(fd);

        if (r &amp;lt; 0)
                fprintf(stderr, "Failure: %s\n", strerror(-r));

        return r &amp;lt; 0 ? EXIT_FAILURE : EXIT_SUCCESS;
}



The example above shows how to write a minimal UDP/IP server, that
listens on port 7777. Whenever a datagram is received it outputs its
contents to STDOUT, unless it is precisely the string EXIT\n in
which case the service exits. The service will react to SIGTERM and
SIGINT and do a clean exit then. It also notifies the service manager
about its completed startup, if it runs under a service
manager. Finally, it sends watchdog keep-alive messages to the service
manager if it asked for that, and if it runs under a service manager.
When run as systemd service this service's STDOUT will be connected to
the logging framework of course, which means the service can act as a
minimal UDP-based remote logging service.
To compile and link this example, save it as event-example.c, then run:
$ gcc event-example.c -o event-example `pkg-config --cflags --libs libsystemd`



For a first test, simply run the resulting binary from the command
line, and test it against the following netcat command line:
$ nc -u localhost 7777



For the sake of brevity error checking is minimal, and in a real-world
application should, of course, be more comprehensive. However, it
hopefully gets the idea across how to write a daemon that reacts to
external events with sd-event.
For further details on the functions used in the example above, please
consult the manual pages:
sd-event(3),
sd_event_exit(3),
sd_event_source_get_event(3),
sd_event_default(3),
sd_event_add_signal(3),
sd_event_set_watchdog(3),
sd_event_add_io(3),
sd_notifyf(3),
sd_event_loop(3),
sd_event_source_unref(3),
sd_event_unref(3).
Conclusion
So, is this the event loop to end all other event loops? Certainly
not. I actually believe in "event loop plurality". There are many
reasons for that, but most importantly: sd-event is supposed to be an
event loop suitable for writing a wide range of applications, but it's
definitely not going to solve all event loop problems. For example,
while the priority logic is important for many usecase it comes with
drawbacks for others: if not used carefully high-priority event
sources can easily starve low-priority event sources. Also, in order
to implement the priority logic, sd-event needs to linearly iterate
through the event structures returned by
epoll_wait(2)
to sort the events by their priority, resulting in worst case
O(n*log(n)) complexity on each event loop wakeup (for n = number of
file descriptors). Then, to implement priorities fully, sd-event only
dispatches a single event before going back to the kernel and asking
for new events. sd-event will hence not provide the theoretically
possible best scalability to huge numbers of file descriptors. Of
course, this could be optimized, by improving epoll, and making it
support how todays's event loops actually work (after, all, this is
the problem set all event loops that implement priorities -- including
GLib's -- have to deal with), but even then: the design of sd-event is focussed on
running one event loop per thread, and it dispatches events strictly
ordered. In many other important usecases a very different design is
preferable: one where events are distributed to a set of worker threads
and are dispatched out-of-order.
Hence, don't mistake sd-event for what it isn't. It's not supposed to
unify everybody on a single event loop. It's just supposed to be a
very good implementation of an event loop suitable for a large part of
the typical usecases.
Note that our APIs, including
sd-bus, integrate nicely into
sd-event event loops, but do not require it, and may be integrated
into other event loops too, as long as they support watching for time
and I/O events.
And that's all for now. If you are considering using sd-event for your
project and need help or have questions, please direct them to the
systemd mailing list.				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">A GTK+ update</title>
    <id>http://fedoraplanet.org/31/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/31/" />
    <author>
      <name>Matthias Clasen(mclasen)</name>
    </author>
    <content type="html/text">You may have noticed that GTK+ master has a large number of changes in the CSS area. As some like to put it:
Oh NO! they’re breaking themes again!
Which is certainly one way to look at it, but I think it misses the point a little bit – since the effort is actually meant to make life easier for anybody who wants to change the appearance of GTK+ widgets.
What changes are we making ?
As a first step, we are introducing CSS nodes. A CSS node has an element name, a state and it can have style classes.  Each widget has one or more CSS nodes, and they are organized in a tree.  GTK+’s CSS machinery matches CSS selectors on this CSS node tree, and as a result, each node carries a full set of CSS properties.
The transition to CSS nodes is mostly done in GTK+ 3.19.2.
In a  second step, we will integrate CSS nodes into size allocation and rendering. This will bring consistent support for margins, padding and min-width/height for all widgets. This step is currently being prepared on the wip/otte/gadget branch.
None of this is exposed as API yet  (with some small exceptions, such as gtk_widget_path_iter_set_object_name ) . It needs more time to prove itself before we are ready to offer this as stable API.
Why are we doing this ?
There are a number of reasons for doing these changes. In no particular order,

Element names and style classes use by widgets for their CSS nodes (and their tree relationships) are now documented and provide a stable interface for themes and custom CSS.
Element names provide a level of abstraction over the direct use of type names, and will allow reuse of CSS. You wil be able to add a “check” node to your own widget, whereas you can’t call your own widget GtkCheckButton.
CSS nodes are permanent. This implies that they can carry state, e.g. for running CSS animations. They can also notify on state changes.
CSS nodes can explored and manipulated in GtkInspector.
CSS nodes (in particular, the second phase) force us to clean up all the irregularities of the current widget rendering and move to a much more regular model, where every node draws a background and a  frame. 
Positional selectors such as :first-child now work everywhere, including parts of a widget. You can e.g., use :nth-child(even) to style notebook tabs.

What do you have to do ?
If you maintain a theme or custom CSS for an application,  update your selectors to use the documented element names and classes. The changes in Adwaita can serve as an example for the kind of changes that are needed.
If you use GTK+’s style machinery to render non-widget content (like mutter does for window decorations), use
gtk_widget_path_iter_set_object_name to make your widget paths look like the widgets they imitate.
If you have code that pokes colors out of GtkStyleContext to do your own rendering, you should really port to use the gtk_render APIs and custom CSS. If you want to keep your existing code working for now, you need to minimally fix gtk_style_context_get_color calls to use the correct state.  Ie. go from
gtk_style_context_get_color (context,
                        GTK_STATE_FLAG_SELECTED,
                        &amp;amp;color);
to
gtk_style_context_save (context);
gtk_style_context_set_state (contexts,
                        GTK_STATE_FLAG_SELECTED);
gtk_style_context_get_color (context,
          gtk_style_context_get_state (context),
          &amp;amp;color);
gtk_style_context_restore (context);
What else is new ?
Support for help overlays  got merged into GTK+ and is available in 3.19.1. We’ve gotten some feedback from early adopters and added a few more features, so things should be in good shape for wider adoption: please add it to your favorite GTK+ application, and update this page if you do so.
Wayland support is progressing. So far in 3.19, the focus has been on straightening out issues with window and popup sizing and positioning. Many of the remaining gaps will be fixed by integrating the protocols that have been under discussion for a while now: DND actions, tablet support, pointer lock,…  Jonas just revamped the Wayland protocol development process, which should lead to faster progress on this front. For more details, see Jonas’ mail.				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">FAD G11N Event Report</title>
    <id>http://fedoraplanet.org/32/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/32/" />
    <author>
      <name>Anish Patil(anish)</name>
    </author>
    <content type="html/text">FAD G11N started with a lot of enthusiasm and energy. It was fully packed with discussions and hackathons. Discussions points How to get started with new contributors? How to get new contributors?Release based statistics for Fedora (in terms of translations)Fedora release schedule w.r.t to translations deadlines Zanata survey and how to improve Fedora g11n structure Fedora 24 planning To attract new comers and get them started, one of the suggestions was to document the whole process and my suggestion was create a online course on openlearning.com and I can help if someone wants to do it.During hackathons everyone worked on various projects and demonstrated it at the end of FAD.It was productive because for some projects some people worked together and it was for the first time fedora g11n group met in person. I have worked on zanata python client with Suanand, we tested z-p-c with latest zanata server and identified missing features.Another thing that I worked on is hunspell dictionary infra project. It's difficult to manage hunspell dictionaries. So one thought is to create online portal for it. I created a prototype for it so that and it can found on http://webwordedit-wwe.rhcloud.com/I will work on this project to create single page app.And Finally FAD ends with happy faces and looking forward to see it happen again 				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Pitivi 0.95 — Enfant Suisse</title>
    <id>http://fedoraplanet.org/33/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/33/" />
    <author>
      <name>Jean-François Fortin Tam(nekohayo)</name>
    </author>
    <content type="html/text">Hey everyone! It’s time for a new Pitivi release, 0.95. This one packs a lot of bugfixes and architectural work to further stabilize the GES backend. In this blog post, I’ll give you an overview of the new and interesting stuff this release brings, coming out from a year of hard work. It’s pretty epic and you’re in for a few surprises, so I suggest listening to this song while you’re reading this blog post.
Engine rework: completed.
Those of you who attended my talk at GUADEC 2013 might remember this particular slide:

Well, it’s done now. It’s dead and buried.
This is something I’ve had on my mind for so long, I was even having nightmares about it—literally. To give you an idea just how ancient gnonlin was from an architectural standpoint, it was created fourteen years ago, merely six months after the first release of GStreamer itself. Well, y’know, a lot of stuff happens in 13-14 years.
So, over the past year, Mathieu and Thibault gradually refactored GNonLin into NLE, the new non-linear engine inside GES. For details, see the previous two blog posts about our War Against Deadlocks: the story about the mixing elements and the story about the new engine using them (replacing gnonlin).
The resulting improvements in reliability are not only palpable in daily use, they are actually quantifiable with the results our GES gst-validate test suite runs:

In the 1.4 series: 154 tests pass out of 198 (22.2% failures)
With the 1.6 release: 198 tests pass out of 198

— “What’s going on? Give me a sitrep!”— “The tests… they all pass!”— “What?!”
Now 100% GTK, with new horizons

We were hitting various limitations and bugs (such as this) in Clutter, the library we used to display and animate the project’s timeline. Eventually we came to a point where we had to change strategy and port the timeline to use pure GTK+ widgets, with Matplotlib for drawing the keyframes on clips. Quite some work went into the new timeline.
The viewer (the widget that shows the main video preview, above the timeline) using glimagesink was causing too many problems related to embedding in the X window. We switched to the new GtkSink instead, which also allowed us to test gtkglsink at the same time, as they are compatible.
Thanks to the new GTK timeline, we have a little surprise to show here: technically, Pitivi can also work on Mac OS X now. This is not an April Fool’s joke.

Some notes about the experiment are sitting there if you’re curious. At this time, we are not supporting the Mac OS version officially, because we don’t have the resources for that (yet?). I was told that we should be able to make something available for testing a Mac build once we reach 1.0. Want to make it happen sooner? Feel free to join us and to work on that.
Wait, that’s not all. These changes also allow us to make Pitivi work with the GDK Broadway backend, meaning we can even run Pitivi in a web browser! Yep, you heard that right. Pitivi in a web browser. What could possibly go wrong? ;)

Spit polishing
An improvement we’re quite happy about is that you can finally drag &amp;amp; drop a file from a different app directly to the timeline, to create a clip.
The layers’ representation changed somewhat. Previously, an audio-video clip would be displayed as two separate clips in the timeline, one for video and one for audio, on two separate layers. At times it was pretty awkward. While porting the timeline, Thibault simplified the layers model to have the notion of generic layers, in which audio-video clips are represented as a unified clip object. This also means that there is no more wasted space if the layer has only video or only audio.
Also worth mentioning:

We have resurrected the transformation box feature, but the UI is currently very primitive. See the Clip properties &amp;gt; Transformation section when a clip is selected on the timeline. You can also drag the image in the viewer to change the position of the selected clip at the current position and you can use the mouse wheel to zoom in/out.
While editing a project, every operation is saved in a scenario file. These can be used when reporting bugs. See how to use scenarios for reporting complicated bugs easily (or if you’re feeling geeky, the details about how the scenarios are used to automatically test the GES backend).
You can now copy/paste clips in the timeline.
We’re now compatible with smaller screen resolutions (such as 1024×768) again
We removed a bunch of widgets in the layer controls. They were placeholders for future features, we should put them back once the features actually become available.
Undo/redo has been disabled until we add unit tests and make sure it works properly. Until then you can Ctrl+S regularly.
See also the release notes for 0.95.

Infrastructure changes

The Pitivi team migrated from Bugzilla to Phabricator for bug/task tracking.
We now have a script to setup the development environment from the latest daily bundle. This hybrid approach makes it very easy for new developers to start hacking on Pitivi’s Python side without needing to build the rest.
It was difficult for us to keep using Dogtail, so we moved all the integration tests to GstValidate.
Some of you have suggested that we compress the all-in-one bundles using XZ, and so we did. Our packages are now 20% lighter than uncompressed tarballs, so they will take less time to download (which is nice if you’re using the dailies to test).
With some help from Jeffrey Schroeder, I have finally upgraded our MediaWiki instance to the latest stable release. We hadn’t upgraded it in four years (thankfully it was fairly locked down so we did not run into trouble), in big part because it was not version-controlled and thus was a pain in the butt to manage. I should be able to do a better job at keeping it up-to-date from now on.

Where do we stand on the fundraiser?
In terms of donations, less than the fundraiser’s first milestone was reached. Therefore, instead of working full-time and burning through the money in a matter of a few months, Thibault and Mathieu decided to work at a slower rate while simultaneously providing professional multimedia consulting services to put food on the table.
Nonetheless, they eventually reached the point where they had worked through all the donated funds, and so they continued in their free time. The GTK+ Timeline and GtkSink work, for example, is one of the big architectural changes that Thibault had to do on his spare time, without monetary compensation whatsoever.
Now is still a good time to let others know and ask those around you to donate! We appreciate it.
A call for ruthless testing
As it is much more stable already, we recommend all users to upgrade to Pitivi 0.95 and help us find remaining issues, if any. Until this release trickles down into distributions, you can download our all-in-one bundle and try out 0.95, right here and now. Enjoy!
You’re in luck: I already spent a lot of my (very limited) spare time testing and investigating the most serious issues. In fact, one of the reasons why it’s been so long since the last release is that I have been Thibault’s worse nightmare for months (there’s a reason why my name strikes fear in the hearts of GStreamer developers):

Every two weeks or so, Thibault would come to me and say, “Hey look, I fixed all your bugs, how about we release now?”. I would then spend a day testing and return with ten more bugs. Then he would fix them all, and I would find ten other bugs in different areas. Then he would fix them, and I would find another batch that I couldn’t test last time. And so on and so forth, from spring to autumn. For example, these are the bugs I’ve found just for the GTK Timeline. Can’t believe I haven’t killed that poor guy.
Now that the blocker issues are solved, I’m quite impressed with how much more reliable this version of Pitivi is shaping out to be now. But hey, we’re not perfect, maybe there are bugs we’ve overlooked, so please grab 0.95 and try to break it as hard as you can, reporting the issues you find (especially freezes, crashes, incorrect output, etc.). We want it to be solid. Go wild.





Thank you for reading, commenting and sharing! This blog post is part of a série of articles tracking progress made with work related to the 2014 Pitivi fundraiser. Researching and writing quality articles takes a lot of time, so please be patient and enjoy the ride! 

	An update from the 2014 summer battlefront
	The 0.94 release
	The War Against Deadlocks, part 1: The story of our new thread-safe mixing elements reimplementation
	The War Against Deadlocks, part 2: GNonLin's reincarnation
	The 0.95 release, the GTK+ timeline and sink
	Measuring quality/reliability through time (clarifying what gst-validate is)
	Our all-in-one binaries building infrastructure, and why it matters
	Samples, “scenario” files and you: how you can help us reproduce (almost) any bug very easily
	The 1.0 release and closure of the fundraiser

				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">If it's not practical to redistribute free software, it's not free software in practice</title>
    <id>http://fedoraplanet.org/34/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/34/" />
    <author>
      <name>Matthew Garrett(mjg59)</name>
    </author>
    <content type="html/text">I've previously written about Canonical's obnoxious IP policy and how Mark Shuttleworth admits it's deliberately vague. After spending some time discussing specific examples with Canonical, I've been explicitly told that while Canonical will gladly give me a cost-free trademark license permitting me to redistribute unmodified Ubuntu binaries, they will not tell me what Any redistribution of modified versions of Ubuntu must be approved, certified or provided by Canonical if you are going to associate it with the Trademarks. Otherwise you must remove and replace the Trademarks and will need to recompile the source code to create your own binaries actually means.Why does this matter? The free software definition requires that you be able to redistribute software to other people in either unmodified or modified form without needing to ask for permission first. This makes it clear that Ubuntu itself isn't free software - distributing the individual binary packages without permission is forbidden, even if they wouldn't contain any infringing trademarks[1]. This is obnoxious, but not inherently toxic. The source packages for Ubuntu could still be free software, making it fairly straightforward to build a free software equivalent.Unfortunately, while true in theory, this isn't true in practice. The issue here is the apparently simple phrase you must remove and replace the Trademarks and will need to recompile the source code. "Trademarks" is defined later as being the words "Ubuntu", "Kubuntu", "Juju", "Landscape", "Edubuntu" and "Xubuntu" in either textual or logo form. The naive interpretation of this is that you have to remove trademarks where they'd be infringing - for instance, shipping the Ubuntu bootsplash as part of a modified product would almost certainly be clear trademark infringement, so you shouldn't do that. But that's not what the policy actually says. It insists that all trademarks be removed, whether they would embody an infringement or not. If a README says "To build this software under Ubuntu, install the following packages", a literal reading of Canonical's policy would require you to remove or replace the word "Ubuntu" even though failing to do so wouldn't be a trademark infringement. If an @ubuntu.com email address is present in a changelog, you'd have to change it. You wouldn't be able to ship the juju-core package without renaming it and the application within. If this is what the policy means, it's so impractical to be able to rebuild Ubuntu that it's not free software in any meaningful way.This seems like a pretty ludicrous interpretation, but it's one that Canonical refuse to explicitly rule out. Compare this to Red Hat's requirements around Fedora - if you replace the fedora-logos, fedora-release and fedora-release-notes packages with your own content, you're good. A policy like this satisfies the concerns that Dustin raised over people misrepresenting their products, but still makes it easy for users to distribute modified code to other users. There's nothing whatsoever stopping Canonical from adopting a similarly unambiguous policy.Mark has repeatedly asserted that attempts to raise this issue are mere FUD, but he won't answer you if you ask him direct questions about this policy and will insist that it's necessary to protect Ubuntu's brand. The reality is that if Debian had had an identical policy in 2004, Ubuntu wouldn't exist. The effort required to strip all Debian trademarks from the source packages would have been immense[2], and this would have had to be repeated for every release. While this policy is in place, nobody's going to be able to take Ubuntu and build something better. It's grotesquely hypocritical, especially when the Ubuntu website still talks about their belief that people should be able to distribute modifications without licensing fees.All that's required for Canonical to deal with this problem is to follow Fedora's lead and isolate their trademarks in a small set of packages, then tell users that those packages must be replaced if distributing a modified version of Ubuntu. If they're serious about this being a branding issue, they'll do it. And if I'm right that the policy is deliberately obfuscated so Canonical can encourage people to buy licenses, they won't. It's easy for them to prove me wrong, and I'll be delighted if they do. Let's see what happens.[1] The policy is quite clear on this. If you want to distribute something other than an unmodified Ubuntu image, you have two choices:Gain approval or certification from CanonicalRemove all trademarks and recompile the source code Note that option 2 requires you to rebuild even if there are no trademarks to remove.[2] Especially when every source package contains a directory called "debian"… comments				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Red Hat Enterprise Linux 7.2 – A major desktop milestone</title>
    <id>http://fedoraplanet.org/35/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/35/" />
    <author>
      <name>Christian Schaller(cschalle)</name>
    </author>
    <content type="html/text">So many of you have probably seen that RHEL 7.2 is out today. There are many important updates in this release, some of them detailed in the official RHEL 7.2 press release.
One thing however which you would only discover if you start digging into the 7.2 update is that its the first time in RHEL history that we are doing a full scale desktop update in a point release. We shipped RHEL 7.0 with GNOME 3.8 and in RHEL 7.2 we are updating it to GNOME 3.14. This brings in a lot of new major features into RHEL, like the work we did on improved HiDPI support, improved touch and gesture support, it brings GNOME Software to RHEL, the improved system status area and so on. We plan on updating the desktop further in later RHEL 7.x point releases.
This change of policy is of course important to the many RHEL Workstation customers we have, but I also hope it will make RHEL Workstation and also the CentOS Workstation more attractive options to those in the community who have been looking for a LTS version of Fedora. This policy change gives you the rock solid foundation of RHEL and the RHEL kernel and combines it with a very well tested yet fairly new desktop release. So if you feel Fedora is moving to quickly, yet have felt that RHEL on the other hand has been moving to slowly, we hope that with this change to RHEL we have found a sweet compromise.
We will of course also keep doing regular applications updates in RHEL 7.x, just like we started with in RHEL 6.x. Giving you up to date versions of things like LibreOffice, Firefox, Thunderbird and more.				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">I’m joining Endless</title>
    <id>http://fedoraplanet.org/36/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/36/" />
    <author>
      <name>Georges Basile Stavracas Neto(gbsneto)</name>
    </author>
    <content type="html/text">Some of you may have asked why I’m so silent for the last 3 weeks. Well, the titles pretty much explain things: between university duties, moving to a new house and conducting my research, I’m also joining Endless!
I’m ridiculously happy with this opportunity, and Endless folks were extremely respectful of my schedule – I’m working remotely, and only as a part-time intern. This is a great chance for me to work with FOSS on something that directly changes people’s lives!
So, wait for 2 more weeks so I can settle again, and I’ll start sending patches and crafting new features on rampage – like the good ol’ times.				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Hitori available as an xdg-app preview</title>
    <id>http://fedoraplanet.org/37/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/37/" />
    <author>
      <name>Philip Withnall(pwithnall)</name>
    </author>
    <content type="html/text">I’ve been playing a bit with xdg-app recently, and just spent half an hour packaging Hitori as an xdg-app bundle. It was remarkably easy — in fact, it only took 7 commands.
If you want to install it, make sure you’ve got xdg-app installed, then:
# Install http://sdk.gnome.org/keys/gnome-sdk.gpg to /usr/share/ostree/trusted.gpg.d first
# Then set up the runtimes (if you haven’t already)
xdg-app add-remote --user gnome-sdk http://sdk.gnome.org/repo/
xdg-app install-runtime --user gnome-sdk org.gnome.Platform 3.18
xdg-app install-runtime --user gnome-sdk org.freedesktop.Platform 1.2
# Add the repository for Hitori, then install it
xdg-app add-remote --user --no-gpg-verify pwithnall-hitori https://people.collabora.co.uk/~pwith/xdg-app/repos/hitori/
xdg-app install-app --user pwithnall-hitori org.gnome.Hitori
# Play the game!
xdg-app run org.gnome.Hitori
What works?

Playing the game
Use of X11
Icons
Desktop file

What doesn’t work (yet)?

GSettings access (I may have misconfigured this, because it’s supposed to work)
Help manual

I don’t plan to support this repository especially well, since it was just for playing around, but it shows that xdg-app is coming along nicely!				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Cockpit 0.85 Released</title>
    <id>http://fedoraplanet.org/38/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/38/" />
    <author>
      <name>Stef Walter(stefw)</name>
    </author>
    <content type="html/text">Cockpit releases every week. This week it was 0.85.
Varying users on dashboard machines
Cockpit now supports adding machines to the dashboard with different
user logins for each one. This can be useful in cases where you’re
adding cloud instances to your dashboard, and they require logging in
with a cloud-user and not the same user as your other servers.


Non standard SSH ports
When Cockpit connects to a machine that was added to the dashboard, it
does so over SSH. Cockpit can now connect on non-standard SSH ports.
See the video above.
Troubleshooting machine connectivity
Cockpit now allows you to fix connectivity issues for servers that are
added to the dashboard. This includes adjusting authentication, checking
on host keys and more.

Fix SELinux certificate file type bug
Cockpit 0.84 failed to start on certain distros because SELinux wasn’t
available or couldn’t be used to reset the certificate file context.
This bug has been fixed.
Work around bug in Firefox 42
A bug in Firefox 42 caused Cockpit to often load with a blank screen,
due to layout calculation issues. The layout code has been changed to
work around this issue.
Docker restart container timeout
Previously Cockpit called the Docker API without a timeout when
restarting containers. This caused Docker to immediately kill the
container without waiting for it to shutdown cleanly. Cockpit now
passes a timeout.
From the future
Marius has made progress
getting the Cockpit integration test suite to run on Debian. Without the
integration tests running for a certain distro, there’s no way to ensure Cockpit
actually works there.
Try it out
Cockpit 0.85 is available now:

Source Tarball
Fedora 23 and Fedora Rawhide
COPR for Fedora 22, CentOS and RHEL
				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">Cockpit 0.83 and 0.84 Released</title>
    <id>http://fedoraplanet.org/39/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/39/" />
    <author>
      <name>Stef Walter(stefw)</name>
    </author>
    <content type="html/text">Cockpit releases every week. This week it was 0.84. I’ll also include notes from 0.83 here.
Building Cockpit on Debian
At systemd.conf Dominik worked with Michael Biebl one of the Debian systemd maintainers on packaging Cockpit for Debian. We’re still looking for a maintainer long term.
Here’s a blog post with more details.
Cross Distro Integration Tests
In Cockpit we run hundreds of tests on real operating systems for each pull request. Without running these tests on an OS it’s impossible to know that the features of Cockpit actually works. So far we’ve been running these tests on Fedora, Atomic, and RHEL. But we’d really like to run them on Debian as well. That’ll make Cockpit much more well rounded.
Marius worked on the first steps toward running the tests on Debian, by doing the Cockpit build inside of our test VM images. Hopefully we’ll see more progress on this.
SELinux certificate file type
The cockpit.service helpfully sets the appropriate user and group on the certificates that cockpit-ws will use for TLS. Now it also sets the SELinux file context type properly, so this is one less things to break for an admin.
Cockpit manual page
There is now a man cockpit overview manual page that links to the guide and elsewhere.
From the future
Marius has done work on an SOS reporting view. Needs some further backend work, but should be ready soon:


Peter has mostly completed the work to add machines with alternate users, and non-standard SSH ports. Among other things, this is useful for cloud instances. I’m looking forward to seeing this in Cockpit 0.85.

Try it out
Cockpit 0.84 is available now:

Source Tarball
Fedora 23 and Fedora Rawhide
COPR for Fedora 22, CentOS and RHEL
				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">guv: Automatic scaling of Heroku workers</title>
    <id>http://fedoraplanet.org/40/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/40/" />
    <author>
      <name>Jon Nordby(jonnor)</name>
    </author>
    <content type="html/text">At The Grid we do a lot of computationally heavy work server-side, in order to produce websites from user-provided content. This includes image analytics (for understanding the content), constraint solving (for page layout) and image processing (optimization and filtering to achieve a particular look). Currently we serve some thousand sites, with some hundred thousands sites expected by the time we’ve completed beta – so scalability is a core concern.
All computationally intensive work is put as jobs in a AMQP/RabbitMQ message queue, which are consumed by Heroku workers. To make it easy to manage many queues and worker roles we also use MsgFlo.
This provides us with the required flexibility to scale: the queues buffer the in-progress work, broker distributes evenly between available workers, and with Heroku we can change number of workers with one command. But, it still leaves us with the decision on how much compute capacity to provision. And when load is dynamic, it is tedious &amp;amp; inefficient to do it manually – especially as Heroku bills workers used by the second.
Monitoring RabbitMQ queues and scaling Heroku workers manually when demand changes; not fun.
If we would instead regulate this every 1-5 minute based on demand, we would reduce costs. Or alternatively, with a fixed budget, provide a better quality-of-service. And most importantly, let developers worry about other things.
Of course, there already exists a number of solutions for this. However, some used particular metrics providers which we were not using, some used metrics with unclear relationship to required workers (like number of users), or had unacceptable limitations (only one worker per service, only run as a service with pay-by-number-of-workers).
guv
guv 0.1 implements a simple proportional scaling model. Based the current number of jobs in the queue, and an estimate of job processing time – it calculates the number of workers required for all work to be completed within a configured deadline.


The deadline is the maximum time you allow for your users to wait for a completed job. The job processing time [average, deviation] can be calculated from metrics of previous jobs. And the number of jobs in queue is read directly from RabbitMQ.
# A simple guv config for one worker role.
# One guv instance typically manages many worker roles
'*':
  app: my-heroku-app
analyze:
  queue: 'analyze.IN' # RabbitMQ queue name
  worker: analyzeworker # Heroku dyno role name
  process: 20
  deadline: 120.0
  min: 1 # keep something always running
  max: 15 # budget limits


Now there are a couple limitations of this model. Primarily, it is completely reactive; we do not attempt to predict how traffic will develop in the future. Prediction is after all terribly tricky business – better not go there if it can be avoided.
And since it takes a non-zero amount of time to spin up a new worker (about 45-60 seconds), on a sudden spike in demand may cause some jobs to miss a tight deadline, as the workers can’t spin up fast enough. To compensate for this, there is some simple hysteresis: scale up more aggressively, and scale down a bit reluctanctly – we might need the workers next couple of minutes.
As a bonus, guv includes some integration with common metrics services: The statuspage.io metrics about ‘jobs-in-flight’ on status.thegrid.io, come directly from guv. And using New Relic Insights, we can analyze how the scaling is performing.
Last 2 days of guv scaling history on some of the workers roles at The Grid.
If we had a manual scaling with a constant number over 48 hours period, workers=35 (Max), then we would have paid at least 3-4 times more than we did with autoscaling (difference in size of area under Max versus area under the 10 minute line). Alternatively we could have provisioned a lower number of workers, but then with spikes above that number – our users would have suffered because things would be taking longer than normal.
We’ve been running this in production since early June. Back then we had 25 users, where as now we have several thousand. Apart from updating the configuration to reflect service changes we do not deal with scaling – the minute to minute decisions are all done by guv. Not much is planned in terms of new features for guv, apart from some more tools to analyze configuration. For more info on using guv, see the README.
Related Posts:Announcing MsgFlo, a distributed FBP runtimeimgflo 0.1: An image processing server and Flowhub runtimeimgflo 0.3: GEGL metaoperations++imgflo 0.2, The Grid launchedMicroFlo 0.1.0, and an Arduino powered fridge 				 

				</content>
  </entry>
  <entry xml:base="http://planet.gnome.org/">
    <title type="text">LinuxCon Europe – Day 1</title>
    <id>http://fedoraplanet.org/41/</id>
    <updated>2015-12-03T07:45:44Z</updated>
    <link href="http://fedoraplanet.org/41/" />
    <author>
      <name>Tobias Mueller(muelli)</name>
    </author>
    <content type="html/text">
The conference was opened by the LinuxFoundation’s Executive Jim Zemlin.  He thanked the FSF for their 30 years of work.  I was a little surprised to hear that, given the differences between OpenSource and Free Software.   He continued by mentioning the 5 Billion Dollar report which calculates  how much “value” the projects hosted at Linux Foundation have generated over the last five years.  He said that a typical product contains 80%, 90%, or even more Free and Open Source Software.  He also extended the list of projects by the Real Time Collaborative project which, as far as I understood, effectively means to hire Thomas Gleisxner to work on the Real Time Linux patches.

The next, very interesting, presentation was given by  Sean Gourley, the founder of Quid, a business intelligence analytics company.   He talked about the limits of human cognition and how algorithms help to exploit these limits.           The limit is the speed of your thinking.  He mentioned that studies measured the blood flow across the brain when making decisions which found differences depending on how proficient you are at a given task.       They also found that you cannot be quicker than a certain limit, say, 650ms.    He continued that the global financial market is dominated by algorithms and that a fibre cable from New York to London costs 300 million dollars to save 5 milliseconds.     He then said that these algorithms make decisions at a speed we are unable to catch up with. In fact, the flash crash of 2:45 is inexplicable until today.  Nobody knows what happened that caused a loss of trillions of dollars.  Another example he gave was the crash of Knight Capital which caused a loss of 440 million dollars in 45 minutes only because they updated their trading algorithms.    So algorithms are indeed controlling our lives which he underlined by saying that 61% of the traffic on the Internet is not generated by humans.    He suggested that Bots would not only control the financial markets, but also news reading and even the writing of news.  As an example he showed a Google patent for auto generating social status updates and how Mexican and Chinese propaganda bots would have higher volume tweets than humans.  So the responsibilities are shifting and we’d be either working with an algorithm or for one.  Quite interesting thought indeed.

Next up was IBM on Transforming for the Digital Economy with Open Technology which was essentially a gigantic sales pitch for their new Power architecture.  The most interesting bit of that presentation was that “IBM is committed to open”.  This, she said, is visible through IBM’s portfolio and through its initiatives like the IBM Academic Initiative.   OpenPower Foundation is another one of those.   It takes the open development model of software and takes it further to  everything related to the Power architecture (e.g. chip design), she said.   They are so serious about being open, that they even trademarked “Open by Design“…

Then, the drone code people presented on their drone project.  They said that they’ve come a long way since 2008 and that the next years are going to fundamentally change the drone scene as many companies are involved now. Their project, DroneCode, is a stack from open hardware to flight control and the next bigger thing will be CAN support, which is already used in cards, planes, and other vehicles.    The talk then moved to ROS, the robot operating system. It is the lingua franca for robotic in academia.

Matthew Garret talked on securing containers.      He mentioned seccomp and what type of features you can deprive processes of.      Nowadays, you can also reason about the arguments for the system call in question, so it might be more useful to people.    Although, he said, writing a good seccomp policy is hard.    So another mechanism to deprive processes of privileges is  to set capabilities.        It allows you to limit the privileges in a more coarse grained way and the behaviour is not very well defined.   The combination of capabilities and seccomp might have surprising results.     For example, you might be allowing the mknod() call, but you then don’t have the capability to actually execute it or vice versa.    SELinux was next on his list as a mechanism to secure your containers.  He said that writing SELinux policy is not the most fun thing in the world.    Another option was to run your container in a virtual machine, but you then lose some benefits such as introspection of fine grained control over the processes.   But you get the advantages of more isolation.   Eventually, he asked the question of when to use what technology.  The performance overhead of seccomp, SELinux, and capabilities are basically negligible, he said.   Fully virtualising is usually more secure, he said, but the problem is that you have more complex infrastructure which tend to attract bugs.   He also mentioned GRSecurity as a means of protecting your Linux kernel.  Let’s hope it’ll be merged some day.

Canonical’s Daniel Watkins then talked on cloud-init.  He said it runs in three stages. Init, config, and final in which init sets up networking, config does the actual configuration of your services, final is for the things that eventually need to be done.  The clound-init architecture is apparently quite flexible and versatile. You can load your own configuration and user-data modules so that you can set up your cloud images as you like.  cloud-init allows you get rid of custom images such that you can have confidence in your base image working as intended.   In fact, it’s working not only with BSDs but also with Windows images.  He said, it is somewhat similar to tools like Ansible, so if you are already happily using one of those, you’re good.

An entertaining talk was given by Florian Haas on LXC and containers.   He talked about tricks managing your application containers and showed a problem when using a naive chroot which is that you get to see the host processes and networking information through the proc filesystem.     With LXC, that problem is dealt with, he said.  But then you have a problem when you update the host, i.e. you have to take down the container while the upgrade is running.  With two nodes, he said, you can build a replication setup which takes care of failing over the node while it is upgrading.   He argued that this is interesting for security reasons, because you can upgrade your software to not be vulnerable against “the latest SSL hack” without losing uptime.   Or much of it, at least…   But you’d need twice the infrastructure to run production.    The future, he said, might be systemd with it’s nspawn tool.  If you use systemd all the way, then you can use fleet to manage the instances.  I didn’t take much away, personally, but I guess managing containers is all the rage right now.

Next up was Michael Hausenblas on Filesystems, SQL and NoSQL with Apache Mesos. I had briefly heard of Mesos, but I really didn’t know what it was.   Not that I’m an expert now, but I guess I know that it’s a scheduler you can use for your infrastructure.   Especially your Apache stack.   Mesos addresses the problem of allocating resources to jobs.   Imagine you have several different jobs to execute, e.g. a Web server, a caching layer, and some number crunching computation framework.   Now suppose you want to increase the number crunching after hours when the Web traffic wears off.   Then you can tell Mesos what type of resources you have and when you need that.   Mesos would then go off and manage your machines.  The alternative, he said, was to manually SSH into the machines and reprovision them.   He explained some existing and upcoming features of Mesos.  So again, a talk about managing containers, machines, or infrastructure in general.

The following Kernel panel didn’t provide much information to me.  The moderation felt a bit stiff and the discussions weren’t really enganged.   The topics mainly circled around maintainership, growth, and community.

SuSE’s  Ralf was then talking on DevOps.  He described his DevOps needs based on a cycle of   planning, coding, building, testing, releasing, deploying, operating, monitoring, and then back to planning.   When bringing together multiple projects, he said, they need to bring two independent integration loops together.     When doing DevOps with a customer, he mentioned some companies who themselves provide services to their customers.   In order to be successful when doing DevOps, you need, he said, Smart tools, Process automation, Open APIs, freedom of choice, and quality control are necessary.    So I guess he was pitching for people to use “standards”, whatever that exactly means.

I awaited the next talk on Patents and patent non aggression.   Keith Bergelt, from OIN talked about ten years of the Open Invention Network.    He said that ten years ago Microsoft sued Linux companies to hinder Linux distribution.    Their network was founded to embrace patent non-aggression in the community.   A snarky question would have been why it would not be simply enough to use GPLv3, but no questions were admitted.  He said that the OIN has about 1750 licensees now with over a million patents being shared.  That’s actually quite impressive and I hope that small companies are being protected from patent threats of big players…

That concluded the first day.  It was a lot of talks and talking in the hallway.  Video recordings are said to be made available in a couple of weeks. So keep watching the conference page.

				 

				</content>
  </entry>
</feed>
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title type="text">Open Stack</title>
  <id>http://planet.openstack.org/</id>
  <updated>2015-12-03T07:45:48Z</updated>
  <link href="http://planet.openstack.org/" />
  <link href="http://planet.openstack.org/" rel="self" />
  <author>
    <name></name>
  </author>
  <subtitle type="text">http://planet.openstack.org/</subtitle>
  <generator>PyAtom</generator>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">OpenStack Community App Catalog Review: Issue #1</title>
    <id>http://fedoraplanet.org/2/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/2/" />
    <author>
      <name>Mirantis</name>
    </author>
    <content type="html/text">The post OpenStack Community App Catalog Review: Issue #1 appeared first on Mirantis | The #1 Pure Play OpenStack Company.
Hello, folks! Here at OpenStack:Unlocked we have decided to start a monthly digest of news related to the OpenStack Community App Catalog, a project started to help app developers promote their products, and to help cloud admins with their daily duties by providing an easy way for users to deploy applications on their OpenStack clusters. As TechCrunch put it, the OpenStack Community App Catalog enables “users to share templates for setting up apps and services on the platform. This means OpenStack users could get started with Kubernetes and containers on OpenStack or install the CloudFoundry PaaS platform with just a few clicks.”
In order to make sure you have the best chance of getting the most out of the OpenStack Community App Catalog, we want to keep all the community updated with events, apps, contributors and discussions inspired by this project.
To that end, we will be bring you monthly reports about events such as meetings of the active contributors of the project — including agenda and decisions — and links to selected articles and presentations with some brief editorial explanations, releases of new hands-on apps available for users, and new personalities contributing to the Community App Catalog.
We thought we’d start with a report on what happened at the OpenStack Summit in Tokyo.
OpenStack Community App Catalog at the OpenStack Summit in Tokyo

The team decided that despite the name, the OpenStack Images (Glance) v3 API is not actually about images at all, but about artifacts, or metadata about images. So Flavio Percoco, Glance PTL for Mitaka, highlighted this naming problem. Basically, v3 is not the next step in the evolution of Glance after v2, but rather something developed in parallel. Consequently, the decision was to rename it as Artifacts API v1. That means that when it comes to Glance in Mitaka, there are three APIs: Glance API v1 (old images, to be deprecated), Glance API v2 (current images) and Glare (Glance Artifacts Repository, experimental) v1 (or 0.x — the discussion is still in progress). Note that deployers will need a new entry in the Keystone service catalog for Glare. 
The team also decided that the python client for Glare will be part of python-glanceclient, but the CLI will be implemented as part of the common OpenStack CLI project. 
Chris Aedo had some concerns, because from his perspective Glance maybe not the best choice for a back-end for the Community App Catalog. By separating Glare out as a separate process, it becomes easier to use Glare as a backend instead, so on the last day of the summit, Mirantis gave a demo of how it works for Glance people, for the PTL of the Community App Catalog, and for Kevin Fox, the core-reviewer for the Community App Catalog who is responsible for the Community App Catalog Horizon Plugin (see screenshots). 
And speaking of Horizon, the team also discussed another issue: the potential conflict between Murano and the Horizon Plugin for the Community App Catalog: they have similar names (Murano’s official name is “Application Catalog for OpenStack”), and their UIs are very similar as well. Also, they both allow end users to “deploy an application” (though the actual capabilities of that deployments are different).  That possibly causes some misunderstanding for users. So the decision was to make a common tool, which enables users to:




Browse a remote app catalog, such as apps.openstack.org (or even additional catalogs) and find some assets (apps), 
Once users find the thing they are interested in, they have a choice. 

a) If they have Glare installed locally, they can import the artifact they need from the remote catalog to their own local catalog.


b) If not, they may not import it, but for some types of assets they may have an option to run them locally without storing. For example for Heat templates one may launch the stack out of the remote template on their local Heat implementation (if they have one). 
c) If no applicable OpenStack components (such as Glare to store artifacts locally, or some plugins for it to support particular artifact types, or other OpenStack components to work with these artifacts, e.g. Murano) are deployed locally, the tool may display a notification or suggestion that they be installed. So this is also an initiative that will help to cross-promote application-related components such as Glare, Heat, and Murano.  



Also this tool lets the user browse the local app catalog (if Glare is installed) and run, delete, or check apps for new available versions.  
Last but not least is the opportunity to see a list of running apps, stop them or execute lifecycle actions for them (for Murano apps).



If you’re interested in the full summary, feel free to check out the PTL’s notes. 
Coming soon
So that’s our first report.  In the next few weeks, you can expect more Murano and App Catalog-related content, including an Artifacts API v1 Deep Dive by Alexander Tivelkov, and a comparative study of using Murano Apps and Glance images for implementing WordPress on OpenStack using the Community App Catalog.
If you want to be involved in some of these decisions, the OpenStack Community App Catalog team meets on Thursdays at 1700 UTC in the Freenode IRC channel #openstack-meeting-3.  You can find the December 3 agenda here.
See you next month!
The post OpenStack Community App Catalog Review: Issue #1 appeared first on Mirantis | The #1 Pure Play OpenStack Company.        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">OpenStack 2016 Board Election Ballot Questions</title>
    <id>http://fedoraplanet.org/3/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/3/" />
    <author>
      <name>JJ Asghar</name>
    </author>
    <content type="html/text">We’ve pushed out a new update, version 1.6, of our Tesora DBaaS Platform Community Edition, which is in sync with the stable OpenStack Trove Liberty branch.
This Community Edition provides a great way for people to check out the database-as-a-service capabilities available for OpenStack. New features in this release include support for:

MongoDB backup and restore, and cluster grow/shrink, configuration management along with user management;
Redis backup and restore, configuration management and clustering, as well as new replication functionality.

This release also includes installation packages for CentOS 7 and Ubuntu 14.04 and comes with pre-packaged guest images providing native database support for Cassandra 2.1, Couchbase 3.0, MariaDB 10.0, MongoDB 3.0, MySQL 5.6, Percona 5.6, PostgreSQL 9.4, and Redis 2.8.
You can get more information and download this latest version of the Tesora DBaaS Platform at http://resources.tesora.com/download-tesora-dbaas-platform-community-edition.
The post Tesora DBaaS Platform Community Edition 1.6 Now Available appeared first on Tesora.
        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Tesora DBaaS Platform Community Edition 1.6 Now Available</title>
    <id>http://fedoraplanet.org/4/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/4/" />
    <author>
      <name>Tesora Corp</name>
    </author>
    <content type="html/text">BURLINGAME, CA. -- Over 700 people, including several OpenStack community members, global telecommunications companies (telcos) and Foundation staff, attended the inaugural OPNFV Summit.  

Jonathan Bryce participated on the keynote Strategic Technologies panel and the Women of OPNFV and Allies happy hour was a great way to meet women and men alike in an informal setting. 

OpenStack was front and center at every session we attended. Results of an OPNFV global survey clearly support the project and OpenStack’s role in network functions virtualization (NFV).  Key findings include:


Over half the respondents said OPNFV is poised to accelerate NFV adoption.
62 percent believe OPNFV will lead to more rapid development.  
68 percent of respondents cited OpenStack as very important to the success of OPNFV. 
OPNFV is a reference implementation of the European Telecommunications Standards Institute (ETSI) NFV specification. OpenStack is a large component of both OPNFV and ETSI NFV. Almost all telcos, cable companies and enterprises that operate large networks are closely following and implementing NFV from the ETSI spec or OPNFV releases. NFV is of tremendous value for agility and cost reduction.

OPNFV’s first release, Arno, is available and includes OpenStack as the Virtualized Infrastructure Manager (VIM).  Brahmaputra, the second release planned for February 2016, will update OpenStack to the Liberty release, which includes many NFV-supporting features and related projects.

Diagram of the OPNFV Arno release

In scheduled meetings and the “hallway track,” the collaboration between OpenStack and OPNFV was discussed, particularly around OPNFV’s "upstream first” practice for requirements and development. The OPNFV community identifies gaps, submits blueprints to OpenStack, then works on those blueprints. This expands the number of OpenStack contributors helping meet key telco requirements.  The OPNFV contributors are skilled developers that may be new to OpenStack processes and schedules and are welcomed by the OpenStack community!

These are a few of the OpenStack features that were included in Liberty.  Features developed to meet telco needs for resiliency, performance and scaling are also valuable to all OpenStack users. 

Nova features such as a new API call to mark compute nodes as down.
A new alarm evaluator has been added to Ceilometer to realize immediate alarm notification.
Service function chaining capabilities have been added to the OpenStack Tacker project.
OpenStack users and vendors also bring feature requests to the table, in addition to OPNFV.  These Liberty-implemented examples are valuable to telcos and enterprise users alike:

Support for CPU pinning and SR-IOV passthrough in Nova's new extensible CPU scheduler
Improvements in the scalability of Neutron's advanced services
Cells v2 support for horizontal scaling
Improved support for IPv6 in Neutron and Nova
The OPNFV OpenStack Community wiki has been updated for the OpenStack Mitaka release -- with the new release schedule, project governance and blueprint process and assistance. Community members from both organizations will advocate OPNFV requirements within OpenStack projects through a streamlined process detailed on the wiki.

We’re excited to continue and enhance the collaboration with telcos and OPNFV. NFV will be prominent at the upcoming OpenStack Summit Austin. 

Stay tuned for more information and telco NFV user stories!

Cover Photo // CC BY NC        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">OpenStack and OPNFV strengthen collaboration for telcos</title>
    <id>http://fedoraplanet.org/5/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/5/" />
    <author>
      <name>OpenStack Superuser</name>
    </author>
    <content type="html/text">With so many new cloud technologies emerging, many companies are carefully considering which platform technologies to standardize on and which to consider experimental or to avoid until the winners shake out. Those chasing the latest hyped technologies risk a proliferation of platforms to maintain - and each one becomes just another island in the data center. 

But competitive pressures mean companies can't afford to wait too long, as the benefits of rapid application development and deployment are becoming the minimum required for most industries. 

Take containers for example - they are meant to be a common building block to encourage reuse of resources and promise to reduce the headaches involved with packaging, deploying and managing applications. Though Linux Containers (LXC) and other forms of isolation have been around for a while, Docker was the first to really get serious attention. That first wave was quickly followed by rkt from CoreOS, itself an implementation of the open “app container runtime for Linux.” Confused yet?

If a common building block is the point, how can so many formats be a good thing? To answer this frequently asked question, a new effort has emerged to unify the disparate formats under the Open Container Initiative.

As the container islands converge to form a continent you can count on, harder questions emerge about just how to actually deploy, manage and network these containers and the apps that live in them.  Docker Inc. (the parent company of Docker, the open-source project) has their own answer in Docker Swarm, while Apache Mesos and Kubernetes (spun out of Google) also seek to ease the management of containers through what are sometimes called “container orchestration engines.”  

While companies experiment with the open territory of “container clouds” for so-called “cloud native apps” using some of these orchestration tools, many are reluctant to create yet another set of platforms for ops to manage and maintain for years to come. After all, the original promise of cloud computing was to reduce complexity, not multiply it. 

Beyond the headaches for operators, we also must consider that distributed applications are growing increasingly complex, with some workloads best deployed on a mixture of virtual machines, bare metal and containers (one, either, or both), which all need to live on the same network. 

To give developers access to the latest tools while giving operators a single infrastructure layer to manage that is battle-tested with drivers for the compute, storage and networking gear they use today, many of the world’s largest companies are turning to OpenStack. Companies are already layering new technology like Kubernetes on top of their OpenStack clouds to manage Docker containers, leveraging the same security and network models they’re used to.

At the OpenStack Silicon Valley event, Amit Tank, a principal architect of cloud architecture and OpenStack at DirecTV, joined the Foundation's executive director Jonathan Bryce onstage to discuss how OpenStack offers a path to production to users trying to solve problems using containers. 

“OpenStack is the only platform that allows you to pick and choose the best-of-breed and make it work with your existing infrastructure,” said Tank. “We see that as our real way to bring containers as well as other emerging technologies into production.” 

At that same event, Lachlan Evenson, cloud platform engineering team lead at Lithium Technologies, gave a talk about how the company integrates Kubernetes with OpenStack and benefits from combining these technologies with minimal effort. 


Thanks @kubernetesio and @OpenStack for elegantly orchestrating complex multitiered apps in seconds rather than hours. #gamechangers— Lachlan Evenson (@LachlanEvenson) August 19, 2015


&amp;lt;script async="async" charset="utf-8" src="http://platform.twitter.com/widgets.js"&amp;gt;&amp;lt;/script&amp;gt;By working with other open-source communities like Mesos, Kubernetes, Cloud Foundry, and Docker, OpenStack users get faster access to new developer productivity tools.  Each of these communities can, in turn, leverage OpenStack’s common networking and security models while running a wide range of compute, storage, and networking gear without reinventing the infrastructure-as-a-service (IaaS) wheel. By eliminating islands and connecting communities, everybody wins.

If your company wants to build on a solid foundation for the next 10 years, join Walmart, PayPal, IBM, eBay, NTT and thousands of others by joining the OpenStack powered planet!

This article was originally published in the print editon of Superuser magazine distributed at the OpenStack Summit Tokyo, where Collier delivered a keynote about OpenStack's future.

&amp;lt;iframe allowfullscreen="allowfullscreen" frameborder="0" height="" src="https://www.youtube.com/embed/iITZBYUerpA" width=""&amp;gt;&amp;lt;/iframe&amp;gt;

Cover Photo // CC BY NC        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">A First Look at RBAC in the Liberty Release of Neutron</title>
    <id>http://fedoraplanet.org/6/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/6/" />
    <author>
      <name>Rackspace Developer Blog</name>
    </author>
    <content type="html/text">The post Voices from Tokyo: The white-collar diaries appeared first on Mirantis | The #1 Pure Play OpenStack Company.
Here at Mirantis, we’re just like you; we look forward to the semi-annual OpenStack summits and all of the new ideas and energy they bring, as well as the opportunity to present our own ideas. Unlike in Vancouver, where we had a remote-controlled robot that enabled our reporting staff who had to stay home to still experience the summit, the logistics of the Tokyo venue meant that the only robot we had was Megarantis printed at the booth’s backdrop, and we were limited to reporting provided by those who were on the ground. 
Fortunately, instead of robots we had a glorious team of volunteers among our engineers, so we are pleased to present, “Voices from Tokyo: The white-collar diaries”. Many thanks to Kirill Zaitsev, Evgeniya Shumakher, Alexander Tivelkov, Fabrizio Soppelsa, Alexander Adamov and Boris Bobrov for their contributions. 
 We brought our own stories to Tokyo, of course, and they can be divided into three groups: comparative studies, such as Mirantis OpenStack 7.0 vs. RHEL OSP7, big data, such as Sparkhara (OpenStack service controllers produce large amounts of log data, and processing these logs can be a time consuming and difficult task), and sessions related to the Community App Catalog, including a number of Murano-related sessions and The Evolution of the Glance API: From v1 to v3, and over the next few weeks you’ll see articles about those ideas here on the blog.
But that’s not what we’re here to talk about today. Today we’re here to give you a view of the rest of the Tokyo summit from some of those who were lucky enough to have been there.
Tuesday, October 27
Even though we’re a global team, the first day was still a bit jarring for most of us; those who’d traveled were a little jet lagged, and those who hadn’t were running on Tokyo time anyway, sometimes after a full day of other work. Why?  Because we were looking forward to covering the summit live, in real time — especially the keynotes, which had been livestreamed from Vancouver.
So we were a bit confused to find out that in fact there would be no livestreaming, (though the OpenStack Foundation did make the video available shortly after). Thank heavens for Evgeniya Schumakher, who used Periscope to show us what was happening in Tokyo at the keynotes — as they happened. We were excited to see Mirantis mentioned by two of the keynote speakers 
 Bitnami’s COO Erica Brescia (see 1h09m of the Keynotes official video) mentioned Murano, of which we’re very proud (having contributed more than 90% of the code by LoC during the Liberty cycle).  “I especially liked the Bitnami keynote,” Fabrizio Soppelsa wrote, “especially where they underlined that application developers now want something like click-and-install, instead of wasting time on configuration (which should be left to experts like us).”
But Brescia had a more urgent note, as Evgeniya Schumakher pointed out: “Erica shared her view on what OpenStack needs to be successful.” In her mind, this ability to provide applications that can be deployed with the same ease as adding an app to your phone is crucial to OpenStack adoption.  Users, Brescia said, will always take the path of least resistance.
Intel’s VP and General manager of the Open Source Technology Center Imad Sousou (see 1h25m of Keynotes official video) talked about the partnership with Mirantis in the context of Intel’s Cloud for All initiative, which we’re very excited about. 
Of course, we’re not all about us. Our experts also noticed the presentation by Lithium’s Lachlan Evenson (see 27m33sec). “I liked the Lithium presentation: the Kubernetes-powered cross-cloud CI/CD solution sounds really familiar and useful,” Alexander Tivelkov mentioned. “Moreover, they know what we are doing in this direction and even used some of our code.” 
Evgeniya also found Yahoo! Japan’s talk about the company’s experience in running OpenStack-managed bare metal environment by Simon Chung to be particularly interesting; the company serves more than a billion users (with a b) with more than 64.99 billion page views a month, with 31.9 billion of those to mobile devices, and operates over 100 services.
There was more going on than just the keynotes, and as our experts settled in to Tokyo, they zeroed in on several projects, including OSA (openstack-ansible) (“Looks like a nice thing to try,” Kirill said), the user stories session, and the introduction of Kuryr by IBM’s Mohammad Banikazemi.  (“However, sometimes I wasn’t sure if I was attending OpenStack Summit or a DockerCon”, Fabrizio said). 
Alexander Tivelkov also had a fruitful discussion of Murano’s roadmap with key external contributors and partners, and Bruce Matthews and Joseph Yep gave an impressive session comparing Mirantis OpenStack and Fuel with Red Hat Enterprise Linux OpenStack Platform and Director, which was fun and very useful.
Still, it was a summit, which meant a time to blow a little bit of steam; Mirantis upped the ante from Vancouver’s air hockey table with a virtual race simulator at the Mirantis booth, and it was a source of real fun for all visitors of the Marketplace. Even various members of the Foundation’s Board Directors enjoyed the race.
Our experts also enjoyed Tokyo itself; Fabrizio went to the Sengakuji Temple and Tokyo imperial palace, but it was night and the garden was closed. But the Gonpachi restaurant was open — a beautiful restaurant, recognized by Tarantino fans as location for the climactic fight between Uma Thurman and Lucy Liu in the Kill Bill films.
And speaking of food, as our volunteers settled in, they also tried out some of the food.  Fabrizio had ramen with all the toppings (but wasn’t sure what they were called), Kirill had octopus pieces in rice balls, and Evgeniya zeroed in on the Japanese sweets, including “Matcha sponge cake and some marmalade candies.”  (Editor’s note:  Evgeniya brings awesome Russian candy when she comes to the US, for which those who receive it are immensely grateful; this woman knows her sweets.)
Wednesday, October 28
On day 2, we settled down to the serious business of project planning and idea exchange.  But that doesn’t mean it’s all business.
Kirill: Who’s the best Pony?
“The Murano meetings were pretty productive,” Kirill said. (For more details, see Alexander Tivelkov’s more extensive report, OpenStack Glance, Murano, Community app catalog: links in a chain. ) “Then I’d been to the OpenStack client session — some takeaways are that we should claim the object names ASAP. Glance V3 should only be in OSC. Also, the current ‘murano-’ prefix is a bad thing, and we should fix that.
“Kolla is a nice project, that is going to request a kolla-mesos repo for mesos-specific configs, which fits the Mirantis direction pretty nicely. Mirantis was going to make those things open anyway,” he noted, which isn’t surprising given that Fuel has been using containers for several releases already, “but having been guided by Kolla folks here is a nice thing.”
“The Congress meetings went really nicely, with them agreeing to have a murano-dsvm job. Also, the operator session lead by Chris Aedo was influenced by the murano guys, You can get more details on the session Etherpad.”
Kirill also enjoyed the evening, but not for the reasons you might expect. “The HP-sponsored party was nice. I had severe nostalgia with the cosplayers, and the J-POP group was good, although I guess most of Mirantis guys left right around then. 
“Oh, and I finally met someone, whose answer to ‘Who’s the best pony?’ is ‘Fluttershy’, not ‘What the *** are you talking about?’ So I kind of had the time of my life this evening.”
Alexander Tivelkov: the cameraman
“In the morning I went to take some pictures at the ‘Women of Openstack’ session,” Alexander said. “The pictures may be found here. Ladies, you are welcome to find yourself in this set of photos!”  Alexander, who at times seems like Mirantis’ unofficial photographer (as well as an engineer) also took pictures of most of the Mirantis team at the summit.
“I spent the day doing serious work on Murano, Glance and the Community App Catalog; you can see my notes in this separate blog post. Finally, there was a great party in the evening: samurai, geisha, cosplayers, cool music, nice food and plenty of drinks. I took some pictures there as well.”
Evgeniya: meetings and more meetings
“I spent most of the day in meetings with partners and on booth duty.  It’s great to see how many technology partners are excited about the Fuel Pluggable Framework, the level of automation it makes possible, and its close integration with Fuel.  Some partners have already developed and validated their plugins (there’s a list here) while some are only starting out this journey. It was great talking about how the Mirantis Unlocked team supports everyone, and it was interesting to see how many partners were interested in the Mirantis NFV initiative. 
“I also got to attend the HP party, which was not only an awesome venue and a great program, but also a terrific opportunity to meet other OpenStackers, and ex-colleagues.”
Fabrizio: Italian man in Tokyo
Adrian Otto presented with his 5-grade son a nice application of running clusters of containers on Rackspace – introducing Carina, but I could have used more talk, rather than Q&amp;amp;A. In practice they want that people test Carina and give feedback — for free.
Project Kuryr is about the joining of forces between Neutron (OpenStack) and libnetwork (Docker), with compliments to Thierry for facilitating collaboration between the communities.
Thursday, October 29
Day three was hard core, with the keynotes over and our volunteers getting into the real work of design sessions intended to determine direction for the next six months of OpenStack development.
Kirill: Mitaka process changes, Searchlight and Kolla
Kirill started by talking about changes to the OpenStack release process itself. Some important takeaways he noted:

Pre-versioning, in which setup.cfg is used for versioning, is about to be dropped in favor of a tagging system. There is a small issue with that — development versions may run into a problem because Pep 440 (Version Identification and Dependency Specification) only supports pre-versioning — but ultimately the release management team agreed to let this go, as the problem would only affect development versions — and even then, only under very specific circumstances.
Synced milestone releases, the process where milestone releases such as mitaka-1, mitaka-2, and so on, must fall on the same date, are to be dropped. Projects may still synchronize their pre-releases, but the tagging system makes it optional;
Adoption of Reno, a Release Notes tool, is targeted for mitaka-1 in early December; 
The Liberty cycle eliminated stable point releases, instead considering every backport to the stable branch to do its own release.  Unfortunately, this provides the potential for an unmanageable flood of releases.  So rather than do a release every time a change was backported to stable (which could prompt teams to hold back changes until they have a batch) release management agreed to enable “on demand” releases with Reno. Almost every commit to stable should be a release, but this enables greater control. 
Release models, which define the relationship between a project’s releases and the releases of OpenStack in general, are hard and many do not understand them, so it was resolved to work harder at educating the community on such issues. 
Another interesting idea discussed was to drop use of blueprints (use either specs or bugs instead).

“Searchlight seems to be a surprisingly mature project,” Kirill noted, “with a couple of Horizon cores involved. Looks like the project is in a very good shape, and Horizon participation is definitely a plus. We can hope for the UI/UX to be good/consistent there. Some of the challenges include cross-region/cross-cloud search and policy-based access to indexed resources” 
Alexander Tivelkov noted, “Searchlight is setting priorities for Mitaka, so the team is investigating the possibility of adding more objects into their index. They are looking to extend Nova support by indexing not just servers, but other nova resources such as flavors. Also, they are gathering opinions on Neutron, Swift and Cinder. They’ve asked us about Searchlight support for Artifacts, and we’ve promised to come back to that as soon as the Glare API (that is, the API for Artifacts) is stable. When they asked about other types of indexable entities, I’ve mentioned Murano Environments: using Elasticsearch for them may good, as it is efficient in searching within large JSON files. The same should apply to deployed Heat stacks, and there was interest in that from somebody from the Heat team.”
As far as Kolla, Kirill said, “Mirantis had very productive sessions there. The biggest takeaway is the new kolla-mesos repository, governed by both Kolla and Mirantis folks.”
Evgeniya’s lucky strike
Another day of booth duty for Evegeniya, but “I won an Apple iWatch from Citrix. Love these guys!”
Alexander Adamov: documentation and security
The Documentation Contributor Guide made by the Mirantis Doc team went down well and will be used as a reference point for all kinds of documentation in the community. Most of my time, though, was spent on security issues. 
Boris Bobrov: Keystone
When it comes to Keystone, it was all about deprecations, deprecations, deprecations! PKI tokens are really close to be deprecated in favor of Fernet tokens, the LDAP assignment driver will be either removed or set to read-only mode, and the v2.0 API will be partially deprecated, leaving only authentication-related parts non-deprecated. In addition, running keystone with an eventlet will be removed in this cycle. Boris has put it all together in a blog post about Keystone in Tokyo.
Friday, October 30
Alexander Tivelkov: Last, but not least
It may have been the last day, but the work was still going on. “One of of the most important conversations happened today,” Alexander reported, “during our Murano Contributors’ Meetup. This actually turned out to be a cross-project work session for Murano, Glance and AppCatalog: we worked on defining the borders between each project, agreeing on shared responsibilities and reuse of common functionality. You can see the deep-dive here.”
The post Voices from Tokyo: The white-collar diaries appeared first on Mirantis | The #1 Pure Play OpenStack Company.        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Why no data center should be full of islands</title>
    <id>http://fedoraplanet.org/7/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/7/" />
    <author>
      <name>OpenStack Superuser</name>
    </author>
    <content type="html/text">The post HPE makes a deal with Microsoft, provides enterprise-grade Docker appeared first on Mirantis | The #1 Pure Play OpenStack Company.
Hewlett Packard Enterprise has made some interesting moves in the past two weeks, announcing both a new set of tools optimized for containers at DockerCon Europe, and a new agreement to become a reseller of Microsoft’s Azure cloud platform. 
The two companies agreed to become “favored providers” for each other. HP will consider Azure its “preferred cloud alternative”, according to HPE CEO Meg Whitman, and Microsoft will recommend HPE to companies that require help implementing cloud.
The company recently announced that its public cloud product will be retired, and appears to be concentrating on private cloud, and on enabling developers to make better use of cloud overall by incorporating better PaaS and container capabilities into its offerings. 
Cloud and containers are sometimes seen as being opposed to each other, but with HPE’s new initiative they will be able complement each other. HPE’s goal is to enable enterprises to increase the speed of innovation, increasing the maneuverability of a client’s business in a time of new technologies. 
For example, the new “Docker-friendly” HPE Helion Developer Platform 2.0 is intended “to deploy microservices into managed Cloud Foundry-based platform-as-a-service offerings. Enterprises can use these capabilities to drive more agile development,” said Jessica Davis in InformationWeek. 
HPE’s Docker-focused offerings include:

HPE Helion Development Platform 2.0 with support for Docker: It enables developers to work with microservices packaged as Docker containers after deployment. Helion Code Engine makes this component a continuous integration/continuous deployment service. With it, users may automate the processes of building, testing and deploying workflow for code. The latter is merged into a Git repository through a Docker Trusted Registry and the Helion Development Platform.
HPE StormRunner and HPE AppPulse for Docker: Both are useful for testing, deploying and monitoring apps packaged in Docker containers by developers. It combines instruments to load test, monitor application performance, fully trace transactions throughout the systems stored in containers and as traditional backend systems, and perform load testing.
Remote Docker Swarm cluster monitoring with HPE Sitescope: Remote Docker Swarm cluster monitoring with HPE Sitescope becomes handy when you need to automatically build a cluster map and monitor all five layers of the cluster: Docker Swarm, cluster nodes, Docker daemon, running containers, and workload specific monitoring.
HPE Codar for Docker: If you need to continuously deploy hybrid workloads consisting of both traditional and containerized apps, in different proportions, HPE Codar for Docker adds Dockerfile and image formats support in its visual application designer.

Container development has taken hold in a big way. Mirantis Director, Product Management – Platform Services Craig Peters once said: “When you containerize something you essentially are separating out the local dependencies. Your business logic only depends on some specific versions of some libraries, and you don’t care about the rest of the operating system. But when you create virtual machine you have to create the all the things and manage all the dependencies. For example, if you need to update, if you have security fixes you have to update the all virtual machine even if the application depend on this. With the container you’ve just taken the bit you care about and you care what operating system is living on zone. So that’s a kind of maintenance and operations problem solving.” 
HPE Matter wrote that containers is a way to the faster and more scalable DC: “Containers mean disrupting traditional virtualization as we know it today by leveraging software-defined infrastructure architecture to create a workload-centric model. It is no longer a trend, it’s practically a necessity.”
The fact that HPE is putting this work into their HPE Helion distribution of OpenStack simultaneously muddies the waters and clears them up when it comes to the company’s newest alliance with Microsoft. The company has announced that it will not only be a reseller of Microsoft Azure (a competitor of OpenStack) but that Azure will be its “preferred cloud alternative”, according to HPE CEO Meg Whitman.  It’s unclear whether Azure, which is also available on-premises, will be an alternative to HPE Helion OpenStack for situations where enterprise clients need public cloud service, or an alternative to AWS in general.  A request to HPE for comment had not yet been returned at press time.
Resources

Containers get a fresh business boost from Hewlett Packard Enterprise – PC World Australia
Meg Whitman: HPE will sell Microsoft’s cloud – Business Insider
HP Enterprise will maximize opportunities as Azure reseller | InfoWorld
Hewlett Packard Enterprise Delivers Docker Solutions from the Data Center to the Cloud 
Hewlett Packard Enterprise shows off Docker tools
Building a Better Cloud Through Container Technology
Hewlett Packard Enterprise Embraces Docker 
Four Questions to Ask at HPE Discover – The New Stack
Hewlett Packard Enterprise Releases Docker Solutions Portfolio
HP Enterprise Embraces Docker, Containers – InformationWeek
HPE launches products for Docker – CIOL
Sales, share price sink for HP Inc – but it’s relative glee for HPE • The Register

The post HPE makes a deal with Microsoft, provides enterprise-grade Docker appeared first on Mirantis | The #1 Pure Play OpenStack Company.        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Maturing the Enterprise Cloud: Virtualization Field Day 6 Part 1</title>
    <id>http://fedoraplanet.org/8/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/8/" />
    <author>
      <name>AppFormix</name>
    </author>
    <content type="html/text">In the previous article in this series we gave you a quick overview of why OpenStack and Windows Nano Server provide some of the most exciting elements in the current Windows ecosystem. In this article we are going to expand on those elements, and also give you the tools you need to deploy your own Hyper-Converged cloud using our OpenStack Windows Liberty components along with Ubuntu’s OpenStack Linux ones!
 
Why is everyone so excited about Windows Nano Server?
Nano Server is a new installation option for Windows Server 2016, reducing the overall footprint to just a few hundreds MB of disk space. The resulting deployed OS is thus way faster to deploy and to boot, reducing drastically also the overall amount of updates and reboots required during daily management. In short, it’s an OS built for a cloud age and huge leap forward compared to traditional GUI based Windows deployments.
Nano images are designed to be purpose built for each deployment. That means that if you want a Windows Server that is just a hypervisor, you can build the image just with that role installed and nothing else. In this article we are going to focus on three main roles:

Compute (Cloudbase OpenStack components and Hyper-V)
Clustering
Storage (Storage Spaces Direct)

 
Storage Spaces Direct (S2D)
Aside from Nano itself, this is one of the features I am most excited about and a key element in allowing a hyper-converged scenario on Windows Server. Storage Spaces Direct is an evolution of Storage Spaces introduced in Windows Server 2012, with one important difference – it allows you to use locally attached storage. This means that you can use commodity hardware to build you own scale out storage at a fraction of the cost of a normal enterprise storage solution. This also means that we can create a hyper-converged setup where all Hyper-V compute nodes are clustered together and become bricks in a scale-out storage system.
 

Ok, Ok… lets deploy already!
Before we begin, a word of warning. Windows Nano Server is in Technical Preview (it will be released as part of Windows Server 2016). The following deployment instructions have been tested and validated on the current Technical Preview 4 and subject to possible changes in the upcoming releases.
 
Prerequisites
We want to deploy an OpenStack cloud on bare metal. We will use Juju for orchestration and MaaS (Metal as a Service) as a bare metal provider. Here’s our requirements list. We kept the number of resources to the bare minimum, which means that some features, like full components redundancy are left for one of the next blog posts:

MaaS install
Windows Server 2016 TP4 ISO
A Windows 10 or Windows Server 2016 installation. You will need this to build MaaS images.
One host to be used for MaaS and controller related services

Should have at least three NICs (management, data, external)


At least 4 hosts that will be used as Hyper-V compute nodes

Each compute node must have at least two disks
Each compute node should have at least two NICs (management and data)



As an example, our typical lab environment uses Intel NUC servers. They are great for testing and have been our trusty companions throughout many demos and OpenStack summits. These are the new NUCs that have one mSATA port and an one M.2 port. We will use the M.2 disk as part of the storage spaces direct storage pool. Each NUC has one extra USB 3 ethernet NIC that acts as a data port.
 
Here’s a detailed list of the nodes configuration:






Node 1


Ubuntu 14.04 LTS MaaS on bare metal with 4 VMs running on KVM.


3 NICs, each one attached to a standard linux bridge.
eth0 (attached to br0) is the MaaS publicly accessible NIC. It will be used by neutron as an external NIC.


eth1 (attached to br1) is connected to an isolated physical switch. This will be the management port for nodes deployed using MaaS.


eth2 (attached to br2) is connected to an isolated physical switch. This will be the data port used for tenant traffic.




This node also hosts 4 virtual machines:



Name
Tags
Purpose
NICs
vCPU
RAM
Disk


VM01
state
Juju state machine
eth0 attached to br1
2
2 GB
20 GB


VM02
s2d-proxy
Manages the Nano Server S2D cluster.
eth0 attached to br1
2
2 GB
20 GB


VM03
services
OpenStack controller
eth0 attached to br1 (maas management)
eth1 attached to br2 (isolated data port)
eth3 attached to br0 (external network)
4
8 GB
80 GB


VM04
addc
Active Directory Controller
eth0 attached to br1
2
2 GB
20 GB




 
The rest of the nodes look like this:






Node 2, 3, 4, 5


Nano Server Hyper-V compute nodes with Cloudbase OpenStack components


Tag: nano


2 NICs
one NIC attached to the MaaS management switch (PXE booting must be enabled and set as first boot option)


one NIC attached to the isolated data switch




 
Install MaaS
We are not going to go into too much detail over this as the installation process has been very well documented in the official documentation. Just follow this article, it’s very simple and straightforward. Make sure to configure your management network for both DHCP and DNS. After installing MaaS, it’s time to register your nodes in MaaS. You can do so by simply powering them on once. MaaS will automatically enlist them.
You can log in the very simple and intuitive MaaS web UI available at http://&amp;lt;MaaS&amp;gt;/MAAS and check that you nodes are properly enlisted.
 
Assign tags to your MaaS nodes
Tags allow Juju to request hardware with specific requirements to MaaS for specific charms. For example the Nano Server nodes will have a “nano” tag. This is not necessary if your hardware is completely homogenous. We listed the tags in the prerequisite section.
This can be done either with the UI by editing each individual node or with the following Linux CLI instructions.
Register a tag with MaaS:maas root tags new name='state'And assign it to a node:# &amp;lt;system_id&amp;gt; is the node's system ID. You can fetch it from MaaS
# using:
# maas root nodes list
# and usually has the form of:
# node-2e8f4d32-7859-11e5-8ee5-b8aeed71df42
# You can also get the ID of the node from the MaaS web ui by clicking on the node.
# The ID will be displayed in the browsers URL bar.
maas root tag update-nodes state add="&amp;lt;system_id&amp;gt;" 
Build Windows images
After you have installed MaaS, we need to build Windows images. For this purpose, we have a set of PowerShell CmdLets that will aid you in building the images. Log into your Windows 10 / Windows Server 2016 machine and open an elevated PowerShell prompt.
 
First lets download some required packages:# install Chocolatey package provider
Get-PackageProvider -Name chocolatey -ForceBootstrap
Set-PackageSource -Name Chocolatey -Trusted:$true

# Install Git
Install-Package -Source Chocolatey git

# Install Notepad++ (optional). Any other good editor will do as well.
Install-Package -Source Chocolatey notepadplusplus

# Add git to your path
$env:PATH +=  ";${env:ProgramFiles}\Git\cmd"

# check that git works
git --version

# If you wish to make the change to your $env:PATH permanent
# you can run:
# setx PATH $env:PATHDownload the required resources:$ErrorActionPreference = "Stop"
mkdir $HOME\hyper-c -ErrorAction SilentlyContinue
cd $HOME\hyper-c

# Fetch scripts and commandlets
Invoke-WebRequest https://bit.ly/FastWebRequest -OutFile FastWebRequest.psm1
Import-Module .\FastWebRequest.psm1

Invoke-FastWebRequest -Uri "https://the.earth.li/~sgtatham/putty/latest/x86/pscp.exe"
Invoke-FastWebRequest -Uri "https://the.earth.li/~sgtatham/putty/latest/x86/putty.exe"

# Fetch nano image tools
git clone https://github.com/cloudbase/cloudbase-init-offline-install.git nano-image-tools
pushd nano-image-tools
git checkout nano-server-support
git submodule init
git submodule update
popd

# Fetch Windows imaging tools
git clone https://github.com/cloudbase/windows-openstack-imaging-tools.git windows-imaging-tools
pushd windows-imaging-tools
git checkout experimental
popdYou should now have two extra folders in your home folder:

generate-nano-image
windows-openstack-imaging-tools-experimental

 
Generate the Nano image
Lets generate the Nano image first:cd $HOME\hyper-c\nano-image-tools

# Change this to your actual ISO location
$isoPath = "$HOME\Downloads\Windows_Server_2016_Technical_Preview_4.ISO"
# This will be your default administrator password. Change this to whatever you prefer
$password = ConvertTo-SecureString -AsPlaintext -Force "P@ssw0rd"
# This is the path of your Nano baremetal image 
$targetPath = "$HOME\DiskImages\Nano.raw.tgz"

# If your hardware needs extra drivers for NIC or storage, you can add it by
# passing the -ExtraDriversPaths option to the script.
.\NewNanoServerImage.ps1 -IsoPath $isoPath -TargetPath $targetPath `
-AdministratorPassword $password -Platform BareMetal `
-Compute -Storage -Clustering -MaxSize 1500MB `
-AddCloudbaseInit -AddMaaSHooks

cd ..

# Change to match you MaaS host address
$MAAS_HOST = "192.168.200.10"

# Copy the Nano image to the MaaS host, change the credentials accordingly
.\pscp.exe "$targetPath" "cloudbase@${MAAS_HOST}:"Now, SSH into your MaaS node and upload the image in MaaS using the following commands:# Get your user's MAAS API key from the following URL: http://${MAAS_HOST}/MAAS/account/prefs/ 
# Note: the following assumes that your MaaS user is named "root", replace it as needed 
maas login root http://${MAAS_HOST}/MAAS 
# Upload image to MaaS
# At the time of this writing, MaaS was version 1.8 in the stable ppa
# Windows Server 2016 and Windows Nano support has been added in the next stable release.
# as such, the images we are uploading, will be "custom" images in MaaS. With version &amp;gt;= 1.9
# of MaaS, the name of the image will change from win2016nano to windows/win2016nano
# and the title will no longer be necessary
maas root boot-resources create name=win2016nano title="Windows Nano server" architecture=amd64/generic filetype=ddtgz content@=$HOME/Nano.raw.tgzThe name is important. It must be win2016nano. This is what juju expects when requesting the image from MaaS for deployment.
 
Generate a Windows Server 2016 image
This will generate a MaaS compatible image starting from a Windows ISO, it requires Hyper-V:cd $HOME\hyper-c\windows-imaging-tools

# Mount Windows Server 2016 TP4 ISO
# Change path to actual ISO
$isoPath = $HOME\Downloads\WindowsServer2016TP4.iso

# Mount the ISO
$driveLetter = (Mount-DiskImage $isoPath -PassThru | Get-Volume).DriveLetter 
$wimFilePath = "${driveLetter}:\sources\install.wim"
 
Import-Module .\WinImageBuilder.psm1 
 
# Check what images are supported in this Windows ISO
$images = Get-WimFileImagesInfo -WimFilePath $wimFilePath
 
# Get the Windows images available in the ISO 
$images | select ImageName 
 
# Select the first one. Note: this will generate an image of Server Core.
# If you want a full GUI, or another image, choose from the list above
$image = $images[0]
 
$targetPath = "$HOME\DiskImages\Win2016.raw.tgz" 
 
# Generate a Windows Server 2016 image, this will take some time!
# This requires Hyper-V for running the instance and installing Windows updates
# If your hardware needs extra drivers for NIC or storage, you can add it by
# passing the -ExtraDriversPath option to the script.
# You also have the option to install Windows Updates by passing in the -InstallUpdates option
New-MaaSImage -WimFilePath $wimFilePath -ImageName $image.ImageName `
-MaaSImagePath $targetPath -SizeBytes 20GB -Memory 2GB `
-CpuCores 2

cd ..

# Copy the Nano image to the MaaS host
.\pscp.exe "$targetPath" "cloudbase@${MAAS_HOST}:"Upload the image to MaaS:# upload image to MaaS
# At the time of this writing, MaaS was version 1.8 in the stable ppa
# Windows Server 2016 and Windows Nano support has been added in the next stable release.
# as such, the images we are uploading, will be "custom" images in MaaS. With version &amp;gt;= 1.9
# of MaaS, the name of the image will change from win2016 to windows/win2016
# and the title will no longer be necessary
maas root boot-resources create name=win2016 title="Windows 2016 server" architecture=amd64/generic filetype=ddtgz content@=$HOME/Win2016.raw.tgzAs with the Nano image, the name is important. It must be win2016.
 
Setting up Juju
Now the fun stuff begins. We need to fetch the OpenStack Juju charms and juju-core binaries, and bootstrap the juju state machine. This process is a bit more involved, because it requires that you copy the agent tools on a web server (any will do). A simple solution is to just copy the tools to /var/www/html on your MaaS node, but you can use any web server at your disposal .
For the juju deployment you will need to use an Ubuntu machine. We generally use the MaaS node directly in our demo setup, but if you are running Ubuntu already, you can use your local machine.
 
Fetch the charms and tools
For your convenience we have compiled a modified version of the agent tools and client binaries that you need to run on Nano Server. This is currently necessary as we’re still submitting upstream the patches for Nano Server support, so this step won’t be needed by the time Windows Server 2016 is released.
From your Ubuntu machine:# install some dependencies
# add the juju stable ppa. We need this to get juju-deployer
sudo apt-add-repository -y ppa:juju/stable
# install packages
sudo apt-get update
sudo apt-get -y install unzip git juju-deployer

mkdir -p $HOME/hyper-c
cd $HOME/hyper-c

# Download juju-core with Nano support and the Hyper-C charms
git clone https://github.com/cloudbase/hyper-c.git hyper-c-master
wget "https://github.com/cloudbase/hyper-c/releases/download/hyper-c/juju-core.zip"
unzip juju-core.zip

# Add the client folder to the $PATH. You can make this change permanend
# for the current user by adding:
# export PATH="$HOME/hyper-c/juju-core/client:$PATH"
# to $HOME/.bashrc
export PATH="$HOME/hyper-c/juju-core/client:$PATH"
# test that the juju client is in your path
juju versionIf everything worked as expected, the last command should give you the Juju version.
 
Configuring the Juju environment
If you look inside $HOME/hyper-c/juju-core you will see a folder called tools. You need to copy that folder to the web server of your choice. It will be used to bootstrap the state machine. Lets copy it to the MaaS node:# NOTE: If you are following this article directly on your MAAS node,
# you can skip these steps
cd $HOME/hyper-c
scp -r $HOME/hyper-c/juju-core/tools cloudbase@$MAAS_HOST:~/Now, ssh into your MaaS node and copy these files in a web accessible location:sudo cp -a $HOME/hyper-c/juju-core/tools /var/www/html/
sudo chmod 755 -R  /var/www/html/toolsBack on your client machine, create the juju environments boilerplate:juju initThis will create a folder $HOME/.juju. Inside it you will have a file called environments.yaml that we need to edit.
Edit the environments file:nano $HOME/.juju/environments.yamlWe only care about the MaaS provider. You will need to navigate over to your MaaS server under http://${MAAS_HOST}/MAAS/account/prefs/ and retrieve the MaaS API key like you did before.
Replace your environments.yaml to make it look like the following:default: maas

environments:
    maas:
        type: maas
        # this is your MaaS node. Replace "MAAS_IP" with the actual hostname or IP
        maas-server: 'http://MAAS_IP/MAAS/'
        # This is where you uploaded the tools in the previous step. Replace "MAAS_IP" with actual hostname or IP
        agent-metadata-url: "http://MAAS_IP/tools"
        agent-stream: "released"
        maas-oauth: 'maas_API_key'
        # This will become you juju administrative user password
        # you may use this password to log into the juju GUI
        admin-secret: 'your_secret_here'
        disable-network-management: false
        bootstrap-timeout: 1800Before you bootstrap the environment, it’s important to know if the newly bootstrapped state machine will be reachable from your client machine. For example, If you have a lab environment where all your nodes are in a private network behind MaaS, where MaaS is also the router for the network it manages, you will need to do two things:

enable NAT and ip_forward on your MaaS node
create a static route entry on your client machine that uses the MaaS node as a gateway for the network you configured in MaaS for your cluster

Enable NAT on MaaS:# enable MASQUARADE
# br0 publicly accessible interface
# br1 MaaS management interface (PXE for nodes)
/sbin/iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
/sbin/iptables -A FORWARD -i br0 -o br1 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i br1 -o br0 -j ACCEPT

# enable ip_forward
echo 'net.ipv4.ip_forward=1' &amp;gt;&amp;gt; /etc/sysctl.conf
sysctl -pAdd a static route on your client:# $MAAS_HOST was defined above in the sections regarding image generation
# NOTE: this is not needed if you are running the juju client directly on your MaaS node
route add -net 192.168.2.0 255.255.255.0 gw $MAAS_HOSTYou are now ready to bootstrap your environment:# Adapt the tags constraint to your environment
juju bootstrap --debug --show-log --constraints tags=state 
Deploy the charms
You should now have a fully functional juju environment with Windows Nano Server support. Time to deploy the charms!
This is the last step in the deployment process. For your convenience, we have made a bundle file available inside the repository. You can find it in:$HOME/hyper-c/hyper-c-master/openstack.yamlMake sure you edit the file and set whatever options applies to your environment. For example, the bundle file expects to find nodes with certain tags. Here is an example:s2d-proxy:
  num_units: 1
  charm: local:win2016/s2d-proxy
  branch: lp:cloudbaseit/s2d-proxy
  options:
    # Change this to an IP address that matches your environment.
    # This IP address should be in the same network as the IP addresses
    # you configured your MaaS cluster to assign to your nodes. Make sure
    # that this IP cannot be allocated to any other node. This can be done
    # by leaving a few IP addresses out of the static and dynamic ranges MaaS
    # allocates from.
    # For example: 192.168.2.10-192.168.2.100 where 192.168.2.0-192.168.2.9
    # are left for you to decide where to allocate them.
    static-address: 192.168.2.9
  # change this tag to match a node you want to target
  constraints: "tags=s2d-proxy"
nova-hyperv:
  num_units: 4
  charm: local:win2016nano/nova-hyperv
  branch: lp:cloudbaseit/nova-hyperv
  options:
    use-bonding: false
    # These are all the MAC addresses from all the nodes that are supposed to be
    # used as data ports. You can find these ports in MaaS under node details
    # Make sure you change this to match your environment.
    data-port: "3c:18:a0:05:cd:1c 3c:18:a0:05:cd:07 3c:18:a0:05:cd:22 3c:18:a0:05:cd:1e"
    network-type: "hyperv"
    openstack-version: "liberty"
  constraints: "tags=nano"Pay close attention to every definition in this file. It should precisely mirror your environment (tags, MAC addresses, IP addresses, etc). A misconfiguration will yield unpredictable results.
Use juju-deployer to deploy everything with just one command:cd $HOME/hyper-c/hyper-c-master
juju-deployer -L -S -c openstack.yamlIt will take a while for everything to run, so sit back and relax while your environment deploys. There is one more thing worth mentioning. Juju has a gorgeous web GUI. Its not resource intensive, so you can deploy it to your state machine. Simply:juju deploy juju-gui --to 0You will be able to access it using the IP of the state machine. To get the ip simply do:juju status --format tabularThe user name will be admin and the password will be the value you set for admin-secret, set in juju’s environments.yaml.
At the end of this you will have the following setup:

Liberty OpenStack cloud (with Ubuntu and Cloudbase components)
Active Directory controller
Hyper-V compute nodes
Storage Spaces Direct

 
Access your OpenStack environment
Get the IP of your Keystone endpointjuju status --format tabular | grep keystoneExport the required OS_* variables (you can also put them in your .bashrc):export OS_USERNAME=cbsdemo
export OS_PASSWORD=Passw0rd
export OS_TENANT_NAME=admin
export OS_AUTH_URL=http://&amp;lt;keystone_ip&amp;gt;:35357/v2.0/

# Let's list the Nova services, including the four Nano Server compute nodes
sudo apt-get install python-novaclient -y
nova service-listYou can access also Horizon by fetching its IP from Juju and open it in your web browser:juju status --format tabular | grep openstack-dashboard 
What if something went wrong?
The great thing in automated deployments is that you can always destroy them and start over!juju-deployer -TT -c openstack.yamlForm here you can run again:juju-deployer -L -S -c openstack.yaml 
What’s next?
Stay tuned, in the next posts, we’ll show how to add Cinder volume on top of Storage Spaces Direct and how to easily add fault tolerance to your controller node (the Nano Server nodes are already fault tolerant).
You can also start deploying some great guest workload on top of your OpenStack cloud, like SQL Server, Active Directory, SharePoint, Exchange etc using our Juju charms!
I know this has been a long post, so if you managed to get this far, congratulations and thank you! We are curious to hear how you will use Nano Server and storage spaces direct!
The post Hyper-Converged OpenStack on Windows Nano Server – Part 2 appeared first on Cloudbase Solutions.        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Voices from Tokyo: The white-collar diaries</title>
    <id>http://fedoraplanet.org/9/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/9/" />
    <author>
      <name>Mirantis</name>
    </author>
    <content type="html/text">Gnocchi is the time series database-as-a-service (TDBaaS) project started under Ceilometer. Gnocchi's latest version,1.3.1 was recently released. 

We've received good feedback on Gnocchi so far, even though we have only had a little of it. Recently, in order to have a better feeling of where we were at, we wanted to know how fast (or slow) Gnocchi was.

The early benchmarks that some of the Mirantis engineers ran last year showed pretty good signs. But a year later, it was time to get real numbers and have a good understanding of Gnocchi capacity.

Benchmark tools

The first thing I realized when starting the process is that we were lacking the tools to run benchmarks. Therefore, I started to write some benchmark tools in the python-gnocchiclient, which provides a command line tool to interrogate Gnocchi. I added a few basic commands to measure metric performance, such as:

$ gnocchi benchmark metric create -w 48 -n 10000 -a low
+----------------------+------------------+
| Field                | Value            |
+----------------------+------------------+
| client workers       | 48               |
| create executed      | 10000            |
| create failures      | 0                |
| create failures rate | 0.00 %           |
| create runtime       | 8.80 seconds     |
| create speed         | 1136.96 create/s |
| delete executed      | 10000            |
| delete failures      | 0                |
| delete failures rate | 0.00 %           |
| delete runtime       | 39.56 seconds    |
| delete speed         | 252.75 delete/s  |
+----------------------+------------------+


The command line tool supports the --verbose switch to have detailed progress report on the benchmark progression. So far it supports metric operations only, but that's the most interesting part of Gnocchi.

Spinning up some hardware

I got a couple of bare metal servers to test Gnocchi on. I dedicated the first one to Gnocchi, and used the second one as the benchmark client, plugged on the same network. Each server is made of 2×Intel Xeon E5-2609 v3 (12 cores in total) and 32 GB of RAM. That provides a lot of CPU to handle requests in parallel.

Then I simply performed a basic RHEL 7 installation and ran devstack to spin up an installation of Gnocchi based on the master branch, disabling all of the others OpenStack components. I then tweaked the Apache httpd configuration to use the worker MPM and increased the maximum number of clients that can sent request simultaneously.

I configured Gnocchi to use the PostsgreSQL indexer, as it's the recommended one, and the file storage driver, based on Carbonara (Gnocchi own storage engine). That means files were stored locally rather than in Ceph or Swift. Using the file driver is less scalable (you have to run on only one node or uses a technology like NFS to share the files), but it was good enough for this benchmark and to have some numbers and profiling the beast.

The OpenStack Keystone authentication middleware was not enabled in this setup, as it would add some delay validating the authentication token.

Metric CRUD operations

Metric creation is pretty fast. I managed to attain 1500 metric/s created pretty easily. Deletion is now asynchronous, which means it's faster than in Gnocchi 1.2, but it's still slower than creation: 300 metric/s can be deleted. That does not sound like a huge issue since metric deletion is actually barely used in production.

Retrieving metric information is also pretty fast and goes up to 800 metric/s. It'd be easy to achieve very higher throughput for this one, as it'd be easy to cache, but we didn't feel the need to implement it so far.

Another important thing is that all of these numbers are constant and barely depends on the number of the metric already managed by Gnocchi.





Sending and getting measures

Pushing measures into metrics is one of the hottest topic. Starting with Gnocchi 1.1, the measures pushed are treated asynchronously, which makes it much faster to push new measures. Getting new numbers on that feature was pretty interesting.

The number of metric per second you can push depends on the batch size, meaning the number of actual measurements you send per call. The naive approach is to push 1 measure per call, and in that case, Gnocchi is able to handle around 600 measures/s. With a batch containing 100 measures, the number of calls per second goes down to 450, but since you push 100 measures each time, that means 45k measures per second pushed into Gnocchi!

I've pushed the test further, inspired by the recent blog post of InfluxDB claiming to achieve 300k points per second with their new engine. I ran the same benchmark on the hardware I had, which is roughly two times smaller than the one they used. I achieved to push Gnocchi to a little more than 120k measurement per second. If I had same hardware as they used, I could interpolate the results to achieve almost 250k measures/s pushed. Obviously, you can't strictly compare Gnocchi and InfluxDB since they are not doing exactly the same thing, but it still looks way better than what I expected.

Using smaller batch sizes of 1k or 2k improve the throughput further to around 125k measures/s.





What about getting measures? Well, it's actually pretty fast too. Retrieving a metric with 1 month of data with 1 minute interval (that's 43k points) takes less than 2 second.

Though it's actually slower than what I expected. The reason seems to be that the JSON is 2 MB big and encoding it takes a lot of time for Python. I'll investigate that. Another point I discovered, is that by default Gnocchi returns all the datapoints for each granularities available for the asked period, which might double the size of the returned data for nothing if you don't need it. It'll be easy to add an option to the API to only retrieve what you need though!

Once benchmarked, that meant I was able to retrieve 6 metric/s per second, which translates to around 260k measures/s.

Metricd speed

New measures that are pushed into Gnocchi are processed asynchronously by the gnocchi-metricd daemon. When doing the benchmarks above, I ran into a very interesting issue: sending 10k measures on a metric would make gnocchi-metricd uses up to 2 GB RAM and 120 % CPU for more than 10 minutes.

After further investigation, I found that the naive approach we used to resample datapoints in Carbonara using Pandas was causing that. I reported a bug on Pandas and the upstream author was kind enough to provide a nice workaround, that I sent as a pull request to Pandas documentation.

I wrote a fix for Gnocchi based on that, and started using it. Computing the standard aggregation methods set (std, count, 95pct, min, max, sum, median, mean) for 10k batches of 1 measure (worst case scenario) for one metric with 10k measures now takes only 20 seconds and uses 100 MB of RAM – 45× faster. That means that in normal operations, where only a few new measures are processed, the operation of updating a metric only takes a few milliseconds. Awesome!

Comparison with Ceilometer

For comparison sake, I've quickly run some read operations benchmark in Ceilometer. I've fed it with one month of samples for 100 instances polled every minute. That represents roughly 4.3M samples injected, and that took a while – almost 1 hour whereas it would have taken less than a minute in Gnocchi. Then I tried to retrieve some statistics in the same way that we provide them in Gnocchi, which mean aggregating them over a period of 60 seconds over a month.





Obviously, Ceilometer is very slow. It has to look into 4M of samples to compute and return the result, which takes a lot of time. Whereas Gnocchi just has to fetch a file and pass it over. That also means that the more samples you have (so the more time you collect data and the more resources you have), slower Ceilometer will become. This is not a problem with Gnocchi, as I emphasized when I started designing it.

Most Gnocchi operations are O(log R) where R is the number of metrics or resources, whereas most Ceilometer operations are O(log S) where S is the number of samples (measures). Since is R millions of time smaller than S, Gnocchi gets to be much faster.

And what's even more interesting, is that Gnocchi is entirely scalable horizontally. Adding more Gnocchi servers (for the API and its background processing worker metricd) will multiply Gnocchi performances by the number of servers added.

Improvements

There are several things to improve in Gnocchi, such as splitting Carbonara archives to make them more efficient, especially from drivers such as Ceph and Swift. It's already on my plate, and I'm looking forwarding to working on that!

And if you have any questions, feel free to shoot them in the comment section. 😉

This post was contributed by Julien Danjou, software engineer at Red Hat. Superuser is always interested in how-tos and other contributions, please get in touch: editor@superuser.org

Cover Photo// CC BY NC        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Hyper-Converged OpenStack on Windows Nano Server – Part 2</title>
    <id>http://fedoraplanet.org/10/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/10/" />
    <author>
      <name>Alessandro Pilotti</name>
    </author>
    <content type="html/text">There's a new book to speed up your knowledge of OpenStack Neutron. The second edition of "Learning OpenStack Networking (Neutron)," is coming down the pike with updates and additional chapters. 

Author James Denton, principal architect at Rackspace, has had his work cut out for him since the October 2014 edition launched. This 329-page manual available now from Packt Publishing promises to help readers "wield the power" of networking in OpenStack.

Superuser talked to Denton about why networking is taking center stage now, eliminating pain points in the Neutron project and his favorite resources for learning about OpenStack. 



What are the most significant updates to this edition of the book?

The second edition is based on features available as of the Kilo release and includes a few new chapters that cover:

• L3 High Availability using Virtual Router Redundancy Protocol (VRRP)
• Distributed Virtual Routing
• VPN as-a-service

In addition, Security Groups and firewall-as-a-service have been broken out into their own chapters, each with new and/or enhanced diagrams and figures to better explain their respective concepts and functionality. The concepts described in the book apply to the Liberty release as well, but there many be minor differences in implementation along with additional functionality compared to Kilo.


Holy crap: @jimmdenton is a golden god. I'm reading his book on Neutron networking in #OpenStack...and NEUTRON IS STARTING TO MAKE SENSE.— Saint Aardvark (@saintaardvark) May 20, 2015


&amp;lt;script async="async" charset="utf-8" src="http://platform.twitter.com/widgets.js"&amp;gt;&amp;lt;/script&amp;gt;What was your reaction when Neutron was called out in the Tokyo Summit keynote as the most active project in OpenStack?

Neutron has been called out numerous times over the last two years as a major pain point in architecting and operating an OpenStack cloud. 

It’s no surprise that Neutron was noted as the most active project this time around, considering all of the focus and resources that have been poured into stabilizing core features and functionality. 

Also, as the project has matured, you’re seeing more vendors take notice and begin developing plugins to bring their technologies into the fold. Networking is the foundation of the cloud, and the work that the team has put into the project in the last two to three release cycles has really paid off.

Any thoughts on why "The time is now for networking to have its day," as Mark Collier said?

Server virtualization technologies have really matured, and the focus now is to bring the network stack into the fold. It makes sense that the next logical step is to virtualize network appliances in the same way servers were virtualized years ago. Network vendors are making it easier to bring firewalls, load balancers, and more in as virtual appliances that can be treated like any other virtual machine. A lot of work has been done in Neutron over the last couple of releases to ensure that the network plumbing and security model can support virtualized network appliances. 

Now that the barriers are being eliminated, we should start seeing more and more network administrators embrace the idea of network virtualization and its benefits, much like server administrators did a decade ago. In addition, containerization technologies have really turned traditional networking implementations on their head, so I think we’ll see a shift towards software-defined networking (SDN) and other non-traditional ways of connecting devices to allow for large scale networking. 

There’s a lot of work to be done!

Neutron has been criticized for its complexity on several OpenStack user surveys -- what's the best way to tackle that for an operator/administrator?

Networking is complicated, and we as users have been fortunate in recent years that vendors have simplified the process of configuring network devices and even networking within operating systems. Think back 15-20 years though, and things weren’t so easy.  The underlying network functions are as complex as ever, but when those functions and configurations are abstracted from the user, one can take for granted how ‘easy’ it is. 

Neutron is complex because networking is complex. No one system or environment is the same, and Neutron has to allow for numerous combinations and configurations. I think it’s important to have a solid foundation in networking to understand how to configure and implement Neutron features; even more so if you’re responsible for maintaining and troubleshooting them. Many operators may have a strong system administration or development background, but lack foundational network knowledge that would benefit them in standing up and maintaining an OpenStack cloud. Work is underway to provide better documentation on simple network configurations, but the truth is, anything other than simple is going to require some work to get right for your environment and use-case. 


It's an excellent book for beginners and advanced https://t.co/KxjtewsCIQ— Gatuus (@gatuus) November 12, 2015


&amp;lt;script async="async" charset="utf-8" src="http://platform.twitter.com/widgets.js"&amp;gt;&amp;lt;/script&amp;gt;There's so much you can learn online -- why buy a physical book (or even an e-book)?

There is a ton of useful information regarding OpenStack and Neutron on the internet. The problem is finding what’s relevant to you. When you’re new to a subject, it’s hard to know what to search for, and even harder to weed through information without context or experience. Most blogs and snippets cover a particular issue or feature, and while extremely useful, are just one piece of a much larger puzzle. 

The goal with this book is to provide an end-to-end experience for the reader, beginning with architecting the physical network, installing OpenStack and Neutron, and laying a foundation that enable the creation of networks, subnets, routers, and advanced network devices. I think readers can appreciate having all of that information in a centralized location.

What books or materials got you started with OpenStack?

When I started with OpenStack, we were deploying Essex-based clouds using nova-network. When Grizzly was introduced, we decided to adopt Quantum (Neutron) and found there was little information to be found other than the code itself. 

I spent a lot of time testing various configurations until I found one that provided some kind of connectivity. I read up on the Open vSwitch manual to figure out how flows worked and were implemented, and spent some time reverse-engineering various OpenStack code files to see what was going on under the hood. Manually creating bridges and flows, creating and attaching VMs, and breaking things really helped me figure out how everything fit together and was orchestrated. Asaaf Muller, a core Neutron developer, has an excellent blog at http://assafmuller.com/ where he breaks down various Neutron components and technologies. I highly recommended his blog for anyone looking to immerse themselves in the nuts and bolts of Neutron.  

Cover Photo // CC BY NC        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Benchmarking Gnocchi for fun and profit</title>
    <id>http://fedoraplanet.org/11/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/11/" />
    <author>
      <name>OpenStack Superuser</name>
    </author>
    <content type="html/text">You never know where a conversation in the hallway might lead you. 

Between sessions at the 2014 OpenStack Summit Paris, Anne Gentle spied something she didn’t recognize on Justin Shepherd’s smartphone. “I’m a curious one,” says Gentle, a principle engineer at Rackspace, so she asked him about it.

From thousands of miles away, Shepherd, a distinguished architect for Rackspace Private Cloud, was keeping an eye his wife’s health while she slept in Texas. After a decade of monitoring her Type 1 diabetes, she was pregnant. 

“You almost are both diabetic at that point. All of your conversations revolve around her blood sugar. Are you too high, are you too low? When did you last eat? Do I need to get you some sugar? Are you starting to pass out in the middle of the night? Do I need to get you some orange juice? Let's take care of all of your blood glucose,” Shepherd says. “That becomes a big part of your life.”



The trip to Paris complicated that vital monitoring process. Before leaving, Shepherd investigated how he could check on her remotely and realized that the Dexcom Continuous Glucose Monitoring device, or Dexcom CGMS, she was using had a service called Dexcom Share, which allows you to take data from the Dexcom CGMS, send it to an iPod-like device and connect that to your smartphone via Bluetooth. The proprietary set-up costs about $400, plus a monthly fee, he says.

His strategy resonated with Gentle, whose son Evan had been diagnosed at age 11 with Type 1 diabetes after the sugary funnel of a Pixy Stick sent him to the emergency room. 

“I was trying to figure out how to give my son more control and at the same time, train him. He's going to middle school this year, he should have more independence. How can we give that to him? I know we can manage this with technology…I have access to a lot of cloud,” Gentle says. “Would you rather have your kid, your wife, your friend, pricking fingers five times a day, or go ahead and get data every five minutes? That's what continuous glucose monitoring (CGM) gives you…We have to emphasize how valuable this is in controlling this disease. ”

Shepherd and Gentle got to talking and realized they could do better. Essentially, the Dexcom CGMS was just connecting a couple of devices and providing those data points. The person monitoring has just a trend line and can set some alarms, but a lot of things affect diabetes control. “If you exercise, that actually drops your blood sugar. When you give yourself insulin, it drops your blood sugar, when you eat, it takes your blood sugar up,” Shepherd says. “There's all this data that would be really interesting to put together and wouldn't it be amazing if there were an open-source solution to this?”



Gentle’s research led her to John Costik, software developer and father of a son also named Evan, an original member of the CGM in the cloud team of a nonprofit called the Nightscout Foundation. Nightscout is an open source, DIY project that allows real-time access to a CGM data via personal website, smartwatches and smartphone apps and widgets. The project's original approach to collect the data required an Android phone attached to the CGM receiver, but the project now has a REST API for collecting and displaying data. 

She found inspiration in Nightscout’s rallying cry, the slogan “We Are Not Waiting.” As in “not waiting for a proprietary solution, not waiting for a company to market a product but reverse-engineering the system to figure out how to make it work for their needs today,” Gentle says. A Stanford diabetes data hackathon gave birth to the slogan in 2013 which quickly gained momentum as a Twitter hashtag, #WeAreNotWaiting.

Her son’s current set-up is a combination of proprietary and open-source solutions. Evan wears a sensor on his arm or backside and carries the small Dexcom device — not too heavy for a sixth grader to stick in his pocket all the time. The device pairs with his iPhone and the Nightscout web application (Node.js connected to a MongoDB database) running on an OpenStack cloud server hosted at Rackspace. Gentle says that there were some initial head scratchers with the data — you have to rely on common sense sometimes if the numbers don't quite look right — but overall it’s given her peace of mind. She and her husband can watch their son's blood sugar on a Pebble, a smartwatch or smartphones.



“This has been amazing because I can have a babysitter come in and just tell her, ‘Go to this webpage on your phone and you can watch his blood sugar too and just make sure he's in safe ranges,’” Gentle says.  

In the process of putting together her son’s set-up, she learned a lot about what it means to run an app on OpenStack, how to get everything working together and reliable enough to stay running. The result is a tiered application stack with multiple open source projects working together and multiple proprietary solutions working together. 



“Our hope is to inspire you to look into open source, to think of ways to solve the data problems that you might have already,” Gentle says. “Let's not wait for someone else to solve it. The OpenStack community is especially good at thinking this way.”

Shepherd and Gentle teamed up to show how they’re monitoring their nearest and dearest (and how to avoid being worst helicopter relative, ever) at the Summit Tokyo. Catch the complete 37-minute talk on the OpenStack Foundation's YouTube channel.
&amp;lt;iframe allowfullscreen="allowfullscreen" frameborder="0" height="" src="https://www.youtube.com/embed/7HvJTc9zl_Y" width=""&amp;gt;&amp;lt;/iframe&amp;gt;

Cover Photo // CC BY NC        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Evolving IT architectures: It can be hard</title>
    <id>http://fedoraplanet.org/12/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/12/" />
    <author>
      <name>Red Hat Stack</name>
    </author>
    <content type="html/text">Introduction
Welcome to Last week on OpenStack Dev (“Lwood”) for the week ending 29th November 2015. For more background on Lwood, please refer here.
Basic Stats for week 23rd to 29th November 2015 :

~618 Messages (down about 2% relative to last week)
~184 Threads (down about 3% relative to last week) 

Traffic and threads steady despite holidays in some parts of the OpenStack world…
Notable Discussions
Work in progress: Grafana Dashboard for Bugs
Lwood-20151115 mentioned the recently launched http://grafana.openstack.org website and this week there’s a post and proof of concept mockup from Markus Zoeller outlining some work he’s doing towards a bug dashboard for OpenStack projects.  He’s actively soliciting feedback on the proposal and assistance – check it out and pitch in if you can :)
Encouraging first time contributors through special bug tags 
Shamail Tahir kicks off an interesting thread about using bug tags to encourage first time contributors.  In essence the idea is to have a specific bug tag (probably a new one) that flags bugs as being suitable for first time contributors.  Some review logic could be added that would reject or at least -1 patch-sets that weren’t from a first time contributor.
A good bit of discussion followed including the suggestion that projects may wish to adopt this and take the idea a little further by having certain bugs defined this way that would also have additional comments in them to help the newcomer know where to go solution wise.
Tweaking the IRC Meeting Infrastructure
Tony Breeds puts forward a very cogent case for making some tweaks to the IRC channels used for OpenStack related meetings.  In short he proposes adding #openstack-meeting-5 and renaming #openstack-meeting-alt to #openstack-meeting-2 (which is what it effectively is anyways)
The proposal was well received it looks like the changes will proceed over the next week or two.
Mitaka 1 Milestone week November 30th – December 4th
Doug Hellmann reminds us that week R-18 (that’s this week) is the Mitaka 1 milestone deadline and provides a hand list of things that projects should be doing in light of this.
Moving to a trusting model ?
Morgan Fainberg puts forward a proposal to subtly alter the social policy that is applied to the permitted relationship between who writes code, who reviews code and who reviews/approves code for inclusion into OpenStack.
As it stands most projects prevent each of these three people being from the same company/organisation – the default is, in a sense, “distrust”.  In his post Adam Young provides a little further context around why the policy was worded the way it was – interestingly it’s as much about protecting employee developers from management pressure as anything else. 
Morgan’s proposal is essentially that it be made “ok” for all three kinds of involvement (write code, review code, approve code) to be done by people from the same organisation/company with the acknowledgment that if it is felt this trust is broken, the changes can be reverted and the core status of those involved be reviewed.  a “trust” rather than “distrust” model.
While it’s a longish thread (27 messages at the time of writing) I’d commend it to all involved in OpenStack development and, equally people who manage folk that undertake this work.
Changes to the DocImpact flag
Lana Brindley writes of changes to the DocImpact flag – a flag used by developers to notify the Documentation team when a patch might cause a change in the docs.  
To quote Lana: “TL;DR: In the future, you will need to add a description whenever you add a DocImpact flag in your commit message.”  
The rationale is eminently sensible – providing a description will save the Docs folks having to dig quite so deeply to understand what the actually impact on the documentation will be.
More detail can be found in the original post or the spec.  Significantly, a Jenkins job will test for this and the job will fail if there is no description – so please bear this in mind for future patches.
Process change for closing bugs when patches merge
Doug Hellman advises of some changes to automated behaviours when patches containing “Closes-Bug” are merged.  Such patches will no longer automatically make the patch status update to “Fix Committed” as it’s seemingly been a bit of a wonky part of the release process. 
Implications of this likely apply to all OpenStack developers, so if that’s you, please take a few minutes to read Doug’s post…
Releases vs Development Cycle explained in a single post
Succinctly put by Thierry Carrez in this email – worth a quick read but, frankly, tricky to summarise in Lwood in less than several paragraphs by which point you might as well have read his email :)
Midcycle dates and locations
A few more midcycle announcements and one poll this past week

[neutron][lbaas][fwaas] Midcycle 12-15 January in San Antonio, TX, USA – Doug Wiegley
[nova] Midcycle 26-28 January in Bristol, UK – Paul Murray
[keystone] Midcycle 27-29 January in Austin, TX, USA – Steve Martinelli
[puppet] Midcycle Poll to reach consensus – Emilien Macchi

People and Projects

[oslo] Proposing ChangBo Guo as core review – Victor Stinner
[fuel] Nominating Dimitry Burmistrov and Sergey Kulanov to core reviewers of fuel-main and fuel-mirror respectively – Roman Vyalov
[glance] Adding Sabari Kumar Murugesan to the glance-core team – Flavio Percoco
[cloudkitty] Removing inactive members Adrian Turjak and François Magimel from core-group – Stéphane Albert

Further Reading &amp;amp; Miscellanea
Don’t forget these excellent sources of OpenStack news :)

“What’s Up, Doc?” by Lana Brindley
OpenStack Weekly Community Newsletter by Jay Fankhauser and others
OpenStack Developer Mailing List Digest by Mike Perez

This edition of Lwood brought to you by Jeff Beck (Guitar Shop, There and Back, Wired) Jordan Rudess (Rhythm of Time), Herbie Hancock (Cantaloupe Island) amongst other excellent tunes.        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Ceph is moving outside DevStack core to a plugin</title>
    <id>http://fedoraplanet.org/13/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/13/" />
    <author>
      <name>Sébastien Han</name>
    </author>
    <content type="html/text">Welcome back from Tokyo. While there, I did not realize a three-dimensional subway map exists for Tokyo, but I sure loved traveling on the subway.
Welcoming the latest projects to OpenStack
Speaking of amazing cities and their subway maps, we should mention the growing list of OpenStack projects. We welcome these projects to OpenStack governance since the OpenStack Summit.


Monitoring – both OpenStack and its resources: monasca
Backups for file systems using OpenStack: freezer
Deployment for OpenStack: fuel
Cluster management service for Compute and Orchestration: senlin
Integrate Hyper-V, Windows and related components into OpenStack: winstackers


During these last weeks, the TC also had other project reviews requests that were put on hold for later once those projects and/or teams are more mature and ready to join the Big Tent.
Reports from TC Working Groups
Project Team Guide
The Project Team Guide team held a session back in Tokyo to discuss the next steps for this project. As a result of that session, more content will be created (or moved from the wiki): add community best practices, detail the benefits and trade-offs of the various release models, introduce deliverables and tags (as maintained in the governance repo’s projects.yaml), detail what common infrastructure projects can build on, and so on.
Communications Group
The communications working group (the one that brings these blog posts to you) will continue to operate under the same model. Announcements, summaries and communications will be sent out as they have been during the last cycle. Remember that feedback is always welcome and the group is looking for ways to improve. Talk back to us, we’re listening!
Project Tags
These are the latest new project tags created by the Technical Committee.


team:single-vendor: A new tag was added to communicate when a project team is currently driven by a single organization. We had some discussion about using the term “vendor” or “organization” but this intent is to show the opposite of a diversity in the team’s makeup.
assert:supports-upgrade: A new tag has been added to communicate when a project supports upgrades. Teams should apply this tag to their project if they assert they intend to support ongoing upgrades.
assert:supports-rolling-upgrade: A new tag has been added to communicate when a project supports rolling upgrades. Team should apply this tag to their project if they assert that operators can expect to perform rolling upgrades of their project, where the service can remain running while the upgrade is performed.

        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Lwood-20151129</title>
    <id>http://fedoraplanet.org/14/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/14/" />
    <author>
      <name>Hugh Blemings</name>
    </author>
    <content type="html/text">Success Bot Says

vkmc: We got 7 new interns for the Outreachy program December-March 2015 round.
bauzas: Reno in place for Nova release notes.
AJaeger: We now have Japanese Install Guides published for Liberty [1].
robcresswell: Horizon had a bug day! We made good progress on categorizing new bugs and removing old ones, with many members of the community stepping up to help.
AJaeger: The OpenStack Architecture Design Guide has been converted to RST [2].
AJaeger: The Virtual Machine Image guide has been converted to RST [3].
Ajaeger: Japanese Networking Guide is published as draft [4].
Tell us yours via IRC with a message “#success [insert success]”.


Release countdown for week R-18, Nov 30 – Dec 4

All projects following the cycle-with-milestones release model should be preparing for the milestone tag.
Release Actions:

All deliverables must have Reno configured before adding a Mitaka-1 milestone tag.
Use openstack/releases repository to manage the Mitaka-1 milestone tags.
One time change, we will be simplifying how we specify the versions for projects by moving to only using tags instead of the version entry for setup.cfg.


Stable release actions: Review stable/liberty branches for patches that have landed since the last release and determine if your deliverables need new tags.
Important dates:

Deadline for requesting a Mitaka-1 milestone tag: December 3rd
Mitaka-2: Jan 19-21
Mitaka release schedule [5]




Common OpenStack ‘Third-Party’ CI Solution – DONE!

Ramy Asselin who has been spearheading the work for a common third-party CI solution announces things being done!

This solution uses the same tools and scripts as the upstream Jenkins CI solution.
The documentation for setting up a 3rd party ci system on 2 VMs (1 private that runs the CI jobs, and 1 public that hosts the log files) is now available here [6] or [7].
There a number of companies today using this solution for their third party CI needs.




Process Change For Closing Bugs When Patches Merge

Today when a patch merges with ‘Closes-Bug’ in the commit message, that marks the associated bug as ‘Fix Committed’ to indicated fixed, but not in the release yet.
The release team uses automated tools to mark bugs from ‘Fix Committed’ to ‘Fix Released’, but they’re not reliable due to Launchpad issues.
Proposal for automated tools to improve reliability: Patches with ‘Closes-Bug’ in the commit message to have the bug status mark the associated bug as ‘Fix Released’ instead of ‘Fix Committed’.
Doug would like to have this be in effect next week.


Move From Active Distrusting Model to Trusting Model

Morgan Fainberg writes most projects have a distrusting policy that prevents the following scenario:

Employee from Company A writes code
Other Employee from Company A reviews code
Third Employee from Company A reviews and approves code.


Proposal for a trusting model:

Code reviews still need 2x Core Reviewers (no change)
Code can be developed by a member of the same company as both core reviewers (and approvers).
If the trust that is being given via this new policy is violated, the code can [if needed], be reverted (we are using git here) and the actors in question can lose core status (PTL discretion) and the policy can be changed back to the “distrustful” model described above.


Dolph Mathews provides scenarios where the “distrusting” model either did or would have helped:

Employee is reprimanded by management for not positively reviewing &amp;amp; approving a coworkers patch.
A team of employees is pressured to land a feature with as fast as possible. Minimal community involvement means a faster path to “merged,” right?
A large group of reviewers from the author’s organization repeatedly throwing *many* careless +1s at a single patch. (These happened to not be cores, but it’s a related organizational behavior taken to an extreme.)




Stable Team PTL Nominations Are Open

As discussed [8][9] of setting up a standalone stable maintenance team, we’ll be organizing PTL elections over the coming weeks.
Stable team’s mission:

Define and enforce the common stable branch policy
Educate and accompany projects as they use stable branches
Keep CI working on stable branches
Mentoring/growing the stable maintenance team
Create and improve stable tooling/automation


Anyone who successfully contributed to a stable branch back port over the last year can vote in the stable PTL election.
If interested, reply to thread with your self-nomination.
Deadline is 23:59 UTC Monday, November 30.
Election will be the week after.
Current candidates:

Matt Riedmann [10]
Erno Kuvaja [11]




Using Reno For Libraries

Libraries have two audiences for release notes:

Developers consuming the library.
Deployers pushing out new versions of the libraries.


To separate the notes from the two audiences and avoid doing manually something that we have been doing automatically, we can use Reno for just deployer release notes.
Library repositories that need Reno should have it configured like service projects, with separate jobs and a publishing location different from their developer documentation [12]


Releases VS Development Cycle

Thierry writes that as more projects enter the Big Tent, there have recently been questions about release models and development cycle.
Some projects want to be independent of the common release cycle and dates, but still keep some adherence to the development cycle. Examples:

Gnocchi wants to be completely independent of the common development cycle, but still maintain stable branches.
Fuel traditionally makes their releases a few months behind the OpenStack release to integration all the functionality there.


All projects above should current be release:independent, until they are able to (and willing) to coordinate their own releases with the projects following the common release cycle.
The release team currently supports 3 models:

release:cycle-with-milestones is the traditional Nova model with one release at the end of a 6-month dev cycle and a stable branch derived from that.
release:cycle-with-intermediary is the traditional Swift model, with releases as-needed during the 6-month development cycle, and a stable branch created from the last release in the cycle.
release:independent, for projects that don’t follow the release cycle at all.

Can make a release supporting the Mitaka release (including stable updates).

Can call the branch stable/mitaka even after the Mitaka release cycle, as long as the branch is stable and not development.


Should clearly document that their release is *compatible with* the OpenStack Mitaka release, rather than *part of* the Mitaka release.






[1] – http://docs.openstack.org/ja/
[2] – http://docs.openstack.org/arch-design/
[3] – http://docs.openstack.org/image-guide/
[4] – http://docs.openstack.org/draft/ja/networking-guide/
[5] – https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
[6] – https://github.com/openstack-infra/puppet-openstackci/tree/master/contrib
[7] – https://git.openstack.org/cgit/openstack-infra/puppet-openstackci/tree/contrib/README.md
[8] – http://www.openstack.org/blog/2015/11/openstack-developer-mailing-list-digest-november-20151107/#stable-team
[9] – http://www.openstack.org/blog/2015/11/openstack-developer-mailing-list-digest-november-20151114/#stable-team
[10] – http://lists.openstack.org/pipermail/openstack-dev/2015-November/080262.html
[11] – http://lists.openstack.org/pipermail/openstack-dev/2015-November/080607.html
[12] – http://docs.openstack.org/developer/reno/        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Cloud certification programs, OPNFV networking, and more OpenStack news</title>
    <id>http://fedoraplanet.org/15/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/15/" />
    <author>
      <name>Opensource.com</name>
    </author>
    <content type="html/text">Happy Friday everyone! As we head into the Thanksgiving weekend, there are many things we have to be thankful for this year. Friends, family and endless pounds of turkey are probably high on the list, but there are other, more nuanced things we have to be thankful for too.
If you’re an online retailer, you’re (hopefully) thankful that your site is buzzing along today, handling Black Friday traffic with ease.
Or, maybe things haven’t gone as smoothly as you had planned. Your site had trouble loading or crashed altogether — not the greatest outcome, but don’t lose hope! You can be thankful that Rackspace has been working with ecommerce customers for years, and we’ve gained a lot of experience along the way.
Earlier this year, Racker Alan Bush compiled a roundup of solid Black Friday tips and advice specifically for folks who were struggling to optimize their ecommerce operations around big retail holidays. It can really be a make or break scenario for businesses, as Alan puts it:
The math is simple: an underperforming site will turn away many would-be buyers; a completely down site means no sales at all (and in both cases, businesses also stand to lose potential future buyers, who simply won’t come back). And if your site isn’t ready for mobile shopping, you’re leaving sales on the table.
Check out all of the helpful tips he’s posted there, as well as the great services Rackspace provides for ecommerce customers, 24x7x365.
We’re thankful for all of the opportunities we get to help businesses thrive, but we’re also thankful that Rackspace has earned a reputation as such a great place to work — worldwide! Just this week, Rackspace was named as one of the top ten coolest companies for Women in Australia. This accolade joins similar recognition we’ve received here in the states, and we couldn’t be more proud.
But this year’s big takeaway for Rackspace, the thing we’re truly thankful for, is our growing base of customers and the increasing number of ways we can help them.
In addition to the support we offer our ecommerce customers, we’re also arming them (and others) with data analytics so they can gain greater insight into their business. We’ve expanded our cloud expertise to encompass leading technologies like Microsoft Azure and Amazon Web Services, and we’ve strengthened our commitment to OpenStack with the addition of Carina and our partnership with Intel in the OpenStack Innovation Center.
Overall, we’re thankful that we get to meet customers where they are and outfit them with the right technologies for their business. With the wide array of expertise Rackers have to offer, we’re able to be technology agnostic and then provide fanatical support on top of whichever solutions you choose.
Offering these capabilities is part of our vision to be the world’s leading service company on top of the world’s leading technologies, and we’re thankful that we get to do it every day.
Thanks for reading this week, have a great weekend and Happy Thanksgiving!        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">5 Minutes Stacks, Episode 14: Graylog</title>
    <id>http://fedoraplanet.org/16/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/16/" />
    <author>
      <name>Cloudwatt</name>
    </author>
    <content type="html/text">Each release cycle, OpenStack project team leads (PTLs) introduce themselves, talk about upcoming features for the OpenStack projects they manage, plus how you can get involved and influence the roadmap.

Superuser will feature these summaries of the videos weekly; you can also catch them on the OpenStack Foundation YouTube channel. This round of interviews covers the OpenStack Client, Documentation. 

OpenStackClient

&amp;lt;iframe allowfullscreen="allowfullscreen" frameborder="0" height="" src="https://www.youtube.com/embed/kpXU-A5wvR8" width=""&amp;gt;&amp;lt;/iframe&amp;gt;

What: OpenStackClient (OSC) is a command-line client for OpenStack that brings the command set for Compute, Identity, Image, Object Store and Volume APIs together in a single shell with a uniform command structure.

Who: Dean Troyer, PTL. Formerly with NASA, Troyer worked on OpenStack before it formally existed. Now he’s a senior cloud software engineer at Intel Corp. 

Burning issues



“One of the things we talked about the most [in Tokyo] was the 'help' command," he said. There’s a long list of things we need to address and we’re still sorting it out, that's one of our goals for the next cycle.” 

What’s next 



Smoothing out the user experience is also a priority, he added. Troyer also says he hopes to work with OpenStack UX to get user feedback in this cycle. 

What matters in Mitaka: 
Performance improvements. 
“The place we see this most is developers in DevStack, [we’re] trying to reduce the time it takes to load,” he said. "You should be able to type 'openstack flavor list' and not have to wait four seconds to get a response.” 

Get involved!
“Like every project out there, we could use new contributors...especially on the newer projects that don’t have legacy client issues…Getting involved with some of those newer projects is helpful.”
Use Ask OpenStack for general questions
For roadmap or development issues, subscribe to the OpenStack development mailing list, and use the tag [OpenStackClient] 

Documentation

&amp;lt;iframe allowfullscreen="allowfullscreen" frameborder="0" height="" src="https://www.youtube.com/embed/dCwl5r5MlpU" width=""&amp;gt;&amp;lt;/iframe&amp;gt;

What: OpenStack Docs,which provides documentation for most of OpenStack’s projects. Some two-thirds of all OpenStack users refer to docs once a week, if not more. 

Who: Lana Brindley, PTL. Day job: Senior manager, information development, Rackspace. 

Burning issues



About these, she added: “We want to make sure we’re good community citizens we want to increase our support for teams who want to include information about their products in the official docs…Big tent has changed the way we look at projects and we want to make sure we’re supporting each product team in the best way possible.” 

What improvements are you working on 

"We're working on feedback that the Web Application Description Language (WADL) system isn't working so well for API docs, so we're working on that. Anne Gentle has been working on an ID since Vancouver that we're now ready to implement, that will switch us to Swagger instead," she said.

"We also got a lot feedback on release notes, it was surprising for me. So we’ve been working with a few different people to understand that problem better and we have some exciting ideas for improvements...” 

What's planned for Mitaka?



Navigation of the docs takes priority, she said. Some of the books are easier to move from role-based to task-based data typing, so "we're going to start with one of the easier ones, the user guides, to see how that works.”

The overall theme for work on the next release is manageability with an additional focus on collaboration, Brindley added. 

"Because Liberty was my first release as PTL, I'm still learning what makes a good release," Brindley said. "It was great to hear feedback from the docs team on what went well and what didn't go so well, so we can implement those changes and hopefully improve in Mitaka..."

Get involved!
Brindley underlined that the docs team is always looking for technical writers, developers (even those who don't think they're good writers.) She also added that docs is developed just like code, so OpenStack active technical contributors (ATCs) already have the skills to help out. 
Join the OpenStack Docs mailing list.
Participate in the weekly meetings: held on #openstack-meeting every Wednesday at alternating times for different time zones:
APAC: Wednesday, 00:30:00 UTC #openstack-meeting 
US: Wednesday, 14:00:00 UTC

Cover Photo // CC BY NC        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Our cloud in Kilo</title>
    <id>http://fedoraplanet.org/17/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/17/" />
    <author>
      <name>OpenStack in Production</name>
    </author>
    <content type="html/text">When locals need to perform search-based queries, including news, healthcare and finance, they often turn to goo, a Japanese web portal and Internet search engine that has been around for 18 years. Goo is a web service brand of NTT Group accommodating the web search, blog, Q&amp;amp;A service Oshiete!goo, smartphone applications and more, which generates one billion page views per month and 170 million unique users. 

Online activity is particularly high in Japan, ranking as country with the fourth highest percentage of its population surfing the web. But what are the locals searching for? The trends suggest that online shopping, last year racking up ¥8.5 trillion yen - or $79.3 billion USD - is a popular pastime. 

Seasons also influence online behavior, the team at NTT Resonant notes. Popular search terms range from hay fever (花粉症) during peak cherry blossom season - February through April - to “zip code” or “post code” (郵便番号) in December, when locals celebrate the new year, biggest holiday in Japan, by sending postcards to family and friends. 

Goo is based on the Q&amp;amp;A service Oshiete!goo and Google’s provision of basic search functions, including web databases. The NTT Resonant team set out to streamline operations for its popular web portal by adopting OpenStack for its private cloud infrastructure in October 2014. 

Approximately 90 percent of Japan’s 126.8 million residents own more than one device, accounting for each unique goo visit. NTT Resonant provides more than 80 services including goo and web services for the enterprise.

The deployment, operated by NTT Resonant, consists of 400 hypervisors and 4,800 physical cores, accommodating more than 1,800 virtual servers in production. It provides about 60 types of goo-related services, including an Internet search business featuring a search engine service developed by goo that searches for mobiles, images and blogs and services offering a wide variety of information including weather, news, healthcare, finance and business.

Committed to open source and the OpenStack community

NTT Resonant’s team has embraced the culture of open source, citing the learning opportunities from the trial and error phases as a key benefit. Toshikazu Ichikawa, a senior research engineer at the NTT Software Innovation Center (SIC), says that the community and open-by-design concept were key factors when deciding to work with OpenStack.

“Choosing OpenStack helps us avoid unnecessary vendor lock-in and gives us choices of vendor plugins and integration when needed,” he says. “Applying OpenStack to our production triggered us to join the OpenStack community deeply.”

The team is rooted in the community, contributing to Summits, meetups and the OpenStack project itself. Koji Iida, a senior research engineer supervisor at the NTT SIC says that identifying bugs, many related to nova-cell, and contributing fixes were mandatory for the success of this deployment.

One particular bug was a show-stopper for NTT Resonant’s team, Iida said, until they were able to push a fix upstream, which also benefits the broader user community. 

“The shelve function didn't work in the Icehouse release with nova-cell deployment,” he said. “With hypervisor maintenance, our workflow relies for our users to shelve/unshelve their virtual servers to migrate servers from the hypervisor; therefore, it was mandatory for us to fix.”

Creating efficiencies for operators and application developers

With a nimble team of 15, six members working for server software including OpenStack and 9 working on the physical server, network and data center, NTT Resonant has leveraged OpenStack to increase productivity among its key team members.

Members of the NTT Resonant team (from left to right): Tomoya Hashimoto, Munetaka Komazaki and Kazuhiro Tooriyama

The team deployed KVM virtualization in 2010 to shift away from each team procuring and managing an infrastructure per application. However, even with KVM, Tomoya Hashimoto, a senior manager at NTT Resonant, says that a lot of tasks, including configuring and assigning virtual servers, remained highly manual and coordinating between application teams and the infrastructure team consumed too much of the project’s time.

By moving to a cloud model with OpenStack and KVM in 2014, many of the steps to provide a virtual server were automated.

“We could automate most of the related tasks, such as monitoring system configuration beside the installation of OpenStack,” says Hashimoto. “This contributed to the reduction of tasks and burdens for the infrastructure operators and application developers.”

Once this was implemented, application developers created and deleted virtual servers more frequently than before, increasing the speed of business overall.

“The time to provide a virtual server for application developers was shortened from five business days to five minutes,” says Kazuhiro Tooriyama, an engineer at NTT Resonant. “Moreover, a migration of virtual servers between physical servers became much easier, making it easier for our operators to handle a server failure.”

Tooriyama also says that since virtual servers can now be easily scrapped and built, this has increased the opportunity for technical evaluation among the team’s application developers.

What’s next?

Currently, the deployment is running on Icehouse in a single datacenter, but at the August operator’s mid-cycle meetup in Palo Alto, Ichikawa lead a lightning talk saying that the team intends to upgrade from Icehouse soon, with the goal to continue upgrading to the newest release of OpenStack. 

The team also has plans for expansion, including increasing the number of hypervisors and launching a second datacenter. 

This article was originally published in the print Superuser publication that was distributed at the OpenStack Summit Tokyo, where the NTT Group was also given the Superuser Awards based on a community vote. 

Learn more about the NTT Group's different use cases, including NTT Resonant with this episode of Superuser TV. 

&amp;lt;iframe allowfullscreen="allowfullscreen" frameborder="0" height="" src="https://www.youtube.com/embed/xxaoeENfGw8" width=""&amp;gt;&amp;lt;/iframe&amp;gt;        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Technical Committee Highlights November 27, 2015</title>
    <id>http://fedoraplanet.org/18/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/18/" />
    <author>
      <name>OpenStack Blog</name>
    </author>
    <content type="html/text">The post OpenStack, Cloud Foundry and a turnkey app environment appeared first on Mirantis | The #1 Pure Play OpenStack Company.
On November 17, Mirantis’ Kamesh Pemmaraju and John Jainschigg  and Pivotal’s Ryan Pei got together to provide a joint webinar explaining how Pivotal Cloud Foundry and OpenStack can come together to provide a turnkey application environment. You can view the entire webinar here, but we also had some great questions, so we wanted to answer them here in the blog.
Q: What do you mean by “not locked in”? How portable is a Cloud Foundry application?
Ryan: Seamlessly portable  Cloud Foundry works on many IaaSs and the way you create and deploy your apps does not change from one IaaS to another.
Q: What are the application dependencies on Cloud Foundry? For example, how easy/hard is to move away from an app done in the Cloud Foundry environment?
Ryan: It’s not difficult at all. For instance, with a Java app, if you wanted to port the app off of Cloud Foundry, you would just need to ensure that the dependencies in the Cloud Foundry buildpacks are provided in the new environment, such as a JVM. There shouldn’t be any configuration changes required.
Q: Can I do the same with Ops Manager or Apps Manager ?
John: Ops Manager is basically a configuration and deployment tool that manages interactions with BOSH (the actual deployment engine) — it’s an easy way for users to configure and deploy Pivotal Cloud Foundry and related products on an IaaS, without having to deal directly with the YAML files that BOSH consumes. Apps Manager is a management UI for an installed PCF environment that provides a web UI to (for admins) manage user accounts, create organizations, spaces and other ‘tenant-like’ permission/resource subdivisions, etc., and (for admins and end user developers) to manage orgs, spaces and apps they own. (So, yes.)
Q: How do you segregate your workloads (security, network, traffic management)? Do you build multiple PaaS (for Dev, for Prod, etc.) or you have a single large PaaS that is segmented for the various uses?
Ryan: Cloud Foundry is inherently a very secure environment, because it limits network traffic to a very small number of entrypoints (the customer-provided load balancer upstream from the CF router, plus VMs used to manage the PCF cluster). PCF deploys apps on secure containers with their own strict memory allocations and private read/write file systems. It uses Application Security Groups, role-based authentication and other abstractions to let operators configure portable security and access policy on an app-by-app basis. The software (buildpacks, service APIs and components) against which applications run impose security on ‘operating system’ calls. And since all these components can be updated non-disruptively, it should be relatively easy to keep pace with patches. This includes VM stemcells providing the guest OS underlying major PCF components, which can be rolled back and out with BOSH. Underneath Cloud Foundry, there are all sorts of ways of segregating and securing VM workloads and tenant networks on OpenStack, including stuff like using Availability Zones, affinity/anti-affinity groups, Intel TXT, etc., to direct VM workloads (e.g., Cloud Foundry components) by tenant and other characteristics to particular compute and storage resources, and stuff like NetScaler and Contrail to build any-to-any high-capacity mesh networks and isolate different traffic types and tenant-by-tenant/app-by-app traffic on VLANs or tunnels. Finally, the extraordinary speed and ease of deploying Mirantis OpenStack and Pivotal Cloud Foundry makes brute-force ‘air-gap’ strategies operationally efficient — you can have, not just separate PaaSs in separate tenants, but separate PaaSs on separate clouds for Dev/Test and Production.
Q:  Patching/Ownership; Application Framework (spring)/Runtime /Infra Auto(bosh), etc. Who’s owns the patching of these?
Ryan:  The Cloud Foundry Foundation is patching and supporting these components on behalf of the community at large, and Pivotal is doing the same on behalf of its customers across all the Pivotal Cloud Foundry products, including Ops Manager, Apps Manager, Spring Cloud Services, etc. 
Q: Hi, I would like to know whether we can install JBoss as Application catalog in Mirantis OpenStack ?
A: Mirantis has published a Murano app that deploys JBoss in a Docker image. You can find it at https://github.com/openstack/murano-apps/tree/master/Docker/Applications/JBoss/package.
Q: Can we use OpenStack’s Trove to provide Databases as a Service?
John: It’s not immediately clear what advantage one might gain from this, since PCF provides DBaaS to many flavors of database already. However, in principle, if you were, for example, using PCF to build an app that provided authorized users (e.g., operators) with a tool to set up databases and provide DB credentials on the underlying OpenStack, it should be possible to use the CF service broker API to create a service broker to Trove.
Q: Hi, can any of this deploy behind a corporate internet proxy?
A: Yes, many people do this.
Q: What’s is the core difference of using ops manager to install CF versus using CF community via the Murano package?
John: There are many differences. Pivotal Cloud Foundry, installed with Ops Manager, includes a distribution of Community Cloud Foundry, plus additional components from Pivotal. If you would prefer to work with Community Cloud Foundry, at this point, we recommend installing a recent version using the community-provided BOSH installer. Alternatively, the Murano app, which deploys version 1.4 of community Cloud Foundry in a small, PoC configuration, may suffice for initial evaluations.
Q: Will you be covering the differences between using a buildpack (e.g. python/django) vs. using docker, particularly in the case where a buildpack exists for your dev environment? What are the pros and cons of using one vs. the other and what different CF “features” set these two uses apart (i.e. docker vs. app buildpack)?
Ryan: Buildpacks come with good guidelines on how to create your applications for a specific language and/or framework. Docker is very open-ended in terms of what you can add to Docker containers, so that gives you a lot of freedom but then you must be careful that this freedom is not abused. It may not be as easy, for instance, to restage every app in your system with a security or maintenance patch if not everyone is using standardized filesystems. 
Q: In the Infra as Code “spirit” how are the configurations (tenants, admin, credentials, etc.) kept so that if someone were to mess up the setup of CF it can be recreated from “code”? Is backing up the way to achieve such redundancy or is there a concept of “coding” that setup (checking in to source control)?
Ryan: PCF Ops Manager has a feature that allows you to “Export settings”, or download a zip file that contains all of your deployment settings. We suggest downloading this package regularly and whenever changes are being made.
Q: When auto-scaling down your app instances, how does the platform determine which instance should be shut down?
Ryan: The platform shuts down instances starting with the highest index values in Cloud Controller.
Q: What are the key points to port a legacy app to a CF compatible version ?
Ryan: Any app can be seamlessly ported over to CF, but if you do have time to refactor, we would recommend following the Twelve Factor principles when designing your application. Some more specifics are available here in the CF docs http://docs.cloudfoundry.org/devguide/deploy-apps/prepare-to-deploy.html as well.
Q: Hi. Where can I read about CF – Integrated logging and about multi-cloud – what it means to have a VM evacuation?
Ryan: You can find out more about Cloud Foundry at http://docs.cloudfoundry.org.
Q: As of now, CF Buildpacks does not support Dynatrace for monitoring. Will it be possible in the near future? I could see New Relic has been added as an extension. 
Ryan: Custom buildpacks are always an option. New Relic actually released a service for Pivotal Cloud Foundry earlier this year, and we’re evaluating whether this is a good solution for the long-term. 
Q: Can end users deploy microservices as well, just like pushing apps?
John: Microservices are essentially just very simple, single-process applications. You can take full advantage of this architecture by using a framework to wire together these microservices into a cohesive app. This is where a tool like Spring Cloud Services can help you to compose something really great with Java Spring microservices.
Q: How much programming skill is required to create custom PCF services? Is this a task for Dev or Ops?
Ryan: It’s easy to do; check out http://docs.cloudfoundry.org/services. Either Dev or Ops can create them for their own use.
If you’re interested in using Cloud Foundry and OpenStack to create a better application environment, go ahead and download the runbook that explains exactly how to deploy Cloud Foundry with OpenStack.
The post OpenStack, Cloud Foundry and a turnkey app environment appeared first on Mirantis | The #1 Pure Play OpenStack Company.        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">OpenStack Developer Mailing List Digest November 21-27</title>
    <id>http://fedoraplanet.org/19/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/19/" />
    <author>
      <name>OpenStack Blog</name>
    </author>
    <content type="html/text">Dan Smith is a principal software engineer at Red Hat. He works primarily on Nova, is a member of the core team and generally focuses on topics relating to live upgrade. You can follow him on Twitter @get_offmylawn.

In the previous post on objects, I explained how Nova uses objects to maintain a consistent schema for services expecting different versions, in the face of changing persistence. That’s an important part of the strategy, as it eliminates the need to take everything down while running a set of data migrations that could take a long time to apply on even a modest data set.

Additive Schema-only Migrations

In recent cycles, Nova has enforced a requirement on all of our database migrations. They must be additive-only, and only change schema not data. Previously, it was common for a migration to add a column, move data there, and then drop the old column. Imagine my justification for adding the foobars field to the Flavor object was because I wanted to rename memory_mb. A typical offline schema/data migration might look something like this:

meta = MetaData(bind=migrate_engine)
flavors = Table('flavors', meta, autoload=True)
flavors.create_column(Column('foobars', Integer))
for flavor in flavors.select():
    flavors.update().\
        where(flavors.id == flavor.id).\
        values(memory_mb=NULL,
               foobars=flavor.memory_mb)
flavors.drop_column(Column('memory_mb', Integer))


If you have a lot of flavors, this could take quite a while. That is a big problem because migrations like this need to be run with nothing else accessing the database — which means downtime for your Nova deployment. Imagine the pain of doing a migration like this on your instances table, which could be extremely large. Our operators have been reporting for some time that large atomic data migrations are things we just cannot keep doing. Large clouds being down for extended periods of time simply because we’re chugging through converting every record in the database is just terrible pain to inflict on deployers and users.

Instead of doing the schema change and data manipulation in a database migration like this, we only do the schema bit and save the data part for runtime. But, that means we must also separate the schema expansion (adding the new column) and contraction (removing the old column). So, the first (expansion) part of the migration would be just this:

meta = MetaData(bind=migrate_engine)
flavors = Table('flavors', meta, autoload=True)
flavors.create_column(Column('foobars', Integer))


Once the new column is there, our runtime code can start moving things to the new column. An important point to note here is that if the schema is purely additive and does not manipulate data, you can apply this change to the running database before deploying any new code. In Nova, that means you can be running Kilo, pre-apply the Liberty schema changes and then start upgrading your services in the proper order. Detaching the act of migrating the schema from actually upgrading services lets us do yet another piece at runtime before we start knocking things over. Of course, care needs to be taken to avoid schema-only migrations that require locking tables and effectively paralyzing everything while it’s running. Keep in mind that not all database engines can do the same set of operations without locking things down!

Migrating the Data Live

Consider the above example of effectively renaming memory_mb to foobars on the Flavor object. For this I need to ensure that existing flavors with only memory values are turned into flavors with only foobars values, except I need to maintain the old interface for older clients that don’t yet know about foobars. The first thing I need to do is make sure I’m converting memory to foobars when I load a Flavor, if the conversion hasn’t yet happened:

@base.remotable_classmethod
def get_by_id(cls, context, id):
    flavor = cls(context=context, id=id)
    db_flavor = db.get_flavor(context, id)
    for field in flavor.fields:
        if field not in ['memory_mb', 'foobars']:
            setattr(flavor, field, db_flavor[field])

    if db_flavor['foobars']:
        # NOTE(danms): This flavor has
        # been converted
        flavor.foobars = db_flavor['foobars']
    else:
        # NOTE(danms): Execute hostile takeover
        flavor.foobars = db_flavor['memory_mb']


When we load the object from the database, we have a chance to perform our switcheroo, setting foobars from memory_mb, if foobars is not yet set. The caller of this method doesn’t need to know which records are converted and which aren’t. If necessary, I could also arrange to have memory_mb set as well, either from the old or new value, in order to support older code that hasn’t converted to using Flavor.foobars.

The next important step of executing this change is to make sure that when we save an object that we’ve converted on load, we save it in the new format. That being, memory_mb set to NULL and foobars holding the new value. Since we’ve already expanded the database schema by adding the new column, my save() method might look like this:

@remotable
def save(self, context):
    updates = self.obj_get_updates()
    updates['memory_mb'] = None
    db.set_flavor(context, self.id, updates)
    self.obj_reset_changes()


Now, since we moved things from memory_mb to foobars in the query method, I just need to make sure we NULL out the old column when we save. I could be more defensive here in case some older code accidentally changed memory_mb, or try to be more efficient and only NULL out memory_mb if I decide it’s not already. With this change, I’ve moved data from one place in the database to another, at runtime, and without any of my callers knowing that it’s going on.

However, note that there is still the case of older compute nodes. Based on the earlier code, if I merely remove the foobars field from the object during backport, they will be confused to find memory_mb missing. Thus, I really need my backport method to revert to the older behavior for older nodes:

def obj_make_compatible(self, primitive,
                        target_version):
    super(Flavor, self).obj_make_compatible(primitive,
                                            target_version)
    target_version = utils.convert_version_to_tuple(
        target_version)
    if target_version &amp;lt; (1, 1):
        primitive['memory_mb'] = self.foobars
        del primitive['foobars']


With this, nodes that only know about Flavor version 1.0 will continue to see the memory information in the proper field. Note that we need to take extra care in my save() method now, since a Flavor may have been converted on load, then backported, and then save()d.

Cleaning Up the Mess

After some amount of time, all the Flavor objects that are touched during normal operation will have had their foobars columns filled out, and their memory_mb columns emptied. At some point, we want to drop the empty column that we’re no longer using.

In Nova, we want people to be able to upgrade from one release to the other, having to only apply database schema updates once per cycle. That means we can’t actually drop the old column until the release following the expansion. So if the above expansion migration was landed in Kilo, we wouldn’t be able to land the contraction migration until Liberty (or later). When we do, we need to make sure that all the data was moved out of the old column before we drop it and that any nodes accessing the database will no longer assume the presence of that column. So the contraction migration might look like this:

count = select([func.count()]).select_from(flavors).\
    where(memory_mb != None)
if count:
    raise Exception('Some Flavors not migrated!')
flavors.drop_column(Column('memory_mb', Integer))


Of course, if you do this, you need to make sure that all the flavors will be migrated before the deployer applies this migration. In Nova, we provide nova-manage commands to background-migrate small batches of objects and document the need in the release notes. Active objects will be migrated automatically at runtime, and any that aren’t touched as part of normal operation will be migrated by the operator in the background. The important part to remember is that all of this happens while the system is running. See step 7 here for an example of how this worked in Kilo.

Doing online migrations, whether during activity or in the background, is not free and can generate non-trivial load. Ideally those migrations would be as efficient as possible, not re-converting data multiple times and not incurring significant overhead checking to see if each record has been migrated every time. However, some extra runtime overhead is almost always better than an extended period of downtime, especially when it can be throttled and done efficiently to avoid significant performance changes.

Online Migrations Are Worth It

Applying all the techniques thus far, we have now exposed a trap that is worth explaining. If you have many nodes accessing the database directly, you need to be careful to avoid breaking services running older code while deploying the new ones. In the example above, if you apply the schema updates and then upgrade one service that starts moving things from memory_mb to foobars, what happens to the older services that don’t know about foobars? As far as they know, flavors start getting NULL memory_mb values, which will undoubtedly lead them to failure.

In Nova, we alleviate this problem by requiring most of the nodes (i.e. all the compute services) to use conductor to access the database. Since conductor is always upgraded first, it knows about the new schema before anything else. Since all the computes access the database through conductor with versioned object RPC, conductor knows when an older node needs special attention (i.e. backporting).

Dan Smith originally posted this tutorial from his blog, Right Angles. Superuser is always interested in how-tos and other contributions, please get in touch: editor@superuser.org 

Cover Photo// CC BY NC        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">The Download: Nov. 27, 2015 — The Thanksgiving Edition!</title>
    <id>http://fedoraplanet.org/20/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/20/" />
    <author>
      <name>The Official Rackspace Blog</name>
    </author>
    <content type="html/text">Introduction
Welcome to Last week on OpenStack Dev (“Lwood”) for the week ending 15th November 2015. For more background on Lwood, please refer here.
Basic Stats for week 16th to 22nd November 2015 :

~628 Messages (down about 8% relative to last week)
~189 Threads (same as last week)

Traffic and threads steady…
Notable Discussions
Nova / Trusted Computing Pools related security notice (OSSN 0059)
Summary from the original security notice: “A trusted VM that has been launched earlier on a trusted host can still be powered on from the same host even after the trusted host is compromised.  More in the original post or the OSSN itself.
A reminder to projects about new “assert” tags 
Over the last few months the TC defined a number of “assert” tags – a standardised way for projects to make certain assertions about their projects.  In his email Thierry Carrez reminds all concerned (basically PTLs and Project Cores) that the time is upon them to see if these tags should apply and if so to start using them.
In time this information will be added to that already displayed in the OpenStack Foundation’s Project Navigator hence the desire to get projects using these tags as soon as possible.  For operators and other non-developers, the use of these tags and endeavours like the Project Navigator promise to make the process of evaluating an OpenStack projects maturity a little simpler.
Vitrage – a Root Cause Analysis engine for OpenStack
Announced at the Mitaka Summit, a post to the list provided some more information on the Vitrage project – part of the broader Telemetry umbrella project for OpenStack,  The Vitrage developers would “like it to be the Openstack RCA (Root Cause Analysis) Engine for organizing, analyzing and expanding OpenStack alarms &amp;amp; events, yielding insights regarding the root cause of problems and deducing the existence of problems before they are directly detected.”
Noble goals and early days but a worthwhile and much needed set of functionality
What should the openstack-announce mailing list be ?
Tom Fifield kicked off a thread discussing what the best use of the mailing list is from herein.  Originally conceived as a low traffic read-only list he makes the point that with the addition of more (arguably) developer oriented content it’s become rather high traffic.  The concern being this appears to have put some folk off with them either filtering the list or unsubscribing – and so possibly missing the urgent content such as security notifications.
While there has been a little discussion since his first post on Friday input from a broad range of readers would be welcome.
Is booting a Linux VM important for certified OpenStack interoperability ?
On behalf of the DefCore Committee Egle Sigler asks for feedback on whether the ability to boot a Linux VM should be required for certified OpenStack interoperability.  A quick glance at the comments in the review cited suggests this is anything but a simple topic particularly once you consider containers and bare metal clouds in an environment…
Autoscaling both clusters and containers
Ryan Rossiter kicked off an interesting thread about autoscaling both containers and clusters. Essentially have the ability for a cluster to expand when the concentration of containers gets too high. Evidently there was some discussion about this in Tokyo with at least one demo being given using Senlin interfacing to Magnum to autoscale.
Developer Mailing List Digest
Originally a section within the OpenStack Community Newsletter, Mike Perez’ excellent openstack-dev digest is now available as a digest sent to the openstack-dev mailing list as well as being posted on the OpenStack Foundation’s blog.  I commend it to you if you’re after a deeper and/or more technical analysis than Lwood or other sources provide.  Here are the links to the Digest for November 7-13 and 14-20.
Discounted documentation changes
While the sprint in question is alas over at the time of writing, this post from Joshua Harlow about the Oslo projects virtual documentation sprint is too well written not to note :)
Midcycle dates and locations
A few more midcycle discussions this past week

[ironic] The Midcycle discussions from last week kicked off by Lucas Alvares seem to have settled on the idea of a virtual midcycle as proposed by Jim Rollenhagen
[manila] A survey for midcycle attendees/interested persons – Ben Swartzlander
[cinder] Mitaka Midcycle Sprint is on 26-29 January in North Carolina, USA – Sean McGinnis

Post Mitaka Summit Summaries and Priorities
A few more Summaries and Priority lists rolled in from the Mitaka Summit

[openstack-ansible] Mitaka Summit Summary by Jesse Pretorius
[tricircle] Tokyo Summit Summary by Zhipeng Huang

People and Projects

[keystone][stable] Nominating Lin Hua Cheng for keystone-stable-maint – Steve Martinelli
[lbaas][octavia] German Eichberger and Brandon Logan stepping down as STLs, Call for Candidates and Proposing Bertrand Lallau as octavia-core – German Eichberger
[puppet] review the core-reviewer members – removing François Charlier, Dan Bode and Michael Chapman – Emilien Macchi
[midonet] Ryu Ishimoto is new mide MidoNet PTL – Sandro Mathys

Further Reading &amp;amp; Miscellanea
Don’t forget these excellent sources of OpenStack news :)

“What’s Up, Doc?” by Lana Brindley
OpenStack Weekly Community Newsletter by Jay Fankhauser and others
OpenStack Developer Mailing List Digest by Mike Perez

Closing on a lighter note – this edition of Lwood brought to you by Booker T Jones (Potato Hole &amp;amp; The Road From Memphis), Vinnie Moore (Aerial Visions), The String Contingent (Talk, TSC II), Steve Ray Vaughan (In Step), Tommy Emmanuel (Determination) amongst other excellent tunes.
         
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">OpenStack Mitaka release: what’s next for OpenStackClient and Documentation</title>
    <id>http://fedoraplanet.org/21/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/21/" />
    <author>
      <name>OpenStack Superuser</name>
    </author>
    <content type="html/text">Each release cycle, OpenStack project team leads (PTLs) introduce themselves, talk about upcoming features for the OpenStack projects they manage, plus how you can get involved and influence the roadmap.

Superuser will feature these videos weekly; once they’re all published you can also catch them on the OpenStack Foundation YouTube channel. Our first round of interviews covers Swift and Ironic.

Swift

&amp;lt;iframe allowfullscreen="allowfullscreen" frameborder="0" height="" src="https://www.youtube.com/embed/uXYHa_wm9_k" width=""&amp;gt;&amp;lt;/iframe&amp;gt;

What: Swift, the OpenStack Object Store project

Who: John Dickinson, PTL. Day job: director of technology, SwiftStack.

Burning issues


Of these he says, "Encryption is something we’re spending a lot of time on now. It’s not a new topic but something that's been in progress for six months….[we’re] trying to implement a way operators can encrypt all of the data stored in the clusters so they meet requirements for certain kinds of information —personally identifiable information, financial records etc. So to lower the barriers for adoption, that’s one of the things we’re working on.”

What’s next 



“We spend a lot of time on improving — in various ways — overall experience for end-users and operators. Specifically around lowering latency, smoothing out latency when clusters are under load…” 

What matters in Mitaka 



Get involved!
Use Ask OpenStack for general questions
For roadmap or development issues, subscribe to the OpenStack development mailing list, and use the tag [swift] 
Participate in the weekly meetings: Wednesday at 2100UTC in #openstack-meeting on freenode IRC

Ironic

What: Ironic, OpenStack's Bare Metal Provisioning Program. 



Ironic moves on an independent release schedule. About that, Rollenhagen said: “It took us awhile with Liberty to get our first release out, and within a month-and-a-half we had two more releases. The second of which had something like 30 or 40 bug fixes.” 

Who:  Jim Rollenhagen, PTL. Day job: software developer, Rackspace.

&amp;lt;iframe allowfullscreen="allowfullscreen" frameborder="0" height="" src="https://www.youtube.com/embed/jPefG22WTTM" width=""&amp;gt;&amp;lt;/iframe&amp;gt;

Burning issues



What’s next 



What matters in Mitaka:
Overall: scalability, resiliency and third-party testing for all drivers. 

About the drivers, he added: “That’s going to be huge for us, ensuring that those all work as expected for our users.” 

Get involved!
Use Ask OpenStack for general questions
For roadmap or development issues, subscribe to the OpenStack development mailing list, and use the tag [ironic] 
Participate in the weekly meetings: The one-hour weekly meetings start at 1700 UTC on Mondays, held in the #openstack-meeting-3 room on irc.freenode.net

Cover Photo // CC BY NC        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">SUSE Linux and OpenStack: Concentrated Strength for SAP Offerings from the Cloud</title>
    <id>http://fedoraplanet.org/22/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/22/" />
    <author>
      <name>SUSE Conversations</name>
    </author>
    <content type="html/text">Time to Make Some Assertions About Your Projects

The technical committee defined a number of “assert” tags which allows a project team to to make assertions about their own deliverables:

assert:follows-standard-deprecation
assert:supports-upgrade
assert:supports-rolling-upgrade


Read more on their definitions [1]
Update the project.yaml [2] of which tags apply to your project already.
The OpenStack foundation will use “assert”tags very soon in the project navigator [3].

Making Stable Maintenance Its Own OpenStack Project Team (Cont)

Continuing discussion from last week [4]…
Negatives:

Not enough work to warrant a designated “team”.
The change is unlikely to bring a meaning full improvement to the situation, sudden new resources.


Positives:

* An empowered team could tackle new coordination tasks, like engaging more directly in converging stable branch rules across teams, or producing tools.
Release management doesn’t overlap anymore with stable branch, so having them under that PTL is limiting and inefficient
Reinforcing the branding (by giving it its own team) may encourage more organizations to affect new resources to it


Matt Riedemann offers to lead the team.

Release Countdown For Week R-19, November 23-27

Mitaka-1 milestone scheduled for December 1-3.
Teams should be…

Wrapping up incomplete work left over from the end of the Liberty cycle .
Finalizing and announcing plans from the summit.
Completing specs and blueprints.


The openstack/release repository will be used to manage Mitaka 1 milestone tags.
Reno [5] will be used instead of Launchpad for tracking completed work. Make sure any release notes done for this cycle are committed to your master branchless before proposing the milestone tag.


New API Guidelines Read for Cross Project Review

The following will be merged soon:

Adding introduction to API micro version guideline [6].
Add description of pagination parameters [7].
A guideline for errors [8].


These will be brought up in the next cross project meeting [9].


[1] – http://governance.openstack.org/reference/tags/index.html
[2] – http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
[3] – https://www.openstack.org/software/project-navigator/
[4] – http://www.openstack.org/blog/2015/11/openstack-developer-mailing-list-digest-november-7-13/#stable-team
[5] – http://www.openstack.org/blog/2015/11/openstack-developer-mailing-list-digest-november-7-13/#reno
[6] – https://review.openstack.org/#/c/187112/
[7] – https://review.openstack.org/#/c/190743/
[8] – https://review.openstack.org/#/c/167793/
[9]- https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Powering one billion page views and 170 million unique visitors per month with OpenStack</title>
    <id>http://fedoraplanet.org/23/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/23/" />
    <author>
      <name>OpenStack Superuser</name>
    </author>
    <content type="html/text">The post Fuel levels up: Enhancements in Mirantis OpenStack 7.0 (Q&amp;amp;A) appeared first on Mirantis | The #1 Pure Play OpenStack Company.
Yesterday, we held a webinar about some of the enhancements to Fuel in Mirantis OpenStack 7.0. Fuel has come a long way in this iteration, and we detailed both the operational and interface improvements — including some of the possibilities of the plugin framework — which you can hear about here.  We also entertained questions from the audience, which we thought you might find helpful.
Q: How does Fuel discover new nodes? Does this happen automatically or do I have to register them as new nodes first?
A: Fuel discovers nodes that boot to its PXE network environment. (In other words, nodes that PXE boot on the same network occupied by Fuel.) When a node powers on and is set to PXE boot, Fuel bootstraps that node and discovers many of the physical attributes such as the CPUs, RAM, HDD, NICs, MAC address, and so on. Fuel then adds the node to the pool of available systems.
Q: I assume there is a way for a plugin to define what other roles it can share a node with?
A: Yes. The plugin framework allows for full control of how the plugin is deployed. For example, Fuel limits which default roles can coexist (for example, Controller and Compute can NOT), and Plugins provide the same capability to developers. In the case of our LMA plugins, for example they can currently only coexist with each other, as far as the specific roles are concerned. We can stack the Kibana and Grafana roles on a single dedicated node, but we can’t stack them with the Storage-Cinder role, for example.
Q: Does Fuel support different deployment modes?
A: Earlier versions of Fuel provided the option to choose between HA and non-HA environments; if you chose non-HA, there was no going back later. Current versions of Fuel will instead default to an HA-capable deployment mode, though the cluster will only truly have high availability if it has at least three controllers.  That said, if you add new controllers to an existing cluster, you will be able to achieve HA. This way, you get the benefits of HA availability without having to install a minimum of three controllers if you don’t need it.
Q: Each node role has its own network template file. What if a node has multiple roles?
A: For the current release, network templates are defined by a single role. Nodes with multiple roles will take the first role template that matches alphabetically. If the node needs configuration from multiple templates, it will require deployment customization. We are looking at adding this type of flexibility to future releases.
Q: What is the difference between the name that is displayed on the node and the hostname in the extended settings screen?
A: While the current implementation can be somewhat confusing, the name shown on the node in the UI is the “node name”. This value can change at any point, before or after deployment, and is used only to visually identify nodes. The name in the extended settings screen is only capable of being changed prior to deployment and is propagated down to the node as the node’s actual hostname, which is visible both in the UI and on the node itself.
Q: Are these labels are locally significant, if they don’t correspond to the hostname or any other server identifier?
A: Labels are also visible in the CLI, but are not used in conjunction with the hostname. However, we do have the ability to define the hostname for a node in the UI as a new feature, as well.
Q: Are there any plans to support the glusterfs plugin with MOS 7.0 ?
A: GlusterFS was initially developed as a proof of concept to showcase the plugin capabilities in 6.0, but we do not have plans at this time to create a GlusterFS plugin compatible with 7.0. (That said, the whole point of the plugin architecture is that you can, if you need it.)
Q: When using ESXi compute (and multiple clusters) do you recommend putting nova-compute processes on the controllers or dedicated nodes?
A: This one is probably best as “it depends based on your workload” but we are exploring the ability to deploy individual processes – including RMQ and Keystone – onto dedicated nodes based on the workloads that will be running on your environment.
Q: Are the HealthChecks automatically constructed based on the contents of the deployment script(s) ?
A: HealthChecks are a predefined subset of relevant, selectable Tempest, Rally, and OSTF tests exposed in the Fuel UI.
Q: Can multiple environments share the same network?
A: Network Templates are environment-specific, but once defined, they can be copied to multiple environments.
Q: Why are the CEPH and Telemetry greyed out in this example?
A: Fuel grays out selections which are incompatible with currently selected roles. In addition, whether a selection is available is dependent on the selections of the specific environment components during the creation of a new environment. In our demo, for example, we had NOT selected CEPH as the storage backend, and also did not enable the optional Ceilometer service.
Q: Is the possibility to install plugins (or update current ones) in already deployed environments planned?
A: Yes, this is one of our high value targets for improving our plugin framework in upcoming releases. (We do not have a release date planned for these features yet.)
Q: I thought there are some more enhancements in the upcoming Mirantis OpenStack 8.0 with respect to plugin management?
A: Yes, there are more enhancements coming with respect to plugin management, including the ability to provide plugin options in the wizard and a further improved Settings tab, where plugins can define where they are presented. This is all being worked on right now, and we hope to see these changes in MOS 8.0.
Q: Will the webinars on December 3 and December 10 be the same as this one? Or do they have different content?
A: The webinars in December will be different. One will be about Kubernetes/Murano integration, while the other will be more VMware-centric. Feel free to check out our landing page for more info: http://content.mirantis.com/Mirantis-OpenStack-7-Webinar-Series-Landing-Page.html
Thanks for joining us. If you’d like to check out Fuel in Mirantis OpenStack 7.0 for yourself, please go ahead and download it and take it for a spin.
 
The post Fuel levels up: Enhancements in Mirantis OpenStack 7.0 (Q&amp;amp;A) appeared first on Mirantis | The #1 Pure Play OpenStack Company.        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">OpenStack, Cloud Foundry and a turnkey app environment</title>
    <id>http://fedoraplanet.org/24/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/24/" />
    <author>
      <name>Mirantis</name>
    </author>
    <content type="html/text">So next week has a certain meaning for millions of Americans that we relate to a story of indians and pilgrims gathering to have a meal together. While that story may be distorted from the historical truth, I do think the symbolic holiday we celebrate is important.
That said, I want to name some individuals I am thankful for….
People
Mozillians
Lukas Blakk
I’m thankful for Lukas for being a excellent mentor to me at Mozilla for the last two years she was at Mozilla. Lukas helped me learn skills and have opportunities that many Mozillians would not have the opportunity to do. I’m very grateful for her mentoring, teaching, and her passion to help others, especially those who have less opportunity.
Jeff Beatty
I’m especially thankful for Jeff. This year, out of the blue, he came to me this year and offered to have his university students support an open source project I launched and this has helped us grow our l10n community. I’m also grateful for Jeff’s overall thoughtfulness and my ability to go to him over the last couple of years for advice and feedback.
Majken Connor
I’m thankful for Majken. She is always a very friendly person who is there to welcome people to the Mozilla Community but also I appreciate how outspoken she is. She is willing to share opinions and beliefs she has that add value to conversations and help us think outside the box. No matter how busy she is, she has been a constant in the Mozilla Project. always there to lend advice or listen.
Emma Irwin
I’m thankful for Emma. She does something much different than teaching us how to lead or build community, she teaches us how to participate better and build better participation into open source projects. I appreciate her efforts in teaching future generations the open web and being such a great advocate for participation.
Stormy Peters
I’m thankful for Stormy. She has always been a great leader and it’s been great to work with her on evangelism and event stuff at Mozilla. But even more important than all the work she did at Mozilla, I appreciate all the work she does with various open source nonprofits the committees and boards she serves on or advises that you do not hear about because she does it for the impact.
Ubuntu
Jonathan Riddell
I’m thankful for Jonathan. He has done a lot for Ubuntu, Kubuntu, KDE and the great open source ecosystem over the years. Jonathan has been a devout open source advocate always standing for what is right and unafraid to share his opinion even if it meant disappointment from others.
Elizabeth Krumbach Joseph
I’m thankful for Elizabeth. She has been a good friend, mentor and listener for years now and does so much more than she gets credit for. Elizabeth is welcoming in the multiple open source projects she is involved in and if you contribute to any of those projects you know who she is because of the work she does.
Glucosio
Paolo Rotolo
I’m thankful for our lead Android developer who helps lead our Android development efforts and is a driving force in helping us move forward the vision behind Glucosio and help people around the world. I enjoy near daily if not multiple time a day conversations with him about the technical bits and big picture.
The Core Team + Contributors
I’m very thankful for everyone on the core team and all of our contributors at Glucosio. Without all of you, we would not be what we are today, which is a growing open source project doing amazing work to bring positive change to Diabetes.
Others
Leslie Hawthorne
I’m thankful for Leslie. She is always very helpful for advice on all things open source and especially open source non-profits. I think she helps us all be better human beings. She really is a force of good and perhaps the best friend you can have in open source.
Jono Bacon
I’m thankful for Jono. While we often disagree on things, he always has very useful feedback and has an ocean of community management and leadership experience. I also appreciate Jono’s no bullshit approach to discussions. While it can be rough for some, the cut to the chase approach is sometimes a good thing.
Christie Koehler
I’m thankful for Christie. She has been a great listener over the years I have known her and has been very supportive of community at Mozilla and also inclusion &amp;amp; diversity efforts. Christie is a teacher but also an organizer and in addition to all the things I am thankful for that she did at Mozilla, I also appreciate her efforts locally with Stumptown Syndicate.        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">OVN L3 Deep Dive</title>
    <id>http://fedoraplanet.org/25/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/25/" />
    <author>
      <name>Gal Sagie</name>
    </author>
    <content type="html/text">A primer on Magnum, OpenStack containers-as-a-service
Adrian Otto, project team lead, on how Magnum works and what problems it can solve for you.
OpenStack Mitaka release: what’s next for Ansible, Oslo and Designate
Meet the project team leads (PTLs) for these OpenStack projects and find out how to get involved.


Learn what’s coming in other OpenStack projects in the Mitaka release on the OpenStack Foundation playlist.


Community feedback
OpenStack is always interested in feedback and community contributions, if you would like to see a new section in the OpenStack Weekly Community Newsletter or have ideas on how to present content please get in touch: community@openstack.org.
Reports from Previous Events 

Two OpenStack operators share their latest action items

Deadlines and Contributors Notifications

Call for papers:

OSCON 2016 deadline: November 24, 2015
FOSDEM 2016 

Testing and Automation November 30, 2015
Virtualization &amp;amp; IaaS December 1, 2015
Containers &amp;amp; Process Isolation December 1, 2015
Config Management December 1, 2015


Continuous Lifecycle London Deadline: December 1, 2015
PyCon 2016 deadline: Jan 3, 2016
USENIX Annual Technical Conference 2016 deadline: February 1, 2016



Security Advisories and Notices 

None this week

Tips ‘n Tricks 

By Dan Smith: Upgrades in OpenStack Nova: Remote Procedure Call APIs
By Dan Smith: Upgrades in OpenStack Nova: Objects
By Rossella Sblendido: How VMs get access to their metadata in Neutron
By Adam Young: Translating Between RDO/RHOS and Upstream OpenStack releases

Upcoming Events 

Nov 21, 2015 11/21 Meet w/ you – Summit Keynote,Container, Neutron, Cinder… Shanghai, CN
Nov 21, 2015 OpenStack云环境的测试与评估（­兼与社区大咖畅聊东京峰会见闻）Beijing, CN
Nov 22, 2015 OpenStack &amp;amp; SDN/NFV at JNU New Delhi, IN
Nov 24, 2015 De Marconi a Zaqar, la evolución del sistema de mensajería y notificaciones Guadalajara, MX
Nov 26, 2015 From Liberty to Mitaka Rome, IT
Nov 26, 2015 OpenStack Orchestratie 2015 Breda, NL
Nov 26, 2015 From Liberty to Mitaka RM, IT
        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">RDO blog roundup, week of November 23</title>
    <id>http://fedoraplanet.org/26/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/26/" />
    <author>
      <name>RDO</name>
    </author>
    <content type="html/text">Dan Smith is a principal software engineer at Red Hat. He works primarily on Nova, is a member of the core team and generally focuses on topics relating to live upgrade. You can follow him on Twitter @get_offmylawn.

Originally incubated in Nova, the versioned object code is now spun out into an Oslo library for general consumption, called oslo.versionedobjects.
As discussed in the post on RPC versioning,, sending complex structures over RPC is hard to get right, as the structures are created and maintained elsewhere and simply sent over the wire between services. When running different levels of code on services in a deployment, changes to these structures must be handled and communicated carefully — something that the general oslo.messaging versioning doesn’t handle well.

The versioned objects that Nova uses to represent internal data help us when communicating over RPC, but they also help us tolerate a shifting persistence layer. They’re a critical facade within which we hide things like online data migrations and general tolerance of multiple versions of data in our database.

What follows is not an exhaustive explanation of versioned objects, but provides just enough for you to see how it applies to Nova’s live upgrade capabilities.

Versioned Objects as Schema

The easiest place to start digging into the object layer in Nova is to look at how we pass a relatively simple structure over RPC as an object, instead of just an unstructured dict. To get an appreciation of why this is important, refer back to the rescue_instance() method in the previous post. After our change, it looked like this:

def rescue_instance(self, context, instance, rescue_password,
                    rescue_image_ref=None):
    ....


Again, the first two parameters (self and context) are implied, and not of concern here. The rescue_password is just a string, as is the rescue_image_ref. However, the instance parameter is far more than a simple string — at version 3.0 of our RPC API, it was a giant dictionary that represented most of what nova knows about its primary data structure. For reference, this is mostly what it looked like in Juno, which is a fixture we use for testing when we need an instance. In reality, that doesn’t even include some of the complex nested structures contained within. You can imagine that we could easily add, remove, or change attributes of that structure elsewhere in the code or database without accounting for the change in the RPC interface in any way. If you end up with a newer node making the above call to an older node, the instance structure could be changed in subtle ways that the receiving end doesn’t understand. Since there is no version provided, the receiver can’t even know that it should fail fast, and in reality, it will likely fail deep in the middle of an operation. Proof of this comes from the test structure itself which is actually not even in sync with the current state of our database schema, using strings in places where integers are actually specified!

In Nova we addressed this by growing a versioned structure that defines the schema we want, independent of what is actually stored in the database at any given point. Just like for the RPC API, we attach a version number to the structure, and we increment that version every time we make a change. When we send the object over RPC to another node, the version can be used to determine if the receiver can understand what is inside, and take action if not. Since our versioned objects are self-serializing, they show up on the other side as rich objects and not just dicts.

An important element of making this work is getting a handle on the types and arrangement of data inside the structure. As I mentioned above, our “test instance” structure had strings where integers were actually expected, and vice versa. To see how this works, lets examine a simple structure in Nova:

@base.NovaObjectRegistry.register
class Flavor(base.NovaObject):
    # Version 1.0: Initial version
    VERSION = '1.0'

    fields = {
        'id': fields.IntegerField(),
        'name': fields.StringField(nullable=True),
        'memory_mb': fields.IntegerField(),
        'vcpus': fields.IntegerField(),
        'root_gb': fields.IntegerField(),
        'ephemeral_gb': fields.IntegerField(),
        'flavorid': fields.StringField(),
        'swap': fields.IntegerField(),
        'rxtx_factor': fields.FloatField(nullable=True,
                                         default=1.0),
        'vcpu_weight': fields.IntegerField(nullable=True),
        'disabled': fields.BooleanField(),
        'is_public': fields.BooleanField(),
        'extra_specs': fields.DictOfStringsField(),
        'projects': fields.ListOfStringsField(),
        }


Here, we define what the object looks like. It consists of several fields of data, integers, floats, booleans, strings, and even some more complicated structures like a dict of strings. The object can have other types of attributes, but they are not part of the schema if they’re not in the fields list, and thus they don’t go over RPC. In case it’s not clear, if I try to set one of the integer properties, such as “swap” with a string, I’ll get a ValueError since a string is not a valid value for that field.

As long as I’ve told oslo.messaging to use the VersionedObjectSerializer from oslo.versionedobjects, I can provide a Flavor object as an argument to an RPC method and it is magically serialized and deserialized for me, showing up on the other end exactly as I sent it, including the version and including the type checking.

If I want to make a change to the Flavor object, I can do so, but I need to make two important changes. First, I need to bump the version, and second I need to account for the change in the class’ obj_make_compatible() method. This method is the routine that I can use to take a Flavor 1.1 object and turn it into a Flavor 1.0, if I need to for an older node.

Let’s say I wanted to add a new property of “foobars” to the Flavor object, which is merely a count of the number of foobars an instance is allowed. I would denote the change in the comment above the version, bump the version, and make a change to the compatibility method to allow backports:

@base.NovaObjectRegistry.register
class Flavor(base.NovaObject):
    # Version 1.0: Initial version
    # Version 1.1: Add foobars
    VERSION = '1.1'

    fields = {
        . . .
        'foobars': fields.IntegerField(),
    }

    def obj_make_compatible(self, primitive,
                            target_version):
        super(Flavor, self).obj_make_compatible(
            primitive, target_version)
        target_version = utils.convert_version_to_tuple(
                target_version)
        if target_version &amp;lt; (1, 1):
            del primitive['foobars']


The code in obj_make_compatible() boils down to removing the foobars field if we’re being asked to downgrade the object to version 1.0. There have been many times in nova where we have moved data from one attribute to another, or disaggregated some composite attribute into separate ones. In those cases, the task of obj_make_compatible() is to reform the data into something that looks like the version being asked for. Within a single major version of an object, that should always be possible. If it’s not then the change requires a major version bump.

Knowing when a version bump is required can be a bit of a challenge. Bumping too often can create unnecessary backport work, but not bumping when it’s necessary can lead to failure. The object schema forms a contract between any two nodes that use them to communicate, so if something you’re doing changes that contract, you need a version bump. The oslo.versionedobjects library provides some test fixtures to help automate detection, but sharing some of the Nova team’s experiences in this area is good subject matter for a follow-on post.

Once you have your data encapsulated like this, one approach to providing compatibility is to have version pins as described for RPC. Thus, during an upgrade, you can allow the operator to pin a given object (or all objects) to the version(s) that are supported by the oldest code in the deployment. Once everything is upgraded, the pins can be lifted.

The next thing to consider is how we get data in and out of this object form when we’re using a database for persistence. In Nova, we do this using a series of methods on the object class for querying and saving data. Consider these Flavor methods for loading from and saving to the database:

class Flavor(base.NovaObject):
    . . .
    @classmethod
    def get_by_id(cls, context, id):
        flavor = cls(context=context)
        db_flavor = db.get_flavor(context, id)
        # NOTE(danms): This only works if the flavor
        # object looks like the database object!
        for field in flavor.fields:
            setattr(flavor, field, db_flavor[field])
        flavor.obj_reset_changes()
        return flavor

    def save(self):
        # Here, updates is a dict of field=value items,
        # and only what has changed
        updates = self.obj_get_updates()
        db.set_flavor(self._context, self.id, updates)
        self.obj_reset_changes()


With this, we can pull Flavor objects out of the database, modify them, and save them back like this:

flavor = Flavor.get_by_id(context, 123)
flavor.memory_mb = 512
flavor.save()


Now, if you’re familiar with any sort of ORM, this doesn’t look new to you at all. Where it comes into play for Nova’s upgrades is how these objects provide RPC and database-independent facades.

Nova Conductor

Before we jump into objects as facades for the RPC and database layers, I need to explain a bit about the conductor service in Nova.

Skipping over lots of details, the nova-conductor service is a stateless component of Nova that you can scale horizontally according to load. It provides an RPC-based interface to do various things on behalf of other nodes. Unlike the nova-compute service, it is allowed to talk to the database directly. Also unlike nova-compute, it is required that the nova-conductor service is always the newest service in your system during an upgrade. So, when you set out to upgrade from Kilo to Liberty, you start with your conductor service.

In addition to some generic object routines that conductor handles, it also serves as a backport service for the compute nodes. Using the Flavor example above, if an older compute node receives a Flavor object at version 1.1 that it does not understand, it can bounce that object over RPC to the conductor service, requesting that it be backported to version 1.0, which that node understands. Since nova-conductor is required to be the newest service in the deployment, it can do that. In fact, it’s quite easy, it just calls obj_make_compatible() on the object at the target version requested by the compute node and returns it back. Thus if one of the API nodes (which are also new) looks up a Flavor object from the database at version 1.1 and passes it to an older compute node, that compute node automatically asks conductor to backport the object on its behalf so that it can satisfy the request.

Versioned Objects as RPC Facade

So, nova-conductor serves an important role for older compute nodes, providing object backports for compatibility. However, except for the most boring of calls, the older compute node is almost definitely going to have to take some action, which will involve reading and writing data, thus interacting with the database.

As I hinted above, nova-compute is not actually allowed to talk directly to the database, and hasn’t for some time, even predating Versioned Objects. Thus, when nova-compute wants to read or write data, it must ask the conductor to do so on its behalf. This turns out to help us a lot for upgrades, because it insulates the compute nodes from the database — more on that in the next section.

However, in order to support everything nova-compute might want to do in the database means a lot of RPC calls, all of which need to be versioned and tolerant of shifting schemas, such as Instance or Flavor objects. Luckily, the versioned object infrastructure helps us here by providing some decorators that turn object methods into RPC calls back to conductor. They look like this:

class Flavor(base.NovaObject):
    . . .    
    @base.remotable_classmethod
    def get_by_id(cls, context, id):
        . . .

    @base.remotable
    def save(self):
        . . .


With these decorators in place, a call to something like Flavor.get_by_id() on nova-compute turns into an RPC call to conductor, where the actual method is run. The call reports the version of the object that nova-compute knows about, which lets conductor ensure that it returns a compatible version from the method. In the case of save(), the object instance is wrapped up, sent over the wire, the method is run, and any changes to the object are reflected back on the calling side. This means that code doesn’t need to know whether it’s running on compute (and thus needs to make an RPC call) or on another service (and thus needs to make a database call). The object effectively handles the versioned RPC bit for you, based on the version of the object.

Versioned Objects as Database Facade

Based on everything above, you can see that in Nova, we delegate most of the database manipulation responsibility to conductor over RPC. We do that with versioned objects, which ensure that on either side of a conversation between two nodes, we always know what version we’re talking about, and we tightly control the structure and format of the data we’re working on. It pays off immediately purely from the RPC perspective, where writing new RPC calls is much simpler and the versioning is handled for you.

Where this really becomes a multiplier for improving upgrades is where the facade meets the database. Before Nova was insulating the compute nodes from the database, all the nodes in a deployment had to be upgraded at the same time as a schema change was applied to the database. There was no isolation and thus everything was tied together. Even when we required compute nodes to make their database calls over RPC to conductor, they still had too much direct knowledge of the schema in the database and thus couldn’t really operate with a newer schema once it was applied.

The object layer in Nova sadly doesn’t automatically make this better for you without extra effort. However, it does provide a clean place to hide transitions between the current state of the database schema and the desired schema (i.e. the objects). I’ll discuss strategies for that next.

The final major tenet in Nova’s upgrade strategy is decoupling the actual database schema changes from the process of upgrading the nodes that access that schema directly (i.e conductor, api, etc). That is a critical part of achieving the goal.

Dan Smith originally posted this tutorial from his blog, Right Angles. Superuser is always interested in how-tos and other contributions, please get in touch: editor@superuser.org 

Cover Photo// CC BY NC        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Upgrades in Nova: Database Migrations</title>
    <id>http://fedoraplanet.org/27/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/27/" />
    <author>
      <name>OpenStack Superuser</name>
    </author>
    <content type="html/text">Welcome to the Short Stack, our regular feature where we search for the most intriguing OpenStack news. These links may come from traditional publications or company blogs, but if it’s about OpenStack, we’ll find the best ones.
Here are our latest links:
Two OpenStack operators share their latest action items | OpenStack Superuser
Matt Fischer and Clayton O’Neill shared the important lessons they learned at OpenStack Summit Tokyo. They divulged ‘action items’ that they would like to implement to optimize their cloud’s performance. Some of these suggestions included always running the latest version and using autoheal.
Database as a Service: New Op on the Cloud Block | Channel Partners Online
Tesora’s VP of Business Development, Brian Otis, explored the concept of Database as a Service (DBaaS) and the reasons behind its growing popularity. He described the basic premise of DBaaS as well as the positives to working with it in the cloud. Notably, Otis remarked that with DBaaS it becomes easier and faster to provision and operate a database in a secure public or private cloud.
Mirantis’ Fuel Project Joins the OpenStack Big Tent | Ostatic
This week, Mirantis announced that Fuel became an official OpenStack component of the Big Tent. Fuel, a library of configuration and management tools, made quite a difference as a cloud deployment and management toolset.
Podcast Episode 13: Sriram Subramanian, The Cloud Don | OpenStack: Now
OpenStack:Now’s Nick Chase and John Jainschigg interviewed Sriram Subramanian, The Cloud Don. The three discuss Sriram’s experiences at the recent Tokyo Summit, which he attended as an analyst for the first time this year. Subramanian participated in more in-depth conversations about use cases. He shared insights into how posed candid questions about the direction of OpenStack to the Foundation and others, as well as summarized the type of data he would like to see released on OpenStack usage in the future.
Sticky situation: the serious business of stickers in open source | Opensource.com
Rikki Endsley explained the dynamic of stickers within the open source community and how they serve as both badges of pride as well as tokens of support. She recounted her experience at a recent conference where she spoke with an event organizer about the multiple functions of stickers, including promoting open source projects, showing support for open source communities, acting as souvenirs, and more.
The post Short Stack: OpenStack Action Items, Fuel Joins the Big Tent, and the New Op on the Cloud Block appeared first on Tesora.
        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Lwood-20151122</title>
    <id>http://fedoraplanet.org/28/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/28/" />
    <author>
      <name>Hugh Blemings</name>
    </author>
    <content type="html/text">Better late than never! I took some off after the summit, but here’s my blog about the Keystone Design Summit outcome and goals for Mitaka. Both Boris Bobrov and Dolph Mathews have already written fantastic recaps, I strongly recommend you take a look at those too. This blog is meant to summarize the action items from various design sessions, and should hopefully act as release notes in 6 months! This is by no means complete, but it’s certainly close!
To summarize the outcome in one sentence
We’ll be continuing the trend from our previous releases, focusing on performance, scalability, stability and adding just a few new features that are essential to both public and private clouds.
Keystone Server
Roles &amp;amp; Policy
Return names when listing role assignments NEW API
– Modify GET /v3/role_assignments to support &amp;amp;include_names flag
– This should improve usability for both Horizon and OpenStackClient
– Specification: http://specs.openstack.org/openstack/keystone-specs/specs/mitaka/list-assignment-names.html
Implied roles NEW APIs
– Have one role imply many roles
– Specification: http://specs.openstack.org/openstack/keystone-specs/specs/backlog/implied-roles.html
Domain Scoped Roles NEW APIs
– Allow roles to be created within a domain, effectively allowing per-domain-policy
– Specification: https://review.openstack.org/#/c/226661/
Define Admin Project in config file
– Add the ability to define “this is my admin project”
– This should resolve a lot of the incorrect usage of the admin role being unnecessarily given to many projects (See bug 968696)
– Specification: http://specs.openstack.org/openstack/keystone-specs/specs/mitaka/is_admin_project.html
Federation
Create shadow accounts for any user that has been created or authenticated (via local SQL, LDAP or federation)
– Greatly improve the story for federated users, we will be able to assign roles directly and trace their actions more easily for billing and auditing
– Specification: https://review.openstack.org/#/c/240595/
New specs that have APIs!
– Service provider and endpoint filtering, see specification: https://review.openstack.org/188534
– Mark identity providers as public or private, see specification: https://review.openstack.org/#/c/209941/
Operator request: Clean up logging, far too much in DEBUG and not enough in INFO
Tokens
Continue to make Fernet tokens the go-to token format for Keystone
– DevStack and Tempest support is still being worked on, needs to be completed before Keystone can make it the default format
– Improve documentation, lots of unofficial docs via blog posts are causing misconceptions
Catalog
Retrieve the service catalog with an unauthenticated call
– Part of a larger cross-project effort, we will be looking to return a well defined service catalog on a new API
– This will allow for a better service-discovery story for OpenStack as a whole
– Implementation and API has yet to be finalized
Fixing broken things
Pagination
– Pagination for projects, roles and doamins, is possible now since they are only available in SQL
– Pagination for users and groups in LDAP? We can add support for it, but YMMV
Custom TTL on tokens for long-running operations
– Make keystone_authtoken configurable with a custom TTL, token validation uses this value or ignores the expires_at
REST interface for domain config NEW API
– List default values of a domain config, see specification: https://review.openstack.org/#/c/185650/
Extensions
OS-FEDERATION, OS-ENDPOINT-POLICY, OS-REVOKE, OS-OAUTH1, OS-INHERIT, OS-EP-FILTER will be moved to keystone proper
– The old routers and SQL backends will be deprecated in M and be removed in O
– Paste files will need to be updated to point to the new resources before O is released
No more extensions – ever.
Deprecations
Each of these items will follow the standard deprecation policy that the TC has now publicized.
v2.0 of the Identity API Deprecate in M, remove in O or greater
– We will maintain some v2.0 authentication calls, such as: POST /v2.0/tokens and GET /v2.0/tenants
PKI token format Deprecate in M, remove in O
– Contains a major security bug
– If PKI format is specified, the resultant token will be a UUID token
LDAP write support Deprecate in M, remove in O
– Rarely do OpenStack deployers want to write to LDAP, and more rarely do LDAP administrators want to allow this sort of operation
Removals
Eventlet Deprecated in K, to be removed in M
– May live to see another release, need confirmation from mailing list
LDAP as a resource backend, to store projects, domains and roles Deprecated in K, to be removed in M
Keystone Libraries
keystoneauth
We need to support federation protocol like SAML and kerberos
– Since support for these pulls in additional libraries, they will be ‘optional’
– Install these optional plugins with: pip install keystoneauth[kerberos] or pip install keystoneauth[saml]
– The python-keystoneauth-saml repo will be removed (there were no releases of it)
– The python-keystoneclient-kerberos repo will become inactive and eventually removed (there were 3 minor releases)
Improve the documentation: Show how to create plugins for the federation plugins, and also explain k2k flows
keystonemiddleware
– Adapt keystonemiddleware to use keystoneauth
– Tokenless auth support
– Deprecate certain auth_token configuration values
keystoneclient
– Only changes to the CRUD calls should be added or modified
– Authentication plugins should go into keystoneauth, and CLI should go into openstackclient
– Modify other python-*clients to use keystoneauth
– deprecate auth plugins and session code (remove these in O)
– potentially remove CLI and mark keystoneclient as 2.0 (need to check deprecation policy for clients)
– potentially remove middleware and mark keystoneclient as 3.0 (need to check deprecation policy for clients)
The post Keystone Design Summit Outcome and Goals for Mitaka appeared first on IBM OpenTech.        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Containers-as-a-service, the Keystone design summit, and more OpenStack news</title>
    <id>http://fedoraplanet.org/29/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/29/" />
    <author>
      <name>Opensource.com</name>
    </author>
    <content type="html/text">The post OpenStack:Now Podcast Ep 13: Sriram Subramanian, The Cloud Don appeared first on Mirantis | The #1 Pure Play OpenStack Company.
&amp;lt;iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="https://www.youtube.com/embed/BzFNgySLDJE" width="560"&amp;gt;&amp;lt;/iframe&amp;gt;
OpenStack:Now’s Nick Chase and John Jainschigg talk with Sriram Subramanian, The Cloud Don, about the goings on at the OpenStack summit in Tokyo.
The post OpenStack:Now Podcast Ep 13: Sriram Subramanian, The Cloud Don appeared first on Mirantis | The #1 Pure Play OpenStack Company.        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">OpenStack Mitaka release: what’s next for Swift and Ironic</title>
    <id>http://fedoraplanet.org/30/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/30/" />
    <author>
      <name>OpenStack Superuser</name>
    </author>
    <content type="html/text">It’s difficult to right-size the excitement about containers, the old/new technology of the moment. 

We can offer the skinny on OpenStack’s Magnum project from Adrian Otto, Rackspace distinguished architect, at the recent Summit Tokyo. Otto runs through what problems OpenStack’s containers-as-a-service project can really solve for you and when to give know-it-alls a kick in the pants.

Supersizing the project
Otto, who is also the PTL, has been talking about Magnum for several Summits. His favorite slide? The one he has to update the most. 



“It shows that we are reviewing code, and we're making that code better before it gets upstream but we're not making tons of revisions to this code,” he said. We're doing a few revisions to make it better and then that code is getting in…there's some velocity here.”

Magnum’s changing vision

Magnum used to be all about containers as a first-class resource in OpenStack, he said. That’s about as passé as dial-up these days, because “we've already achieved this.”

Now, “Magnum is all about is combining the best of infrastructure software with the best of container software..I want everyone to recognize that container software does not solve our problems,” he added.

Kick ‘em in the pants
There’s a lot of confusion about what containers are, Otto said. If someone asserts that containers just like virtual machines but smaller and faster, there’s only one thing to do. 

“Please kick someone in the nuts if they say that because they're not,” he said. “Containers are about things that are related to processes that run on hosts. Killing them, starting them, setting their environment variables, binding file system volumes, attaching terminals to them and running processes within them.” Cramming all of those capabilities into Nova, OpenStack’s compute project, would be a terrible fit, he said, so it was decided to create a new project with its own API. 



What Magnum can solve

Most of the problems that crop up when you try to run applications on containers are still infrastructure problems, he said. These are problems like: “How do I connect my networks?” “What do I do with my storage?” “Where does my addressing come from?” “How are these things related?” “How do I orchestrate these? How do I scale them?”

Container software helps at the app layer and it helps with packaging and distribution — but it doesn't solve everything in the infrastructure. “Magnum is trying to take and vertically integrate solutions that solve an entire range of problems,” he added.

Magnum 101


Otto ran through the basics. First you have OpenStack — compute, networking and storage. 



Bays
Magnum is an additional service that allows you to create a new entity, a new cloud resource called a Bay. A Bay is where your container orchestration engine (COE) lies. You can run Docker Swam, Kubernetes and, with the Liberty release, Apache Mesos.

Bays were designed provide users with the native tool experience — using the Docker CLI or the Cube CTL command against the cluster as you see fit.

“You should be able to enjoy the new features that surface in these various COEs as they're made,” Otto said adding, “not have to wait for the Magnum team to build leaky obstructions on top of all that stuff in order to surface that to you.” Instead, you rely on Magnum to create the bay and scale that infrastructure from a capacity perspective, then you interact and create containers and manage containers and stock containers all using your native tools, he said.  

DIY Containers
Magnum does also provide a feature to create a container — more about this from his talk in Vancouver. It allows you to create a port in Kubernetes, it has this capability as well but you also have the option to run this as a native experience. Depending on what bay you choose, he said, you’ll get a different native API experience.

Nodes
Nodes are essentially Nova instances. A Bay is simply a grouping of Nova instances, so all of the bays in Magnum today have at least these three abstractions. 

Pods
A pod is a grouping of containers that run together on the same host. A service is a way of connecting a network port to a container and a bay is a grouping of Nova instances. Nodes are one-to-one related to Nova instances. 

What’s new
Otto talked about his favorite new features in Magnum: Mesos Bay Type, Security Bays (TLS), External Load Balance Support and Multi-master from Kubernetes. 



The Future? Uncontainable excitement 

“What I'm most proud of is that collaboration is now between 101 engineers who come from 28 different affiliations,” Otto said. “I think this is a testament to the excitement that we all feel about where this new technology might take us.”

How to get involved
Use Ask OpenStack for general questions
For roadmap or development issues, subscribe to the OpenStack development mailing list, and use the tag [magnum] Weekly meetings held on Tuesdays at 16:00 UTC.

You can watch his 30-minute talk on the OpenStack Foundation’s YouTube channel.

&amp;lt;iframe allowfullscreen="allowfullscreen" frameborder="0" height="" src="https://www.youtube.com/embed/_ZbebTIaS7M" width=""&amp;gt;&amp;lt;/iframe&amp;gt;

Cover Photo // CC BY NC        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">OpenStack Developer Mailing List Digest November 14-20</title>
    <id>http://fedoraplanet.org/31/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/31/" />
    <author>
      <name>OpenStack Blog</name>
    </author>
    <content type="html/text">The post Fuel Becomes an OpenStack Project under Big Tent appeared first on Mirantis | The #1 Pure Play OpenStack Company.
The OpenStack Big Tent just got a whole lot bigger. The Technical Committee has voted in the largest OpenStack project yet: Fuel. Fuel is an open source deployment and management tool for OpenStack. It’s a lesser-known project, but it’s huge, with 50 percent more code than Nova and 75 percent more commits per month than Neutron. Developed as an OpenStack community effort, Fuel provides an intuitive, GUI-driven experience for deploying and operating OpenStack, related community projects and plug-ins. In short, it provides a quick onramp to OpenStack.


 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
OpenStack User Survey, p. 26
The Technical Committee, which is composed of elected representatives from most key players in the OpenStack community, accepted Fuel as an OpenStack project under the Big Tent governance model because the engineering process in Fuel is done in the OpenStack way. Mirantis uses Fuel as a part of Mirantis OpenStack and is a major contributor. The company’s pure-play approach has enabled the Fuel team to use the same process as upstream, from code reviews and bug tracking tools, to sharing email and IRC communication channels with other OpenStack teams, to establishing active collaboration with other OpenStack projects such as Puppet and Infrastructure. Today Fuel is flexible, decoupled from vendor-specific solutions, and enables multiple choices for key supporting technologies (from storage to networking to operating systems).
Fuel’s acceptance into the Big Tent is terrific news for Fuel contributors and the OpenStack community. OpenStack operators get a comprehensive and mature deployment service. OpenStack vendors get assurance that Fuel can and will support their favored OpenStack version and distribution. OpenStack developers can use Fuel to explore more complex multi-node deployment configurations.
It also goes a long way in assuring community members that the Fuel project will remain open and neutral. My hope is that this encourages other vendors to increase their contributions to enable additional platforms, OpenStack projects, and deployment configurations. More diverse contributions would not just expand Fuel’s functional scope, but also drive the flexibility of Fuel’s core components. It will also ensure the long term viability of the project by making it less dependent on investments from a single commercial entity.
To the current and future Fuel contributors: our work has just begun. The whole community will be paying close attention to Fuel, and will expect our open source team to improve our high standards of open collaboration, cross-project communication, adherence to OpenStack engineering practices and alignment with OpenStack development tools.
We have solved the problem of initial deployment, so the next big challenge for the Fuel team is to simplify the “day 2” operation of OpenStack environments: applying updates, upgrades, configuration changes, adding and removing services and plugins, scaling up and down, logging, monitoring, and alerting. This whole class of problems is often called “lifecycle management,” and remains largely unaddressed by existing tools.
Fuel developers kicked off the discussion of lifecycle management use cases with the OpenStack community at large before the OpenStack summit in Tokyo in October, focusing on what it means not only for deployment services, but for all OpenStack projects. The Technical Committee is also looking into encouraging all OpenStack projects to consider these use cases by labeling projects with tags such as “supports-upgrade” which indicate which aspects of this problem are supported out of the box.
With increased interest in Fuel from other OpenStack developers, turning Fuel itself and its massive body of deployment tests into a development tool for other OpenStack projects will become another major theme for the Fuel team. While some projects such as Puppet OpenStack are interested in validating their code with the Fuel CI, the OpenStack Infrastructure team is already calling for the next step: porting the same tests to nodepool and other tools used to operate the OpenStack CI on top of public OpenStack clouds.
We have a great opportunity and responsibility to make OpenStack easy to install and operate at scale. Let’s work together to make Fuel the best it can be!
Want to learn more? Download the latest version of Fuel or contact Mirantis.
The post Fuel Becomes an OpenStack Project under Big Tent appeared first on Mirantis | The #1 Pure Play OpenStack Company.        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Fuel levels up: Enhancements in Mirantis OpenStack 7.0 (Q&amp;amp;A)</title>
    <id>http://fedoraplanet.org/32/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/32/" />
    <author>
      <name>Mirantis</name>
    </author>
    <content type="html/text">Each release cycle, OpenStack project team leads (PTLs) introduce themselves, talk about upcoming features for the OpenStack projects they manage, plus how you can get involved and influence the roadmap.

Superuser will feature these summaries of the videos weekly; you can also catch them on the OpenStack Foundation YouTube channel. This round of interviews covers Ansible, Oslo and Designate.

Ansible

&amp;lt;iframe allowfullscreen="allowfullscreen" frameborder="0" height="" src="https://www.youtube.com/embed/F4Qba9f4WIY" width=""&amp;gt;&amp;lt;/iframe&amp;gt;

What: OpenStackAnsible, a collection of Ansible playbooks and roles to deploy OpenStack.Who: Jesse Pretorius, PTL. Day job: DevOps engineer, Rackspace. Burning issues



“We trying to do things that are simple to use and simple to understand. OpenStack is complicated enough, operators don't have to learn another complex deployment tool to do what they need to do.”

What’s next 



What matters in Mitaka 



“One thing that struck me in the conversations I had at the Summit was that the deployment projects have a unique position in the community. We are the first to test a lot of things that are coming out of the development community,” Pretorius says.  “We get to either lead the operators in new feature deployments, or we get to figure out some of the hard things that the operators don't really have the time to figure out. As a deployer community, we could spend a lot more time getting together and being that interface between the two parties, that would be a valuable thing…"

Get involved!
Use Ask OpenStack for general questions
For roadmap or development issues, subscribe to the OpenStack development mailing list, and use the tag [ansible] 
Participate in the weekly meetings: community meeting, on IRC in #openstack-meeting-4, on Thursdays at 16:00 UTC,
or bug triage, on IRC in #openstack-ansible, on Tuesdays at 16:00 UTC.

Oslo

&amp;lt;iframe allowfullscreen="allowfullscreen" frameborder="0" height="" src="https://www.youtube.com/embed/-9dUXvgL9og" width=""&amp;gt;&amp;lt;/iframe&amp;gt;

What: Oslo is the OpenStack Common Libraries project. Who: Davanum Srinivas aka Dims, PTL. Day job: Community architect/principal software engineer, Mirantis.

Burning issues



What’s next 



What matters in Mitaka 



"Based on feedback, we'll be working on messaging a lot this cycle," Srinivas added. "All [of these efforts] are attempts to stabilize the infrastructure so we can scale out to a huge number of nodes, compute nodes for example," he added. 

Get involved!

“Typically, Oslo developers work primarily on other projects," says Srinivas. "We tend to be folks who work part-time on things they really care about in Oslo, so we welcome folks who start contributing and usually quickly promote them as core [contributors.]”

Use Ask OpenStack for general questions
For roadmap or development issues, subscribe to the OpenStack development mailing list, and use the tag [oslo] 
Participate in the weekly meetings: held Mondays, 16:00 UTC.

Designate

What: 

"Traditionally, in companies, DNS is difficult to do. Users have to file a ticket with IT or they have to go edit text files on some server and do it all manually. Designate provides an easy-to-use multi-tenant API to create and update DNS records," says Graham Hayes, PTL, and senior software engineer, Hewlett-Packard Enterprise.

Burning issues



"We've been going through a large amount of re-architecture," Hayes says, adding that the issues discussed at the Summit Tokyo were largely around those changes in addition to the points mentioned above. 

What’s next 


What matters in Mitaka 


In the drive to make it more manageable, he says: “It's always good to put things into the hands of users and get feedback, so we're taking that feedback now and updating the Horizon panels with it.” 

Get involved!
Use Ask OpenStack for general questions
For roadmap or development issues, subscribe to the OpenStack development mailing list, and use the tag [designate] 
Participate in the weekly meetings: held at #openstack-meeting-alt on freenode at 17:00 UTC every Wednesday.

Cover Photo: OpenStack Foundation.        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Openly Thankful</title>
    <id>http://fedoraplanet.org/33/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/33/" />
    <author>
      <name>Benjamin Kerensa</name>
    </author>
    <content type="html/text">There is a straight forward mapping between the version numbers used for RDO and Red Hat Enterprise Linux OpenStack Platform release numbers, and the upstream releases of OpenStack.  I can never keep them straight.  So, I write code.
UPDATE:  missed Juno before…this is why we code review
#!/usr/bin/python

upstream = ['Austin', 'Bexar', 'Cactus', 'Diablo', 'Essex', 'Folsom',
            'Grizzly', 'Havana', 'Icehouse', 'Juno', 'Kilo', 'Liberty',
            'Mitaka', 'N', 'O', 'P', 'Q', 'R', 'S']

for v in range(0, len(upstream) - 3):
    print "RHOS Version %s = upstream %s" % (v, upstream[v + 3])


RHOS Version 0 = upstream Diablo
RHOS Version 1 = upstream Essex
RHOS Version 2 = upstream Folsom
RHOS Version 3 = upstream Grizzly
RHOS Version 4 = upstream Havana
RHOS Version 5 = upstream Icehouse
RHOS Version 6 = upstream Juno
RHOS Version 7 = upstream Kilo
RHOS Version 8 = upstream Liberty
RHOS Version 9 = upstream Mitaka
RHOS Version 10 = upstream N
RHOS Version 11 = upstream O
RHOS Version 12 = upstream P
RHOS Version 13 = upstream Q
RHOS Version 14 = upstream R
RHOS Version 15 = upstream S
I’ll update one we have names for N and O.        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">OpenStack Weekly Community Newsletter (Nov. 14 – 20)</title>
    <id>http://fedoraplanet.org/34/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/34/" />
    <author>
      <name>OpenStack Blog</name>
    </author>
    <content type="html/text">The OpenStack Summit Tokyo was, as always, educational, exciting, entertaining and energizing. 

After we flew back and shook off the jet lag, the question was what will we do with what we learned and discussed? What actions will we take as an operator to make our cloud more stable, performant and future-proof? 

After some team discussions, we here are the things that we are taking immediate action on -- either doing, or investigating, -- based on what we learned in Tokyo.

On the first day of the summit, we attended a talk called “RabbitMQ Operations for OpenStack.” RabbitMQ is always a sore spot and a dangerous area to poke in an OpenStack deployment. In this talk, Michael Klishin from Pivotal Labs gave dozens of tips on how to operate RabbitMQ.

A few of these tips really hit home:

“Always run the latest version.” I was a bit horrified, but not surprised, to find out that we were two full versions out of date.
    “Tune your FDs." We’d already been hit by this, the default limit is way too low and as we add capacity and nodes the number in use keeps climbing.
    “Use autoheal.” We’re not and we should be.
    “Optimize the TCP config.” This paraphrases about 5 minutes of the talk. The good news is that the newer Puppet modules do most of this for us, so we upgraded the Puppet module, too.
The thing with Rabbit is that if you’re going to take it down for a reconfig or an upgrade, you only want to do it once. So we spent some time digging into all the rest of his optimizations and also wrote up an Ansible-based RabbitMQ upgrade playbook. We can happily say that we finished rolling out this upgrade of RabbitMQ (from 3.3 to 3.5) to production last week. This included our optimized configuration.

Another talk that we enjoyed (and led along with GoDaddy) was “Duct-Tape, Bubblegum, and Bailing Wire: The 12 Steps in Operating OpenStack." In this talk we learned about a bunch of issues that operators had, little problems that crop up and cause headaches. There were plenty of other talks in this category, including hallway discussions and as an outcome of this we made a few small tweaks in our environment:

Raising kernel.pid_max (sysctl): We had the default value and according to other operators this can cause issues with Ceph. This rolled to production last week.
    Enabling the neutron root-wrap daemon: Neutron wastes a lot of time execing rootwrap and sudoing and the daemon should make neutron calls to things like ip netns much faster. This change is baking in our dev environment while we test how stable it is.
Finally, we both attended lots of Ops sessions. Much of the discussion in these sessions was on prepping for the Liberty upgrade. We have a philosophy that we always try to upgrade fairly quickly after the summit so we’re getting some tasks done now that will make it easier when we do it. One of the big things we’re looking forward to in Liberty is improved Fernet token performance. Fernet tokens are marching towards being the default token provider and although they work well for us, we’d like them to be faster. There was a great design session on these changes on Wednesday of the summit. Another major thing we’re going to enjoy in Liberty is the Neutron OVS agent fix. Right now in Kilo (and before) when the OVS agent restarts it can interrupt networking to the customer VMs we host. This makes host maintenance and upgrades painful. Unfortunately, this fix will not be backported to Kilo, but our upgrades will be much easier after Liberty.

Due to some infrastructure work and holiday closures, we’re not starting Liberty now, but what pre-Liberty work are we doing now?

One topic that saw a lot of discussion is the requirement to be on Kilo.1 for Nova before upgrading to Liberty.  In general, upgrading to a new minor release for OpenStack is fairly straightforward, but as mentioned before, restarting the OVS agent to do that upgrade can be really disruptive. Additionally package dependencies can force you to upgrade everything on a box even if you just want a newer copy of Nova.  For these reasons, we’re currently working on moving Nova services into Docker containers so that we can upgrade just that single service.

Keystone deprecated eventlet during the Kilo cycle, and so we’ve already switched over to service keystone with Apache.  However because other services will probably also deprecate eventlet and for performance reasons, we’re looking to switch all of our API services to use a higher performing WSGI server.  We moving more and more services into containers and running Apache inside a container would be workable, but seemed like overkill. Reading up we learned that most people recommend using uWSGI for this now and we’ve been reading up, experimenting it and getting close to rolling our first service (heat) using it soon.

Tokyo gave us a ton of ideas and also a ton of work, but we’re confident that these changes will make our cloud better, our lives as operators easier and our customers happier.

 You can catch Matt Fischer, princple engineer at Time Warner Cable, on Twitter at @openmfisch. Clayton O'Neill, also a principle engineer at TWC, is on Twitter at @clayton_oneill.

Superuser is always interested in how-tos and other contributions, please get in touch: editor@superuser.org

Cover Photo // CC BY NC        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">Upgrades in OpenStack Nova: Objects</title>
    <id>http://fedoraplanet.org/35/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/35/" />
    <author>
      <name>OpenStack Superuser</name>
    </author>
    <content type="html/text">In the wake of OpenStack Tokyo last month, Rackblog asked Rackers serving as Project Team Leads to share the status of their particular projects.  Lana Brindley’s post on priorities for Mitaka will kick off this occasional series. If you’re a PTL on an OpenStack project and you’d like to write an update, great! Just email blog@rackspace.com.
Tokyo is a city of contrast. 
From the neon lights of Shibuya and Akihabara (“Electronics Town”) to the shrines and temples dotted in green spaces around the city, old and new Japan come together in Tokyo in a surprisingly harmonious way. 
While the OpenStack Summit, like the people of Tokyo, is focused on new technology and moving into the future, an atmosphere of community, fellowship, and camaraderie that underpins the conference also flourishes.
I am privileged to be the documentation PTL for Mitaka, having taken over the reins from Anne Gentle after the Kilo cycle. 
[Anne and Lana sat down with Superuser TV in Tokyo to discuss why documentation is important for the user community, the latest metrics from the Liberty release and how you can get involved.]
&amp;lt;iframe allowfullscreen="allowfullscreen" frameborder="0" height="281" src="https://www.youtube.com/embed/o2y_UMi1THU?feature=oembed&amp;amp;amp;wmode=opaque" width="500"&amp;gt;&amp;lt;/iframe&amp;gt;
This time around, we have three main priorities to achieve, and I think it’s a  lovely blend between the technical and the community.
First, we will focus on improving the usability of our documentation, making it easier to navigate the docs site and find relevant information quickly. The main way we want to address this is through a different model of data typing, and moving away from a role-based architecture towards a task-based one. This is easier to do for some guides than others, of course, and we intend to start with the user guides. The other component of this is reorganizing the index page, and adding some more guidance on what each book is about. You should start to see those changes rolling in shortly.
We also want to continue converting our books to restructured text (RST). A lot of our books have already been converted, but we still have quite a few to go, and determining which books are to be converted in each release and who is responsible for doing so can take quite a bit of planning. This time around, we’re looking at the Architecture Design Guide, the Operations Guide, and the Configuration Reference Guide.
Finally, a fairly small thing that should have a big influence on our work is tweaking the way the docimpact tool works. At the moment, it creates a lot of noise in our bug queue and makes it harder for us to find the real work that needs to be done. By changing the way this tool operates, we hope it to make it much more responsive and useful both for the docs team, and for the OpenStack developer community.
This release is about having docs work more efficiently and effectively as part of the OpenStack development community. With OpenStack moving to the big tent, we need to reevaluate which projects we document, how we go about communicating with other development teams, and we need to ensure we’re being good community citizens. I also want to ensure we’re working closely with enterprise writing teams, and valuing the input that our corporate contributors provide to the documentation.
Liberty was my first release as Docs PTL, so I’m still learning what makes a good release. It was great to hear feedback from the docs team on what went well and what didn’t go so well, so I can learn from this to improve in Mitaka. I’m very grateful to have a team that has supported me in my new role, and I am honored to be leading them again into the next release.
Finally, we always need docs contributors.
If you are a technical writer, we have plenty of projects that need your writing expertise. If you’re a developer, even if you don’t think you’re a good writer, we could definitely use your technical prowess to test and improve our documentation. Remember, the documentation is developed exactly like code within the OpenStack system, so if you’re an active technical contributor (ATC), you already have the skills required to contribute, and to improve the docs for all our users.        
        </content>
  </entry>
  <entry xml:base="http://planet.openstack.org/">
    <title type="text">OVB Network Diagram and Update</title>
    <id>http://fedoraplanet.org/36/</id>
    <updated>2015-12-03T07:45:48Z</updated>
    <link href="http://fedoraplanet.org/36/" />
    <author>
      <name>Ben Nemec</name>
    </author>
    <content type="html/text">The post Red Hat makes a deal with … Microsoft? appeared first on Mirantis | The #1 Pure Play OpenStack Company.
Apparently the cloud is like politics; it makes very strange bedfellows. As Red Hat tries to unseat Ubuntu as the operating system of the cloud, and Microsoft tries to unseat Amazon Web Services as, well, the cloud itself, the two companies have joined forces, agreeing to help each other.  Yes, you read that right.
Microsoft will offer Red Hat Enterprise Linux as the default choice for Linux on its Azure cloud service, and Red Hat will provide support for it.  Red Hat will also make a “pay as you go” license available on the Azure cloud, just as it is on AWS. 
Don’t think that means that Red Hat is giving up on OpenStack, of course; the companies said that part of the deal is that Azure will run on Red Hat’s OpenStack distribution, Red Hat Enterprise Linux OpenStack Platform.
RHEL will also become the primary platform for developing and testing .NET Core on Linux. Microsoft’s cooperation in making the .NET environment cross-platform fits in with the hybrid nature of the deal, which will also see Red Hat’s CloudForms management project interact with Azure.
“The partnership,” said Redmond Magazine, “will involve a Red Hat engineering team moving to Redmond to provide joint technical support for Red Hat Enterprise Linux workloads running in the Microsoft Azure public cloud and on its hybrid cloud offerings. The pact also calls for applications developed in the Microsoft .NET Framework language to run on RHEL, OpenShift and the new Red Hat Atomic Host container platform.”
A Microsoft spokesman said there were no plans to run OpenStack natively on Azure, but Paul Cormier, Red Hat President of Products and Technologies, told the audience of the announcement webcast that the possibility existed for Windows VMs and containers to be run in the Red Hat OpenStack environment.
This deal is surprising because it wasn’t that long ago that Microsoft was calling Linux a “cancer” and threatening its users with patent infringement lawsuits.  Part of this deal involves both companies setting aside that kind of talk — for now.  Cormier told eWeek, “Red Hat and Microsoft did not acknowledge the validity or value of each other’s patents. This is a commercial deal spurred by strong customer demand for our solutions to work together.”
“As we said for the Ansible acquisition, our enterprise customers have complex heterogeneous IT environments and don’t want IT organizations to create redundant management silos, or embrace single vendor stacks if it’s not the best for their business,” Alessandro Perilli, General Manager, Cloud Management Strategy, wrote.  It’s not clear how this view meshes with the company’s “one OS to rule them all” attitude.
Resources

Microsoft and Red Hat Announce New Open Source Partnership — Redmondmag.com
Microsoft and Red Hat Partner on Massive Hybrid Cloud Deal – Enterprise Software on CIO Today
Microsoft Links Open-Source Arms with Linux Frenemy Red Hat | WIRED
Microsoft, Red Hat Partner For Linux On Azure – InformationWeek
Nadella delivers another shocker as Microsoft embraces Red Hat in cloud alliance | SiliconANGLE
Red Hat and Microsoft making .NET on Linux work for Enterprises | Red Hat Developer Blog
Red Hat Enterprise Linux lands on Microsoft Azure cloud – no, we’re not pulling your leg • The Register
Red Hat, Microsoft Forge Wide-Ranging Cloud Partnership
What’s behind the odd couple Microsoft-Red Hat partnership – Computerworld
Why Red Hat is extending management support to Microsoft private and public clouds | Cloud Strategy Blog
iTWire – With Microsoft and Red Hat in bed, what happens to SUSE?
Red Hat Preps Containerized Cloud Workloads In OpenShift – InformationWeek
Red Hat CloudForms 4.0 Public Beta 2 | CloudFORMS NOW
Red Hat launches application platform and Linux container offerings to link business demands, IT delivery – Computer Technology Review

The post Red Hat makes a deal with … Microsoft? appeared first on Mirantis | The #1 Pure Play OpenStack Company.        
        </content>
  </entry>
</feed>
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title type="text">Planet Python</title>
  <id>http://planetpython.org/</id>
  <updated>2015-12-03T07:45:52Z</updated>
  <link href="http://planetpython.org/" />
  <link href="http://planetpython.org/" rel="self" />
  <author>
    <name></name>
  </author>
  <subtitle type="text">http://planetpython.org/</subtitle>
  <generator>PyAtom</generator>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


Revisiting an old friend, yet again</title>
    <id>http://fedoraplanet.org/2/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/2/" />
    <author>
      <name>Andre Roberge</name>
    </author>
    <content type="html/text">

The most popular blog post I ever wrote was on a suggested alternative for type hinting in Python. This was likely due to the fact that the blog post was linked in PEP 484 which codified a syntax for type hinting.The alternative syntax I had been suggesting was to use a clause introduced by a new keyword: where. (I had first discussed this idea more than 10 years ago.) For example, instead of the approved type hinting syntaxdef twice(i: int, next: Function[[int], int]) -&amp;gt; int:    return next(next(i))I was suggesting to use something like the following:def twice(i, next):    where:        i: int        next: Function[[int], int]        returns: int    return next(next(i))Similarly, instead of using a comment to introduce type hinting for single variablesx = 3 # type: intone would have used the following:x = 3where:    x: intHowever, this alternative was never considered as a serious contender for type hinting since it was not compatible with Python 2.7, unlike the accepted syntax from PEP 484.Still, as an experiment, I decided to see if I could use the approach mentioned in my last few blog posts and use an nonstandard where clause.  And, of course, it is possible to do so, and it is surprisingly easy. :-)The main details are to be found in three  previous blog posts.  However, to summarize, suppose you with to use a where clause like the one described above which would not have an effect on the actual execution of the Python program (same as for the current type hinting described in PEP 484).  All you need to do is1. include the linefrom __nonstandard__ import where_clausein your program.2a) if the program to be run is the main program, instead of running it viapython my_program.pyyou would dopython import_nonstandard.py my_programinstead, where import_nonstandard.py is in the directory "version 5" of this repository, and the relevant where_clause.py is in "version 6".2b) If instead of having it run as the main program, you would like to import it, then you would include an extra import statement:import import_nonstandardimport my_program# rest of the codeand run this program in the usual way.  By importing "import_nonstandard" first, a new import hook is created which pre-processes any modules to be imported afterwards - in this case, to remove the where clause or, as I have described in previous posts, to define new keywords or even an entirely different syntax (French Python).Note: None of the recent experiments are to be taken as serious proposals to modify Python.  Instead, they are a demonstration of what can be done (often in a surprisingly easy way)with Python as it exists today.

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


Comparing Twitter &amp;amp; Google+ engagement</title>
    <id>http://fedoraplanet.org/3/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/3/" />
    <author>
      <name>Brett Cannon</name>
    </author>
    <content type="html/text">

I was employed at Google when Google+ launched. Like many Googlers, I tried it out, loved the sharing model, and stuck with the platform. People always joked that Google+ was made up of Googlers, their family, or photographers, but I still enjoyed the engagement I had on Google+ as it typically was a bit better than other places. But after more than 4 years on Google+, is it still the best place for me to share things I find online to spread knowledge and spark conversations w/ people? Thanks to a somewhat popular blog post of mine that I shared on Google+ and Twitter at the same time, I can quantitatively look at engagement between Google+ and Twitter.

Google+

My Google+ post was shared to my Programming collection where I have 9,417 followers. Now according to my Google+ profile I have 5,982 followers, which means I have 3435 people explicitly following my Programming collection (practically all of my 5,982 followers were grandfathered into all of my collections when Google+ introduced the concept). That would suggest that I have 3,435 people who should have a high degree of interest in a blog post that people have told me was interesting and well-written.

What kind of engagement did I have with those 3,435 people (on top of whomever happens to follow me entirely and finds programming interesting)? I got 4 +1s, 1 comment, and no reshares.

Twitter

My tweet was obviously shared directly to my feed w/ no hashtags. According to my Twitter profile I have 1,390 followers, so 40% as many on Google+ just in my Programming collection, let alone all of the other people who follow all of my Google+ posts.

What kind of engagement did I get with Twitter's fraction of followers? 68 likes, 90 re-tweets, and 6 comments. And this doesn't even cover retweets from other people who directly shared the link and the corresponding interaction from those tweets. So with 40% of the followers I had 17x the appreciation of the share, I actually had re-tweets/shares, and 6x the comments.

Conclusion

It's hard to ignore the discrepancy between the two platforms in terms of engagement (I'm leaving Facebook out since I don't really use it and this is not the kind of stuff I would share on Instagram). While I still appreciate the concept of collections and circles on Google+, I can't ignore the fact that my engagement with people on Twitter in this instance was just so much better (my tweet actually got another like and reshare in the time it took for me to write this). But Twitter's length restrictions drives me nuts and has historically been why I have stayed off of Twitter in the past. I might just have to bite the bullet, though, and put up with the length restriction  if I want to engage in more constructive conversations online.

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


Let's Encrypt Tomorrow</title>
    <id>http://fedoraplanet.org/4/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/4/" />
    <author>
      <name>Mike C. Fletcher</name>
    </author>
    <content type="html/text">

Just a reminder, as of tomorrow Let's Encrypt should be in public Beta (i.e. *every* public-facing server you create from tomorrow on should have SSL-by-default).

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


can-I-haz-libfoo</title>
    <id>http://fedoraplanet.org/5/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/5/" />
    <author>
      <name>Marcos Dione</name>
    </author>
    <content type="html/text">

In my last job I had to do a complex Python script for merging several git histories
into one. I used Python because I needed to do a lot of high level stuff I was sure
bash would be a pain to use, like building trees and traversing them. My options
for managing the underlaying git repositories were two: either do an ugly hack to
execute git and parse its output; or use the ugly hack that already exists, called
GitPython. The first was not
an option, and the second meant that in some corner cases I had to rely on it just
to execute particular git invocations. It was not pleasant, but it somehow worked.

While developing ayrton I'm using
paramiko as the ssh client for implementing
semi transparent remote code execution.
The problem I have with it is that it's mostly aimed at executing commands almost
blindly, with not much interaction. It only makes sense: its main client code is
fabric, which mostly uses it in that context.
ayrton aims to have a ssh client as transparent as the original openssh client,
but bugs like this and
this are in the way.

What those two situations have in common? Well, there are two incomplete Python
libraries to emulate an existing program. At least in the case of GitPython they
have a backdoor to call git directly. My complaint is not their
incompleteness, far from it, but the fact that they have to do it from scratch.
It's because of that that they're incomplete.

Take ayrton, for instance. It's mostly an executable that serves as an interpreter for
scripts written in that language (dialect?), but it's implementation is so that the
executable itself barely handles command line options and calls a library. That
library implements everything that ayrton does for interpreting the language, to
the point where most unit tests are using ayrton library for executing ayrton
scripts. ayrton is not alone, others do similarly:
fades, and at some point all those other Python
modules like timeit or unittest.

So that's my wish for these Christmas, or Three Wise Men day[1], or my birthday next month;
I would even accept it as an Easter Egg: have all these complex pieces of software
implemented mainly as a public library (even if the API changed a lot, but that right
now should be fairly stable) and very thin frontends as executables. I wish for
libgit and libssh and their Python bindings.



[1] In my culture, kids get presents that day too.



python rants

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


PyTN Profile: Lars Lohn - Keynoter</title>
    <id>http://fedoraplanet.org/6/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/6/" />
    <author>
      <name>PyTennessee</name>
    </author>
    <content type="html/text">

And then there is the case of Lars…To look at him, you’d think he’s some  character from a biker bar on the bad side oftown.  However, speaking with him dispels that image in favor of, perhaps, some mystical wizard from the pages of Tolkien.  A moment later, though, he’s just a bumbling old man with no clue as to what mayhem all you young folks are up to on his lawn.   There is little doubt, Lars is one of the more memorable characters that you’ll encounter in your life.    With a forty year career in the software industry, Lars is an eccentric, skeptic and heretic.  Lars embraces complexity, shows no fear in the face of threading, prefers  recursion over iteration, and thinks dependency injection is the solution to  everything.  Lars believes that there are parallels between software and the basic structures of nature and mathematics.  Building on the idea that we live in a recursive universe with infinite layers of indirection, he believes softwareshould mimic the structures of the world that it models.  “Fail gracefully” is good, but “recover” is better. Lars has had a diverse career in many industries.  He’s written software in manylanguages ranging from the old workhorse Fortran, the exotic APL, the pedestrian Pascal, the sharp swords of C &amp;amp; C++, the tragedy of Java, the plucky Python and the most revered Lisp.  Ask him about working on Wall Street in a Harley T-shirt and torn jeans.  Lars’ work was the genesis of the Rogue Wave C++ database abstractions in the ‘90s.  Those libraries built “the Uncommon Rose”, a software package in the form of an online nursery specializing in roses.  Running a nursery lead to adoption of a more agile implementation language, Python.  Python lead the way to Mozilla. Lars started working with Mozilla while employed at Oregon State University Open Source Lab (OSUOSL) in '05 and moved to full time with Mozilla in '08.  Lars is the principle engineer behind the Firefox crash reporting system, Socorro.  Lars lives a yurt on organic farm in the Willamette Valley of Oregon with his partner, four cats, and eight greenhouses.  Never having understood or experienced the word “bored”, Lars hacks hardware, restores old pin ball machines, draws mazes, makes 3D printable designs and rides a noisy Harley.  

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


Managing small teams</title>
    <id>http://fedoraplanet.org/7/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/7/" />
    <author>
      <name>Tarek Ziade</name>
    </author>
    <content type="html/text">

In the past three years, I went from being a developer in a team, to a team lead,
to a engineer manager. I find my new position is very challenging because of
the size of my team, and the remote aspects (we're all remotes.)
When you manage 4/5 people, you're in that weird spot where you're not going to
spend 100% of your time doing manager stuff. So for the remaining time, the obvious
thing to do is to help out your team by putting back your developer hat.
But switching hats like this has a huge pitfall: you are the person giving
people some work to do depending on the organization priorities and you are
also helping out developing. That puts you in a position where it's
easy to fall into micromanagement: you are asking someone or a group of person
to be accountable for a task and you are placing yourself on both sides.
I don't have any magic bullet to fix this, besides managing a bigger team
where I'd spent 100% of my time on management. And I don't know if/when this
will happen because teams sizes depends on the organization priorities and
on my growth as a manager.
So for now, I am trying to set a few rules for myself:

when there's a development task, always delegate it to someone it the team and
propose your help as a reviewer. Do not lead any development task,
but try to have an impact on how things move forward, so they go into
the direction you'd like them to go as a manager.
Every technical help you are doing for your team should be done by working
under the supervision of a member of your team. You are not a developer
among other developers in your own team.
If you lead a task, it should be an isolated work that does not direcly
impact developers in the team. Like building a prototype etc.
Never ever participate in team meetings with a developer hat on. You
can give some feedback of course, but as a manager. If there
are some technical points where you can help, you should tackle them
through 1:1s. See #1

There. That's what I am trying to stick with going forward. If you have more tips
I'll take them :)
I see this challenge as an interesting puzzle to solve, and a key for me to
maximize my team's impact.
Coding was easier, damned...

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


10 Neat Python Tricks Beginners Should Know</title>
    <id>http://fedoraplanet.org/8/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/8/" />
    <author>
      <name>Codementor</name>
    </author>
    <content type="html/text">

Trick #1

Reversing a string in Python

&amp;gt;&amp;gt;&amp;gt; a =  "codementor"
&amp;gt;&amp;gt;&amp;gt; print "Reverse is",a[::-1]
Reverse is rotnemedoc


Trick #2

Transposing a Matrix
&amp;gt;&amp;gt;&amp;gt; mat = [[1, 2, 3], [4, 5, 6]]
&amp;gt;&amp;gt;&amp;gt; zip(*mat)
[(1, 4), (2, 5), (3, 6)]


Trick #3

a = [1,2,3]

Store all three values of the list in 3 new variables
&amp;gt;&amp;gt;&amp;gt; a = [1, 2, 3]
&amp;gt;&amp;gt;&amp;gt; x, y, z = a 
&amp;gt;&amp;gt;&amp;gt; x
1
&amp;gt;&amp;gt;&amp;gt; y
2
&amp;gt;&amp;gt;&amp;gt; z
3


Trick #4

a = [“Code”, “mentor”, “Python”, “Developer”] 
Create a single string from all the elements in list above.&amp;lt;/h5&amp;gt;
```python


  
    
      print “ “.join(a)
Code mentor Python Developer
```
    
  


Trick #5

list1 = [‘a’, ‘b’, ‘c’, ‘d’]

list2 = [‘p’, ‘q’, ‘r’, ‘s’]

Write a Python code to print

ap

bq

cr

ds

&amp;gt;&amp;gt;&amp;gt; for x, y in zip(list1,list2):
...    print x, y
...
a p
b q
c r
d s


Trick #6

Swap two numbers with one line of code.
&amp;gt;&amp;gt;&amp;gt; a=7
&amp;gt;&amp;gt;&amp;gt; b=5
&amp;gt;&amp;gt;&amp;gt; b, a =a, b
&amp;gt;&amp;gt;&amp;gt; a
5
&amp;gt;&amp;gt;&amp;gt; b
7


Trick #7

print “codecodecodecode mentormentormentormentormentor” without using loops
&amp;gt;&amp;gt;&amp;gt; print "code"*4+' '+"mentor"*5
codecodecodecode mentormentormentormentormentor


Trick #8

a = [[1, 2], [3, 4], [5, 6]]

Convert it to a single list without using any loops.

Output:- [1, 2, 3, 4, 5, 6]

&amp;gt;&amp;gt;&amp;gt; import itertools 
&amp;gt;&amp;gt;&amp;gt; list(itertools.chain.from_iterable(a))
[1, 2, 3, 4, 5, 6]


Trick #9

Checking if two words are anagrams

def is_anagram(word1, word2):
    """Checks whether the words are anagrams.
    word1: string
    word2: string
    returns: boolean
    """


Complete the above method to find if two words are anagrams.
python
from collections import Counter
def is_anagram(str1, str2):
     return Counter(str1) == Counter(str2)
&amp;gt;&amp;gt;&amp;gt; is_anagram('abcd','dbca')
True
&amp;gt;&amp;gt;&amp;gt; is_anagram('abcd','dbaa')
False


Trick #10.

Take a string input.

For example “1 2 3 4” and return [1, 2, 3, 4]

Remember list being returned has integers in it.
Don’t use more than one line of code.

&amp;gt;&amp;gt;&amp;gt; result = map(lambda x:int(x) ,raw_input().split())
1 2 3 4
&amp;gt;&amp;gt;&amp;gt; result
[1, 2, 3, 4]


</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


Django 1.9 released</title>
    <id>http://fedoraplanet.org/9/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/9/" />
    <author>
      <name>Django Weblog</name>
    </author>
    <content type="html/text">

After 10 and a half months of development, the Django team is happy to announce the release of Django 1.9.
As always, the release notes cover everything in-depth, but the major highlights are:

Support for performing actions after a transaction commit.
Support for password validation.
Permission mixins for class-based views.
New styling for contrib.admin.
Support for running tests in parallel.

You can get Django 1.9 from our downloads page or from the Python Package Index. The PGP key ID used for this release is Tim Graham: 1E8ABDC773EDE252.
Django 1.9 will receive fixes for security issues, data loss bugs, crashing bugs, major functionality bugs in newly-introduced features, and regressions from older versions of Django for eight months until August 2016. Fixes for security issues and data loss bugs will be provided for another eight months until April 2017.
With the release of Django 1.9, Django 1.7 has reached end-of-life. Django 1.7.11 is the final release of the 1.7 series and all users are encouraged to upgrade to Django 1.8+ as soon as possible so they can continue to receive security updates. Django 1.8 LTS will receive security updates until April 2018. Django 1.4 (the previous LTS) reached end of life on October 1, 2015. See the downloads page for a table of supported versions and the future release schedule.

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


French Python ?</title>
    <id>http://fedoraplanet.org/10/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/10/" />
    <author>
      <name>Andre Roberge</name>
    </author>
    <content type="html/text">

In two previous post, I showed how it was possible to transform some source code prior to having it executed.  My original motivation was to see how one could add a new keyword ("repeat") to use as "repeat n:" and it be equivalent to "for _ in range(n):".As part of the additional motivation for my experiment, I mentioned the following:In one of his posts to python-ideas, Terry Jan Reddy mentioned a discussion on the idle-dev list about making idle friendlier to beginners.   In one of his post, he mentioned the idea of having non-English keywords.  This idea is not new.  There already exists an unmaintained version with Chinese Keywords as well as a Lithuanian and Russion version.  Maintaining a version based on a different language for keywords is surely not something simple ... nor I think it would be desirable.  However, it might be possible to essentially achieve the same goal by using an approach I describe in the next section.Even just adding new keywords can be quite difficult.  For example, in this post, Eli Bendersky explains how one can add a new keyword to Python.  "All" you ned to do isModify the grammar to add the new keywordModify the AST generation code; this requires a knowledge of CCompile the AST into bytecodeRecompile the modified Python interpreterNot exactly for the faint of heart...I thought I should revisit the idea I had to see how difficult it might be to create a French Python syntax.  As it turned out, it was even simpler than implementing a new keyword.   In addition to the code mentioned previously, the new function needed is simply:def transform_source_code(text):    dictionary = {...}    toks = tokenize.generate_tokens(StringIO(text).readline)    result = []    for toktype, tokvalue, _, _, _ in toks:        if toktype == tokenize.NAME and tokvalue in dictionary:            result.append((toktype, dictionary[tokvalue]))        else:            result.append((toktype, tokvalue))    return tokenize.untokenize(result)where the dictionary contains the equivalent (e.g. "Vrai": "True", etc.)The one change I made from the previous version was to replace __experimental__ by __nonstandard__.For example, here's a test program:from __nonstandard__ import french_syntax de math importe pi  imprime(pi)  imprime("The first 5 odd integers are:") pour i dans intervalle(1, 11, 2):         imprime(i)  imprime("This should be false:", Vrai et Faux)  si pi == 3:         imprime("We must be in Indiana") ousi pi &amp;gt; 4:         print("Non standard Euclidean space") autrement:         print("There should be nothing about Indiana nor Euclidean space.") The code found in version 5 of this repository.  Using this approach, it would be trivial to create localized Python versions suitable to introduce absolute beginners to programming concepts.    I would not do this myself, here in Canada, but I could see the appeal in some other countries especially those where the English alphabet is not very well known by young learners.Now, if only I could figure out how to use importlib instead of imp ...

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


Python List Comprehensions: Explained Visually</title>
    <id>http://fedoraplanet.org/11/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/11/" />
    <author>
      <name>Trey Hunner</name>
    </author>
    <content type="html/text">

Sometimes a programming design pattern becomes common enough to warrant its own special syntax.  Python’s list comprehensions are a prime example of such a syntactic sugar.

List comprehensions in Python are great, but mastering them can be tricky because they don’t solve a new problem: they just provide a new syntax to solve an existing problem.

Let’s learn what list comprehensions are and how to identify when to use them.

What are list comprehensions?

List comprehensions are a tool for transforming one list (any iterable actually) into another list.  During this transformation, elements can be conditionally included in the new list and each element can be transformed as needed.

If you’re familiar with functional programming, you can think of list comprehensions as syntactic sugar for a filter followed by a map:

1
2
&amp;gt;&amp;gt;&amp;gt; doubled_odds = map(lambda n: n * 2, filter(lambda n: n % 2 == 1, numbers))
&amp;gt;&amp;gt;&amp;gt; doubled_odds = [n * 2 for n in numbers if n % 2 == 1]



If you’re not familiar with functional programming, don’t worry: I’ll explain using for loops.

From loops to comprehensions

Every list comprehension can be rewritten as a for loop but not every for loop can be rewritten as a list comprehension.

The key to understanding when to use list comprehensions is to practice identifying problems that smell like list comprehensions.

If you can rewrite your code to look just like this for loop, you can also rewrite it as a list comprehension:

1
2
3
4
new_things = []
for ITEM in old_things:
    if condition_based_on(ITEM):
        new_things.append(&amp;quot;something with &amp;quot; + ITEM)



You can rewrite the above for loop as a list comprehension like this:

1
new_things = [&amp;quot;something with &amp;quot; + ITEM for ITEM in old_things if condition_based_on(ITEM)]



List Comprehensions: The Animated Movie™

That’s great, but how did we do that?

We copy-pasted our way from a for loop to a list comprehension.



Here’s the order we copy-paste in:


Copy the variable assignment for our new empty list (line 3)
Copy the expression that we’ve been append-ing into this new list (line 6)
Copy the for loop line, excluding the final : (line 4)
Copy the if statement line, also without the : (line 5)



We’ve now copied our way from this:

1
2
3
4
5
6
numbers = [1, 2, 3, 4, 5]

doubled_odds = []
for n in numbers:
    if n % 2 == 1:
        doubled_odds.append(n * 2)



To this:

1
2
3
numbers = [1, 2, 3, 4, 5]

doubled_odds = [n * 2 for n in numbers if n % 2 == 1]



List Comprehensions: Now in Color

Let’s use colors to highlight what’s going on.


doubled_odds = []
for n in numbers:
    if n % 2 == 1:
        doubled_odds.append(n * 2)






doubled_odds = [n * 2 for n in numbers if n % 2 == 1]



We copy-paste from a for loop into a list comprehension by:


Copying the variable assignment for our new empty list
Copying the expression that we’ve been append-ing into this new list
Copying the for loop line, excluding the final :
Copying the if statement line, also without the :



Unconditional Comprehensions

But what about comprehensions that don’t have a conditional clause (that if SOMETHING part at the end)?  These loop-and-append for loops are even simpler than the loop-and-conditionally-append ones we’ve already covered.

A for loop that doesn’t have an if statement:


doubled_numbers = []
for n in numbers:
    doubled_numbers.append(n * 2)



That same code written as a comprehension:


doubled_numbers = [n * 2 for n in numbers]



Here’s the transformation animated:



We can copy-paste our way from a simple loop-and-append for loop by:


Copying the variable assignment for our new empty list (line 3)
Copying the expression that we’ve been append-ing into this new list (line 5)
Copying the for loop line, excluding the final : (line 4)



Nested Loops

What about list comprehensions with nested looping?… 😦

Here’s a for loop that flattens a matrix (a list of lists):


flattened = []
for row in matrix:
    for n in row:
        flattened.append(n)



Here’s a list comprehension that does the same thing:


flattened = [n for row in matrix for n in row]



Nested loops in list comprehensions do not read like English prose.

Note: My brain wants to write this list comprehension as:


flattened = [n for n in row for row in matrix]



But that’s not right!  I’ve mistakenly flipped the for loops here.  The correct version is the one above.

When working with nested loops in list comprehensions remember that the for clauses remain in the same order as in our original for loops.

Other Comprehensions

This same principle applies to set comprehensions and dictionary comprehensions.

Code that creates a set of all the first letters in a sequence of words:


first_letters = set()
for w in words:
    first_letters.add(w[0])



That same code written as a set comprehension:


first_letters = {w[0] for w in words}



Code that makes a new dictionary by swapping the keys and values of the original one:


flipped = {}
for key, value in original.items():
    flipped[value] = key



That same code written as a dictionary comprehension:


flipped = {value: key for key, value in original.items()}



Readability Counts

Did you find the above list comprehensions hard to read?  I often find longer list comprehensions very difficult to read when they’re written on one line.

Remember that Python allows line breaks between brackets and braces.

List comprehension

Before

1
doubled_odds = [n * 2 for n in numbers if n % 2 == 1]



After

1
2
3
4
5
doubled_odds = [
    n * 2
    for n in numbers
    if n % 2 == 1
]



Nested loops in list comprehension

Before

1
flattened = [n for row in matrix for n in row]



After

1
2
3
4
5
flattened = [
    n
    for row in matrix
    for n in row
]



Dictionary comprehension

Before

1
flipped = {value: key for key, value in original.items()}



After

1
2
3
4
flipped = {
    value: key
    for key, value in original.items()
}



Note that we are not adding line breaks arbitrarily: we’re breaking between each of the lines of code we copy-pasted to make these comprehension.  Our line breaks occur where color changes occur in the colorized versions.

Learn with me

I did a class on list comprehensions with PyLadies Remote recently.

If you’d like to watch me walk through an explanation of any of the above topics, check out the video:


list comprehensions
generator expressions
set comprehensions
dictionary comprehensions



Summary

When struggling to write a comprehension, don’t panic.  Start with a for loop first and copy-paste your way into a comprehension.

Any for loop that looks like this:


new_things = []
for ITEM in old_things:
    if condition_based_on(ITEM):
        new_things.append("something with " + ITEM)



Can be rewritten into a list comprehension like this:


new_things = ["something with " + ITEM for ITEM in old_things if condition_based_on(ITEM)]



If you can nudge a for loop until it looks like the ones above, you can rewrite it as a list comprehension.

This blog post was based on my Intro to Python class.  If you’re interested in chatting about my Python training services, drop me a line.

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


Let’s help people go to PyCon Namibia</title>
    <id>http://fedoraplanet.org/12/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/12/" />
    <author>
      <name>David MacIver</name>
    </author>
    <content type="html/text">

PyCon Namibia is coming up. I think it’s a great idea and I’m planning to go.
I’m currently somewhat budget constrained while I sort out the early days of my new business. But… I’m self-employed, right? If I want more money, I can just work more (Technically correct. The best kind of correct). So lets do that!
Of course, there are plenty of other people who want to go and are vastly more budget constrained than I am. There are travel grants, but there are a lot more people who need budget than there is budget. So if I’m helping myself go by working more, perhaps I can lend a hand with that too?
A plan emerges.
This is how it goes:

I will be going to PyCon Namibia regardless. If this plan somehow fails spectacularly, I’ll just suck up the cost.
I’ll be doing a Hypothesis and Python testing tutorial there, so if you want to attend that go buy a ticket.
At any point between now and when I physically set foot on the plane to go to Namibia (currently pencilled in at 22nd of January), my Hypothesis training courses (details below) are available for the fairly heavily discounted price of £2000 (if that sounds like a lot to you, me too. It’s a sign that neither of us should be put in charge of a training budget, because for advanced software training courses this is dirt cheap).
Of that £2000, I will be donating 50%, i.e. £1000, to the PyCon Namibia travel fund to help bring people there. I shall not further earmark it but leave it up to the judgement of the organisers as to who most needs it.

Questions
What does the training course entail?
My training courses are designed for groups of up to ten people. In theory an even number of people is better because I like to organise people to pair during it, but in practice that usually breaks down so any number up to ten people is fine.
The primary training course I am currently offering is a very hands on workshop. It’s structured around helping you test your code better using Hypothesis – there is some theory, but it is mostly going to be about your engineers working to improve the quality of your testing, with my being there to point them in the right direction, answer questions, and generally offer advice that will help them avoid false starts and dead ends.
I am in the process of developing a more theory heavy course, some material of which will be in my proposed session in Namibia, so if you are interested in something that involves a lot more theory and working through examples I provide, we can talk about that, but it’s not quite ready yet.
You can see a bit more detail on my consulting page.
Where can you do the training course?
Anywhere that I can get to, really. For now, that definitely restricts it to the UK (and, really, England). If it’s in London or within about two hours drive of Cambridge, it’s probably fine. If it involves more travel than that scheduling starts to become more complicated. If you don’t fit this description, read on to the next section for the ability to schedule a course for after the conference at a still reduced rate.
When can you do the training course?
I have a moderate amount of availability between now and PyCon Namibia. Realistically I can almost certainly fit in 5 courses between now and then, and I can probably fit in up to 10 but it will start to be tight. These will be available on a more or less first come first served basis, so getting in touch soon is a good idea.
If we simply cannot find a mutually agreeable schedule between now and the conference, I’m happy to offer the following fall back plan:
For up to ten additional clients, if you become a sponsor and donate £1500 directly to PyCon Namibia’s travel funds between now and the start of the conference, I am prepared to offer you a one day training course for only £1000 to be claimed at any mutually convenient date in 2016.
Note: Unlike the main offer, this offer is also available to people outside of the UK, but I will also require travel expenses in this case. Also if you don’t get in touch with me before donating this may turn out to no longer be an option, so get in touch first (although feel free to donate even if this is no longer available!)
How can I take you up on this offer?
Drop me an email at david@drmaciver.com with the subject line “Hypothesis training” or similar.
Are you affiliated with PyCon Namibia in some way?
Not even slightly. Until yesterday morning I wasn’t even totally sure I was going. I have talked to them a bit about this plan though.
Are you going to change any details of this plan?
I may update some of the details of how funds will be directed if things go very well and e.g. we swamp the travel fund. All funds that I’ve currently said will be going to PyCon Namibia will go to them or a charity of their choice in some capacity though.
Why are you doing this?
Because it’s a good deed, because I can, and because I’m in the right place at the right time. I like the idea of PyCon Namibia a lot, and I suddenly saw the possibility of doing a thing that helps both of us, so I decided to do it.
Have you considered this other worthy cause?
My plan is that once my business is reasonably profitable I will be donating a significant amount of its revenue to charity (probably around 10%), but plans are still TBD. For now, this is what I’m doing.
I have another question
Please either email me privately or post any additional questions in the comments, and I’ll do my best to answer them and keep this post updated.

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


Scientific software metrics with Depsy – a great new tool!</title>
    <id>http://fedoraplanet.org/13/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/13/" />
    <author>
      <name>Robin Wilson</name>
    </author>
    <content type="html/text">

As a fellow of the Software Sustainability Institute, I have talked a lot about how important software is in science, and how we need to make sure we recognise its contribution. Writing good scientific software takes a lot of work, and can have a lot of impact on the community, but it tends not to be recognised anywhere near as much as writing papers. This needs to change!
Depsy, a new project run by ImpactStory, have developed an awesome new tool which allows you to investigate impact metrics for scientific software which has been published to the Python and R package indexes (PyPI and CRAN respectively). For example, if you go to the page for Py6S, you see something like this (click to enlarge):

This gives various statistics about my Py6S library, such as number of downloads, number of citations, and the PageRank value in the dependency network. However, far more importantly it gives the percentiles for each of these too. This is particularly useful for non-computing readers who may have absolutely no idea how many downloads to expect for a scientific Python library (what counts as “good”? 20 downloads? 20,000 downloads?). Here, they can see that Py6S is at the 89th percentile for downloads, 77th for citations and 84th for dependencies, and has an overall ‘impact’ percentile of 95%.
As well as making me feel nice and warm inside, this gives me some actual numbers to show that the time I spent on Py6S hasn’t been wasted, and it has actually had an impact. You can take this further and click on my name on the bottom left, and get to my metrics page, which shows that I am at the 91st percentile for impact…again something that makes me feel good, but can also be used in job applications, etc.

I won’t tell you how long I spent browsing around various projects and people that I know, but it was far too long, when I really should have been doing something else (fixing bugs in an algorithm, I think) instead.
Anyway, I thought I’d finish this post by summarising a few of the brilliant things about Depsy, and a few of the areas that could be improved. I’ve discussed all of the latter issues with the authors, and they are very keen to continue working on Depsy and improve it – and are currently actively seeking funding to do this. So, if you happen to have lots of money, please throw it their way!
So, great things:

The percentiles. I’ve talked about this above, but they’re really great. (I think percentiles should be used a lot more in life generally, but that’s another blog post…)
Their incredibly detailed about page, which links to huge amounts of information on how every statistic is calculated
The open-source code that powers it, which allows you to check their algorithms and hack around with it (yes, I did spend a little while checking to make sure that they weren’t vulnerable to Little Bobby Tables attacks)
The responsiveness of the development team: Jason and Heather have responded to my emails quickly, and taken on board lots of my comments already.

A few things that will be improved in the future, and a few more general concerns:

Currently they try to guess whether a library is research software or not, but it seems to get a fair few things wrong. I believe they’re actively working on this.
Citation searching is a bit dodgy at the moment. For example, it shows one citation for Py6S, but actually there is a paper on Py6S which has seven citations on Google Scholar. My idea for CITATION files could help them to link up packages and papers – so that’s another reason to add a CITATION file to your project!
Not all scientific software is in Python and R, or hosted on Github, so they are hoping to expand their sources in the future.
More generally, the issue with all metrics is that they never quite manage to capture what you’re interested in. Unfortunately, metrics are a fact of life in academia – but we need to be careful that we don’t start blindly applying ‘software impact metrics’ in unsuitable situations. Still, even if these metrics do start being used stupidly, they’re definitely better than the Impact Factor (after all, we know how they’re calculated for a start!)

So, enough waffling from me: go and check out Depsy, if you find any problems then post an issue on Github – and tell your friends!

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


Black Pipe Testing: In Summary</title>
    <id>http://fedoraplanet.org/14/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/14/" />
    <author>
      <name>A. Jesse Jiryu Davis</name>
    </author>
    <content type="html/text">


Every conversation I hear about testing seems to go thus:
"Here's a useful way to test!"
"But if you only test that way, you won't catch all the bugs."
I would like us, the open source community, to move on from this conversation. Each testing method is useful for some kinds of software, and each accomplishes some goals. But none is plenipotent. There is no silver bullet.
So the next time someone proposes unit testing, please don't object: "Unit tests can't catch integration bugs." Nor, when you hear about integration tests, should you object: "Integration tests don't reveal bugs as early as unit tests." Instead, consider whether each method is being applied where appropriate, or if some other method would be better in this particular circumstance.
It's the same with this series of articles I've written about "black pipe" testing. I make no claim that my testing method is perfect, certain, and complete. Please don't replace your other tests with black pipe tests wholesale. I have merely identified a color in the spectrum that ranges between unit tests and integration tests, and named it. And I have distinguished two scenarios where I think black pipe testing is a superior way to test connected applications.
The first scenario is when your code's observable behavior is correct, even if it misbehaves at the network layer. In this case, a black pipe test can watch the wire and check that your code sends the messages you expect. I describe a case like this in Testing PyMongo As A Black Pipe: PyMongo would appear correct even if it sent outdated wire protocol messages to MongoDB. I need a black pipe test to validate that PyMongo uses the latest MongoDB wire protocol.
Second, black pipe tests can reliably test rare events, like network timeouts, hangups, and resets. These events are hard to trigger during integration testing. If you want to continuously test your code's reaction to a timeout, for example, it may not be practical to stop a network interface at exactly the moment when your test is exercising the relevant code. But a black pipe test impersonates the server and reacts predictably to each message your code sends.
Black pipe tests are a useful complement to your existing methods. If you have bad tests or untested code that falls into one of these two scenarios, I hope my articles offer you the tool you did not know you lacked.
I hope you apply this method to servers besides MongoDB. Take inspiration from MockupDB's API in Python, or the mock_server_t functions in C, but impersonate some other server: a mock PostgreSQL server, for example, could be used to test thousands of different client libraries and applications. A mock LDAP or SMTP server would be similarly useful. And if you write a RESTful HTTP server with testing methods as expressive and convenient as MockupDB's, the number of Python client libraries you could help test would be practically numberless.

Further reading:

My six-part black pipe testing series
Dan Crosta's "Good Test, Bad Test"
Nick Coghlan's "Client and Server in Python 3.5"


Image: a pipe in Montreal

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


Better tests for Redis integrations with redislite</title>
    <id>http://fedoraplanet.org/15/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/15/" />
    <author>
      <name>Obey the Testing Goat</name>
    </author>
    <content type="html/text">

A colleague and I were staring at some ugly, mocky tests for our redis integration the other day, when I remembered someone at Pycon last year showing me a cool library called redislite -- basically, a lightweight, self-contained, pip installable version of redis, that can be installed almost anywhere and run totally separately from the system redis.  (That was Dwight, who I now realise is the main author of redislite.  Yay Pycon.)
He'd said "it's great for testing", so we thought we'd give it a go.

pip installs and compiles in 20 seconds
Here's the sample usage from the docs:
&amp;gt;&amp;gt;&amp;gt; import redislite
&amp;gt;&amp;gt;&amp;gt; r = redislite.StrictRedis()
&amp;gt;&amp;gt;&amp;gt; r.set('foo', 'bar')
True
&amp;gt;&amp;gt;&amp;gt; r.get('foo')
'bar'



Couldn't be simpler!  You can initiate a lightweight version of redis just like that, have one for each test even, and throw it away at the end, without having to worry about ports, passwords, or any interaction with the system redis.
The code under test is meant to parse a web server log line, and then update some hit counts in redis.  Here's how our tests looked before:
@patch('hit_counter.redis')
def test_write_to_redis_updates_appropriate_keys(self, mock_redis):
    write_to_redis('www.nowhere.com', datetime(2013, 11, 14, 16, 54, 21, 0), 2323)

    self.assertItemsEqual(
        mock_redis.method_calls,
        [
            call.incr('count|www.nowhere.com'),
            call.incr('count|www.nowhere.com|2013'),
            call.incr('count|www.nowhere.com|2013-11'),
            call.incr('count|www.nowhere.com|2013-11-14'),
            call.incr('count|www.nowhere.com|2013-11-14 16'),
            call.incr('count|www.nowhere.com|2013-11-14 16:54'),
            call.incrby('bytes|www.nowhere.com', 2323),
            call.incrby('bytes|www.nowhere.com|2013', 2323),
            call.incrby('bytes|www.nowhere.com|2013-11', 2323),
            call.incrby('bytes|www.nowhere.com|2013-11-14', 2323),
            call.incrby('bytes|www.nowhere.com|2013-11-14 16', 2323),
            call.incrby('bytes|www.nowhere.com|2013-11-14 16:54', 2323),
        ]
    )



And here's how they look after:
class WriteToRedisTest(unittest.TestCase):

    def setUp(self):
        self.fake_redis = redislite.StrictRedis()
        self.patcher = patch('hit_counter.redis', self.fake_redis)
        self.patcher.start()

    def tearDown(self):
        self.patcher.stop()


    def test_increments_all_counts(self):
        timestamp = datetime(2013, 11, 14, 16, 54, 21, 0)
        expected_counts = [
            'count|www.nowhere.com',
            'count|www.nowhere.com|2013',
            'count|www.nowhere.com|2013-11',
            'count|www.nowhere.com|2013-11-14',
            'count|www.nowhere.com|2013-11-14 16',
            'count|www.nowhere.com|2013-11-14 16:54',
        ]
        for key in expected_counts:
            self.fake_redis.set(key, 11)

        write_to_redis('www.nowhere.com', timestamp, 2323)

        for key in expected_counts:
            self.assertEqual(self.fake_redis.get(key), '12')


    def test_increments_all_bytes(self):
        timestamp = datetime(2013, 11, 14, 16, 54, 21, 0)
        expected_bytes = [
            'bytes|www.nowhere.com',
        # etc



Look at that!


Instead of mocking the library, I'm mocking out a particular Redis instance, with a real, functioning redis that I have full control over


I now no longer need to care about exactly how I use the redis API in my code -- no need to check whether I'm calling incr or incrby, I can just set an actual value before, and check the actual value after. It allows me to obey one of the key rules of testing, "test behaviour, don't test implementation".


The approach only continued to deliver benefits.  The reason we were looking at this code was because we wanted to start setting some expiry times on keys.  As a result of using redislite, the tests for expiry came out really sane and readable:
def test_hourly_data_expires_after_one_week(self):
    timestamp = datetime(2013, 11, 14, 16, 54, 21, 0)
    write_to_redis('www.thing.com', timestamp, 123)
    ttl = int(self.fake_redis.ttl('count|www.thing.com|2013-11-14 16'))
    self.assertAlmostEqual(
        ttl,
        7 * 24 * 60 * 60,
        delta=2,
    )



Imagine that test with mocks! 
    self.assertItemsEqual(
        mock_redis.method_calls,
        [
            call.incr('count|www.thing.com'),
            call.incr('count|www.thing.com|2013'),
            # ... 
            call.incr('count|www.thing.com|2013-11-14 16'),
            call.expire('count|www.thing.com|2013-11-14 16', expected_expiry),
            # and so on



Ugh. And that's glossing over the complexities of timestamping -- the assertAlmostEqual works nicely in the redislite tests, but here I'd have to either mock out datetime, or pull all of the call instances out of .method_calls one by one...  Oh I just don't even want to think about it.
So, remember kids, friends don't let friends use mocks when there's a better alternative around.  Definitely check out redislite if you ever find yourself writing some tests for a redis integration in your own codebase.
[thanks to Nicole for prompting me to write this post]

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


#36 Python IDEs with the PyCharm team</title>
    <id>http://fedoraplanet.org/16/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/16/" />
    <author>
      <name>Talk Python to Me</name>
    </author>
    <content type="html/text">

As a software developer, what's the most important application on your computer? If your answer is Microsoft Outlook, my heart goes out to you - stay strong! But for most of us, it's probably a toss up between your web browser and code editor.&amp;lt;more&amp;gt;&amp;lt;/more&amp;gt; For editors, there are basically two camps: lightweight smart, text editors such as vim, emacs, and sublime text and heavy weight but highly functional IDEs such as PyDev and PyCharm. This week you'll meet Dmitry Trofimov who is one of the main developers behind one of my favorite editors: PyCharm.

Links from the show:
&amp;lt;div style="font-size: .85em;"&amp;gt;
	&amp;lt;b&amp;gt;JetBrains&amp;lt;/b&amp;gt;:  &amp;lt;a href='https://www.jetbrains.com/' target='_blank'&amp;gt;jetbrains.com&amp;lt;/a&amp;gt;
	&amp;lt;b&amp;gt;PyCharm&amp;lt;/b&amp;gt;:  &amp;lt;a href='https://www.jetbrains.com/pycharm/' target='_blank'&amp;gt;jetbrains.com/pycharm&amp;lt;/a&amp;gt;
	&amp;lt;b&amp;gt;9 reasons you should be using PyCharm&amp;lt;/b&amp;gt;:  &amp;lt;a href='http://bit.ly/whypycharm' target='_blank'&amp;gt;bit.ly/whypycharm&amp;lt;/a&amp;gt;
	&amp;lt;b&amp;gt;Dmitry on Twitter&amp;lt;/b&amp;gt;:  &amp;lt;a href='https://twitter.com/dmitrytrofimov' target='_blank'&amp;gt;@dmitrytrofimov&amp;lt;/a&amp;gt;
&amp;lt;/div&amp;gt;

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


November 2015 week 3 and 4 - TSF Sponsored Development</title>
    <id>http://fedoraplanet.org/17/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/17/" />
    <author>
      <name>Twisted Matrix Labs</name>
    </author>
    <content type="html/text">

This is my report for the work done in the last weeks of November as part of the 2015 Twisted Maintainer Fellowship program.We continue to have a small waiting line for the review queue. In general the initial review response time was below 24 hours, and delayed mainly due to time zones.Important changes made in these weeks:* Release of Twisted 15.5.0* Serial port support was ported to Python 3.* SSH client and server now support SHA2 HMAC.Tickets reviewed and merged#6082 - Make test_updateWithKeywords work on Python 3#6842 - Dead link in documentation of t.i._dumbwin32proc#6978 - rst markup bugs in docs#7668 - Links to Dive into Python in the testing documentation are dead#7881 - Misleading example in Deferred Intro#7944 - Typo in docs/core/howto/logger.rst#7791 - Error in options howto doc#8050 - Release Twisted 15.5#8070 - Twisted web client IPV6 DNS lookup failed#8099 - Port twisted.internet.serial to Python 3.#8101 - Malformed HTTP Header causes exception in twisted.web.http server#8102 - Malformed HTTP method causes exception in twisted.web.http server/Resource.render#8104 - Fix documentation of default thread pool size#8106 - Add Python 3.5 to our tox config.#8108 - conch: support hmac-sha2-256 and hmac-sha2-512Tickets reviewed and not merged yet#5789 - Remove usage of UserDict#6757 - SSL server endpoints don't provide a way to verify client certificates#7050 - Remove long deprecated _bwHack parameter#7460 - HTTP2 inital patch#7879 - documentation incorrectly says that Agent does not do certificate validation in Agent#7926 - TLSMemoryBIOProtocol.loseConnection does not work properly#7998 - twisted.conch.ssh.keys should be ported to Python 3#8009 - twisted.web.twcgi should be ported to Python 3#8077 - Session cookie under python3 never found#8115 - Some Twisted tests use the deprecated "assertEquals" and similar#8125 - LoopingCall.withCount with interval 0#8126 - Improvements to Twisted’s SMTP server#8127 - Support a user defined facility when using syslog#8128 - ESMTP class can't be usefully subclassed to add extensions#8129 - twisted.web.http_headers.Headers should work on bytes and UnicodeThanks to the Software Freedom Conservancy and all of the sponsors who made this possible, as well as to all the other Twisted developers who helped out by writing or reviewing code.

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


PyTN Profile: Rivkah Standig - Keynoter</title>
    <id>http://fedoraplanet.org/18/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/18/" />
    <author>
      <name>PyTennessee</name>
    </author>
    <content type="html/text">

Rivkah Standig is a software engineer at MoveOn.org. Before becoming a programmer, Rivkah trained as a linguist, speech-language pathologist, painter, and actress. She delights in exploring the intersections of all of these disciplines with the power of coding. When she’s not programming, Rivkah enjoys studying endangered language documentation, watching rugby, and planning elaborate and oddly specific parties.

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


Cyber Monday: 50% off Django book and videos</title>
    <id>http://fedoraplanet.org/19/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/19/" />
    <author>
      <name>Caktus Consulting Group</name>
    </author>
    <content type="html/text">

Are you looking for a good gift for a current or future Django developer? Check out Caktus technical director Mark Lavin's work for O'Reilly: 

Lightweight Django (book co-written with Julia Elman) 
Intermediate Django: Build modern, scalable, and maintainable web applications (videos)

Both are now 50% off at the O'Reilly site with the discount code CYBER15.

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


Anyone want a speaker?</title>
    <id>http://fedoraplanet.org/20/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/20/" />
    <author>
      <name>David MacIver</name>
    </author>
    <content type="html/text">

I’m in the process of doing a lot of speaking and putting together a lot of talks. This means I’m always up for new places to speak at. So if you’re looking for tech speakers at your meetup group, conference or company, read on.
The following are talk subjects I currently have ready to go (or could have ready to go on short notice):

Various things on property-based testing in general and Hypothesis in particular. I’ve got two talks prepared for this: “Finding more bugs with less work” and “The plural of anecdote is not test suite”
Gory details of how Conjecture works and why this is cool
“Writing libraries is terrible”. A short rant about all the social and technical problems one runs into when writing open source libraries plus some things I think might help.
“Your CI is the wrong shape”. A piece about designing your CI to fit with your developer workflow instead of spending all your time waiting on CI. Somewhat based on my empirically derived testing principles post.

I’ve done a large number of variations on the first one at this point. They’ve all gone very well, but I’m keen to try some of the others.
Also, I have plenty of other things I can speak on (if you’re at this blog you’ve probably noticed I have a few opinions to share) and haven’t turned into a talk yet, so if none of those quite fit feel free to get in touch anyway and I might have something for you.
I do have some (fairly reasonable) requirements:

If you’re a meetup group or conference, you must have a code of conduct (which I will look at before agreeing).
If you’re a paid conference, I require a free ticket if I’m speaking (I’m self-employed and on a budget until I manage to get my income variance way down from where it currently is, so this is particularly important, but I also think it’s just appropriate to not make speakers pay for tickets).
If you’re somewhere that is not easily accessible from Cambridge UK (London is fine) I’ll probably need travel and accommodation expenses (see above. A London train fare is fine, but anything more than that starts to hurt).
Half hour or longer speaking slots. I can do and have done shorter talks, but it’s just not worth it unless it’s at an event I’m going to be at anyway.
If you’re a company then I’m still happy to do a free talk, but I’m going to want to sell you training and/or consulting services, so I’ll happily trade a talk for a meeting with e.g. someone who has access to training budget.

All that sound good? Great! Do get in touch.

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


Announcing Motor 0.5 with asyncio, Python 3.5, and "async" / "await"</title>
    <id>http://fedoraplanet.org/21/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/21/" />
    <author>
      <name>A. Jesse Jiryu Davis</name>
    </author>
    <content type="html/text">


Welcome back, I hope you enjoyed Thanksgiving. I certainly did; among everything for which I give thanks this year, I am grateful for the contributions Rémi Jolin, Andrew Svetlov, and Nikolay Novik made to Motor's asyncio integration. Their help is the greatest gift any project of mine has received.
And now, it's official! Motor 0.5 is released. Install it with:
python -m pip install motor



This version of Motor is compatible with Python 2.6 through 3.5, and it can use either Tornado or asyncio. This means pip no longer automatically installs Tornado.
For a detailed description of the changes, read the beta announcement.
Enjoy!

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


PyDev of the Week: Nick Coghlan</title>
    <id>http://fedoraplanet.org/22/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/22/" />
    <author>
      <name>Mike Driscoll</name>
    </author>
    <content type="html/text">

This week we welcome Nick Coghlan (@ncoghlan_dev) as our PyDev of the Week. Nick is a core developer of the Python language. He also write a pretty intense Python blog. Let’s take some time to hear what he has to say.

Can you tell us a little about yourself (hobbies, education, etc):
By training, I’m a computer systems engineer, and my first full time job was writing digital signal processing software for the Australian Defence Force’s national high frequency radio network. I now work for Red Hat, aiming to make Fedora a better platform for building cutting edge open source applications (especially in Python!).
My main current pastimes involve helping to improve the sustainability of the Python Software Foundation and CPython core development. I’m actually working to scale back the number of different Python community activities I’m involved with in order to regain time for entirely “just for fun” activities, like playing cricket.
Why did you start using Python?
My original test software for the DSP code in my first job was a really simplistic C program that was letting far too many bugs through to the next level of integration testing. Python’s unittest module and the SWIG wrapper generator gave me everything I needed to write a new, far more sophisticated, test harness that did a much better job of ensuring the DSP software was working as intended.
What other programming languages do you know and which is your favorite?
Aside from Python, the other languages that I use regularly are C, JavaScript and POSIX shell code. I actually really like C, as it’s still the “portable assembly code” that makes modern computing possible. The main other language I’ve used professionally is C++.
There’s a much longer list of languages I’ve learned well enough to read, and I’m currently working on a blog post offering suggestions on other programming languages folks may want to consider studying as aids in understanding various aspects of the way Python works.
What projects are you working on now?
The main project I’m working on now is Fedora’s Software Component Pipeline, which aims to make it easier both to develop Fedora itself, and to develop other applications that use Fedora as the base operating system. The specific piece I’m currently building is a project called RepoFunnel, which is aimed at making it easier to mix and match components from different software repositories using the Pulp content management system.
As a member of the Fedora Environments &amp; Stacks working group, I’m also helping to consider ways in which we might redesign Fedora’s package review process to make it more incremental with multiple stages of review, rather than a single all-or-nothing review gate.
Which Python libraries are your favorite (core or 3rd party)?
As a backend focused developer, Tom Christie’s Django REST Framework is one I love for the sheer amount of knowledge regarding designing REST APIs that it captures, as well as the incredibly helpful browsable HTML version of the API it provides by default.
In the standard library, I love the fact that we ship a disassembler by default in the dis module, as I really enjoy making it easier for folks to poke around in CPython’s internals.
Is there anything else you’d like to say?
One of the best pieces of advice I ever received is “Health, relationships, career, community, in that order”, and as far as a personal priority list goes, I think it’s a pretty good one.
Python has a vibrant, resilient, global ecosystem, so we don’t want anyone to sacrifice their own interests for the benefit of the community. Unfortunately, when we’re passionate and excited about community projects, it’s really easy to overcommit ourselves, and nobody except us can see the whole picture for where our time and energy is going. If we’re feeling burned out by our community involvement, the best thing we can do is to step back and say “I can’t sustainably do this any more”. And if we suspect someone we know is burning out? We can explicitly remind them that it’s always OK to stop volunteering time and energy we don’t have to spare.
Thanks so much!

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


The Tutorial deadline is here!</title>
    <id>http://fedoraplanet.org/23/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/23/" />
    <author>
      <name>PyCon</name>
    </author>
    <content type="html/text">

Tutorial proposals for PyCon 2016 are due today. The submission form will close once it has passed midnight in every time zone. If you have dreamed of giving an in-depth 3-hour class to your fellow PyCon attendees, it is time to write up a description and get it submitted!What is a Tutorial?https://us.pycon.org/2016/speaking/tutorials/The main CFP.https://us.pycon.org/2016/speaking/The “Submit a new proposal” button is on your dashboard.https://us.pycon.org/2016/dashboard/

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


How to measure the duration of a function call or code block in python</title>
    <id>http://fedoraplanet.org/24/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/24/" />
    <author>
      <name>Lintel Technologies</name>
    </author>
    <content type="html/text">

The simple way to measure the duration of function call in python using context management.
Some times we may encounter the situation where we need to know total time taken by the function call. Here is the code which is pretty much handy and simple to measure the duration of function call  or  time taken by the function(call) in pythonimport time

class MeasureDuration:
    def __init__(self):
        self.start = None
        self.end = None

    def __enter__(self):
        self.start = time.time()
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        self.end = time.time()
        print "Total time taken: %s" % self.duration()

    def duration(self):
        return str((self.end - self.start) * 1000) + ' milliseconds'Here is how you apply the above code to get the time taken by the function call

import time

def foo():
    time.sleep(1)

with MeasureDuration() as m:
   foo()    # We can place here the multiple calls or 
        # arbitary code block to measure
 

Output would look like as follows,

Total time taken: 1001.03282928 milliseconds
 

The post How to measure the duration of a function call or code block in python appeared first on Lintel Technologies Blog.

</content>
  </entry>
  <entry xml:base="http://planetpython.org/">
    <title type="text">


A virtualenv first approach to Python projects</title>
    <id>http://fedoraplanet.org/25/</id>
    <updated>2015-12-03T07:45:52Z</updated>
    <link href="http://fedoraplanet.org/25/" />
    <author>
      <name>Amit Saha</name>
    </author>
    <content type="html/text">

I have until the last few months (of my ~4 years of working with
Python) always worked without virtualenv for all my Python
projects. Why? I think I found the whole idea of having to do the
following two steps before I work on something cumbersome:

Remember the exact virtualenv name, and then
Activate it

That said, I was very much aware that it was certainly a good thing
to do and would cause me less headaches someday. That someday finally
came, and I ran into conflicting package requirements for applications
which needed to run simultaneously. This forced me to start using
virtualenvs. I think I also found the tool which will make me  keep
using them even when I don't need to. The tool is pew.

Installation and Basics
The home page lists various options of installing pew. The most
straightforward is of course to just use pip install pew. Once you
have it installed, typing pew lists the various sub-commands, such
as new, workon, ls and others. Eac of the sub-commands is
accompanied by a summary of they will do.
So far, I have been mostly working with the above sub-commands. Here
is how we can create a new virtualenv:

$ pew new flask-graphql-demo
New python executable in flask-graphql-demo/bin/python2
Also creating executable in flask-graphql-demo/bin/python
Installing setuptools, pip...done.
Launching subshell in virtual environment. Type 'exit' or 'Ctrl+D' to return.
flask-graphql-demo $

Our virtualenv flask-graphql-demo is created and we are in it, which we can check:

$ which pip
~/.local/share/virtualenvs/flask-graphql-demo/bin/pip

We can do all our usual work now (installing other packages, running
our applications) and once done, we can simply exit and we will be
out of the virtualenv.
Now, if I want to resume work on this particular project, I can first
use pew ls to list the currently created virtualenvs:

$ pew ls
flask-graphql-demo

and then use pew workon flask-graphql-demo to start working on it
again. On Linux, pew workon also gives me all the available
virtualenvs as suggestions automatically.


Conclusion
As you may have already seen, pew has a number of other features
which should make working with virtualenvs really easy. It has
definitely made me change my approach to working on Python projects.


</content>
  </entry>
</feed>