It seems like only yesterday, but it was actually almost 10 years ago when I gave something awesome to the VMware community - the first version of the VMware stencils.

The reason I did this was because at the time - there was no decent set of VMware stencils out there - so I took the initiative and created a set. And I subsequently set out to update them over the years.
I have a small confession. The VMware Visio stencils have been the biggest driver of traffic to my blog over the years. Even till this day - I have a minimum of 5000 monthly views (and this on a post that is more than 5 years old).

And I already hear you say - there is already a number of architectural Visio icon sets available - and even an official one from AWS - you can find them here. (I assume that the graphics are going to be updated just before / after re:Invent - with the new design that they have released a few weeks ago, in the meantime - only the current one is available)

There are other tools that have online graphics as well. LucidChart, Cacoo, Creately, draw.io, Cloudcraft (the only vendor who has original graphics - the rest are all the standard AWS icons). 
If you are following some of the AWS community work - will probably have heard of Jerry Hargrove (better know as @awsgeek). He actually works at Lucidchart and is famous for his unbelievable sketch notes on AWS and their products. Not only are they beautiful, clear and sometimes even really funny, they are also very informative and extremely useful.

Jerry was also recently awarded the honor of AWS community Hero.
I mean really - these are a real work of art!!




So without further ado I present to you version 1.0 of the AWS Community Visio Stencils.

Jerry was kind enough to allow me to use his graphics and provide the AWS community with a set of graphics - that (in my opinion) are not only more appealing to the eye - but are just plain fun!!

40 icons of AWS services.

• API Gateway
• AppStream
• Athena
• Cloudfront
• CloudTrail
• CloudWatch
• Code Build
• Code Pipeline
• Comprehend
• Directory Service
• EBS
• EC2
• EFS
• Elastic Beanstalk
• ElasticCache
• ELB
• GuardDuty
• IAM
• Kinesis
• KMS
• Lambda
• Lambda Edge
• Machine Learning
• Neptune
• RDS
• Redshift
• Rekognition
• Route53
• S3
• SES
• SNS
• SQS
• Step Functions
• Storage Gateway
• VMware on AWS
• VPC
• VPC Endpoint
• WAF
• WorkSpaces
• xRay
  

All of the graphics are from Jerry's artwork.
Each of the Icons is resizable

If you so please, the blue background can be removed.

You can modify the text on each icon.

Each icon has 9 possible anchor points.

All yours to use for free, to modify, and diagram to your hearts content.

And yes - this is only the beginning...  There are over another 200 graphics and icons that I will be taking out of these sketches and converting them into usable icons for your diagramming pleasure.

v1.0 is available for download here

I would love to hear your feedback!

Update Dec. 13, 2018

Today I have released version 1.1 of the Stencils. Here is what changed.

1. New AWS Product icon - DynamoDB
2. I decided to add a few additional stencils
   
   a. People
   
   
    
   
   
   
   
   b. Icons
   
   
   
   
   
   c. Shapes and Banners
   
   
    

There comes a time in one’s life where you ask yourself, “Is this it? Is this all I am doing? Is this all I want to do?”

There are people who love their job, I do. I get to deal with technology all day, every day and at all hours of the day. I learn new things - all the time. I solve problems and sometimes I even amaze myself (and others) at what we accomplish and how we actually manage to do what others said could not be done.

I have a blog, which has exceeded more that I ever thought was possible

I have my name of two different books, I have presented at international conferences. I have done things that again I never thought would happen these past 10 years - but yet they have - and I have enjoyed every moment of it.

But about 6 months ago I came to a realization that as much as I love what I do, as much as I am grateful for my wonderful family and the time that I can spend with them, that I needed something else - something that was not technology, something that was not family, just something else.

I posted a while back - this on Twitter

Today I start something which is completely not technology related and totally out of my comfort zone, which actually terrifies me....

— Maish Saidel-Keesing (@maishsk) November 23, 2016

Approximately six month ago I enrolled in an “Emergency Medical Technicians and Ambulance Drivers” course through Magen David Adom here in Israel. I saw an ad in my local community newsletter that they were looking for additional ambulance drivers to volunteer. I decided to give it a chance

As a side note. A bit about the emergency medicine here in Israel.

Unfortunately I happen to live in a country that is no stranger to terror attacks, bombings, and other kinds of ‘unwanted’ activity that happens almost on a daily basis. My home town - is also no stranger to any and all of the above. A big part of this huge medical ‘enterprise’ relies on volunteers and donations, last year alone an astounding amount of 1,500,000 hours were filled by volunteers, both adults and teenagers alike.

I had no previous medical experience - none was needed - and I embarked on a 6 month long course, investing 10 hours every week - to learn how to help others in their worst times.

During this course we learned many things. 30 people from my local area spent time away from their families, from work, from other activities for 6 months to go through the course. All of them with one thing in common. They wanted to give - to give back to their community.

We learned a lot.

How to open an IV (which was not always successful)

We learned how to interact with the fire department during different trauma incidents.

We even leaned how to treat people during a Hazardous materials spill.

And yesterday we graduated.

Now before you get any funny ideas..

No - I am not quitting my job.
I am not leaving technology.
I love what I do and I will continue to do so.

I am just adding something else to my weekly/monthly schedule, that is 100% about giving to others.
(Of course there is some self benefit here (indirect) - by deriving personal satisfaction and personal fulfillment from helping others)

I think we need to challenge ourselves on a regular basis - that is the only way we can continue to grow, continue to help others grow, and contribute not only to your employer - not only to those in your immediate family - but to humanity as a whole.

I know that some will say - I have no time, I can’t do this.

To that I would like to say - time is what you make of it. Yes I am guilty as well of sometimes saying that there is not enough time in the day - to do what I want - I always have a backlog - I am too busy. All of that is sometimes true - but only by prioritizing what is important to you can you actually do what you want.

For me - Work is important. Family is important. Helping others is important. There will be times that one will take precedent over the other, that is life. It is up to you decide how to divide your time, allocate your focus and when each part should receive your time. Yes I will sometimes be doing a night shift - and then go directly the next morning to work. I will sometimes take of a day of work - to go an spend 8 hours answering emergency calls, and helping those when they need it the most, and yes I will sometimes be spending an 8 hour shift after work - at the expense of my family time.

So what is my point in this post? I don’t really know - I guess more of a way for me to share what I went through - and why I did it. It feels to me to as the right thing to do - not only for the benefit of those around me - but also for my own inner self.

This journey has helped me - in many ways. Challenging myself, doing something that is completely out of my comfort zone has helped me grow.

If you would like leave a thought, a comment, or share a story of your own - please do so in the comments below.

A short while back I tweeted the following:

Has hell frozen over? There is actual talk about prioritizing stability over landing new features. Times are a changin' #OpenStack

— Maish Saidel-Keesing (@maishsk) November 5, 2015

This was a result of me reading the minutes of the OpenStack Technical committee from November 3rd, 2015 (full log is here)

What pleasantly surprises me is that this might finally becoming a viable option.

Let me first go into the background of my trail of thoughts.
I really enjoy working with OpenStack, but I also really hate working with OpenStack. A good old love/hate relationship.

There are amazing things about this community, the way we work, and the software we produce (just to name two).

On the other hand there are really bad things about this community, namely – the way we work, and the software we produce.

One might say that is an oxymoron (I am not calling anyone stupid though). But yes it is true. The OpenStack community produces amazing things – or at least that is until someone (let’s call them an Operator) tries to actually use this in a production environment, and then they find out until it is completely and totally, not ready, in any way for production use.

So this Operator tries to raise his concerns, why this is not useable, these are valid concerns and maybe these should be fixed. But unfortunately they have no way of actually getting this done, because – the feedback loop is completely broken. Operators have no way of getting that information back in. The community has no interest in opening up a new conduit into the developer community – because they are fixated on working in a specific way.

I must stress and honestly say, that this was the case up until approximately a year ago. Since then the OpenStack community has embarked on a number of initiatives that are making this a much easier process, and we are actually seeing some change (see the title of this post).

For me the question actually is – what sparked this change? Up until now I was under the impression that the OpenStack community (and I mean the developers) was of the opinion that they are driving the requirements and development goals, but it seems as of late – this could be shifting.

To me this is going to have a significant effect of what OpenStack is, and how it moves forward.

For better and for worse. Time will tell.

What do you all think? Please feel free to leave your thoughts and comments below.

As of late I have been thinking long and hard about if I can in some way contribute in a more efficient way into the OpenStack community.

Almost all of my focus today is on OpenStack, on its architecture and how to deploy certain solutions on top such an infrastructure.

What is the Technical Committee?

It is a group of 13 elected people by the OpenStack ATC’s (Active Technical contributors – a.k.a the people that are actively contributing code to the projects over the last year). There are seven spots up for election for this term, in addition to the six TC members that were chosen 6 months ago for a term of one year.

The TC’s Mission is defined as follows:

The Technical Committee (“TC”) is tasked with providing the technical leadership for OpenStack as a whole (all official projects, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality...), decides on issues affecting multiple projects, forms an ultimate appeals board for technical decisions, and generally has technical oversight over all of OpenStack.

On Thursday I decided to take the plunge. Here is the email where I announced my candidacy.

This is not a paid job, if anything it more of a “second” part-time job – a voluntary part-time job. There are meetings, email discussions on a regular basis.

There are a number of reasons that I am running for a spot on the TC.

Diversity

In my post The OpenStack Elections - Another Look, I noted that operators were not chosen to for the board. This is something that I think is lacking in the OpenStack community today. The influence that the people who are actually using and deploying the software is minimal if at all. The influence they have is mostly after the fact (at best) and not much of an input of what they would like to have put into the product.

I am hoping to bring in a new perspective to the TC, to help  them understand the needs of those who actually deploy the software and have to deal with it day in and day out. There are valid pain points that they have, and in my honest opinion they feel they are not being heard or not being taken into consideration, at least not enough in their eyes.

Acceptance of others

The people who vote are only those who contribute code. Those who have committed a patch to the OpenStack code repositories. That is the definition of an ATC.

It is not easy to get a patch committed. Not at all (at least that is my opinion). You have to learn how to use the tools that the OpenStack community has in place. That takes time. I tried to ease the process with a Docker container to help you along. But even with that, it still seems (to me) that to get into this group of contributors takes time.

It is understandable. There is a standard of doing things (and rightfully so) so the chances of you getting your change accepted the first time are slim, for a number of reasons that I will not go into in this post.

I think that the definition of contributor should be expanded and not only limited to a those who write the code. There are a number of other ways to contribute.

I know that this will not be an easy “battle to win”. I am essentially asking the people to relinquish the way they have been doing things for the past 5 years and allow those who are not developers, those who do not write the code, to steer the technical direction of OpenStack.

I do think this will be in the best interest of everyone to extend the reach of OpenStack community, to branch out.

More information on the actual election that will run until April 30th can be found here. If you are one of the approximate 1,800 people who is an ATC, you should have received a ballot for voting.

It will be interesting to see the results which should be out in a few days.

As always your thoughts and comments are appreciated, please feel free to leave them below.

The Board of directors and the bylaws were approved. Summary posts can be found here (2015 Individual Director Election results) and here (Bylaws amendments approved).

Individual Directors

• Tim Bell
• Russell Bryant
• Alex Freedland
• Rob Hirschfeld
• Vishvananda Ishaya
• Kavit Munshi
• Egle Sigler
• Monty Taylor

The voting numbers can be found here.

Congratulations to all the new and re-elected board members. Well deserved!

I have a few things I would like to add about the data that was presented – and my thoughts.

1. Tim Bell 

Tim received the highest number of votes. CERN is a huge OpenStack user and was showcased at the summit in Paris. He is one of only 3 the board members that are not officially affiliated with a vendor directly involved in OpenStack. I see this as a big vote of confidence by the members of the foundation – that are interested in seeing more representation from non-affiliated members. Something I personally would like to see as well.

2. Participation Numbers

Only just over 16% of the members voted in the election. That to me seems to be very low. and I would like to address the OpenStack community to ask why this is so? This is actually something the Board and Foundation should also be actively looking into as well (perhaps they already are).

• Is it because people are not interested in participating?
• Is it because the importance of the process was not made clear enough?
• People did not find the candidates suitable?

More people actually voted for the amendment changes that in the election itself – which I find quite strange. They were already on the page and did not bother to vote for any of the candidates.

3. Operators were not chosen

Neither Jesse Proudman and Randy Bias were voted in – both seemed to me that they were very vocal in their campaign as to why they wanted to get on the board – and that was to bring a change into the way OpenStack is currently “run”. I do personally think this is pity – because I would have liked to see more representation from the Operator standpoint, something which I still feel is still lacking in the OpenStack community.

4. Participation in Amendment changes

The quorum was achieved – but only by 315 votes. My previous post The OpenStack Foundation – 2015 Individual Director Election – spoke about how I see this change as a problematic one. I personally do not think that the quorum would have been reached – if it was not for the “aggressive” marketing campaign that the Foundation embarked upon in order to reach this quorum. Without the countless number of posts from Board members, Foundation members (myself included) and anyone that cared about this election - on their blogs, social media and everywhere that was possible. Jonathan Bryce even promised to remove his beard to achieve this goal..

If we hit quorum in time, @jbryce will shave his beard! If you haven't voted, vote NOW! pic.twitter.com/ys0g3Q60XS

— OpenStack (@OpenStack) January 16, 2015

And he did!

@jbryce's beard is gone! If you haven't voted, you have 5 MINUTES & soon we'll post the 2015 election results pic.twitter.com/ATFdOe5pQX

— OpenStack (@OpenStack) January 16, 2015

A huge effort indeed, from the foundation and the community at large – but my question is..

How long will it be until it is needed again?

Yes the quorum needed is now officially only 10% (instead of 25%) but I do foresee the day that even that will not be reached (and that will not be too far in the future). That is why I think the change should have been to remove the quorum all together.

5. People were not happy with the change in the quorum

On both the first two amendments, the approval rate was 93-95% – almost everyone agreed. Changing the quorum – only had 80% of the people that approved. Of course that is still a majority and perfectly valid and acceptable as a decision, but still it is interesting to see that more people were not happy with the change.

It would be interesting to know if it was the lowering of the percentage to 10% or was it that the proposed change should have been to remove the quorum altogether. I personally voted against this change because I think that the quorum should be removed completely and not lowered to 10%.

I am very pleased that the changes were made – because it allows OpenStack to continue to grow, but I do think that planning should start now – for when the changes made in these amendments will not suffice and need to be changed again.

If you are willing to share - I would be interested in hearing your thoughts about the points above. Please feel free to leave them in the comments below.

I would like to add one or two more points points to my previous post - An Open Letter to the OpenStack Foundation.

1. I used Ceilometer as an example, and only as an example. I am more than sure that there are perfectly valid reasons to have chosen MongoDB instead of MySQL. I have no doubt. But doing so this still introduces more complexity.
2. Paul Richards left a comment – and because of his example – I think this just made thoughts even clearer.
   
   "The point is to use the right tool for the job. Don't use pliers when you need to use a wrench".
   
   I completely agree with that. I “stole” his example and used it to further emphasize my point.
   
   Of course every tool has to fit the right job, but to steal your analogy (forgive me), each group thinks that their tool is the right one. And over time - instead of walking around with only a pliers and a wrench you now need a big toolbox with a hammer, a saw, 15 different screwdriver bits, a cutters, duct tape, wire, a wrench, a pliers and so on and so on.

   To continue the analogy - I would have like to see the TC either change the bolt - whether now or in the future - that it will become acceptable for both tasks with one tool. Or alternatively create a tool that can be used both as a wrench and as a pliers.

   That is the job of the TC. But I personally feel that since the work being done on the overall architecture, a holistic OpenStack Product architecture, is lacking - here is where the biggest potential failure could occur.

   I already see it breaking apart - with different HA models, different scaling models for the different components. And it is only going to get worse.

My toolbox becometh heavy.

I have recently started to regularly follow the mailing lists and the conversations are quite interesting.

It is quite evident that that OpenStack is starting to go through growing pains. It was quite evident as well from OpenStack Silicon Valley 2014 that was held yesterday.

OpenStack has grown from a minimal amount – where most of the developers knew each other personally, knew each others phone numbers, a good personal community – the way it should be. But as all good things, like all successful thing, it grows. This is what OpenStack looks like today.

Current OpenStack programs are listed below:

• OpenStack Compute (code-name Nova) - integrated project since Austin release
• OpenStack Networking (code-name Neutron) - integrated project since Folsom release
• OpenStack Object Storage (code-name Swift) - integrated project since Austin release
• OpenStack Block Storage (code-name Cinder) - integrated project since Folsom release
• OpenStack Identity (code-name Keystone) - integrated project since Essex release
• OpenStack Image Service (code-name Glance) - integrated project since Bexar release
• OpenStack Dashboard (code-name Horizon) - integrated project since Essex release
• OpenStack Telemetry (code-name Ceilometer) - integrated project since the Havana release
• OpenStack Orchestration (code-name Heat) - integrated project since the Havana release
• OpenStack Database (code-name Trove) - integrated project since the Icehouse release

New capabilities under development for Juno and beyond:

• Bare Metal (Ironic)
• Queue Service (Marconi)
• Data Processing (Sahara)

These are the core components. I do not think that I am exaggerating if I was to say that there are at least another 30 projects or Github repositories either on the OpenStack repo or the Stackforge repo, and a good portion of them are actively being developed.

Ideally each and every project should be independent from the other. This of course has its upside but also problems as well.

Let’s take an example.

Most of the core components use a central database, typically MySQL. Keystone, Neutron, Glance and so on. You could install a database server for each and every component – but that would probably be major overkill, so usually what will happen is you create different tables on the same database server for each component. This now becomes a shared dependency for all the components now using that Database server. The larger the number of components use it, the more things that need to be considered. It has to be made highly available, the MySQL queries of a single component should not have any major effect on any other component, and so on and so forth.

So you would think that if most components have decided on using the same database then we should do the same for all of the components? That would be a logical assumption. No need to over complicate things.

Along comes Ceilometer. I will not go into the reasons why, but it uses MongoDB, not MySQL. That just created a complication. I now need to know how to manage another database, back it up, replicate it, and make it highly available. In addition to MySQL.

I have seen this many times, my organization is as guilty as any other for doing things like this. A development group starts working on a product and look for what is the easiest way for them to deliver their solution. Sometimes a solution is chosen because it is a “hot technology” and other times, because the standard “just doesn’t cut it”.

(As a side note – a whole other discussion could be held here, is adhering to standards the right way – even if it is more difficult or takes longer, or get the job done in the best and fastest way possible – ideally it should be a balance of the two – IMHO)

Without clear direction from the product leadership, without a proper standard – things can go wrong very quickly.

That is how I came across a product (with about 30 components) that had 6 different database technologies:

• Cassandra
• Oracle
• CouchDB
• MySQL
• MongoDB
• Derby

That is

1. 6 different connection strings
2. 6 different database clients
3. 6 different backup procedures
4. 6 different High availability models

And so on and so on…

Is this a bad thing? Depends who you would ask. The people who developed it – they are happy – because they got the job done, product works and they did not create a dependency.

For those who have to deploy, manage, troubleshoot and support this product – THIS IS A NIGHTMARE! for obvious reasons, some of them mentioned above.

I think that the same is happening in OpenStack. The proliferation of projects, the number of developers and just the sheer size of the solution is becoming very hard to manage. Goals of one projects do not necessarily align with that of other projects, and cross project collaboration is not the “best” at the moment between the projects.

Randy Bias said yesterday in his talk at OpenStackSV (not an exact quote):

The problem  is that OpenStack does not currently have a unifying vision or product strategy. With the growth in programs, OpenStack’s more consistent mission starts to be degraded and less meaning around OpenStack occurs.

Each program team tends to have their own view of what OpenStack is. This does not mean there needs to be a dictator in OpenStack, but there does need to be product leadership.

(Source – vElemental)

Adrian Ionel also raised some thought yesterday on the subject.

The general developer does not care about things below or around the application like monitoring software, storage, network, or the hypervisor. They care about API quality and ease of use, feature velocity (not about OpenStack plumbing), and portability (devs want to write things once). Is OpenStack too intrinsic and poorly focused? Are infrastructure vendors moving focus away from critical areas?

In conclusion, he believes that there are some tangible things that can be done.
– Focus on API (awesome, well documented, easy to use, consistent, backwards compatible)
– Invest in ease of use vs flexbile plumbing (could have too many options)
– Don’t move up stack partner instead (LB, DBaaS, etc)
– Reshape upstream engineering to foster open competition inside OpenStack projects (engineering come up with solutions and compete while staying in framework and let market forces choose) vs central planning

(Source – vElemental)

I am not sure I agree with everything that Adrian said, especially not the part about competition. Yes this does produce better products in the end – due to the competition, but it also generates a lot of work (and lines of code) that will probably go down the drain in the end. I do not think that the OpenStack Community is currently in the position to allow themselves that luxury. Code reviews and code fixes are not being completed in the fastest time possible. Added to that extra code in two competing projects for the same purpose will only emphasize this point.

One last thing. The OpenStack WTE (Win the Enterprise) initiative is something that should have been kicked off 2 years ago.

No matter how good the product is – if people cannot use it or it does not provide the functionality that people need, it will not be adopted.

There are things, basic things that the Enterprise needs today, and have been asking for a number of years and can get them today in competing products.

I am not saying that OpenStack has to cater for every single kind of workload, for every application, for every single scenario - not at all. But the vision, the direction has to be there. Lay down the basic foundation of what OpenStack is going after, when you think it will happen, and more importantly what will not be supported or worked on in the upcoming future.

The feeling that I have (and I am not the only one) is that each project is doing what is best for them – and not necessarily what is best for OpenStack.

The Technical Committee’s charter:

The OpenStack Technical Committee provides technical leadership for OpenStack as a whole. Responsibilities include enforcing OpenStack ideals (such as Openness, Transparency, Commonality, Integration and Quality), deciding on issues that impact multiple programs, providing an ultimate appeals board for technical decisions and general oversight. It is a fully-elected Committee that represents the contributors to the project, and more details about membership and programs may be found in its charter.

I think at the upcoming Summit this is going to be a hot discussion topic. The important thing is that it should be an open discussion, and I think taking into consideration not only the development part of the community – but also the User and operators as well.

As always I would be happy to help out in any way I can.

It was a great event. They were expecting 300+ people at the event, and almost 500 people were there - it was really full - but not crowded.

Slide Decks from the whole day can be found here.

The slides from my session are embedded below, and I would like to add a few words to expand on the content.

OpenStack is an amazing community - very different from the VMware one I am so acquainted with - and yet very similar in many ways.

But I will iterate what I said in my session. If you are looking for a 1 to 1 comparison between your current virtual Infrastructure - and for arguments sake - let's say it a VMware one - you will not find a compatible solution or even an easy migration from one product to the other.

OpenStack is a cloud platform, it can be deployed on-premises (did you notice I did not fall into the semantics trap there) but it is a cloud platform. That means that will be a part of your current application infrastructure that will not run well on OpenStack - due to the nature of these applications - they were never designed for the cloud. They rely heavily on a sound and robust infrastructure below - which is something you cannot assume (or maybe should not assume) to have with OpenStack.

A few nuggets from the day - and quotes that I think are worth sharing.

Believe me it works, I tested it yesterday :) #openstackIL

— Maish Saidel-Keesing (@maishsk) June 2, 2014

The best advice so far at #openstackil from @markmc_ -JFDI (just fecking do it, in Irish)

— Uri Cohen (@uri1803) June 2, 2014

@maishsk Thank you for an excellent session @OpenStackIL ! pic.twitter.com/zKAYwnmpAW

— Rotem Agmon (@RotemAgmon) June 2, 2014

The Gi(f)t that keeps on Giving #git #OpenStackIL some words of wisdom from @markmc_

— Maish Saidel-Keesing (@maishsk) June 2, 2014

Amazing panoramic picture by @erezcarmel at #OpenStack #Israel with @openstackil pic.twitter.com/DQDTe2juLE

— Sharone Zitzman (@shar1z) June 2, 2014

Today @OpenStackIL .. ~500 attendees ..every year it is growing just like the #cloud #OpenStack

— Ofir Nachmani (@IAmOnDemand) June 2, 2014

This was not widely announced, so I guess that many of you do not know that since the upgrade that was performed on the VMware Community Forums (VMTN) there is now support for mobile devices
(such as Android and iPhone/iPad).

This is what it looks like through a regular tablet browser (Android with Chrome in my case). With a tablet this is pretty much ok, but from a phone the forums are pretty much unusable.

Here is a quick how-to on how you go about allowing mobile devices access to your account.

From a web browser - go to the preferences on your VMware Communities account.

And choose the new Mobile Tab

Give your device a name and Get Activation Code

You will presented with a QR code that you can scan and an activation code number.

Scan the code which will take you to https://vmware.jive-mobile.com where you will already have the activation code in the link.

Now with the new interface.. Click on the login button.

Click on Register.

And now you will be logged with your credentials, with access to your recent activity on the forums.

I think this is great improvement and makes the forums a lot easier to use on the go.

I would like to give a big shout out to Corey Romero (@vCommunityGuy) the Community Manager, for all the great work and planning that was put into the upgrade, and all the great day-to-day work he does for the community.

Thanks Corey!!