Re: [openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?

2017-10-19 Thread Adam Lawson
"Right, so we all agree that what we *don't* want is TC candidates saying
"I'm here to represent the interests of user community X against those of
evil user community Y", all of the X users voting for X candidates and not
Y candidates, and then the elected X members voting to block anything that
only benefits Y, and vice-versa."

Interestingly (and without wanting to derail the overall subject) but this
is precisely what is done by a certain individuals seeking a seat on the
board of directors. And the funny thing is that while the board of
directors is not about representing one bloc of geography, campaigning on
that issue is very effective. The tactic is gratuitous but I guess some
people highly prioritize board membership as an achievement rather than a
service to the community.

/soapbox

//adam

On Oct 18, 2017 11:11 AM, "Zane Bitter"  wrote:

> On 17/10/17 14:16, Doug Hellmann wrote:
>
>> Excerpts from Zane Bitter's message of 2017-10-16 18:10:20 -0400:
>>
>>> On 14/10/17 11:47, Doug Hellmann wrote:
>>>
 Even the rewritten question can be answered
 legitimately using several different personas by people with a bit
 of experience.  I have worked at a public cloud provider and two
 distributors with a wide range of customers, and I use OpenStack
 clouds myself. I hope that all of that background feeds into my
 contributions.

>>>
>>> Yes, that's great. I think most people would agree that there's a
>>> threshold somewhere between 'several' and 'infinity' beyond which we've
>>> crossed over into platitudes though.
>>>
>>
>> Maybe. On the other hand, TC members aren't elected to represent
>> specific constituencies, so there's something to be said for taking each
>> case as it comes and considering the users impacted by that case.
>>
>
> Right, so we all agree that what we *don't* want is TC candidates saying
> "I'm here to represent the interests of user community X against those of
> evil user community Y", all of the X users voting for X candidates and not
> Y candidates, and then the elected X members voting to block anything that
> only benefits Y, and vice-versa. Obviously every step of that process is an
> unmitigated disaster.
>
> So of course each TC member should consider the all of the users impacted
> by any decision on a case-by-case basis. However, even if we're only
> thinking purely about reactive decision-making, it's still often not easy
> to know *which* users are impacted by any particular decision unless you
> have someone in the room who has a deep familiarity with that use case.
> That's why I'd like to see candidates saying something like "I spend a lot
> of time thinking about user community X and if anything came up that
> affected their use cases I'm pretty sure I'd spot it". So that I can vote
> to optimise the diversity of Xs represented, where X might be e.g. web
> developers, devops teams, scientific researchers, vSphere migrants,
> multi-cloud users, NFV, the next Facebook/Twitter/Snapchat/Netflix,
> mobile app or IoT backend developers, kubernetes users, or something I
> haven't even thought of.
>
> Possible tangent: I've always enjoyed this article (about the Sapir-Whorf
> hypothesis): http://www.nytimes.com/2010/08/29/magazine/29language-t.html
> tl;dr Anybody can think about anything, regardless of the language they
> speak (i.e. Sapir-Whorf is wrong). But there are things in every language
> that you can't *not* think about, and they're different for different
> languages.
>
> I want to maximise the set of things the TC, collectively, can't not think
> about.
>
> Suffice to say that nobody should take my example here as anything more
>>> than a rationale for the importance of user-centred design.
>>>
>>
>> How much "design" do you think the TC is doing as a governance group?
>>
>
> It varies between different levels of abstraction.
>
> At the code level, none.
>
> At the level of setting the broad technical direction of the project, not
> as much as I'd like. But y'all did pass https://governance.openstack.o
> rg/tc/resolutions/20170317-cloud-applications-mission.html for me
> (thanks!) so definitely not nothing. There are other less-directly-relevant
> examples like adding etcd to the list of base services too.
>
> At the level of deciding what projects OpenStack consists of, and
> therefore what sort of cloud you can build with it (that is to say, what
> you can _use_ it for)... that's _entirely_ within the TC's purview.
>
> At an even higher level of abstraction, deciding what OpenStack is and
> what the Foundation is for, the TC has at least a significant role in
> giving input to the board and delegated authority to make decisions in some
> areas. Notably, discussions at this level often occur face-to-face at
> TC-only events, or at board meetings where non-members aren't entitled to
> speak, and which few people can and even fewer people do attend. (I've
> given up a few Sunday afternoons before OpenStack Summits 

Re: [openstack-dev] [ptg] Simplification in OpenStack

2017-09-25 Thread Adam Lawson
Hey Jay,
I think a GUI with a default config is a good start. Much would need to
happen to enable that of course but that's where my mind goes. Any talk
about 'default' kind of infringes on what we've all strived to embrace; a
cloud architecture without bakes in assumptions. A default-anything need
not mean other options are not available - only that a default gets them
started. I would never ever agree to a default that consists of
KVM+Contrail+NetApp. Something neutral would be great- easier said than
done of course.

Samuel,
Default configuration as I envision it != "Promoting a single solution". I
really hope a working default install would allow new users to get started
with OpeStack without *promoting* anything. OpenStack lacking a default
install results in an unfriendly deployment exercise. I know for a fact the
entire community at webhostingtalk.com ignores OS for the most part because
of how hard it is to deploy. They use Fuel or other third-party solutions
because we as a OS community continue to fail to acknowledge the importance
of an easier of implementation. Imagine thousands of hosting providers
deploying OpenStack because we made it easy. That is money in the bank
IMHO. I totally get the thinking about avoiding the term default for the
reasons you provided but giving users a starting point does not necessarily
mean we're trying to get them to adopt that as their final design. Giving
them a starting point must take precedence over not giving them any
starting point.

Jonathan,
"I'm not going to adopt something new that requires a new parallel management
tool to what I use." I would hope not! :) I don't mean having a tool means
the tool is *required*. Only that a user-friendly deployment tool is
*available*. Isn't that better than giving them nothing at all?

//adam


*Adam Lawson*

Principal Architect
Office: +1-916-794-5706

On Mon, Sep 25, 2017 at 5:27 PM, Samuel Cassiba <s...@cassiba.com> wrote:

>
> > On Sep 25, 2017, at 16:52, Clint Byrum <cl...@fewbar.com> wrote:
> >
> > Excerpts from Jonathan D. Proulx's message of 2017-09-25 11:18:51 -0400:
> >> On Sat, Sep 23, 2017 at 12:05:38AM -0700, Adam Lawson wrote:
> >>
> >> :Lastly, I do think GUI's make deployments easier and because of that, I
> >> :feel they're critical. There is more than one vendor whose built and
> >> :distributes a free GUI to ease OpenStack deployment and management.
> That's
> >> :a good start but those are the opinions of a specific vendor - not he
> OS
> >> :community. I have always been a big believer in a default cloud
> >> :configuration to ease the shock of having so many options for
> everything. I
> >> :have a feeling however our commercial community will struggle with
> >> :accepting any method/project other than their own as being part a
> default
> >> :config. That will be a tough one to crack.
> >>
> >> Different people have differnt needs, so this is not meant to
> >> contradict Adam.
> >>
> >> But :)
> >>
> >> Any unique deployment tool would be of no value to me as OpenStack (or
> >> anyother infrastructure component) needs to fit into my environment.
> >> I'm not going to adopt something new that requires a new parallel
> >> management tool to what I use.
> >>
> >
> > You already have that if you run OpenStack.
> >
> > The majority of development testing and gate testing happens via
> > Devstack. A parallel management tool to what most people use to actually
> > operate OpenStack.
> >
> >> I think focusing on the existing configuration management projects it
> >> the way to go. Getting Ansible/Puppet/Chef/etc.. to support a well
> >> know set of "constellations" in an opinionated would make deployment
> >> easy (for most people who are using one of those already) and ,
> >> ussuming the opionions are the same :) make consumption easier as
> >> well.
> >>
> >> As an example when I started using OpenStack (Essex) we  had recently
> >> switch to Ubuntu as our Linux platform and Pupept as our config
> >> management. Ubuntu had a "one click MAAS install of OpenStack" which
> >> was impossible as it made all sorts of assumptions about our
> >> environment and wanted controll of most of them so it could provide a
> >> full deployemnt solution.  Puppet had a good integrated example config
> >> where I plugged in some local choices and and used existing deploy
> >> methodologies.
> >>
> >> I fought with MAAS's "simple" install for a week.  When I gave up and
> >> went with Puppet I had live users on a substantial (for 

Re: [openstack-dev] [ptg] Simplification in OpenStack

2017-09-23 Thread Adam Lawson
Quick note (started quick anyway) since I haven't been as active on this
list as I have in the past.

Two things:

   1. Great topic and addresses a historical, persistent well-known problem
   with OpenStack - complexity. Technology is useless if it's so complex new
   organizations can't get it to work easily or reliably.

   2. I'm gonna call it as I'm seeing it: it makes me sick to read
   statements/replies by some members taking the time to itemize every single
   suggestion by another member to simplify OpenStack with one snarky remark
   after another. Thankfully (hopefully?) the influence of those individuals
   will lessen over time. It's literally poisonous to read and holds no value.

Okay aside from that, as an OpenStack architect now increasing my focus on
AWS/GCP as well as OpenStack, I would suggest there are two key areas with
OpenStack that desperately need to be simplified: the architecture and the
implementation. I never hear people say the architecture is too complex so
while that can see some improvements, what I hear over and over and over
again is how hard it is to deploy OpenStack on more than one machine
quickly and easily. I think that has to be the priority. Until deployments
are easy and stable and 'just work', that's a missed opportunity and
OpenStack will continue to scare away potential new users -- like we need
any more of that. OpenStack is deep in the trough of disillusionment (my
perception) whether others recognize it or not so anything that makes
OpenStack adoption easier should be our Numero Uno goal.

Lastly, I do think GUI's make deployments easier and because of that, I
feel they're critical. There is more than one vendor whose built and
distributes a free GUI to ease OpenStack deployment and management. That's
a good start but those are the opinions of a specific vendor - not he OS
community. I have always been a big believer in a default cloud
configuration to ease the shock of having so many options for everything. I
have a feeling however our commercial community will struggle with
accepting any method/project other than their own as being part a default
config. That will be a tough one to crack.

That's what I got tonight. hve a great weekend.

//adam


*Adam Lawson*

Principal Architect
Office: +1-916-794-5706

On Thu, Sep 21, 2017 at 11:23 AM, Clint Byrum <cl...@fewbar.com> wrote:

> Excerpts from Jeremy Stanley's message of 2017-09-21 16:17:00 +:
> > On 2017-09-20 17:39:38 -0700 (-0700), Clint Byrum wrote:
> > [...]
> > > Something about common use cases and the exact mix of
> > > projects + configuration to get there, and testing it? Help?
> > [...]
> >
> > Maybe you're thinking of the "constellations" suggestion? It found
> > its way into the TC vision statement, though the earliest mention I
> > can locate is in John's post to this ML thread:
> >
> > http://lists.openstack.org/pipermail/openstack-dev/2017-
> April/115319.html
> >
>
> Yes, constellations. Thanks!
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] Initial TC Vision for 2019 Draft survey responses

2017-04-24 Thread Adam Lawson
I appreciate the sensitivity to disclosure but you can publish it. The
person including contact info was *me* since I am keenly interested in
making this useful for everyone. i didn't see a point is being critical
without being willing to actively find a solution. ; )

//adam


*Adam Lawson*

Principal Architect
Office: +1-916-794-5706

On Fri, Apr 21, 2017 at 2:54 PM, Colette Alexander <
colettealexan...@gmail.com> wrote:

> Hi everyone,
>
> Good news! As of this morning, we've had 146 responses to our survey
> asking for community feedback on the initial draft of the TC Vision for
> 2019.
>
> The results are collected here:
> https://docs.google.com/spreadsheets/d/1YzHPP2EQh2DZWGTj_
> VbhwhtsDQebAgqldyi1MHm6QpE/edit?usp=sharing
>
>
> Please keep in mind that there isn't a great way to view long-form survey
> comments (it's one of the downsides of wanting to allow people to express
> themselves, alas) besides just... reading through them.
>
> The top spreadsheet in the file is all responses collected in order of
> completion, and the rest of the tabs are for respondents by-type. You'll
> see multiple responses repeated over those type-sheets, as type was a
> multi-select option (with the exception of "rather not say").
>
> One person (responding under the 'other' category) left some personally
> identifying information in their responses, and I have that available for
> the TC in case they'd like to contact them, but felt it wasn't necessarily
> prudent to give out their PII to the rest of the community without their
> direct permission so it's edited out. If anyone does want to contact that
> person who's *not* on the TC to talk more about their responses with them,
> let me know and we can do an introduction on a case by case basis. I've
> done no other editing of responses besides that.
>
> I'll plan on updating this response sheet weekly with new data as my
> schedule permits, until we decide to close the survey.
>
> TC Members - what do you think is the best way to go about discussing this
> feedback and incorporating it into a finalized vision (besides our planned
> session at the Forum in Boston)? Taking some time out of a couple of TC
> meetings might be nice but if agendas are full for the next few weeks I am
> happy to attempt to schedule another time with everyone.
>
> Thanks so much - and if you haven't taken the survey yet, please do so,
> here: http://www.surveygizmo.com/s3/3490299/TC-2019-Vision
>
> -colette/gothicmindfood
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc][elections]questions about one platform vision

2017-04-19 Thread Adam Lawson
I appreciate the remarks.

I think we are perhaps looking at early data and discussing two separate
things: events versus trends. While I do not doubt K8S has been deployed on
OpenStack, I'm looking at how folks are planning to use those two
platforms. Is it possible to host one in another, absolutely. Is that
supportable at scale or discussed as a serious possibility. Rarely. Where I
believe things are going based on conversations and numerous roadmap
strategy sessions. literally no one I'm talking to talks about the combo as
making sense from a scale perspective whether it be too-big-to-fail banks,
network companies or SaaS companies. Again, this is my perception based on
the folks I'm taking to. That's not where I see the market shifting. And
that's certainly not what I see enterprises doing or planning to go.

On my end I'm seeing many in the OpenStack community falling into a
different trap - believing nothing needs to change to accommodate a
significant new element in the market or to plan a vision for the project
with a misunderstanding of it's place in the FOSS marketplace. The two
platforms do in fact compete as I see things as they are today - and with
increasing interest in orchestrating VM's with K8S, that competition will
likely become more distinct and OpenStack will face a very new
potentiality: OpenStack being considered versus something else. OpenStack
has been IT and the idea of a viable alternate hasn't happened for at least
5 years and I see K8S as a real potential challenger.

But again, everything may change next week and we'll all be wrong. ; )


*Adam Lawson*

Principal Architect
Office: +1-916-794-5706

On Wed, Apr 19, 2017 at 5:14 AM, Flavio Percoco <fla...@redhat.com> wrote:

> On 19/04/17 11:17 +0200, Thierry Carrez wrote:
>
>> Adam Lawson wrote:
>>
>>> [...]
>>> I've been an OpenStack architect for at least 5+ years now and work with
>>> many large Fortune 100 IT shops. OpenStack in the enterprise is being
>>> used to orchestrate virtual machines. Despite the additional
>>> capabilities OpenStack is trying to accommodate, that's basically it. At
>>> scale, that's what they're doing. Not many are orchestrating bare metal
>>> that I've seen or heard. And they are exploring K8s and Docker Swarm to
>>> orchestrate containers. They aren't looking at OpenStack to do that.
>>>
>>
>> I have to disagree. We have evidence that some of the largest Kubernetes
>> deployments in the world happen on top of an OpenStack infrastructure,
>> and hopefully some of those will talk about it in Boston.
>>
>> I feel like you fall in the common trap of thinking that both
>> technologies are competing, while one is designed for infrastructure
>> providers and the other for application deployers. Sure, you can be a
>> Kubernetes-only shop if you're small enough or have Google-like
>> discipline (and a lot of those shops, unsurprisingly, were present in
>> Berlin), but most companies have to offer a wider array of
>> infrastructure services for their developers. That's where OpenStack, an
>> open infrastructure stack, comes in. Giving the infrastructure provider
>> a framework to offer multiple options to application developers and
>> operators.
>>
>
>
> Yes, this, a gazillion of times. I do _NOT_ think CNCF and OpenStack are
> (or
> need to be) in competition and I'd rather explore the different ways we can
> combine these 2 communities or, more specifically, some of the
> technologies that
> are part of these communities.
>
> To do this, we need to explore ways to make OpenStack more "flexible" so
> that we
> can allow different combinations of OpenStack, we need to allow people to
> use it
> more like a framework.
>
> I definitely don't mean it's the only thing and I'm really against calling
> almost anything "the one thing" (unless we're talking about pasta or
> pizza) and
> I believe falling into that trap would damage the community (we barely
> made it
> out in our early years/days).
>
>
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc][elections]questions about one platform vision

2017-04-18 Thread Adam Lawson
My personal feeling:

We need to be very very careful. While I really respect Jay Pipes and his
commentary, I fundamentally disagree with his toolbox mindset. OpenStack is
one tool in the Enterprise toolbox. It isn't a toolbox. K8s is another tool
in the toolbox since it's turning out to be much more than just a container
management platform. Believe it or not AWS is another.

I've been an OpenStack architect for at least 5+ years now and work with
many large Fortune 100 IT shops. OpenStack in the enterprise is being used
to orchestrate virtual machines. Despite the additional capabilities
OpenStack is trying to accommodate, that's basically it. At scale, that's
what they're doing. Not many are orchestrating bare metal that I've seen or
heard. And they are exploring K8s and Docker Swarm to orchestrate
containers. They aren't looking at OpenStack to do that. I recently
attended the K8s conference in Berlin this year and I'll tell you, the
container community is not looking at OpenStack as the means to manage
containers. If they are, they were likely sitting at the OpenStack booth.
Additionally these enterprises are not going to use two platforms side by
side with two means of orchestrating resources. That's both unrealistic and
understandable. Shoe-horning K8s into an OpenStack model really underserves
the container user space.

OpenStack's approach is to treat K8s as a tool.
K8s is working to classify OpenStack as a tool.

So to me we're one of two - maybe one of three solid FOSS cloud platforms -
not including Azure and AWS which are both trending up in consumer adoption
again. All of these are aiming to orchestrate the same resources and in
different ways, they each do it very well. A One Platform vision coming
from the minds within one of those projects creates unnecessary friction
and sounds a little small-minded. Big world out there - we're not the only
player.

In the end I guess I'm trying to say that we need to be careful when we
make assertions because this vision sounds like we're drinking too much of
our own Kool-Aid. When we assume our platform orchestrates the heap, we
need to understand there are several other heaps getting bigger and do
things OpenStack can't. If we buy into a marketing vision, we start a
downward path towards where Eucalyptus and CloudStack are today.

Just my oh, 3 cents worth. ; )

//adam


*Adam Lawson*

Principal Architect
Office: +1-916-794-5706 <(916)%20794-5706>

On Tue, Apr 18, 2017 at 7:39 AM, Flavio Percoco <fla...@redhat.com> wrote:

> On 16/04/17 09:03 +0100, Neil Jerram wrote:
>
>> FWIW, I think the Lego analogy is not actually helpful for another
>> reason: it has vastly too many ways of combining, and (hence) no sense at
>> all of consistency / interoperability between the different things that you
>> can construct with it. Whereas for OpenStack I believe you are also aiming
>> for some forms of consistency and interoperability.
>>
>
> Could you expand on why you think the lego analogy does not cover
> consistency
> and interoperability?
>
>
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

2016-10-11 Thread Adam Lawson
My personal opinion, speaking as a non-candidate, is that it's very likely
true name recognition plays a role. In fact if I was to vote I would do so
and probably vote for Monty or Doug cause I like how they operate and I'm
familiar with them. And if I don't like someone, I won't vote for them.
Selection decisions are influenced by human nature and as such we might
want to at least consider whether name recognition is important or not
versus the actual positions candidates hold or the experience they bring to
the table.

I heard (can't recall who it was) someone say they like names being
attached to positions because they lean towards voting for people who
they've seen or know can get the work done. Interestingly, work as a PTL is
*much* different than the work as a TC member. One question I've often
asked myself is about the role of the TC itself is what *should* these
dudes and dudettes be focusing on? If it's governance, getting out code is
miles apart from working through and making evangelizing decisions.
Experience and approach should, I feel, take utmost precedence over
community popularity. it should if we want a stronger TC anyway.

Strangely, I'll bet some of the top names voted in would continue to be
voted in without a name being attached because they are good at what they
do and don't need to rely on name recognition to draw votes.

I support the blind voting idea personally. Just my two cents.

//adam




*Adam Lawson*

Principal Architect, CEO
Office: +1-916-794-5706

On Tue, Oct 11, 2016 at 11:45 AM, Anita Kuno <ante...@anteaya.info> wrote:

> On 2016-10-11 02:35 PM, Thiago da Silva wrote:
>
>>
>>
>> On 10/11/2016 01:21 PM, Anita Kuno wrote:
>>
>>> On 2016-10-11 12:57 PM, Thiago da Silva wrote:
>>>
>>>>
>>>>
>>>> On 10/11/2016 12:00 PM, Ed Leafe wrote:
>>>>
>>>>> On Oct 11, 2016, at 10:37 AM, Anita Kuno <ante...@anteaya.info> wrote:
>>>>>
>>>>> Just in case folks care, now is the best time to discuss our election
>>>>>> process and suggest options or changes for the next round of elections. 
>>>>>> I'm
>>>>>> not adverse to discussing it I just think the best time for doing so is
>>>>>> from the time the last election is over up to milestone one. Then we have
>>>>>> lots of time for ideas and debate and any suggestions, if accepted, have
>>>>>> time to be implemented and communicated so the process is fair for all,
>>>>>> candidates and electorate.
>>>>>>
>>>>> Agreed.
>>>>>
>>>>> During the election is a wonderful time for posing questions to
>>>>>> candidates in order to clarify their position or stance such that the
>>>>>> electorate can make an informed choice.
>>>>>>
>>>>> To me, that’s the crux: “during the election”. When exactly should
>>>>> that be? Candidates can (and do) declare up to the very last minute of the
>>>>> nomination window, and ballots go out immediately after that, and voting
>>>>> starts. There really needs to be a period when a) we know who all the
>>>>> candidates are, and b) voting has not yet begun. I would like to see that
>>>>> period be created so that the kind of question/answer/clarify process you
>>>>> mention can happen.
>>>>>
>>>> +1
>>>> Just to add on to that, it would also be nice to have a better place
>>>> for the questions/answers to be stored.
>>>>
>>>
>>> Have you a suggestion for where you would like to see them?
>>>
>>> Also regardless of what is formally set up, anyone can ask questions via
>>> the mailing list, that option has been used every election that I have
>>> witnessed, I don't see that changing. I don't think it is reasonable to ask
>>> officials to curate mailing list posts. I think what we are discussing is
>>> something in addition to mailing list discussions. I don't think anything
>>> ever would (or should) replace what comes up on the mailing list.
>>>
>> Anita,
>>
>> Agree that the mailing list is irreplaceable, a lot of of the discussion
>> would continue to happen here. I also don't think asking anyone to curate
>> the answers is scalable.
>>
>
> Great, we agree.
>
>
>> A *suggestion* would be to come up with a set of questions prior to
>> nomination so that candidates could answer in their self-nomination. Of
>> course, how we would come up with those questions is then another issue.
>> Maybe the questions

Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

2016-09-21 Thread Adam Lawson
Travis,

My answer would be -that- is the most ideal scenario. I care about
OpenStack and ensuring quality projects have adequate representation so I
checked to see which ones didn't have anyone defined for leadership and
picked one to step in and help, assuming no one was able to fill that role
for that specific cycle.

On Sep 21, 2016 12:06 PM, "Travis McPeak"  wrote:

> "So all this said, there are individuals interested in the PTL role to
> ensure project teams have someone handling the logistics and coordination.
> My issue however was that I was not yet eligible to be a candidate which
> I'll remedy moving forward.
>
> I'm still interested in serving as a PTL for a project that needs one. I
> personally believe that in the case of Security, there needs to be a
> dedicated team due to the nature and impact of security breaches that
> directly influence the perception of OpenStack as a viable cloud solution
> for enterprises looking (or re-looking) at it for the first time."
>
> @Adam we'd certainly appreciate your help staying on top of
>
> required activities, email, etc.  Surely a PTL should be
>
> somebody who has at least been involved in the project?
>
> --
> -Travis
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

2016-09-21 Thread Adam Lawson
You know something that struck me, I noticed there were several teams last
cycle that did not elect a PTL so this round I was watching to see if any
teams did not have a PTL elected and presumed it was because of many of the
reasons surfaced in previous emails in this thread including being heads
down, watching other channels and potentially insufficient numbers of
individuals interested in the PTL role.

So I waited and noticed Astara, Security and a handful of other projects
did not have a PTL elected so I picked Astara because I am an OpenStack
architect who specializes in SDN, security and distributed storage and
applied. Of course I missed the deadline by about 2 hours but Security was
another project I was interested in.

So all this said, there are individuals interested in the PTL role to
ensure project teams have someone handling the logistics and coordination.
My issue however was that I was not yet eligible to be a candidate which
I'll remedy moving forward.

I'm still interested in serving as a PTL for a project that needs one. I
personally believe that in the case of Security, there needs to be a
dedicated team due to the nature and impact of security breaches that
directly influence the perception of OpenStack as a viable cloud solution
for enterprises looking (or re-looking) at it for the first time.

I'm not a full-time developer but an architect so I am planning to open a
new discussion about how PTL candidates are currently being qualified.
Again, different thread.

For this thread, if there is a concern about PTL interest - it's there and
I would be open to helping the team in this regard if it helps keep the
team activity in the OpenStack marquee.

//adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072

On Wed, Sep 21, 2016 at 8:56 AM, Clint Byrum <cl...@fewbar.com> wrote:

> Excerpts from Filip Pytloun's message of 2016-09-21 14:58:52 +0200:
> > Hello,
> >
> > it's definately our bad that we missed elections in OpenStackSalt
> > project. Reason is similar to Rob's - we are active on different
> > channels (mostly IRC as we keep regular meetings) and don't used to
> > reading mailing lists with lots of generic topics (it would be good to
> > have separate mailing list for such calls and critical topics or
> > individual mails to project's core members).
> >
> > Our project is very active [1], trying to do things the Openstack way
> > and I think it would be a pitty to remove it from Big Tent just because
> > we missed mail and therefore our first PTL election.
> >
> > Of course I don't want to excuse our fault. In case it's not too late,
> > we will try to be more active in mailing lists like openstack-dev and
> > not miss such important events next time.
> >
> > [1] http://stackalytics.com/?module=openstacksalt-group
> >
>
> Seems like we need a bit added to this process which makes sure big tent
> projects have their primary IRC channel identified, and a list of core
> reviewer and meeting chair IRC nicks to ping when something urgent comes
> up. This isn't just useful for elections, but is probably something the
> VMT would appreciate as well, and likely anyone else who has an urgent
> need to make contact with a team.
>
> I think it might also be useful if we could make the meeting bot remind
> teams of any pending actions they need to take such as elections upon
> #startmeeting.
>
> Seems like all of that could be automated.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

2016-09-21 Thread Adam Lawson
But something else struck me, the velocity and sheer NUMBER of emails that
must be filtered to find and extract these key announcements is tricky so I
don't fault anyone for missing the needle in the haystack. Important needle
no doubt but I wonder if there are more efficient ways to ensure important
info is highlighted.

My knee jerk idea is a way for individuals to subscribe to certain topics
that come into their inbox. I don't have a good way within Gmail to
sub-filter these which has been a historical problem for me in terms of
awareness of following hot topics.

//adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072

On Wed, Sep 21, 2016 at 9:28 AM, Adam Lawson <alaw...@aqorn.com> wrote:

> You know something that struck me, I noticed there were several teams last
> cycle that did not elect a PTL so this round I was watching to see if any
> teams did not have a PTL elected and presumed it was because of many of the
> reasons surfaced in previous emails in this thread including being heads
> down, watching other channels and potentially insufficient numbers of
> individuals interested in the PTL role.
>
> So I waited and noticed Astara, Security and a handful of other projects
> did not have a PTL elected so I picked Astara because I am an OpenStack
> architect who specializes in SDN, security and distributed storage and
> applied. Of course I missed the deadline by about 2 hours but Security was
> another project I was interested in.
>
> So all this said, there are individuals interested in the PTL role to
> ensure project teams have someone handling the logistics and coordination.
> My issue however was that I was not yet eligible to be a candidate which
> I'll remedy moving forward.
>
> I'm still interested in serving as a PTL for a project that needs one. I
> personally believe that in the case of Security, there needs to be a
> dedicated team due to the nature and impact of security breaches that
> directly influence the perception of OpenStack as a viable cloud solution
> for enterprises looking (or re-looking) at it for the first time.
>
> I'm not a full-time developer but an architect so I am planning to open a
> new discussion about how PTL candidates are currently being qualified.
> Again, different thread.
>
> For this thread, if there is a concern about PTL interest - it's there and
> I would be open to helping the team in this regard if it helps keep the
> team activity in the OpenStack marquee.
>
> //adam
>
>
> *Adam Lawson*
>
> AQORN, Inc.
> 427 North Tatnall Street
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW ext. 101
> International: +1 302-387-4660
> Direct: +1 916-246-2072
>
> On Wed, Sep 21, 2016 at 8:56 AM, Clint Byrum <cl...@fewbar.com> wrote:
>
>> Excerpts from Filip Pytloun's message of 2016-09-21 14:58:52 +0200:
>> > Hello,
>> >
>> > it's definately our bad that we missed elections in OpenStackSalt
>> > project. Reason is similar to Rob's - we are active on different
>> > channels (mostly IRC as we keep regular meetings) and don't used to
>> > reading mailing lists with lots of generic topics (it would be good to
>> > have separate mailing list for such calls and critical topics or
>> > individual mails to project's core members).
>> >
>> > Our project is very active [1], trying to do things the Openstack way
>> > and I think it would be a pitty to remove it from Big Tent just because
>> > we missed mail and therefore our first PTL election.
>> >
>> > Of course I don't want to excuse our fault. In case it's not too late,
>> > we will try to be more active in mailing lists like openstack-dev and
>> > not miss such important events next time.
>> >
>> > [1] http://stackalytics.com/?module=openstacksalt-group
>> >
>>
>> Seems like we need a bit added to this process which makes sure big tent
>> projects have their primary IRC channel identified, and a list of core
>> reviewer and meeting chair IRC nicks to ping when something urgent comes
>> up. This isn't just useful for elections, but is probably something the
>> VMT would appreciate as well, and likely anyone else who has an urgent
>> need to make contact with a team.
>>
>> I think it might also be useful if we could make the meeting bot remind
>> teams of any pending actions they need to take such as elections upon
>> #startmeeting.
>>
>> Seems like all of that could be automated.
>>
>> 

Re: [openstack-dev] [all][astara][cloudkitty][dragonflow][i18n][karbor][openstack_ux][openstacksalt][security][senlin][elections] Last hours for PTL candidate announcements

2016-09-18 Thread Adam Lawson
Yep got it got it. Thanks.

//adam

On Sep 18, 2016 8:46 PM, "Tony Breeds" <t...@bakeyournoodle.com> wrote:

> On Sun, Sep 18, 2016 at 06:12:53PM -0700, Adam Lawson wrote:
> > Tony, I tried to commit my candidacy for Astara but I am not seeing the
> > file present. Is there a delay between the commit and the display at
> > git.openstack.org?
>
> Hi Adam,
> No it's just the standard gerrit review system.  Once git review tells
> you
> the change is uploaded it should be visible in gerrit.
>
> I see 2 nominations from you that both arrived after the cut off.  Which
> means
> that the TC will be bound by [1].
>
> During the next week the election officials will let the TC know about
> leaderless projects and the TC will determine the correct course of action.
>
> Yours Tony.
>
> [1] http://governance.openstack.org/resolutions/20141128-
> elections-process-for-leaderless-programs.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][astara][cloudkitty][dragonflow][i18n][karbor][openstack_ux][openstacksalt][security][senlin][elections] Last hours for PTL candidate announcements

2016-09-18 Thread Adam Lawson
Tony, I tried to commit my candidacy for Astara but I am not seeing the
file present. Is there a delay between the commit and the display at
git.openstack.org?

//adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072

On Sat, Sep 17, 2016 at 4:53 PM, Tony Breeds <t...@bakeyournoodle.com>
wrote:

> A quick reminder that we are in the last hours for PTL candidate
> announcements.
>
> If you want to stand for PTL, don't delay, follow the instructions at [1]
> to make sure the community knows your intentions.
>
> Make sure your candidacy have been submitted to the openstack/election
> repository and approved by election officials.
>
> Election statistics[2]:
> ---
> Nominations started   @ 2016-09-12 00:00:00 UTC
> Nominations end   @ 2016-09-18 23:45:00 UTC
> Nominations duration  : 6 days, 23:45:00
> Nominations remaining : 23:54:55
> Nominations progress  :  85.74%
> ---
> Projects  :59
> Projects with candidates  :50 ( 84.75%)
> Projects with election: 3 (  5.08%)
> ===
> Stats gathered@ 2016-09-17 23:50:05 UTC
> Projects without candidates[2]
> Astara
> Cloudkitty
> Dragonflow
> I18n
> Karbor
> OpenStack_UX
> OpenStackSalt
> Security
> Senlin
>
>
> This means that with approximately 1 day left more than 15% of projects
> will be deemed
> leaderless.  In this case the TC will be bound by [3].
>
> Thank you,
> Tony.
>
> [1] http://governance.openstack.org/election/#how-to-submit-your-candidacy
> [2] Assuming the open reviews below are validated
>https://review.openstack.org/#/q/is:open+project:openstack/election
> [3] http://governance.openstack.org/resolutions/20141128-
> elections-process-for-leaderless-programs.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Upstream - Barcelona

2016-09-01 Thread Adam Lawson
There are probably limited number of seats to participate in the session
this cycle. opps = seats in my messed up way of thinking.

//adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072

On Thu, Sep 1, 2016 at 5:20 AM, Thierry Carrez <thie...@openstack.org>
wrote:

> M Ranga Swami Reddy wrote:
> > yes...Even I have not seen any emails for upstream tasks @
> > BarcelonaI guess we might have missed it...
> >
> > Thanks
> > Swami
> >
> > On Thu, Sep 1, 2016 at 9:23 AM, Adam Lawson <alaw...@aqorn.com
> > <mailto:alaw...@aqorn.com>> wrote:
> >
> > I seemed to have missed the thread where upstream opps we're being
> > announced and/or opened. Who do I contact to get in on this? I had
> > table duty last year and couldn't do it.
>
> What do you mean by "upstream opps" ?
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Upstream - Barcelona

2016-08-31 Thread Adam Lawson
I seemed to have missed the thread where upstream opps we're being
announced and/or opened. Who do I contact to get in on this? I had table
duty last year and couldn't do it.

//adam
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-22 Thread Adam Lawson
Let me toss out my perspective (FWIW) from a cloud planning perspective as
relates to single-vendor projects:

As an established OpenStack and cloud SDN architect and by extension a
working owner, I do design work for lots of the companies who read this
list. Let me just say that from where I sit, there is rarely a time where I
or any of my colleagues have been able to recommend using an open source
project developed by single vendor driving development for obvious reasons.
Companies usually consider OpenStack because of the open standard, modular
framework and vendor avoidance (not tied to one that is). If part of your
cloud strategy uses a tool developed by one vendor, your entire cloud is
tied to that tool and unfortunately, organizations end up doing this as a
result of politics, partner commitments and/or perceived safety of projects
developed by a familiar entity. Software developed by a single company is a
risk which affects adoption[1]. Who is driving an open source project is a
key consideration by cloud consumers. The biggest exception to this that
I've seen is Ceph given the staying power of RHEL (and/or the perceived
safety in using a product developed by a recognized Linux distro).

I'm glad we're discussing this and I want to re-iterate that project
diversity within the big tent is more important than how each project
integrates into OpenStack's development process. There's a perception that
comes with the association with membership. Projects in the big tent and
the evangelized reasons for they're there are being closely watched by more
than just our community. And cloud planners such as myself and many others
are watching for our own reasons as well.

Just adding that there's a perception that drives adoption by how we
structure and evangelize the Big Tent idea.

Anyway, ; )

[1]
http://www.zdnet.com/article/google-intel-and-mirantis-rewrite-openstacks-life-cycle-management-tool/

//adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072

On Fri, Aug 5, 2016 at 6:26 AM, Zane Bitter <zbit...@redhat.com> wrote:

> On 04/08/16 23:00, joehuang wrote:
>
>> I think all the problem is caused by the definition "official OpenStack
>> project" for one big-tent project.
>>
>> I understand that each OpenStack vendor wants some differentiation in
>> their solution, while also would
>> like to collaborate with common core projects.
>>
>
> Nobody wants this. We want to build a fully-featured cloud that can run
> the same kinds of apps that users might develop for AWS/Azure/GCE, and we
> want those apps to be portable substantially everywhere. It's all right
> there in the Mission Statement.
>
> If we replace the title "official OpenStack project" to "OpenStack
>> ecosystem player", and make "big-tent"
>> as "ecosystem play yard" ( no close roof ), TCs can put more focus on
>> governance of core projects
>> (current non-big-tent projects), and provide a more open place to grow
>> abundant ecosystem.
>>
>
> You're describing the exact situation we had before the 'big-tent' reform.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Cinder] Support for volume sharing across multiple VM's

2016-07-27 Thread Adam Lawson
I heard there's been some attention given to and progress made supporting
sharing a single volume with multiple VM's. Where are we along the
development curve and has anyone been able to get this to work?

Thanks!

//adam

*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Proposal: Architecture Working Group

2016-06-30 Thread Adam Lawson
Okay I'll bite. I'm a working owner; Cloud/OpenStack/SDN architect slash
OpenStack SI business owner working with companies trying to extract value
from technology they don't understand. Or in ways they aren't familiar
with. Or with code they don't have time to build/maintain themselves.

This working group seems like we'll get to look at things from the
perspective of "what is openstack and how can we make it better for those
who want to use it" among other things. Sad reality is SI's and product
vendors make more money if OpenStack remains complicated so we'll be
working against working against a powerful money machine that funds this
project. I want OpenStack to address real non-theoretical and
non-marketing-BS cloud problems that are based in today's reality and in
advance of tomorrow's challenges. I hope we'll get that chance.

Today, it seems to me that this WG would focus un-crunching code, design
and evangelize opportunities for potential improvements for consideration
by the greater OpenStack community and the TC. No successful architecture
group I've ever participated wondered how do we can compel others to accept
our recommendations. Leave that to the business/OpenStack governance.

Ultimately, I totally agree with Clint in that if we avoid too much focus
on design enforcement, that's our first win. And in my mind, our designs
will not be absorbed nor accepted de facto anyway. I think the value will
however be recognized over time though and I'm totally down with that.

I'd like to participate with this Clint if there's room for one more. ; )

//adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072

On Thu, Jun 30, 2016 at 11:16 AM, Joshua Harlow <harlo...@fastmail.com>
wrote:

> Mike Perez wrote:
>
>> On 11:31 Jun 20, Clint Byrum wrote:
>>
>>> Excerpts from Joshua Harlow's message of 2016-06-17 15:33:25 -0700:
>>>
>>>> Thanks for getting this started Clint,
>>>>
>>>> I'm happy and excited to be involved in helping try to guide the whole
>>>> ecosystem together (it's also why I like being in oslo) to a
>>>> architecture that is more cohesive (and is more of something that we can
>>>> say to our current or future children that we were all involved and
>>>> proud to be involved in creating/maturing...).
>>>>
>>>> At a start, for said first meeting, any kind of agenda come to mind, or
>>>> will it be more a informal gathering to start (either is fine with me)?
>>>>
>>>> I've been hesitant to fill this in too much as I'm still forming the
>>> idea, but here are the items I think are most compelling to begin with:
>>>
>>> * DLM's across OpenStack -- This is already under way[1], but it seems to
>>>have fizzled out. IMO that is because there's no working group who
>>>owns it. We need to actually write some plans.
>>>
>>
>> Not meaning to nitpick, but I don't think this is a compelling reason for
>> the
>> architecture working group. We need a group that wants to spend time on
>> reviewing the drivers being proposed. This is like saying we need the
>> architecture working group because no working group is actively reshaping
>> quotas
>> cross-project.
>>
>> With that said, I can see the architecture working group providing
>> information
>> on to a group actually reviewing/writing drivers for DLM and saying "Doing
>> mutexes with the mysql driver is crazy, I brought it in a environment and
>> have
>> such information to support that it is not reliable". THAT is useful and I
>> don't feel like people do enough of.
>>
>> My point is call your working group whatever you want (The Purple
>> Parrots), and
>> just go spearhead DLM, but don't make it about one of the most compelling
>> reasons for the existence of this group.
>>
>
> Sadly I feel if such a group formed it wouldn't be addressing the larger
> issue that this type of group is trying to address; the purple parrots
> would be a tactical team that could go do what u said, but that doesn't
> address the larger strategic goal of trying to improve the full situation
> (technical and architectural inconsistencies and 'fizzling out' solutions)
> that IMHO needs to be worked through.
>
> So yes, the tactical group needs to exist, and overall it likely will, but
> there also needs to be a strategic group that is being proactive about the
> issues and not just tactically reacting to things (which isn't imho
> healthy).
>
> -Josh
>
>
> 

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

2016-04-09 Thread Adam Lawson
I have a quick question:
How is anyone hurt out harmed by the practice? I agree it isn't helpful.
But it isn't harming either. It could be gaming and it could be ignorance -
mistakes by not knowing.

I'm asking because I see the same predictable personalities making passive
aggressive accusations against their peers about gaming and ill intent.
When folks are approached, they realize it is due to not knowing. Their
answers are received with suspicion and presumptions that they are in the
minority.

We really need to stop rushing to embrace the worst in each other.

//adam
On Apr 9, 2016 1:18 PM, "Morgan Fainberg"  wrote:


On Apr 9, 2016 12:05, "Ken'ichi Ohmichi"  wrote:
>
>
> 2016/04/08 10:55、Anita Kuno  :
>
> >> On 04/08/2016 01:42 PM, Dmitry Tantsur wrote:
> >> 2016-04-08 19:26 GMT+02:00 Davanum Srinivas :
> >>
> >>> Team,
> >>>
> >>> Steve pointed out to a problem in Stackalytics:
> >>> https://twitter.com/stevebot/status/718185667709267969
> >>
> >>
> >> There are many ways to game a simple +1 counter, such as +1'ing changes
> >> that already have at least 1x +2, or which already approved, or which
need
> >> rechecking...
>
> Can we merge this kind of patches without reviews?
> When seeing this kind of patches, I check all jobs are succeeded.
Sometimes some job failed, I check the reason and +2 if that is unrelated.
>
> This workflow seems possible to be implemented automatically.
> Or bad idea?
>
> Thanks
>

A true automerge has potential to accidentally clobber things in an ugly
way if it goes wrong. The auto propose but core approval still has a level
of human spot checking. I would personally be uncomfortable with the bot
automatically merging  things. At face value the overhead of a core
approval and possibility of what is highlighted in this thread is better
IMHO.

>
>
>
>
>
>
>
> >>
> >>
> >>>
> >>>
> >>> It's pretty clear what's happening if you look here:
> >>>
> >>>
https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open
> >>>
> >>> Here's the drastic step (i'd like to avoid):
> >>> https://review.openstack.org/#/c/303545/
> >>>
> >>> What do you think?
> >>
> >> One more possible (though also imperfect) mitigation is to make
exception
> >> from the usual 2x +2 rule for requirements updates passing gates and
use
> >> only 1x +2. Then requirements reviews will take substantially less
time to
> >> land, reducing need/possibility of having such +1's.
> >
> > Proposal bot patches merge in many cases with 1 +2 already.
> >
> > Have you looked at the timing of the bot patches generated and the first
> > +1's? If not, take a look at that.
> >
> > I don't think we should be expecting core reviewers to schedule
> > approving bot proposals to prevent extraneous +1s.
> >
> > Thanks,
> > Anita.
> >
> >>
> >>>
> >>> Thanks,
> >>> Dims
> >>>
> >>> --
> >>> Davanum Srinivas :: https://twitter.com/dims
> >>>
> >>>
__
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >>
> >>
> >>
__
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
__
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] the bugs team needs (more) members

2016-04-01 Thread Adam Lawson
Markus,

If you van connect me with someone who can tell me what needs the most
attention and how to get started, I'd be happy to help.

//adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072

On Fri, Apr 1, 2016 at 3:46 AM, Markus Zoeller <mzoel...@de.ibm.com> wrote:

> TL;DR: * The Nova bugs team needs more members
>* Tasks: https://wiki.openstack.org/wiki/BugTriage
>* Cleanup: http://45.55.105.55:8082/bugs-dashboard.html
>* Meeting: https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam
>* Etherpad: https://etherpad.openstack.org/p/nova-bugs-team
>
>
> The Nova project has a large backlog of open bug reports. Around 5 new
> bug reports get created everyday. It is not possible to make a
> reasonable progress with the current number of people. The nova bugs
> team needs to play a more active role and it needs more people for that.
>
>
> What's in for you?
> --
> As bugs are in every software in every place, you will get around a lot.
> Having a specific issue makes it also easier to ping other folks to
> discuss this issue. Bug fixes also don't have the hard deadlines
> imposed on feature patches. Being once on the bug triage side will
> improve the quality of your future bug reports which will make them
> more likely to get solved.
>
>
> Current Status
> --
> The main issue which slows down all following steps are bug reports
> without the essential informations [1]:
> * versions (nova, hypervisor, database, ...)
> * steps-to-reproduce (with actual data)
> * expected behavior
> * actual observed behavior
> * logs (in debug mode)
> * topology (for example: nova-network vs. neutron)
> Although this gets asked for when creating a bug report, the vast
> majority of bug reports lack this information. Usually it takes one
> to three roundtrips to get this information from the reporter. This
> is time consuming. As we focus less on new features in Newton [2] I
> have the hope that the bug list will get more attention.
>
>
> Tasks
> -
> The tasks are listed in the wiki [3]. They "just" need to be done.
> Repeatedly. Some on a daily basis, some less frequently. The cleanup
> dashboard [4] is a tool I use personally but can be used by you too.
>
> The Neutron folks introduced a weekly rotating bug skimming duty and
> they've made good experiences with it. This involves 1-3 people who
> check new bugs reports if they are valid and provide the essential
> information. We should adapt that [5].
>
> In general we should aim for:
> * respond to new bugs in a timely manner to get high quality reports
> * clean up the "old stuff" (>= 1.5 years)
> * spread the effort to multiple shoulders
> * rotate the different efforts to prevent exhaustion and tunnel vision
>
> There is an ongoing effort to move the RFEs (request for feature
> enhancements) away from the bug list [6] to allow us to be more
> focused on faulty behavior of existing features people already rely on.
>
>
> Organization
> 
> * The nova bugs team has an IRC meeting [7] which allows us to sync
>   with each other.
> * The cleanup dashboard [4] shows bug reports which need a check
>   based on the tasks [3].
> * The etherpad [8] can be used to avoid an overlap of efforts of
>   different people.
>
>
> Education
> -
> It's possible to use the nova bugs team IRC meeting for education
> sessions if this helps you.
> I will also attend the summit in Austin in a few weeks. We can do an
> unofficial "bugs mgmt process" crash course there if you like. Just
> talk to me there (or beforehand in IRC) and we will find the time
> and space.
> At last I can offer a Google Hangout session if some are interested
> in that.
>
>
> How to Join?
> 
> * Join the nova-bugs Launchpad group [9]
> * Familiarize with the process [10]
> * Attend the bugs meeting [7]
>
> With a few people who are willing to spent a few hours per week we
> can create a well maintained bug list where issues get addressed
> in a timely manner to consistently improve the quality of Nova.
>
>
> References
> --
> [1] "working on bug reports; what blocks you?":
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/089677.html
> [2] "No spec approvals for new things until after the summit":
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/090370.html
> [3] https://wiki.openstack.org/wiki/BugTriage
> [4] http://45.55.105.55:8082/bugs-dashboard.html

[openstack-dev] [Cinder] Status of cinder-list bug delay with 1000's of volumes

2016-03-03 Thread Adam Lawson
Hey all (hi John),

What's the status of this [1]? We're experiencing this behavior in Icehouse
- wondering where it was addressed and if so, when. I always get confused
when I look at the launchpad/review portals.

[1] https://bugs.launchpad.net/cinder/+bug/1317606


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] A proposal to separate the design summit

2016-03-01 Thread Adam Lawson
After reading through this, it seems to me like Anita is frustrated with
the motivation among those who submit one patch because of her perception
that they are doing so only to take advantage of a free ticket and by
extension, crowding rooms that affects her ability to hear/engage
effectively. I understand the desire to engage more (for lack of better
term) but reaching beyond someone's contribution and openly suggest they
are not contributing for the right reasons isn't anyone'e concern to be
perfectly frank.

Aside from that, I don't think anyone is taking advantage of anything if
they earn a free ticket to an OpenStack Summit by fulfilling the needful
requirements. If they submit a patch, OpenStack becomes better and the
contributor is entitled to a free ticket to the next Summit. I fail to see
a single downside in that.

Tough love: "gaming" within the context of those who submit one patch,
making remarks about a perceived dishonorable motivation of our peers; that
level of discourse among peers is simply damaging.

//adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072

On Tue, Mar 1, 2016 at 2:08 PM, Chris Friesen <chris.frie...@windriver.com>
wrote:

> On 03/01/2016 03:52 PM, Clint Byrum wrote:
>
>> Excerpts from Eoghan Glynn's message of 2016-03-01 02:08:00 -0800:
>>
>
> There are a whole slew of folks who work fulltime on OpenStack but
>>> contribute mainly in the background: operating clouds, managing
>>> engineering teams, supporting customers, designing product roadmaps,
>>> training new users etc. TBH we should be flattered that the design
>>> summit sessions are interesting and engaging enough to also attract
>>> some of that sort of audience, as well as the core contributors of
>>> code. If those interested folks happen to also have the gumption to
>>> earn an ATC pass by meeting the threshold for contributor activity,
>>> then good for them! As long as no-one is actively derailing the
>>> discussion, I don't see much of an issue with the current mix of
>>> attendees.
>>>
>>>
>> I think you're right on all of these points. However, what you might
>> not have considered is that _the sheer number of people in the room_
>> can derail the productivity of a group of developers arguing complicated
>> points. It's not that we want to be operating in the shadows; it is that
>> we want to be operating in a safe, creative environment. A room with 5
>> friends, 5 acquaintances, and 100 strangers, is not that. But if there
>> are only, say, 15 strangers, one can take the time to get to know those
>> people, to understand their needs, and make far more progress and be
>> far more inclusive in discussions.
>>
>> What we want is for people to be attending and participating _on
>> purpose_.
>>
>
> I think it's pretty unlikely that people would attend the developer summit
> sessions by accident.  :)
>
> It kind of sounds to me like you want to limit the number of 'tourists'
> that aren't actively involved in the issues being discussed, but are just
> there to observe.  Or am I misinterpreting?
>
> Chris
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] MTU configuration pain

2016-01-23 Thread Adam Lawson
For the sake of over-simplification, is there ever a reason to NOT enable
jumbo frames in a cloud/SDN context where most of the traffic is between
virtual elements that all support it? I understand that some switches do
not support it and traffic form the web doesn't support it either but
besides that, seems like a default "jumboframes = 1" concept would work
just fine to me.

Then again I'm all about making OpenStack easier to consume so my ideas
tend to gloss over special use cases with special requirements.


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072

On Fri, Jan 22, 2016 at 7:13 PM, Matt Kassawara <mkassaw...@gmail.com>
wrote:

> The fun continues, now using an OpenStack deployment on physical hardware
> that supports jumbo frames with 9000 MTU and IPv4/IPv6. This experiment
> still uses Linux bridge for consistency. I'm planning to run similar
> experiments with Open vSwitch and Open Virtual Network (OVN) in the next
> week.
>
> I highly recommend reading further, but here's the TL;DR: Using physical
> network interfaces with MTUs larger than 1500 reveals an additional problem
> with veth pair for the neutron router interface on the public network.
> Additionally, IP protocol version does not impact MTU calculation for
> Linux bridge.
>
> First, review the OpenStack bits and resulting network components in the
> environment [1]. In the first experiment, public cloud network limitations
> prevented truly seeing how Linux bridge (actually the kernel) handles
> physical network interfaces with MTUs larger than 1500. In this experiment,
> we see that it automatically calculates the proper MTU for bridges and
> VXLAN interfaces using the MTU of parent devices. Also, see that a regular
> 'ping' works between the host outside of the deployment and the VM [2].
>
> [1] https://gist.github.com/ionosphere80/a3725066386d8ca4c6d7
> [2] https://gist.github.com/ionosphere80/a8d601a356ac6c6274cb
>
> Note: The tcpdump output in each case references up to six points: neutron
> router gateway on the public network (qg), namespace end of the veth pair
> for the neutron router interface on the private network (qr), bridge end of
> the veth pair for router interface on the private network (tap), controller
> node end of the VXLAN network (underlying interface), compute node end of
> the VXLAN network (underlying interface), and the bridge end of the tap for
> the VM (tap).
>
> In the first experiment, SSH "stuck" because of a MTU mismatch on the veth
> pair between the router namespace and private network bridge. In this
> experiment, SSH works because the VM network interface uses a 1500 MTU and
> all devices along the path between the host and VM use a 1500 or larger
> MTU. So, let's configure the VM network interface to use the proper MTU of
> 9000 minus the VXLAN protocol overhead of 50 bytes... 8950... and try SSH
> again.
>
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc pfifo_fast qlen
> 1000
> link/ether fa:16:3e:46:ac:d3 brd ff:ff:ff:ff:ff:ff
> inet 172.16.1.3/24 brd 172.16.1.255 scope global eth0
> inet6 fd00:100:52:1:f816:3eff:fe46:acd3/64 scope global dynamic
>valid_lft 86395sec preferred_lft 14395sec
> inet6 fe80::f816:3eff:fe46:acd3/64 scope link
>valid_lft forever preferred_lft forever
>
> SSH doesn't work with IPv4 or IPv6. Adding a slight twist to the first
> experiment, I don't even see the large packet traversing the neutron
> router gateway on the public network. So, I began a tcpdump closer to the
> source on the bridge end of the veth pair for the neutron router
> interface on the public network.
>
> Looking at [3], the veth pair between the router namespace and private
> network bridge drops the packet. The MTU changes over a layer-2 connection
> without a router, similar to connecting two switches with different MTUs.
> Even if it could participate in PMTUD, the veth pair lacks an IP address
> and therefore cannot originate ICMP messages.
>
> [3] https://gist.github.com/ionosphere80/ec83d0955c79b05ea381
>
> Using observations from the first experiment, let's configure the MTU of
> the interfaces in the qrouter namespace to match the other end of their
> respective veth pairs. The public network (gateway) interface MTU becomes
> 9000 and the private network router interfaces (IPv4 and IPv6) become 8950.
>
> 2: qr-49b27408-04: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc
> pfifo_fast state UP mode DEFAULT group default qlen 1000
> link/ether fa:16:3e:e5:43:1c brd ff:ff:ff:ff:ff:ff
> 3: qr-b7e0ef22-32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc
>

Re: [openstack-dev] [puppet] [ceph] Puppet Ceph CI

2015-11-23 Thread Adam Lawson
I'm confused, what is the context here? We use Ceph with OpenStack Kilo
without issue.
On Nov 23, 2015 2:28 PM, "David Moreau Simard"  wrote:

> Last I remember, David Gurtner tried to use Kilo instead of Juno but
> he bumped into some problems and we settled for Juno at the time [1].
> At this point we should already be testing against both Liberty and
> Infernalis, we're overdue for an upgrade in that regard.
>
> But, yes, +1 to split acceptance tests:
> 1) Ceph
> 2) Ceph + Openstack
>
> Actually learning what failed is indeed challenging sometimes, I don't
> have enough experience with the acceptance testing to suggest anything
> better.
> We have the flexibility of creating different logfiles, maybe we can
> find a way to split out the relevant bits into another file.
>
> [1]: https://review.openstack.org/#/c/153783/
>
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
>
> On Mon, Nov 23, 2015 at 2:45 PM, Andrew Woodward  wrote:
> > I think I have a good lead on the recent failures in openstack / swift /
> > radosgw integration component that we have since disabled. It looks like
> > there is a oslo.config version upgrade conflict in the Juno repo we where
> > using for CentOS. I think moving to Kilo will help sort this out, but at
> the
> > same time I think it would be prudent to separate the Ceph v.s. OpenStack
> > integration into separate jobs so that we have a better idea of which is
> a
> > problem. If there is census for this, I'd need some direction / help, as
> > well as set them up as non-voting for now.
> >
> > Looking into this I also found that the only place that we do integration
> > any of the cephx logic was in the same test so we will need to create a
> > component for it in the ceph integration as well as use it in the
> OpenStack
> > side.
> >
> > Lastly un-winding the integration failure seemed overly complex. Is
> there a
> > way that we can correlate the test status inside the job at a high level
> > besides the entire job passed / failed without breaking them into
> separate
> > jobs?
> > --
> >
> > --
> >
> > Andrew Woodward
> >
> > Mirantis
> >
> > Fuel Community Ambassador
> >
> > Ceph Community
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Nominations open for the N and O names of OpenStack

2015-11-09 Thread Adam Lawson
Norris! As in ... Chuck Norris lives in Texas.

Just saying. ; )
On Nov 9, 2015 5:31 AM, "Monty Taylor"  wrote:

> Hey everybody!
>
> It's release naming time, and this time we get to do two at once!
>
> If you'd like to propose a name, there are two wiki pages:
>
> For the N release, where the geographic region is "Texas Hill Country":
>
> https://wiki.openstack.org/wiki/Release_Naming/N_Proposals
>
> For the O release, where the geographic region is "Catalonia":
>
> https://wiki.openstack.org/wiki/Release_Naming/O_Proposals
>
> We're going to keep proposals open until 2015-11-15 23:59:59 UTC, and
> voting will start 2015-11-30. The time in between proposals closing and
> voting starting is to allow for a TC meeting to approve any exceptional
> names that people propose, and then to not attempt to have a vote spanning
> the US Thanksgiving holiday.
>
> Have fun!
>
> Monty
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Scheduler proposal

2015-10-11 Thread Adam Lawson
I have a quick question: how is Amazon doing this? When choosing a next
path forward that reliably scales, would be interesting to know how this is
already being done.
On Oct 9, 2015 10:12 AM, "Zane Bitter"  wrote:

> On 08/10/15 21:32, Ian Wells wrote:
>
>>
>> > 2. if many hosts suit the 5 VMs then this is *very* unlucky,because
>> we should be choosing a host at random from the set of
>> suitable hosts and that's a huge coincidence - so this is a tiny
>> corner case that we shouldn't be designing around
>>
>> Here is where we differ in our understanding. With the current
>> system of filters and weighers, 5 schedulers getting requests for
>> identical VMs and having identical information are *expected* to
>> select the same host. It is not a tiny corner case; it is the most
>> likely result for the current system design. By catching this
>> situation early (in the scheduling process) we can avoid multiple
>> RPC round-trips to handle the fail/retry mechanism.
>>
>>
>> And so maybe this would be a different fix - choose, at random, one of
>> the hosts above a weighting threshold, not choose the top host every
>> time? Technically, any host passing the filter is adequate to the task
>> from the perspective of an API user (and they can't prove if they got
>> the highest weighting or not), so if we assume weighting an operator
>> preference, and just weaken it slightly, we'd have a few more options.
>>
>
> The optimal way to do this would be a weighted random selection, where the
> probability of any given host being selected is proportional to its
> weighting. (Obviously this is limited by the accuracy of the weighting
> function in expressing your actual preferences - and it's at least
> conceivable that this could vary with the number of schedulers running.)
>
> In fact, the choice of the name 'weighting' would normally imply that it's
> done this way; hearing that the 'weighting' is actually used as a 'score'
> with the highest one always winning is quite surprising.
>
> cheers,
> Zane.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Fuel] fuel-createmirror "command not found"

2015-09-15 Thread Adam Lawson
Hi guys,
Is there a trick to get the fuel-createmirror command to work? Customer
fuel environment was at 6.0, upgraded to 6.1, tred to create local mirror
and failed. Not working from master node.


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

2015-09-09 Thread Adam Lawson
We thought about doing this as well and opted for a local repo, at least
for now. If you want to offer an online repo, I think it could be useful to
allow either scenario.

Just a thought from your friendly neighbors here. ; )

/adam
On Sep 8, 2015 7:03 AM, "Vladimir Kozhukalov" 
wrote:

> Sorry, fat fingers => early sending.
>
> =
> Dear colleagues,
>
> The idea is to remove MOS DEB repo from the Fuel master node by default
> and use online MOS repo instead. Pros of such an approach are:
>
> 0) Reduced requirement for the master node minimal disk space
> 1) There won't be such things in like [1] and [2], thus less complicated
> flow, less errors, easier to maintain, easier to understand, easier to
> troubleshoot
> 2) If one wants to have local mirror, the flow is the same as in case of
> upstream repos (fuel-createmirror), which is clrear for a user to
> understand.
>
> Many people still associate ISO with MOS, but it is not true when using
> package based delivery approach.
>
> It is easy to define necessary repos during deployment and thus it is easy
> to control what exactly is going to be installed on slave nodes.
>
> What do you guys think of it?
>
>
>
> Vladimir Kozhukalov
>
> On Tue, Sep 8, 2015 at 4:53 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> The idea is to remove MOS DEB repo from the Fuel master node by default
>> and use online MOS repo instead. Pros of such an approach are:
>>
>> 0) Reduced requirement for the master node minimal disk space
>> 1) There won't be such things in like [1] and [2], thus less complicated
>> flow, less errors, easier to maintain, easier to understand, easier to
>> troubleshoot
>> 2) If one wants to have local mirror, the flow is the same as in case of
>> upstream repos (fuel-createmirror), which is clrear for a user to
>> understand.
>>
>> Many people still associate ISO with MOS
>>
>>
>>
>>
>>
>> [1]
>> https://github.com/stackforge/fuel-main/blob/master/iso/ks.template#L416-L419
>> [2]
>> https://github.com/stackforge/fuel-web/blob/master/fuel_upgrade_system/fuel_upgrade/fuel_upgrade/engines/host_system.py#L109-L115
>>
>>
>> Vladimir Kozhukalov
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Capturing program architecture

2015-08-30 Thread Adam Lawson
Hi everyone!

I'm trying to capture how each program is constructed for the purposes of
writing a new set of OpenStack deep dive training material and wondering
what is considered the best place to gi for this level of information? Such
as breaking down neutron or nova... All programs really... Anyone do this
and found a workable method?

/adam
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Quick question..

2015-07-30 Thread Adam Lawson
How many up votes are needed for code to be accepted into the trunk
(assuming it passes testing etc)?


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] OPENSTACK with CEPH storage backend cant down size an instance

2015-07-26 Thread Adam Lawson
Agreed on resizing. Perhaps create a snapshot of the old VM (assuming
!ephemeral storage), and boot a new VM with a smaller disk size from the
snapshot.

Future reference you can leverage SAN-specific tools to save unused disk
such as thin provisioning and/or the vendor's dedup capabilities.




*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Fri, Jul 24, 2015 at 12:11 PM, Monty Taylor mord...@inaugust.com wrote:

 On 07/24/2015 12:47 PM, Clint Byrum wrote:
  Excerpts from James Galvin's message of 2015-07-24 09:08:36 -0700:
  Hi All
 
  I am having some trouble with down sizing an instance,
 
  I can resize the instance from say small flavour to medium flavour but
 when trying to resize the instance back from medium to small
 
  I get the following :
 
  Error: Failed to perform requested operation on instance jg-10, the
 instance has an error status: Please try again later [Error: Flavor's disk
 is too small for requested image.].
 
  I am using ceph as the storage backend clustered over 3 nodes with 3
 pools volumes vms images
 
 
  In addition to the note already made about reducing filesystem sizes,
  I just want to reaffirm that resize is really not the way you want to
  be using clouds, and IMO should be removed from Nova (but there's enough
  people who disagree with me that it will probably stay).
 
  Anyway, I suggest never using resize, and just deploying new servers,
  running tests, and then deleting the old ones. Having cloud with
  flexibility and space for this is why you have a cloud.

 As a person who runs a system with both long-lived pets and cattle that
 we grind in to food, I can attest that we do not use resize. It is a
 much longer downtime/risk operation than you want.


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Openstack-operators] [Openstack] Rescinding the M name decision

2015-07-09 Thread Adam Lawson
Yes I'm talking about vetting by legal since the community already vets via
the usual process. Legal has stricter guidelines so we could start future
vetting with legal to remove the options we can't use even if we wanted to.
That's where the inefficiency lies imho. The issue with this particular
snafu is kind of an exceptional case.
On Jul 9, 2015 4:39 PM, Anita Kuno ante...@anteaya.info wrote:

 On 07/09/2015 07:16 PM, Adam Lawson wrote:
  It seems we have a golden opportunity here to improve efficiency by
 vetting
  names before we vote on them.

 The vetting from the crowd was intended to happen on the wikipage. I'm
 not sure how much vetting did take place but obviously not enough to
 give us a list of names that the community felt comfortable with.

 Hopefully subsequent rounds will show community members stepping forward
 more vocally than they did this round.

 Also as I think ttx pointed out, culturally those with the most
 knowledge of the significance of these names behave in a way that trusts
 the judgment of the decision makers. Unfortunately the decision makers
 in this case lacked the culture information the community members have.
 It is a learning experience all round.

 Legally vetting all the names suggested on the wikipage would be
 expensive I do believe, if that is what you are suggesting by vetting.

  Seems that voting for a bunch of names then
  eliminating all of the top votes because they won't work doesn't strike
 me
  as very efficient (i.e. why vote on names that MIGHT be valid).

 Well sometimes groups aren't very efficient, mostly since they are
 composed of humans and humans have opportunities to learn from each
 other. This process is rarely a straight line from A to B. (Personally I
 picture lots of spirograph images.)

 Thanks,
 Anita.

 
  The alternative of course is to just number the releases since names
  ultimately don't mean anything but it seems there are problems with that
  level of simplicity. I personally prefer Tristan's suggestion to keep it
 as
  simple as possible. In a few years we'll run out of letters anyway.
 
  Just my two cents.
 
  Adam
 
 
  *Adam Lawson*
 
  AQORN, Inc.
  427 North Tatnall Street
  Ste. 58461
  Wilmington, Delaware 19801-2230
  Toll-free: (844) 4-AQORN-NOW ext. 101
  International: +1 302-387-4660
  Direct: +1 916-246-2072
 
 
  On Thu, Jul 9, 2015 at 12:18 PM, Tim Bell tim.b...@cern.ch wrote:
 
  Feel free to give input on the Mitaka proposal.
 
  Tim
 
  -Original Message-
  From: Jonathan Bryce [mailto:jbr...@jbryce.com]
  Sent: 09 July 2015 20:52
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Openstack] Rescinding the M name decision
 
  On Jul 9, 2015, at 9:35 AM, Russell Bryant rbry...@redhat.com
 wrote:
 
  On 07/09/2015 09:19 AM, Neil Jerram wrote:
  In the hope of forestalling an unnecessary sub-thread...
 
  Mita was #1 in the vote, so has presumably already been ruled out by
  OpenStack's legal review.
 
  That is correct.
 
 
  Hi everyone,
 
  I’ve really loved seeing everyone’s understanding and engagement on
 this
  thread as we worked through the release cycle naming for ‘M’. This was
  the
  first attempt to follow a new process, so not surprisingly, we found
 some
  improvements in the algorithm for the future. Still it’s awesome to see
  how
  constructive and positive the whole conversation has been.
 
  I wanted to provide a quick update on the status of the Foundation’s
  reviews of the names. First, as Russell mentioned above, after the
 voting
  was completed, we asked our trademark counsel to do checks on the top 3
  names. The first two both had significant trademark issues with
 existing
  trademark holders in the same space that would have prevented us from
  using the names in most jurisdictions where we have our largest
  communities (US, Europe and Asia). The 3rd choice was relatively low
 risk
  and so we passed word back to Monty who announced it. Once we realized
  there were other issues with Meiji, we asked for an expedited check of
  the
  next 3 names: Mitaka, Musashi, and Meguro. The preliminary check shows
  that Mitaka and Meguro both present an acceptable level of risk, while
  Musashi is higher on the risk scale and would probably create problems
  for
  usage.
 
  At this time, we’re going to do a deeper check on Mitaka, which was the
  #4
  candidate in voting and would be next in line after Meiji. I know
  Itoh-san
  mentioned the Mitaka locale has the potential to be associated with
  certain
  corporations in Japan, but my personal feeling is that may not be
  significant
  enough to override it’s position in the voting and it’s availability
 for
  use.
 
  I’d encourage anyone with other concerns about Mitaka to post those
  within the next 24 hours so we can appropriately consider and discuss
  them. We should have results on the deeper trademark check by next week
  as well and can hopefully settle on a final name

Re: [openstack-dev] [Openstack-operators] [Openstack] Rescinding the M name decision

2015-07-09 Thread Adam Lawson
It seems we have a golden opportunity here to improve efficiency by vetting
names before we vote on them. Seems that voting for a bunch of names then
eliminating all of the top votes because they won't work doesn't strike me
as very efficient (i.e. why vote on names that MIGHT be valid).

The alternative of course is to just number the releases since names
ultimately don't mean anything but it seems there are problems with that
level of simplicity. I personally prefer Tristan's suggestion to keep it as
simple as possible. In a few years we'll run out of letters anyway.

Just my two cents.

Adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Thu, Jul 9, 2015 at 12:18 PM, Tim Bell tim.b...@cern.ch wrote:

 Feel free to give input on the Mitaka proposal.

 Tim

  -Original Message-
  From: Jonathan Bryce [mailto:jbr...@jbryce.com]
  Sent: 09 July 2015 20:52
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Openstack] Rescinding the M name decision
 
   On Jul 9, 2015, at 9:35 AM, Russell Bryant rbry...@redhat.com wrote:
  
   On 07/09/2015 09:19 AM, Neil Jerram wrote:
   In the hope of forestalling an unnecessary sub-thread...
  
   Mita was #1 in the vote, so has presumably already been ruled out by
   OpenStack's legal review.
  
   That is correct.
 
 
  Hi everyone,
 
  I’ve really loved seeing everyone’s understanding and engagement on this
  thread as we worked through the release cycle naming for ‘M’. This was
 the
  first attempt to follow a new process, so not surprisingly, we found some
  improvements in the algorithm for the future. Still it’s awesome to see
 how
  constructive and positive the whole conversation has been.
 
  I wanted to provide a quick update on the status of the Foundation’s
  reviews of the names. First, as Russell mentioned above, after the voting
  was completed, we asked our trademark counsel to do checks on the top 3
  names. The first two both had significant trademark issues with existing
  trademark holders in the same space that would have prevented us from
  using the names in most jurisdictions where we have our largest
  communities (US, Europe and Asia). The 3rd choice was relatively low risk
  and so we passed word back to Monty who announced it. Once we realized
  there were other issues with Meiji, we asked for an expedited check of
 the
  next 3 names: Mitaka, Musashi, and Meguro. The preliminary check shows
  that Mitaka and Meguro both present an acceptable level of risk, while
  Musashi is higher on the risk scale and would probably create problems
 for
  usage.
 
  At this time, we’re going to do a deeper check on Mitaka, which was the
 #4
  candidate in voting and would be next in line after Meiji. I know
 Itoh-san
  mentioned the Mitaka locale has the potential to be associated with
 certain
  corporations in Japan, but my personal feeling is that may not be
 significant
  enough to override it’s position in the voting and it’s availability for
 use.
 
  I’d encourage anyone with other concerns about Mitaka to post those
  within the next 24 hours so we can appropriately consider and discuss
  them. We should have results on the deeper trademark check by next week
  as well and can hopefully settle on a final name.
 
  Thanks again for all the discussion and participation and especially to
  Monty who’s been on the front lines of helping us navigate this. Feel
 free to
  let me know if you have any other questions,
 
  Jonathan
  210-317-2438
 
 
  __
  
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: OpenStack-dev-
  requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 ___
 OpenStack-operators mailing list
 openstack-operat...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS capabilities

2015-06-28 Thread Adam Lawson
If fwaas code is at the router level, it would seem that null routing might
be one method of handling ddos, making fwaas a potentially suitable
program. Qos seems to address quality issues rather than focusing on
protection from unauthorized or malicious traffic whether that traffic
originates from the inside or externally. That seems again, to me, as a
fwaas-centric function.

Just my two cents. ;)
On Jun 28, 2015 6:19 PM, John Joyce (joycej) joy...@cisco.com wrote:

  Gal:

  I am also slow to jump between this and other work so I think I
 should be the one apologizing.  I think we are receptive to any of the
 approaches QoS, FWaaS or Security Groups.  I am not an expert on FWaaS but
 from a quick look it seemed like the FWaaS granularity was at the router
 level.  We would want this per neutron port (e.g. per VM port although
 don’t want to limit the possibility for this be per container or per bare
 metal port).   Allowing an aggregate across all ports of the VM would be
 very nice,  but not a strict requirement.   Do you see this as an issue
 going the FWaaS route?   Have you been making any headway getting it in
 there?

  One detailed comment after looking through the reviews.   Would there
 be any issue in adding a “reject-with-tcp-reset” option?

 The DDOS coming from a VM could be due to a virus within the VM our
 maybe just an overly aggressive tenant.  I know the team that runs our
 cloud offering has experienced an excessive connection requests coming from
 a VM.   I can try to get the exact scenario that triggered this.   The net
 is that all tenants on that host can be affected,  especially with an OVS
 based vswitch.

  John











 *From:* Gal Sagie [mailto:gal.sa...@gmail.com]
 *Sent:* Tuesday, June 23, 2015 2:43 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Cc:* lionel.zer...@huawei.com; Derek Chamorro (dechamor); Eran Gampel
 *Subject:* Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS
 capabilities



 Hi John,



 Sorry for the delayed response as i was on vacation with no internet
 connection (you don't know how much

 you miss it until you don't have it).



 The work in terms of coding is pretty much done for the reference
 implementation.

 We initially tried to push it as a security group extension but there is a
 strong objection

 to change the security group API, so FWaaS can be next best candidate if
 we can find support

 or other uses of this (like your use case)

 (Of course that work will need to be added for supporting the connection
 limit, we tried

 to  tackle brute force prevention which i personally see as a more
 concerning attack vector internally)



 Out of curiosity can you describe scenarios of DDoS attacking from an
 internal VM ?

 I would assume most DDoS will happen from external traffic or a combine
 attack from various internal

 VM's (and then this might no longer fit as a QoS)



 But if you feel this belongs in QoS this can certainly be added on top of
 the framework as Miguel suggested.



 Thanks

 Gal.



 On Fri, Jun 19, 2015 at 12:39 AM, John Joyce (joycej) joy...@cisco.com
 wrote:

 Gal:

   I had seen the brute force blueprint and noticed how close the use
 case was.  Can you tell me the current status of the work?  Do you feel
 confident it can get into Liberty?  Ideally, we think this fits better with
 QoS.  Also I don’t think of it as providing FWaaS as we see that all VMs
 would be protected by this when enabled, but maybe that is just
 terminology.   We think these protections are critical so we are more
 concerned with having the ability to protect against these cases than the
 specific API or service it falls under.  Yes we would be interested in
 working together to get this pushed through.


 John



 *From:* Gal Sagie [mailto:gal.sa...@gmail.com]
 *Sent:* Wednesday, June 17, 2015 12:45 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Cc:* lionel.zer...@huawei.com; Derek Chamorro (dechamor); Eran Gampel
 *Subject:* Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS
 capabilities



 Hi John,



 We were trying to push a very similar spec to enhance the security group
 API, we covered both DDoS case

 and another use case for brute force prevention (We did a research to
 identify common protocols login behaviour

 in order to identify brute force attacks using iptables) and even some UI
 work



 You can view the specs and implementations here:

 1) https://review.openstack.org/#/c/184243/

 2) https://review.openstack.org/#/c/154535/

 3) https://review.openstack.org/#/c/151247/

 4) https://review.openstack.org/#/c/161207/



 The spec didn't got approved as there is a strong opinion to keep the
 security group API compatible with Amazon.

 I think this and your request fits much more into the FWaaS and if this is
 something you would like to work together on and push

 i can help and align the above code to use FWaaS.



 Feel 

[openstack-dev] [Ironic] development team

2015-05-29 Thread Adam Lawson
I have a question I'd like to ask offline... Can someone from the ironic
team ping me? Have a question about pxe...
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [swift] Go! Swift!

2015-05-07 Thread Adam Lawson
Chuck (and/or others who understand tor have experienced the limits of
Python)

I found this comment of yours incredibly intriguing: we are running out of
incremental improvements that can be made with Python.

Given your work with Swift thus far, what sort of limitations have you
discovered that had to do specifically with the fact we're using Python? I
haven't run into real-life limitations specific to a particular language
before (I usually run into issues with my approach rather than limitations
with the language itself) so i find this to be a fascinating (and perhaps
accidental) consideration.



*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Thu, May 7, 2015 at 3:48 PM, Clint Byrum cl...@fewbar.com wrote:

 Excerpts from Chuck Thier's message of 2015-05-07 13:10:13 -0700:
  I think most are missing the point a bit.  The question that should
 really
  be asked is, what is right for Swift to continue to scale.  Since the
  inception of Openstack, Swift has had to solve for problems of scale that
  generally are not shared with the rest of Openstack.
 
  When we first set out to write Swift, we had set, what we thought at the
  time were pretty lofty goals for ourselves:
 
  * 100 Billion objects
  * 100 Petabytes of data
  * 100 K requests/second
  * 100 Gb/s throughput
 
  We started with Python figuring that when we hit major bottlenecks, we
  would look at other options.  We have been surprised at how far we have
  been able to push Python and have met most if not all of the goals above.
 
  As we look toward the future, we realize that we are now looking for how
 we
  will support trillions of objects, 100's of petabytes to exabytes of
 data,
  etc.  We feel that we have finally hit that point that we need more than
  incremental improvements, and that we are running out of incremental
  improvements that can be made with Python.
 
  What started as a simple experiment by Mike Barton, has turned into
 quite a
  significant improvement in performance and builds a base that can be
 built
  off of for future improvements.  This wasn't built because of it being
  shiny but out of direct need, and is currently being tested with great
  results on production workloads.
 
  I applaud the team that has worked on this at Rackspace, and hope the
  community can look at the current needs of Swift, and the merits of the
  work that has been accomplished, rather than the politics of shiny.
 

 Chuck, much respect to you and the team for everything accomplished.

 I'm still very curious to hear if anybody has been willing to try to
 make Swift work on pypy. This is pretty much why pypy exists, and making
 pypy work for Swift could mean some really nice residual benefits to the
 other projects that haven't gone as far as to experiment with a compiled
 language like Go yet. There's also the other benefit that pypy would
 gain some eyeballs and improvements that we could feed back into it.

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates

2015-05-05 Thread Adam Lawson
Doug, it isn't about me or about trying to add more to the pool of one type
of contributor from a different pool of individuals with a different
skillset or about attempting to make shortcuts to leadership as you so
delicately put it. Frankly I think you're missing the point. When there is
a technical body governing everything of a technical nature within
OpenStack and it consists of members from one slice of the overall
community and candidates speak of engaging the operator community more than
it has in the past as part of the reason folks should vote for them, I
think the candidates are on point and we have an opportunity in front of
us. Has nothing to do with broadening the pool of one specific type of
contributor but about taking advantage of those who are already
contributing in a different way. That's a strength in our community and
when the tc appears to be moving towards technical leadership that paints
with broader multi-discipline strokes, I'm completely on board with that.
On May 5, 2015 6:07 AM, Doug Hellmann d...@doughellmann.com wrote:

Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700:
 So Thierry I agree. Developers are required to make it happen. I would say
 however that acknowledging the importance of developer contributions and
 selecting leadership from the development community is really half the
 battle as it's pretty rare to see project teams led and governed by only
 developers. I think addressing the inclusion of
architects/operators/admins
 within this committee is a hugely positive development.

The community of contributors is led by members, not all of whom
are developers -- some are writers, translators, designers, or
fill other important roles. The characteristic that cuts across all
of those roles is that they are *contributors*.

If architects/operators/admins or anyone else want to become
contributors, there is already a path to accomplish that by interacting
with the existing teams, and their insight and input would be very
welcome. But there is no shortcut to becoming a leader in this
community. Everyone has to earn their stripes.

I've asked a couple of times in this thread what benefit you see
in having someone from outside of the contributor community on the
TC, but I haven't seen an answer. Is there something specific we
could be addressing beyond the question of representation?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates

2015-05-05 Thread Adam Lawson
I think the ATC thing came up as one avenue to explore when folks were
trying to figure out ways to quantify Operator involvement for the purpose
of identifying who are actively contributing to OpenStack versus those who
are fans/users of OpenStack but don't have time right now to contribute
more formally. ATC, BTC, CTC, DTC... there are several great ideas that
were brought up as possibilities as well as some take-aways for further
discussion at the Vancouver Summit and the talking points for the User
Committee. I'm really crossing my fingers this translates into something
noticeably unique starting with the next election. In my perfect world
anyway. ; )


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Tue, May 5, 2015 at 7:59 AM, Doug Hellmann d...@doughellmann.com wrote:

 Excerpts from Adam Lawson's message of 2015-05-05 07:01:48 -0700:
  Doug, it isn't about me or about trying to add more to the pool of one
 type
  of contributor from a different pool of individuals with a different
  skillset or about attempting to make shortcuts to leadership as you so
  delicately put it. Frankly I think you're missing the point. When there
 is
  a technical body governing everything of a technical nature within
  OpenStack and it consists of members from one slice of the overall
  community and candidates speak of engaging the operator community more
 than
  it has in the past as part of the reason folks should vote for them, I
  think the candidates are on point and we have an opportunity in front of
  us. Has nothing to do with broadening the pool of one specific type of
  contributor but about taking advantage of those who are already
  contributing in a different way. That's a strength in our community and
  when the tc appears to be moving towards technical leadership that paints
  with broader multi-discipline strokes, I'm completely on board with that.

 Early on in the thread I thought you wanted community members without
 ATC status to be able to vote for and run for the TC. Maybe I
 misunderstood what you were saying?

 Doug

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates

2015-05-04 Thread Adam Lawson
So Thierry I agree. Developers are required to make it happen. I would say
however that acknowledging the importance of developer contributions and
selecting leadership from the development community is really half the
battle as it's pretty rare to see project teams led and governed by only
developers. I think addressing the inclusion of architects/operators/admins
within this committee is a hugely positive development.

I also liked your suggestions earlier about potential ways to implement.
On May 4, 2015 9:31 AM, Thierry Carrez thie...@openstack.org wrote:

 Maish Saidel-Keesing wrote:
  A three point triangle. I like the idea! Anita I assume that you are
  talking about the TC[3], the board [1] and the user committee [2].
 
  I honestly do not see this at the moment as an equally weighted triangle.
  Should they be? Perhaps not, maybe yes.
 
  It could be that my view of things is skew, but here it is.
 
  The way to get something into OpenStack is through code.
  Who submits the code? Developers.
  Who approves code? Reviewers and core
  On top of that you have the PTL
  Above the PTL - you have the TC. They decide what is added into
  OpenStack and (are supposed) drive overall direction.
 
  These are the people that have actionable influence into what goes into
  the products.
 
  AFAIK neither the Foundation - nor the User committee have any
  actionable influence into what goes into the products, what items are
  prioritized and what is dropped.

 That's simply acknowledging the mechanics of an open source / open
 innovation project like OpenStack. Having the Board or the User
 committee decide what goes into the products, what items are
 prioritized and what is dropped won't make it magically happen. At the
 end of the day, you need a contributor willing to write, review,
 prioritize that code.

 The contributors to an open source project ultimately make things go in
 the open source project. They can be (and should be) influenced by
 outside input, especially users of the project. Companies can influence
 what is being worked on by funding developers to work on specific
 things. But in the end, it all boils down to contributors that get the
 work done and therefore make it going in one direction or another.

 --
 Thierry Carrez (ttx)

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [all] OpenStack project testing, gating etc

2015-05-03 Thread Adam Lawson
Can someone please point me to where OpenStack testing processes are
explained? Which systems is/are used, how it tied into Jenkins, what gates
are, etc. I'm not a developer but this stuff has been an area that I
haven't explored for far too long. I keep running into URL's that are
labeled obsolete.

Many thanks!

Mahalo,
Adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Elections] TC Election analysis

2015-05-03 Thread Adam Lawson
Keep in mind also there is an increasing interest with potentially
integrating Operators in some manner.Judging from the candidates statements
anyway. Whatever we pursue to improve engagement, it will be interesting to
see how an expressed desire to represent the Operator community actually
translates into tangible steps. Not from a disinterest but because some
logistics approaches are easier than others to adopt.


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Sun, May 3, 2015 at 12:35 PM, Cody A.W. Somerville 
cody-somervi...@ubuntu.com wrote:

 On Thu, Apr 30, 2015 at 4:00 PM, Joe Gordon joe.gord...@gmail.com wrote:

 On Thu, Apr 30, 2015 at 1:28 PM, Maish Saidel-Keesing 
 mais...@maishsk.com wrote:

 On 04/30/15 21:48, Joe Gordon wrote:

 As others have done for past elections, here is a brief breakdown of
 the TC election ballot data.

 analysis: http://paste.openstack.org/show/213831
 source code: http://paste.openstack.org/show/213830

 snip

  Thanks Joe for the analysis. It is quite interesting. Another thing that
 I find interesting is the low participation rate.

 Out of 2169 eligible voters, 548 participated - that is 25.26%.


 According to [0] there were 369 ”Regular” contributors in 2014, and in
 Kilo there were only 748 contributors with 5 or more patches out of
 the 1886 contributors [1]. So measuring participation from eligible votes
 is a misleading. Well over half of the eligible voters have only
 contributed a few patches, and we had more voters participate then we have
 'regular' contributors.  So I think our turnout is actually really good.

 [0] https://www.openstack.org/assets/reports/osf-annual-report-2014.pdf
 [1] http://stackalytics.com/?release=kilometric=commits



 Comparing to previous elections
 Oct. 2014 - 1893 eligible voters, 506 participated - 26.73%
 Apr. 2014 - 1510 eligible voters, 408 participated - 29.66%

 I am wondering why the participation level is so low. This is really one
 of the few opportunities a contributor has to define the direction of
 OpenStack as a whole. And yet it goes down each election.


 I would also hypothesize that contributors who are eligible but less
 regular in their contribution may not pay as much attention (or even be
 subscribed? -- would be an interesting metric to see I imagine) to the
 mailing list where a majority of the promotion and election activity occur.

 Where do all code contributors visit? Gerrit. If we were able to put up
 Clippy on Gerrit for April Fools, maybe we could put something up to raise
 awareness during the next election cycle? This could include linking people
 to the election wiki page and reminding eligible folks to ensure they have
 their correct e-mail address in Gerrit in order to receive a ballot.

 --
 Cody A.W. Somerville


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates

2015-05-01 Thread Adam Lawson
So this is an interesting idea. Would we require operators co-author/review
all patches that land? if not (and that actually strikes me as making
uploading patches more difficult unnecessarily), My question is how
Operators can easily get involved with that process.

If Operators want to get recognized for contributing and participate with
TC elections, an easy way to start an engagement with some means of
tracking would be immensely helpful I think.

Does the current system allow this kind of co-authoring/operator review
sort of thing?


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Fri, May 1, 2015 at 8:44 AM, Joshua Harlow harlo...@outlook.com wrote:

 Davanum Srinivas wrote:

 One concrete suggestion based on my experience working with Kris
 Lindgren on Heartbeat patch:
 http://markmail.org/message/gifrt5f3mslco24j

 I could have added a Co-Tested-By (or Co-Operator - get it? :) in
 my commit message which would have signaled a concrete
 contribution/feedback with specific folks in the operator community.
 This could be done not just for code, could be for reviews or
 documentation etc as well. WDYT?


 +1 Kris is a great example, and I can think of other operators that should
 be some sort of ATC (but may not contribute code to get this). IMHO any
 operator running openstack (let's say at least at 50+ compute nodes) and
 operating it should get full access to the summit, because their words of
 advice/experience are just as useful as technical contributors...



 thanks,
 dims

 On Thu, Apr 30, 2015 at 9:06 PM, Adam Lawsonalaw...@aqorn.com  wrote:

 I think it's easy to quantify a code contributor since we have systems
 that
 monitor activity - who contributed, what they contributed and when. But
 we
 don't have a system that monitors operator activity and honestly, that's
 the
 question mark for which I really don't have any answers. That might be
 our
 first hurdle - how define the difference between a causal user making
 remarks on the mailing lists and someone who works with the technology
 and
 engages. We'd have to quantify them differently somehow.

 Maybe attending an operators meeting would qualify someone to vote?

 On Apr 30, 2015 5:35 PM, Stefano Maffullistef...@openstack.org
 wrote:

 On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote:

 I've seen the number of threads to discuss Ops topics increase in
 openstack-dev and the influence of Ops - even just points of views
 inherited from the feedback we've got - on reviews has gotten better
 as well.

 Fantastic, that has always been the intention.

  If it's a matter of having more Ops voting for the TC, we do have a
 process in place that we could likely improve. Other than that, I
 believe Thierry and Doug have explained perfectly the issues related
 to having these 2 groups merged from a *governance* perspective.

 I noticed that this round of elections we had TC *candidates* that at
 least I consider more operators than strictly 'dev'. That, to me, is a
 huge sign of the progress we've made to integrate the two categories.

 To me the real big question is: how are candidates from the operators
 side going to get a better chance of being elected next time?

 And what's the role of the User Committee in all this?

 /stef



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates

2015-05-01 Thread Adam Lawson
I purposely didn't email the general mailing list since I didn't want to
cross-post, hard to have these discussions across verticals and choosing
one list = hearing one community - those subscribed to the developer
mailing list.

So I'm not assuming anything, it seems some are suggesting that Operators
get into code review to quantify their role as an engaged Operator. Is that
a correct statement? Just want to make sure I'm hearing correctly. I try to
avoid absolutes but personally speaking for the record, I don't believe the
answer lies with asking Operators to become code reviewers on top of
everthing else they're doing in order for them to have a voice in the TC
elections. If code reviews are being suggested (again, assuming the
assumption is correct for the sake of making my point), technical
contribution extends far beyond uploading and reviewing code. This
alternate means to gain ATC status seems like a potential candidate for
those who want to review code but not for those who are day-to-day
operators engaging with the community.

Is there any meetings planned in Vancouver where users/operators are
meeting where we can add an agenda items to gather input?

Given this conversation involves the Operator community as well, I went
ahead and CC'd them to hopefully capture their specific thoughts/ideas on
the subject.

Mahalo,
Adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Fri, May 1, 2015 at 12:22 PM, Morgan Fainberg morgan.fainb...@gmail.com
wrote:



 On Friday, May 1, 2015, Russell Bryant rbry...@redhat.com wrote:

 On 05/01/2015 02:22 PM, Tim Bell wrote:
 
  The spec review process has made it much easier for operators to see
  what is being proposed and give input.
 
  Recognition is a different topic. It also comes into who would be the
  operator/user electorate ? ATC is simple to define where the equivalent
  operator/user definition is less clear.

 I think spec review participation is a great example of where it would
 make sense to grant extra ATC status.  If someone provides valuable spec
 input, but hasn't made any commits that get ATC status, I'd vote to
 approve their ATC status if proposed.


 This is exactly the case for David Chadwick (U of Kent) if anyone is
 looking for prior examples of someone who has contributed to the spec
 process but has not landed code and has received ATC for the contributions.

 This is a great way to confer ATC for spec participation.

 --Morgan


 --
 Russell Bryant

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates

2015-04-30 Thread Adam Lawson
For the record, thanks for your replies guys. I am not suggesting any
specific means to resolve or suggesting what we're doing is wrong; only
that the current structure seems odd.

The TC charter, as I read it, states that the TC committee represents
everything of a technical nature of OpenStack via this quote: generally
has technical oversight over all of OpenStack. That includes whatever the
Operators contribute or engage with (all of OpenStack). Given OpenStack
has a vibrant Operators community who contribute a great deal in terms of
rubber on the road feedback, suggestions for improvement and real-world
implementation reality checks, it seems appropriate that the committee
tasked to oversee everything technical within OpenStack (which I think we
all agree encompasses more than those who contribute code) should not be
disallowing one community but allowing another to elect that committee.

This i know is totally my opinion, but if we require Operators to seek
special approval, that doesn't seem to fit our ideal goals of Commonality.
Whatever we need to do to quantify those who contribute to OpenStack versus
those who don't is tricky I agree. I don't know the answer. But it would
seem to me the current situation is ripe for a change.


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Thu, Apr 30, 2015 at 3:26 AM, Flavio Percoco fla...@redhat.com wrote:

 On 30/04/15 12:07 +0300, Maish Saidel-Keesing wrote:


 On 04/30/15 10:15, Thierry Carrez wrote:

Doug Hellmann wrote:

Anyway, I find it curious that the TC is elected by those
 within the
developer community but TC candidates talk about representing
 the operator
community who are not allowed to vote. Operators meaning
 Admins,
Architects, etc. It sounds like this is something most TC
 candidates want
which most would agree is a good thing. At least I think so. ;
 )

I'm going to nitpick on terminology a bit. The TC is elected by
*technical contributors*, not developers, as described in the
 charter:

 http://governance.openstack.org/reference/charter.html#voters-for-tc-seats-atc

+1

I think there is a key misconception in this thread that the TC is
supposed to represent (or talk about representing) more than just the
technical contributors that produce OpenStack.

When the OpenStack Foundation was set up, three bodies of governance
were established:

- the Board of Directors (representing the community as a whole)
- the Technical Committee (representing technical contributors)
- the User Committee (representing users and ops of OpenStack)

The Technical Committee mandate is therefore not to represent the users
and Ops of OpenStack in that setup, it's the role of the User
 committee.
If we did include Ops, we would be clearly overstepping our mandate.

 Thierry, essentially I agree with you. I do think though that the
 disconnect
 between Dev  Ops is an unhealthy situation. Two separate bodies working
 in two
 different ways with two different agendas is actually very much against
 the
 current way that most development organizations are aspire towards.

 The TC charter [1] states.

  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.

 IMHO, the spirit of the original question that was raised was - how can
 all of
 OpenStack only be those who write the code, and not those that use and
 operate
 it on a day to day basis?


 Are these thoughts based on the current state of OpenStack? or are
 they influenced a bit by our past?

 The reason I ask is because I believe we've come a long way on
 integrating more with Ops and Users. New groups have been created, new
 meetups have been run, a dedicated day has been assigned at the
 summit, a dedicated mailing list - that most of us follow - has been
 created, etc, etc, etc.

 I've seen the number of threads to discuss Ops topics increase in
 openstack-dev and the influence of Ops - even just points of views
 inherited from the feedback we've got - on reviews has gotten better
 as well.

 While I don't consider we're there yet, I do think there have been
 several improvements in this area, which is why I'm curious to know
 the answer to my questions above.

 If it's a matter of having more Ops voting for the TC, we do have a
 process in place that we could likely improve. Other than that, I
 believe Thierry and Doug have explained perfectly the issues related
 to having these 2

Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates

2015-04-30 Thread Adam Lawson
I think it's easy to quantify a code contributor since we have systems that
monitor activity - who contributed, what they contributed and when. But we
don't have a system that monitors operator activity and honestly, that's
the question mark for which I really don't have any answers. That might be
our first hurdle - how define the difference between a causal user making
remarks on the mailing lists and someone who works with the technology and
engages. We'd have to quantify them differently somehow.

Maybe attending an operators meeting would qualify someone to vote?
On Apr 30, 2015 5:35 PM, Stefano Maffulli stef...@openstack.org wrote:

 On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote:
  I've seen the number of threads to discuss Ops topics increase in
  openstack-dev and the influence of Ops - even just points of views
  inherited from the feedback we've got - on reviews has gotten better
  as well.

 Fantastic, that has always been the intention.

  If it's a matter of having more Ops voting for the TC, we do have a
  process in place that we could likely improve. Other than that, I
  believe Thierry and Doug have explained perfectly the issues related
  to having these 2 groups merged from a *governance* perspective.

 I noticed that this round of elections we had TC *candidates* that at
 least I consider more operators than strictly 'dev'. That, to me, is a
 huge sign of the progress we've made to integrate the two categories.

 To me the real big question is: how are candidates from the operators
 side going to get a better chance of being elected next time?

 And what's the role of the User Committee in all this?

 /stef


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [tc] Who is allowed to vote for TC candidates

2015-04-29 Thread Adam Lawson
So I started replying to Doug's email in a different thread but didn't want
to hi-jack that so I figured I'd present my question as a more general
question about how voting is handled for the TC.

Anyway, I find it curious that the TC is elected by those within the
developer community but TC candidates talk about representing the operator
community who are not allowed to vote. Operators meaning Admins,
Architects, etc. It sounds like this is something most TC candidates want
which most would agree is a good thing. At least I think so. ; )

Is it be feasible to start allowing the operator community to also cast
votes for TC candidates? Is the TC *only* addressing technical concerns
that are relevant to the development community? Since the TC candidates are
embracing the idea of representing more than just the developer community,
it would /seem/ the voters electing the TC members should include the
communities being represented. If the TC only addresses developer concerns,
it would seem they become at risk of losing touch with the
operator/architecture/user concerns because the operator community voice is
never heard in the voting booth.

Perhaps this bumps into how it used to be versus how it should be. I don't
know. Just struck me as incongruent with the platform of almost every
candidate - broadening representation while the current rules prohibit that
level of co-participation.

Thoughts?


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Nova][Cinder] Questions re progress

2015-03-18 Thread Adam Lawson
Hi everyone,

Got some questions for whether certain use cases have been addressed and if
so, where things are at. A few things I find particularly interesting:

   - Automatic Nova evacuation for VM's using shared storage
   - Using Swift as a back-end for Cinder

I know we discussed Nova evacuate last year with some dialog leading into
the Paris Operator Summit and there were valid unknowns around what would
be required to constitute a host being down, by what logic that would be
calculated and what would be required to initiate the move and which
project should own the code to make it happen. Just wondering where we are
with that.

On a separate note, Ceph has the ability to act as a back-end for Cinder,
Swift does not. Perhaps there are performance trade-offs to consider but
I'm a big fan of service plane abstraction and what I'm not a fan of is
tying data to physical hardware. The fact this continues to be the case
with Cinder troubles me.

So a question; are these being addressed somewhere in some context? I
admittedly don't want to distract momentum on the Nova/Cinder teams, but I
am curious if these exist (or conflict) with our current infrastructure
blueprints?

Mahalo,
Adam

*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova][Cinder] Questions re progress

2015-03-18 Thread Adam Lawson
The aim is cloud storage that isn't affected by a host failure and major
players who deploy hyper-scaling clouds architect them to prevent that from
happening. To me that's cloud 101. Physical machine goes down, data
disappears, VM's using it fail and folks scratch their head and ask this
was in the cloud right? That's the indication of a service failure, not a
feature.

I'm just a very big proponent of cloud arch that provides a seamless
abstraction between the service and the hardware. Ceph and DRDB are decent
enough. But tying data access to a single host by design is a mistake IMHO
so I'm asking why we do things the way we do and whether that's the way
it's always going to be.

Of course this bumps into the question whether all apps hosted in the cloud
should be cloud aware or whether the cloud should have some tolerance for
legacy apps that are not written that way.



*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Wed, Mar 18, 2015 at 10:59 AM, Duncan Thomas duncan.tho...@gmail.com
wrote:

 I'm not sure of any particular benefit to trying to run cinder volumes
 over swift, and I'm a little confused by the aim - you'd do better to use
 something closer to purpose designed for the job if you want software fault
 tolerant block storage - ceph and drdb are the two open-source options I
 know of.

 On 18 March 2015 at 19:40, Adam Lawson alaw...@aqorn.com wrote:

 Hi everyone,

 Got some questions for whether certain use cases have been addressed and
 if so, where things are at. A few things I find particularly interesting:

- Automatic Nova evacuation for VM's using shared storage
- Using Swift as a back-end for Cinder

 I know we discussed Nova evacuate last year with some dialog leading into
 the Paris Operator Summit and there were valid unknowns around what would
 be required to constitute a host being down, by what logic that would be
 calculated and what would be required to initiate the move and which
 project should own the code to make it happen. Just wondering where we are
 with that.

 On a separate note, Ceph has the ability to act as a back-end for Cinder,
 Swift does not. Perhaps there are performance trade-offs to consider but
 I'm a big fan of service plane abstraction and what I'm not a fan of is
 tying data to physical hardware. The fact this continues to be the case
 with Cinder troubles me.

 So a question; are these being addressed somewhere in some context? I
 admittedly don't want to distract momentum on the Nova/Cinder teams, but I
 am curious if these exist (or conflict) with our current infrastructure
 blueprints?

 Mahalo,
 Adam

 *Adam Lawson*

 AQORN, Inc.
 427 North Tatnall Street
 Ste. 58461
 Wilmington, Delaware 19801-2230
 Toll-free: (844) 4-AQORN-NOW ext. 101
 International: +1 302-387-4660
 Direct: +1 916-246-2072


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Duncan Thomas

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Fwd: [Neutron] ML2 + Nexus :: update_port_precommit ERROR

2015-03-01 Thread Adam Lawson
Hello,

Sending this message to the dev group instead since I may be running into a
bug (https://bugs.launchpad.net/neutron/+bug/1247976/+activity). I'm
running Icehouse (modules come up as 2014.1.3 generally).

Thoughts?

*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


-- Forwarded message --
From: Adam Lawson alaw...@aqorn.com
Date: Sat, Feb 28, 2015 at 2:30 PM
Subject: [Neutron] ML2 + Nexus :: update_port_precommit ERROR
To: openstack openst...@lists.openstack.org


I'm experimenting with OpenStack Icehouse with a dedicated Network node
using the ML2 plugin, cisco_nexus mechanism driver and seeing Neutron
errors relating to *update_port_precommit* and *delete_port_precommit*.
Defined type driver is VLAN. Problem is being unable to boot instances
using Private or Public networks.

Is this a known bug when using ML2 with Cisco Nexus switches or is it
resolvable? Has anyone else run into this?

Mahalo,
Adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Neutron] HTTP-based switch config/mgmt with API control

2015-02-20 Thread Adam Lawson
Howdy folks.

Does anyone know of any open source projects that facilitate managing
switches from within a browser (not CLI)? I know there are mechanism
drivers today that allow the ML2 plug-in to connect directly to a switch
via SSH and add/remove VLAN's, I'm wondering if this has been implemented
somewhere where it can be done within a browser or with some guts governed
by some kind of API.

We are wondering if we need to analyze how Neutron goes about this and
create something from scratch or if we can build upon the efforts of others.

Mahalo,
Adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] OpensStack w/ Chef

2015-02-04 Thread Adam Lawson
Question: is there a tool that does the same sort of things as Mcollective
but is specific to Chef? I know Mcollective is compatible with Chef, but
I'd like to research tooling native to the Chef platform if possible... (if
that makes any sense)


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Cinder][nova] Cinder backend for ephemeral disks?

2015-01-31 Thread Adam Lawson
Question, looks like this spec was abandoned , hard to tell if it is being
addressed elsewhere? Good idea that received a -2 then ultimately abandoned
sure to juno freeze I think.

https://blueprints.launchpad.net/nova/+spec/nova-ephemeral-cinder
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] Take back the naming process

2015-01-29 Thread Adam Lawson
Hi Anne; this was more or less directed in Monty's direction and/or those
in agreement with his position. Sorry for the confusion, I probably should
have been a bit more clear. ; )

Mahalo,
Adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Thu, Jan 29, 2015 at 9:05 AM, Anita Kuno ante...@anteaya.info wrote:

 On 01/28/2015 07:24 PM, Adam Lawson wrote:
  I'm short on time so I apologize for my candor since I need to get
 straight
  to the point.
 
  I love reading the various opinions and my team is immensely excited with
  OpenStack is maturing. But this is lunacy.
 
  I looked at the patch being worked [1] to change how things are done and
  have more questions than I can count.
 
  So I'll start with the obvious ones:
 
 - Are you proposing this change as a Foundation Individual Board
 Director tasked with representing the interests of all Individual
 Members
 of the OpenStack community or as a member of the TC? Context matters
 because your two hats are presenting a conflict of interest in my
 opinion.
 One cannot propose a change that gives them greater influence while
 suggesting they're doing it for everyone's benefit.
 How can Jim be proposing a change as a Foundation Individual Board
 Director? He isn't a member of the Board.

 http://www.openstack.org/foundation/board-of-directors/

 He is a member of the Technical Committee.

 http://www.openstack.org/foundation/tech-committee/

 Keep in mind that the repository that he offered the change to, the
 openstack/governance repository, welcomes patches from anyone who takes
 the time to learn our developer workflow and offers a patch to the
 repository using Gerrit.

 http://docs.openstack.org/infra/manual/developers.html

 Thanks,
 Anita.
 - How is fun remotely relevant when discussing process improvement?
 I'm really hoping we aren't developing processes based on how fun a
 process
 is or isn't.
 - Why is this discussion being limited to the development community
 only? Where's the openness in that?
 - What exactly is the problem we're attempting to fix?
 - Does the current process not work?
 - Is there group of individuals being disenfranchised with our current
 process somehow that suggests the process should limit participation
 differently?
 
  And some questions around the participation proposals:
 
 - Why is the election process change proposing to limit participation
 to
 ATC members only?
 There are numerous enthusiasts within our community that don't fall
 within the ATC category such as marketing (as some have brought up),
 corporate sponsors (where I live) and I'm sure there are many more.
 - Is taking back the process a hint that the current process is being
 mishandled or restores a sense of process control?
 - Is the presumption that the election process belongs to someone or
 some group?
 That strikes me as an incredibly subjective assertion to make.
 
  opinionThis is one reason I feel so strongly folks should not be
 allowed
  to hold more than one position of leadership within the OpenStack
 project.
  Obfuscated context coupled with increased influence rarely produces
  excellence on either front. But that's me./opinion
 
  Mahalo,
  Adam
 
  [1] https://review.openstack.org/#/c/150604/
 
 
  *Adam Lawson*
 
  AQORN, Inc.
  427 North Tatnall Street
  Ste. 58461
  Wilmington, Delaware 19801-2230
  Toll-free: (844) 4-AQORN-NOW ext. 101
  International: +1 302-387-4660
  Direct: +1 916-246-2072
 
 
  On Wed, Jan 28, 2015 at 10:23 AM, Anita Kuno ante...@anteaya.info
 wrote:
 
  On 01/28/2015 11:36 AM, Thierry Carrez wrote:
  Monty Taylor wrote:
  What if, to reduce stress on you, we make this 100% mechanical:
 
  - Anyone can propose a name
  - Election officials verify that the name matches the criteria
  -  * note: how do we approve additive exceptions without tons of
 effort
 
  Devil is in the details, as reading some of my hatemail would tell you.
  For example in the past I rejected Foo which was proposed because
  there was a Foo Bar landmark in the vicinity. The rules would have to
  be pretty detailed to be entirely objective.
  Naming isn't objective. That is both the value and the hardship.
 
  - Marketing team provides feedback to the election officials on names
  they find image-wise problematic
  - The poll is created with the roster of all foundation members
  containing all of the choices, but with the marketing issues clearly
  labeled, like this:
 
  * Love
  * Lumber
  Ohh, it gives me a thrill to see a name that means something even
  remotely Canadian. (not advocating it be added to this round)
  * Lettuce
  * Lemming - marketing issues identified
 
  - post poll - foundation staff run trademarks checks on the winners in
  order until a legally acceptable winner

Re: [openstack-dev] [Ironic] volunteer to be rep for third-party CI

2015-01-29 Thread Adam Lawson
Hi ruby, I'd be interested in this. Let me know next steps when ready?

Thanks!
On Jan 29, 2015 11:14 AM, Ruby Loo rlooya...@gmail.com wrote:

 Hi,

 Want to contribute even more to the Ironic community? Here's your
 opportunity!

 Anita Kuno (anteaya) would like someone to be the Ironic representative
 for third party CIs. What would you have to do? In her own words: mostly
 I need to know who they are so that when someone has questions I can work
 with that person to learn the answers so that they can learn to answer the
 questions

 There are regular third party meetings [1] and it would be great if you
 would attend them, but that isn't necessary.

 Let us know if you're interested. No resumes need to be submitted. In case
 there is a lot of interest, hmm..., the PTL, Devananda, will decide.
 (That's what he gets for not being around now. ;))

 Thanks in advance for all your interest,
 --ruby

 [1] https://wiki.openstack.org/wiki/Meetings#Third_Party_Meeting

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] Take back the naming process

2015-01-28 Thread Adam Lawson
I'm short on time so I apologize for my candor since I need to get straight
to the point.

I love reading the various opinions and my team is immensely excited with
OpenStack is maturing. But this is lunacy.

I looked at the patch being worked [1] to change how things are done and
have more questions than I can count.

So I'll start with the obvious ones:

   - Are you proposing this change as a Foundation Individual Board
   Director tasked with representing the interests of all Individual Members
   of the OpenStack community or as a member of the TC? Context matters
   because your two hats are presenting a conflict of interest in my opinion.
   One cannot propose a change that gives them greater influence while
   suggesting they're doing it for everyone's benefit.
   - How is fun remotely relevant when discussing process improvement?
   I'm really hoping we aren't developing processes based on how fun a process
   is or isn't.
   - Why is this discussion being limited to the development community
   only? Where's the openness in that?
   - What exactly is the problem we're attempting to fix?
   - Does the current process not work?
   - Is there group of individuals being disenfranchised with our current
   process somehow that suggests the process should limit participation
   differently?

And some questions around the participation proposals:

   - Why is the election process change proposing to limit participation to
   ATC members only?
   There are numerous enthusiasts within our community that don't fall
   within the ATC category such as marketing (as some have brought up),
   corporate sponsors (where I live) and I'm sure there are many more.
   - Is taking back the process a hint that the current process is being
   mishandled or restores a sense of process control?
   - Is the presumption that the election process belongs to someone or
   some group?
   That strikes me as an incredibly subjective assertion to make.

opinionThis is one reason I feel so strongly folks should not be allowed
to hold more than one position of leadership within the OpenStack project.
Obfuscated context coupled with increased influence rarely produces
excellence on either front. But that's me./opinion

Mahalo,
Adam

[1] https://review.openstack.org/#/c/150604/


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Wed, Jan 28, 2015 at 10:23 AM, Anita Kuno ante...@anteaya.info wrote:

 On 01/28/2015 11:36 AM, Thierry Carrez wrote:
  Monty Taylor wrote:
  What if, to reduce stress on you, we make this 100% mechanical:
 
  - Anyone can propose a name
  - Election officials verify that the name matches the criteria
  -  * note: how do we approve additive exceptions without tons of effort
 
  Devil is in the details, as reading some of my hatemail would tell you.
  For example in the past I rejected Foo which was proposed because
  there was a Foo Bar landmark in the vicinity. The rules would have to
  be pretty detailed to be entirely objective.
 Naming isn't objective. That is both the value and the hardship.
 
  - Marketing team provides feedback to the election officials on names
  they find image-wise problematic
  - The poll is created with the roster of all foundation members
  containing all of the choices, but with the marketing issues clearly
  labeled, like this:
 
  * Love
  * Lumber
 Ohh, it gives me a thrill to see a name that means something even
 remotely Canadian. (not advocating it be added to this round)
  * Lettuce
  * Lemming - marketing issues identified
 
  - post poll - foundation staff run trademarks checks on the winners in
  order until a legally acceptable winner is found
 
  This way nobody is excluded, it's not a burden on you, it's about as
  transparent as it could be - and there are no special privileges needed
  for anyone to volunteer to be an election official.
 
  I'm going to continue to advocate that we use condorcet instead of a
  launchpad poll because we need the ability to rank things for post-vote
  trademark checks to not get weird. (also, we're working on getting off
  of launchpad, so let's not re-add another connection)
 
  It's been some time since we last used a Launchpad poll. I recently used
  an open surveymonkey poll, which allowed crude ranking. Agree that
  Condorcet is better, as long as you can determine a clear list of voters.
 

 Glad we are talking about this,
 Anita.

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ

Re: [openstack-dev] [Swift] Swift GUI (free or open source)?

2015-01-28 Thread Adam Lawson
Okay cool beans. Incidentally, are there any efforts out there going
through the motions that you know about (even abandoned)? I'd be willing to
prop them a bit if they're low on development resources..


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Wed, Jan 28, 2015 at 2:12 AM, Martin Geisler mar...@geisler.net wrote:

 Adam Lawson alaw...@aqorn.com writes:

 Hi Adam,

  I'm researching for a web-based visualization that simply displays
  OpenStack Swift and/or node status, cluster health etc in some manner.

 I wrote Swift Browser, which will let you browse the containers and
 objects in your Swift cluster:

   Repository: https://github.com/zerovm/swift-browser
   Demo here: http://www.zerovm.org/swift-browser/#/

 You mention node status and cluster health -- this is unfortunately not
 what I considered in Swift Browser.

 --
 Martin Geisler

 http://google.com/+MartinGeisler

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Swift] Swift GUI (free or open source)?

2015-01-26 Thread Adam Lawson
I'm researching for a web-based visualization that simply displays
OpenStack Swift and/or node status, cluster health etc in some manner.
being able to run a command would be cool but a little more than I need.
Does such a thing currently exist? I know about SwiftStack but I'm
wondering if there are other efforts that have produced a way to visualize
Swift telemetry.

Has anyone run across such a thing?


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Project list (official un-official)

2015-01-08 Thread Adam Lawson
Thanks!!
On Jan 8, 2015 5:09 AM, Thierry Carrez thie...@openstack.org wrote:

 Adam Lawson wrote:
  I've been looking for a list of projects that folks are working on. The
  official list is simple to find for those but when talking about things
  like Octavia, Libra and other non-official/non-core programs, knowing
  what people are working on would be pretty interesting.
 
  Does an exhaustive list like this exist somewhere?

 The canonical list of official programs (which translates into a set of
 code repositories) currently lives here:


 http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml

 In a larger sense, the list of all openstack/ and stackforge/ code
 repositories can be found here:

 http://git.openstack.org/cgit/

 Hope this helps,

 --
 Thierry Carrez (ttx)

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Project list (official un-official)

2015-01-07 Thread Adam Lawson
I've been looking for a list of projects that folks are working on. The
official list is simple to find for those but when talking about things
like Octavia, Libra and other non-official/non-core programs, knowing what
people are working on would be pretty interesting.

Does an exhaustive list like this exist somewhere?


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Board election

2014-11-30 Thread Adam Lawson
Everyone on my team are also seeing the same errors. Will submit a bug but
that's a lot of people to file bugs. ; )


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Sun, Nov 30, 2014 at 8:17 AM, Anne Gentle a...@openstack.org wrote:

 Hi Gary and Anita,
 We do have a bug tracker for www.openstack.org at:

 https://bugs.launchpad.net/openstack-org

 Log a bug there to make sure the web devs at the Foundation get it.
 Thanks,
 Anne

 On Sun, Nov 30, 2014 at 8:44 AM, Gary Kotton gkot...@vmware.com wrote:

  Hi,
 When I log into the site I am unable to nominate people. Any ideas? I
 get: *Your account credentials do not allow you to nominate candidates.*
 *”*
  Any idea how to address that?
  Thanks
  Gary

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] TC election by the numbers

2014-10-30 Thread Adam Lawson
I was thinking after reading all this; besides modifying the number of
required patches, perhaps we could try a blind election; candidate names
are removed so ballots have to be cast based on the merit of each
candidate's responses to the questions and/or ideas - which I think
effectively eliminates the possibility of partisan voting based name
recognition or based on the fact they are a well-known as PTL for a
specific project i.e. nothing to do with TC but their prominence within the
development hierarchy.

Or something along those lines. If we aren't electing names, might as well
cast ballots that eliminates them form the equation. ; ) Might be another
'when hell freezes over' suggestion but I thought I'd at least throw it out
there for discussion.

Mahalo,
Adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Thu, Oct 30, 2014 at 5:43 PM, Clint Byrum cl...@fewbar.com wrote:

 Excerpts from Thierry Carrez's message of 2014-10-30 04:16:48 -0700:
  Eoghan Glynn wrote:
   I haven't seen the customary number-crunching on the recent TC
 election,
   so I quickly ran the numbers myself.
 
  Haven't been able to run my analysis yet. I should be able to a few
  weeks after summit :)
 
  In complement to the partisan analysis you ran, one interesting
  analysis is to see how much the results would be different if we enable
  the proportional vote option in CIVS (which is designed to deter block
  voting). I'll do that one.
 
   The turnout rate continues to decline, in this case from 29.7% to
 26.7%.
  
   Here's how the participation rates have shaped up since the first
 TC2.0
   election:
  
   Election | Electorate | Voted | Turnout | Change
   
   10/2013  | 1106   | 342   | 30.9%   | -8.0%
   04/2014  | 1510   | 448   | 29.7%   | -4.1%
   10/2014  | 1892   | 506   | 26.7%   | -9.9%
  
  
   Overall percentage of the electorate voting is declining, but absolute
   numbers of voters has increased. And in fact, the electorate has
 grown more
   than the turnout has declined.
  
   True that, but AFAIK the generally accepted metric on participation
 rates
   in elections is turnout as opposed to absolute voter numbers.
 
  It's the generally-accepted metric in classic elections, which have a
  slow-growing electorate.
 
  I agree that a decline in global participation is not a good trend, but
  in our case I think it's more an artifact of our long tail of small
  contributors than true decline in interest in existing voters.
 
  What is *is* showing is that we grow the number of people who care about
  OpenStack governance at a smaller rate (+12%) than we grow raw
  contributors (+25%).

 It may be worth noting that we are also doing things _right_ if the TC
 isn't having to do much that impacts the broad base of ATCs.

 Decentralizing things in the way we've been looking at lately, would
 mean there is less involvement by the TC in ATCs' business. That would
 then lead to less familiarity with the candidates and incumbents, and
 indeed less interest in the election process.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] Backup of information about nodes.

2014-10-24 Thread Adam Lawson
Okay and one other question which I must have missed; is it possible to
expand Swift capacity through Fuel? I notice Swift is installed on the
Controllers but if we need to expand Swift capacity, does that necessarily
mean Fuel requires the addition of more Controllers?


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Thu, Oct 23, 2014 at 2:59 AM, Tomasz Napierala tnapier...@mirantis.com
wrote:


 On 22 Oct 2014, at 21:03, Adam Lawson alaw...@aqorn.com wrote:

  What is current best practice to restore a failed Fuel node?

 It’s documented here:

 http://docs.mirantis.com/openstack/fuel/fuel-5.1/operations.html#restoring-fuel-master

 Regards,
 --
 Tomasz 'Zen' Napierala
 Sr. OpenStack Engineer
 tnapier...@mirantis.com







 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] Backup of information about nodes.

2014-10-22 Thread Adam Lawson
What is current best practice to restore a failed Fuel node?


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Wed, Oct 22, 2014 at 10:40 AM, Sergii Golovatiuk 
sgolovat...@mirantis.com wrote:

 Hi Andrew,

 Thank you for sharing your ideas. We have similar blueprint where you
 should be able to save/restore information about your environment

 https://blueprints.launchpad.net/fuel/+spec/save-and-restore-env-settings

 For development, it's very useful when you need to create the identical
 environment (including networks) or other specific tasks. Also you may use
 the case to backup information about a cluster and restore one particular
 node.

 --
 Best regards,
 Sergii Golovatiuk,
 Skype #golserge
 IRC #holser

 On Wed, Oct 22, 2014 at 6:07 PM, Andrey Volochay avoloc...@mirantis.com
 wrote:

 Hi, everyone.

 For one project we need to have backup of info about nodes (astute.yaml).
 In case the Fuel and a Node-n is down.

 How a bad idea to keep a copy of the astute.yaml file of each node to
 each node of the cluster?
 For example:
 pod_state/node-1.yaml
 pod_state/node-2.yaml
 pod_state/node-3.yaml
 pod_state/node-n.yaml

 I have idea. Add new deployment engine for astute.yaml and switcher of
 engines. Then we will be able to choose between two ways.

 engine here: fuel-astute/lib/astute/deployment_engine

 --
 Regards,
 Andrey Volochay

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-10-21 Thread Adam Lawson
I fully and wholeheartedly agree that inventory management is out of scope
of Ironic. But I have a small suggestion:

We'd do well as a community to adopt/evangelize an informal rule which I
enforce at work (because I see this happen a lot when brainstorming with
cross-project goals); we cannot say no (X) without suggesting an
alternative (Y)... Like a runner throwing his baton at the next guy in the
race instead of handing it to him. ; )

Back on topic however, is there an existing program where inventory data
(consumed by Ironic or any other program that needs to know the
configuration of hardwareX) could be stored? I.e. hardware catalog?


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Tue, Oct 21, 2014 at 10:29 AM, Stuart Fox stu...@demonware.net wrote:

 Having written/worked on a few DC automation tools, Ive typically broken
 down the process of getting unknown hardware into production in to 4
 distinct stages.
 1) Discovery (The discovery of unknown hardware)
 2) Normalising (Push initial configs like drac/imm/ilo settings, flashing
 to known good firmware etc etc)
 3) Analysis (Figure out what the hardware is and what its constituent
 parts are cpu/ram/disk/IO caps/serial numbers etc)
 4) Burnin (run linpack or equiv tests for 24hrs)

 At the end of stage 4 the hardware should be ready for provisioning.

 Hope that helps

 Stuart

 On Tue, Oct 21, 2014 at 2:38 AM, Lucas Alvares Gomes 
 lucasago...@gmail.com wrote:

 On Tue, Oct 21, 2014 at 10:27 AM, Sam Betts (sambetts)
 sambe...@cisco.com wrote:
  I agree with Devananda's definition of Œhardware discovery¹ and other
  tools similar to Ironic use the term discovery in this way, however I
 have
  found that these other tools often bundle the gathering of the system
  properties together with the discovery of the hardware as a single step
  from a user perspective. I also agree that in Ironic there needs to be a
  separate term for that (at least from a dev perspective) and I think
  Lucas¹s suggestion of Œhardware interrogation¹ or something like
 Œhardware
  inventory¹ would be more explanatory at first glance than
 Œintrospection¹.

 Thanks for the suggestion but no inventory please, this is another
 taboo word in Ironic. This is because when we say hardware inventory
 it kinda suggests that Ironic could be used as a CMDB, which is not
 the case.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 BR,
 Stuart

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Ironic] [Triple-O] Openstack Onboarding

2014-10-20 Thread Adam Lawson
I made a similar comment to the Triple-O design summmit etherpad in hopes
others have a similar interest in Kilo but I wanted to share evangelize my
thoughts with the community for discussion:

For better or for worse, one thing I've heard over and over is how
Openstack community/TC approves/prefers the use of TripleO and Ironic to
deploy Openstack on bare metal. Cool, but for the majority of users
considering using Openstack in their organization, the question always goes
back to: If I'm not savvy enough yet to install Openstack without these
tools, how do I setup TripleO and Ironic? Seems like a chien and egg thing.

There has not been much discussion (that I've noticed) re making a
deployment process easy to erect. That should be the easy part but it's as
confusing as the second part for most who are starting out. Using Openstack
to deploy Openstack means the installer method should be straight forward
and itself should be easy to install for users with limited understanding
of Openstack or the tooling methods used by OOO and Ironic. But the bar to
use Openstack continues to be a relatively-high engineering hurdle. It
always has been and I'd love to see that change in the next cycle.

Something that comes to mind:

   - Setup Process Definition
   - Quickstart Wizards
   - Tooling

The above may seem to be dumbing down the process but widespread Openstack
adoption requires an easy on-boarding process and so far, it simply doesn't
exist.

Thoughts?



*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-16 Thread Adam Lawson
Be forewarned; here's my two cents before I've had my morning coffee.

It would seem to me that if we were seeking some level of resiliency
against host failures (if a host fails, evacuate the instances that were
hosted on it to a host that isn't broken), it would seem that host HA is a
good approach. The ultimate goal of course is instance HA but the task of
monitoring individual instances and determining what constitutes down
seems like a much more complex task than detecting when a compute node is
down. I know that requiring the presence of agents should probably need
some more brain-cycles since we can't expect additional bytes consuming
memory on each individual VM.

Additionally, I'm not really hung up on the 'how' as we all realize there
several ways to skin that cat, so long as that 'how' is leveraged via tools
over which we have control and direct influence. Reason being, we may not
want to leverage features as important as this on tools that change outside
our control and subsequently shifts the foundation of the feature we
implemented that was based on how the product USED to work. Basically if
Pacemaker does what we need then cool but it seems that implementing a
feature should be built upon a bedrock of programs over which we have a
direct influence. This is why Nagios may be able to do it but it's a hack
at best. I'm not saying Nagios isn't good or ythe hack doesn't work but in
the context of an Openstack solution, we can't require a single external
tool for a feature like host or VM HA. Are we suggesting that we tell
people who want HA - go use Nagios? Call me a purist but if we're going
to implement a feature, it should be our community implementing it because
we have some of the best minds on staff. ; )



*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Thu, Oct 16, 2014 at 7:53 AM, Russell Bryant rbry...@redhat.com wrote:

 On 10/16/2014 09:00 AM, Florian Haas wrote:
  On Thu, Oct 16, 2014 at 1:59 PM, Russell Bryant rbry...@redhat.com
 wrote:
  On 10/16/2014 04:29 AM, Florian Haas wrote:
  (5) Let monitoring and orchestration services deal with these use
  cases and
  have Nova simply provide the primitive API calls that it already
 does
  (i.e.
  host evacuate).
 
  That would arguably lead to an incredible amount of wheel
 reinvention
  for node failure detection, service failure detection, etc. etc.
 
  How so? (5) would use existing wheels for monitoring and
 orchestration
  instead of writing all new code paths inside Nova to do the same
 thing.
 
  Right, there may be some confusion here ... I thought you were both
  agreeing that the use of an external toolset was a good approach for
 the
  problem, but Florian's last message makes that not so clear ...
 
  While one of us (Jay or me) speaking for the other and saying we agree
  is a distributed consensus problem that dwarfs the complexity of
  Paxos, *I* for my part do think that an external toolset (i.e. one
  that lives outside the Nova codebase) is the better approach versus
  duplicating the functionality of said toolset in Nova.
 
  I just believe that the toolset that should be used here is
  Corosync/Pacemaker and not Ceilometer/Heat. And I believe the former
  approach leads to *much* fewer necessary code changes *in* Nova than
  the latter.
 
  Have you tried pacemaker_remote yet?  It seems like a better choice for
  this particular case, as opposed to using corosync, due to the potential
  number of compute nodes.
 
  I'll assume that you are *not* referring to running Corosync/Pacemaker
  on the compute nodes plus pacemaker_remote in the VMs, because doing
  so would blow up the separation between the cloud operator and tenant
  space.

 Correct.

  Running compute nodes as baremetal extensions of a different
  Corosync/Pacemaker cluster (presumably the one that manages the other
  Nova services)  would potentially be an option, although vendors would
  need to buy into this. Ubuntu, for example, currently only ships
  pacemaker-remote in universe.

 Yes, this is what I had in mind.

 --
 Russell Bryant

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-16 Thread Adam Lawson
Okay the coffee kicked in.

I can see how my comment could be interpreted that way so let's take a step
backward so I can explain my perspective here.

Amazon was the first to implement a commercial-grade cloud IaaS, Openstack
was developed as an alternative. If we avoided wheel re-invention as a
rule, Openstack would have never been written. That's how I see it.
Automatic fail-over is already done by VMware. If we were looking to avoid
re-invention as our guide to implementing new features, we'd setup a
product referral partnership with VMware, tell our users that HA requires
VMware, dust off our hands and say job well done. No one here is saying
that though, but that's the mindset I think I'm hearing. I champion the
in-house approach not as an effort to develop something that doesn't exist
elsewhere or for the sake of control but because we don't want to be tied
to a single external product for a core feature of Openstack.

When ProductA+ProductB = XYZ, it creates a one-way dependency that I
historically try to avoid. Because if ProductA = Openstack, ProductB is no
longer optional.

Personally speaking, I'm actually speaking more towards our approach to how
we scope features for Openstack rather than whether we use Pacemaker,
Nagios, Nova, Heat or something else.

Question: is host HA not achievable using the programs we have in place now
(with modification of course)? If not, I'm still a champion to see it done
within our four walls.

Just my 10c or so. ; )



*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Thu, Oct 16, 2014 at 10:53 AM, Florian Haas flor...@hastexo.com wrote:

 On Thu, Oct 16, 2014 at 7:03 PM, Adam Lawson alaw...@aqorn.com wrote:
 
  Be forewarned; here's my two cents before I've had my morning coffee.
 
  It would seem to me that if we were seeking some level of resiliency
 against host failures (if a host fails, evacuate the instances that were
 hosted on it to a host that isn't broken), it would seem that host HA is a
 good approach. The ultimate goal of course is instance HA but the task of
 monitoring individual instances and determining what constitutes down
 seems like a much more complex task than detecting when a compute node is
 down. I know that requiring the presence of agents should probably need
 some more brain-cycles since we can't expect additional bytes consuming
 memory on each individual VM.

 What Russell is suggesting, though, is actually a very feasible
 approach for compute node HA today and per-instance HA tomorrow.

  Additionally, I'm not really hung up on the 'how' as we all realize
 there several ways to skin that cat, so long as that 'how' is leveraged via
 tools over which we have control and direct influence. Reason being, we may
 not want to leverage features as important as this on tools that change
 outside our control and subsequently shifts the foundation of the feature
 we implemented that was based on how the product USED to work. Basically if
 Pacemaker does what we need then cool but it seems that implementing a
 feature should be built upon a bedrock of programs over which we have a
 direct influence.

 That almost sounds a bit like let's always build a better wheel,
 because control. I'm not sure if that's indeed the intention, but if
 it is then that seems like a bad idea to me.

  This is why Nagios may be able to do it but it's a hack at best. I'm not
 saying Nagios isn't good or ythe hack doesn't work but in the context of an
 Openstack solution, we can't require a single external tool for a feature
 like host or VM HA. Are we suggesting that we tell people who want HA - go
 use Nagios? Call me a purist but if we're going to implement a feature, it
 should be our community implementing it because we have some of the best
 minds on staff. ; )

 Anyone who thinks that having a monitoring solution to page people and
 then waking up a human to restart the service constitutes HA needs to
 be doused in a bucket of ice water. :)

 Cheers,
 Florian

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-15 Thread Adam Lawson
It would seem to me that if guest HA is highly-desired, and it is,
requiring multiple flavors for multiple SLA requirements (and that's what
we're really talking about) introduces a trade-off that conceivably isn't
needed - double the flavor requirement for the same spec (512/1/10 and
another for HA). I'd like to explore this a little further to define other
possibilities.

I like the idea of instance HA; I like the idea of host HA way better
because it protects every instance on it. And hosts with HA logic would
obviously not be allowed to only host instances that use shared storage.

What are our options to continue discussing in Paris?


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Wed, Oct 15, 2014 at 1:50 PM, Florian Haas flor...@hastexo.com wrote:

 On Wed, Oct 15, 2014 at 9:58 PM, Jay Pipes jaypi...@gmail.com wrote:
  On 10/15/2014 03:16 PM, Florian Haas wrote:
 
  On Wed, Oct 15, 2014 at 7:20 PM, Russell Bryant rbry...@redhat.com
  wrote:
 
  On 10/13/2014 05:59 PM, Russell Bryant wrote:
 
  Nice timing.  I was working on a blog post on this topic.
 
 
  which is now here:
 
 
 http://blog.russellbryant.net/2014/10/15/openstack-instance-ha-proposal/
 
 
  I am absolutely loving the fact that we are finally having a
  discussion in earnest about this. i think this deserves a Design
  Summit session.
 
  If I may weigh in here, let me share what I've seen users do and what
  can currently be done, and what may be supported in the future.
 
  Problem: automatically ensure that a Nova guest continues to run, even
  if its host fails.
 
  (That's the general problem description and I don't need to go into
  further details explaining the problem, because Russell has done that
  beautifully in his blog post.)
 
  Now, what are the options?
 
  (1) Punt and leave it to the hypervisor.
 
  This essentially means that you must use a hypervisor that already has
  HA built in, such as VMware with the VCenter driver. In that scenario,
  Nova itself neither deals with HA, nor exposes any HA switches to the
  user. Obvious downside: not generic, doesn't work with all
  hypervisors, most importantly doesn't work with the most popular one
  (libvirt/KVM).
 
  (2) Deploy Nova nodes in pairs/groups, and pretend that they are one
 node.
 
  You can already do that by overriding host in nova-compute.conf,
  setting resume_guests_state_on_host_boot, and using VIPs with
  Corosync/Pacemaker. You can then group these hosts in host aggregates,
  and the user's scheduler hint to point a newly scheduled guest to such
  a host aggregate becomes, effectively, the keep this guest running at
  all times flag. Upside: no changes to Nova at all, monitoring,
  fencing and recovery for free from Corosync/Pacemaker. Downsides:
  requires vendors to automate Pacemaker configuration in deployment
  tools (because you really don't want to do those things manually).
  Additional downside: you either have some idle hardware, or you might
  be overcommitting resources in case of failover.
 
  (3) Automatic host evacuation.
 
  Not supported in Nova right now, as Adam pointed out at the top of the
  thread, and repeatedly shot down. If someone were to implement this,
  it would *still* require that Corosync/Pacemaker be used for
  monitoring and fencing of nodes, because re-implementing this from
  scratch would be the reinvention of a wheel while painting a bikeshed.
 
  (4) Per-guest HA.
 
  This is the idea of just doing nova boot --keep-this running, i.e.
  setting a per-guest flag that still means the machine is to be kept up
  at all times. Again, not supported in Nova right now, and probably
  even more complex to implement generically than (3), at the same or
  greater cost.
 
  I have a suggestion to tackle this that I *think* is reasonably
  user-friendly while still bearable in terms of Nova development
  effort:
 
  (a) Define a well-known metadata key for a host aggregate, say ha.
  Define that any host aggregate that represents a highly available
  group of compute nodes should have this metadata key set.
 
  (b) Then define a flavor that sets extra_specs ha=true.
 
  Granted, this places an additional burden on distro vendors to
  integrate highly-available compute nodes into their deployment
  infrastructure. But since practically all of them already include
  Pacemaker, the additional scaffolding required is actually rather
  limited.
 
 
  Or:
 
  (5) Let monitoring and orchestration services deal with these use cases
 and
  have Nova simply provide the primitive API calls that it already does
 (i.e.
  host evacuate).

 That would arguably lead to an incredible amount of wheel reinvention
 for node failure detection, service failure detection, etc. etc.

 Florian

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [QA] How to attach multiple NICs to an instance VM?

2014-10-15 Thread Adam Lawson
May I ask a question about approach? Why don't you use aliases i.e. eth0:0,
eth0:1 instead of creating multiple NIC's?


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Wed, Oct 15, 2014 at 4:09 PM, Danny Choi (dannchoi) dannc...@cisco.com
wrote:

  Hi Salvatore,

  eth1 is not configured in /etc/network/interfaces.

  After I manually added eth1 and bounced it, it came up with the 2nd
 private address.

 $ sudo vi /etc/network/interfaces


  # Configure Loopback

 auto lo

 iface lo inet loopback


  auto eth0

 iface eth0 inet dhcp



 auto eth1

 iface eth1 inet dhcp

 ~

 ~

 ~

 $ sudo ifdown eht1  sudo ifup eth1

 ifdown: interface eht1 not configured

 udhcpc (v1.20.1) started

 Sending discover...

 Sending select for 20.0.0.10...

 Lease of 20.0.0.10 obtained, lease time 86400

 deleting routers

 adding dns 8.8.4.4

 adding dns 8.8.8.8

 $ ifconfig -a

 eth0  Link encap:Ethernet  HWaddr FA:16:3E:7A:49:1E

   inet addr:10.0.0.7  Bcast:10.0.0.255  Mask:255.255.255.0

   inet6 addr: fe80::f816:3eff:fe7a:491e/64 Scope:Link

   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

   RX packets:707 errors:0 dropped:0 overruns:0 frame:0

   TX packets:446 errors:0 dropped:0 overruns:0 carrier:0

   collisions:0 txqueuelen:1000

   RX bytes:66680 (65.1 KiB)  TX bytes:57968 (56.6 KiB)


  eth1  Link encap:Ethernet  HWaddr FA:16:3E:73:C7:F0

   inet addr:20.0.0.10  Bcast:20.0.0.255  Mask:255.255.255.0

   inet6 addr: fe80::f816:3eff:fe73:c7f0/64 Scope:Link

   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

   RX packets:39 errors:0 dropped:0 overruns:0 frame:0

   TX packets:8 errors:0 dropped:0 overruns:0 carrier:0

   collisions:0 txqueuelen:1000

   RX bytes:3354 (3.2 KiB)  TX bytes:1098 (1.0 KiB)


  loLink encap:Local Loopback

   inet addr:127.0.0.1  Mask:255.0.0.0

   inet6 addr: ::1/128 Scope:Host

   UP LOOPBACK RUNNING  MTU:16436  Metric:1

   RX packets:4 errors:0 dropped:0 overruns:0 frame:0

   TX packets:4 errors:0 dropped:0 overruns:0 carrier:0

   collisions:0 txqueuelen:0

   RX bytes:336 (336.0 B)  TX bytes:336 (336.0 B)


  $ ping 10.0.0.7

 PING 10.0.0.7 (10.0.0.7): 56 data bytes

 64 bytes from 10.0.0.7: seq=0 ttl=64 time=0.138 ms

 64 bytes from 10.0.0.7: seq=1 ttl=64 time=0.041 ms

 64 bytes from 10.0.0.7: seq=2 ttl=64 time=0.066 ms

 ^C

 --- 10.0.0.7 ping statistics ---

 3 packets transmitted, 3 packets received, 0% packet loss

 round-trip min/avg/max = 0.041/0.081/0.138 ms

 $ ping 20.0.0.10

 PING 20.0.0.10 (20.0.0.10): 56 data bytes

 64 bytes from 20.0.0.10: seq=0 ttl=64 time=0.078 ms

 64 bytes from 20.0.0.10: seq=1 ttl=64 time=0.041 ms

 ^C

 --- 20.0.0.10 ping statistics ---

 2 packets transmitted, 2 packets received, 0% packet loss

 round-trip min/avg/max = 0.041/0.059/0.078 ms

 $

  Thanks,
 Danny

  ===

  Date: Thu, 16 Oct 2014 00:10:20 +0200
 From: Salvatore Orlando sorla...@nicira.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [QA] How to attach multiple NICs to an
 instance VM?
 Message-ID:
 CAGR=i3jeuz6-peghjze-hnh2yvn8ykmbn4ies4dtqc3b2xl...@mail.gmail.com
 Content-Type: text/plain; charset=utf-8

  I think you did everything right.

  Are you sure cirros images by default are configured to boostrap
 interfaces
 different from eth0?
 Perhaps all you need to do is just ifup the interface... have you already
 tried that?

  Salvatore

  On 15 October 2014 23:07, Danny Choi (dannchoi) dannc...@cisco.com
 wrote:

Hi,

?nova help boot? shows the following:

  --nic
 net-id=net-uuid,v4-fixed-ip=ip-addr,v6-fixed-ip=ip-addr,port-id=port-uuid

   Create a NIC on the server. Specify
 option

   multiple times to create multiple NICs.
 net-

   id: attach NIC to network with this UUID

   (either port-id or net-id must be
 provided),

   v4-fixed-ip: IPv4 fixed address for NIC

   (optional), v6-fixed-ip: IPv6 fixed
 address

   for NIC (optional), port-id: attach NIC
 to

   port with this UUID (either port-id or
 net-id

   must be provided).


NOTE:  Specify option multiple times to create multiple NICs.
 


I have two private networks and one public network (for floating IPs)
 configured.


localadmin@qa4:~/devstack$ nova net-list

  +--+---+--+

  | ID

Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-14 Thread Adam Lawson

 Nova is also not the right place to do the generic solution as many other
 parts could be involved... neutron and cinder come to mind. Nova needs to
 provide the basic functions but it needs something outside to make it all
 happen transparently.
 I would really like a shared solution rather than each deployment doing
 their own and facing identical problems. A best of breed solution which can
 be incrementally improved as we find problems to get the hypervisor down
 event, to force detach of boot volumes, restart elsewhere and reconfigure
 floating ips with race conditions is needed.
 Some standards for tagging is good but we also need some code :-)


I think this would actually be a worthwhile cross-project effort but
getting it done would require some higher-level guidance to keep it on
track.

I also do not believe Nova *contains* all of the data to perform auto-evac,
but it has *access* to the data right? Or could anyway. I think Cinder
would definitely play a roll, and Neutron for sure.

And as far is scope is concerned, I personally think something like this
should only support VM's with shared storage. Otherwise, phase 1 gets
overly complex and gets into something akin to VMware's DRS which I DO
think could be another step, but the first step needs to be clean to ensure
it gets done.


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Tue, Oct 14, 2014 at 12:01 PM, Mathieu Gagné mga...@iweb.com wrote:

 On 2014-10-14 2:49 PM, Tim Bell wrote:


 Nova is also not the right place to do the generic solution as many other
 parts could be involved... neutron and cinder come to mind. Nova needs to
 provide the basic functions but it needs something outside to make it all
 happen transparently.

 I would really like a shared solution rather than each deployment doing
 their own and facing identical problems. A best of breed solution which can
 be incrementally improved as we find problems to dget the hypervisor down
 event, to force detach of boot volumes, restart elsewhere and reconfigure
 floating ips with race conditions is needed.

 Some standards for tagging is good but we also need some code :-)


 I agree with Tim. Nova does not have all the required information to make
 a proper decision which could imply other OpenStack (and non-OpenStack)
 services. Furthermore, evacuating a node might imply fencing which Nova
 might not be able to do properly or have the proper tooling. What about
 non-shared storage backend in Nova? You can't evacuate those without data
 loss.

 --
 Mathieu


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Nova] Automatic evacuate

2014-10-13 Thread Adam Lawson
[switching to openstack-dev]

Has anyone automated nova evacuate so that VM's on a failed compute host
using shared storage are automatically moved onto a new host or is manually
entering *nova compute instance host* required in all cases?

If it's manual only or require custom Heat/Ceilometer templates, how hard
would it be to enable automatic evacuation within Novs?

i.e. (within /etc/nova/nova.conf)
auto_evac = true

Or is this possible now and I've simply not run across it?


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Sat, Sep 27, 2014 at 12:32 AM, Clint Byrum cl...@fewbar.com wrote:

 So, what you're looking for is basically the same old IT, but with an
 API. I get that. For me, the point of this cloud thing is so that server
 operators can make _reasonable_ guarantees, and application operators
 can make use of them in an automated fashion.

 If you start guaranteeing 4 and 5 nines for single VM's, you're right
 back in the boat of spending a lot on server infrastructure even if your
 users could live without it sometimes.

 Compute hosts are going to go down. Networks are going to partition. It
 is not actually expensive to deal with that at the application layer. In
 fact when you know your business rules, you'll do a better job at doing
 this efficiently than some blanket replicate all the things layer might.

 I know, some clouds are just new ways to chop up these fancy 40 core
 megaservers that everyone is shipping. I'm sure OpenStack can do it, but
 I'm saying, I don't think OpenStack _should_ do it.

 Excerpts from Adam Lawson's message of 2014-09-26 20:30:29 -0700:
  Generally speaking that's true when you have full control over how you
  deploy applications as a consumer. As a provider however, cloud
 resiliency
  is king and it's generally frowned upon to associate instances directly
 to
  the underlying physical hardware for any reason. It's good when instances
  can come and go as needed, but in a production context, a failed compute
  host shouldn't take down every instance hosted on it. Otherwise there is
 no
  real abstraction going on and the cloud loses immense value.
  On Sep 26, 2014 4:15 PM, Clint Byrum cl...@fewbar.com wrote:
 
   Excerpts from Adam Lawson's message of 2014-09-26 14:43:40 -0700:
Hello fellow stackers.
   
I'm looking for discussions/plans re VM continuity.
   
I.e. Protection for instances using ephemeral storage against host
   failures
or auto-failover capability for instances on hosts where the host
 suffers
from an attitude problem?
   
I know fail-overs are supported and I'm quite certain
 auto-fail-overs are
possible in the event of a host failure (hosting instances not using
   shared
storage). I just can't find where this has been addressed/discussed.
   
Someone help a brother out? ; )
  
   I'm sure some of that is possible, but it's a cloud, so why not do
 things
   the cloud way?
  
   Spin up redundant bits in disparate availability zones. Replicate only
   what must be replicated. Use volumes for DR only when replication would
   be too expensive.
  
   Instances are cattle, not pets. Keep them alive just long enough to
 make
   your profit.
  
   ___
   Mailing list:
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
   Post to : openst...@lists.openstack.org
   Unsubscribe :
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
  

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-13 Thread Adam Lawson
Looks like this was proposed and denied to be part of Nova for some reason
last year. Thoughts on why and is the reasoning (whatever it was) still
applicable?


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Mon, Oct 13, 2014 at 1:26 PM, Adam Lawson alaw...@aqorn.com wrote:

 [switching to openstack-dev]

 Has anyone automated nova evacuate so that VM's on a failed compute host
 using shared storage are automatically moved onto a new host or is manually
 entering *nova compute instance host* required in all cases?

 If it's manual only or require custom Heat/Ceilometer templates, how hard
 would it be to enable automatic evacuation within Novs?

 i.e. (within /etc/nova/nova.conf)
 auto_evac = true

 Or is this possible now and I've simply not run across it?


 *Adam Lawson*

 AQORN, Inc.
 427 North Tatnall Street
 Ste. 58461
 Wilmington, Delaware 19801-2230
 Toll-free: (844) 4-AQORN-NOW ext. 101
 International: +1 302-387-4660
 Direct: +1 916-246-2072


 On Sat, Sep 27, 2014 at 12:32 AM, Clint Byrum cl...@fewbar.com wrote:

 So, what you're looking for is basically the same old IT, but with an
 API. I get that. For me, the point of this cloud thing is so that server
 operators can make _reasonable_ guarantees, and application operators
 can make use of them in an automated fashion.

 If you start guaranteeing 4 and 5 nines for single VM's, you're right
 back in the boat of spending a lot on server infrastructure even if your
 users could live without it sometimes.

 Compute hosts are going to go down. Networks are going to partition. It
 is not actually expensive to deal with that at the application layer. In
 fact when you know your business rules, you'll do a better job at doing
 this efficiently than some blanket replicate all the things layer might.

 I know, some clouds are just new ways to chop up these fancy 40 core
 megaservers that everyone is shipping. I'm sure OpenStack can do it, but
 I'm saying, I don't think OpenStack _should_ do it.

 Excerpts from Adam Lawson's message of 2014-09-26 20:30:29 -0700:
  Generally speaking that's true when you have full control over how you
  deploy applications as a consumer. As a provider however, cloud
 resiliency
  is king and it's generally frowned upon to associate instances directly
 to
  the underlying physical hardware for any reason. It's good when
 instances
  can come and go as needed, but in a production context, a failed compute
  host shouldn't take down every instance hosted on it. Otherwise there
 is no
  real abstraction going on and the cloud loses immense value.
  On Sep 26, 2014 4:15 PM, Clint Byrum cl...@fewbar.com wrote:
 
   Excerpts from Adam Lawson's message of 2014-09-26 14:43:40 -0700:
Hello fellow stackers.
   
I'm looking for discussions/plans re VM continuity.
   
I.e. Protection for instances using ephemeral storage against host
   failures
or auto-failover capability for instances on hosts where the host
 suffers
from an attitude problem?
   
I know fail-overs are supported and I'm quite certain
 auto-fail-overs are
possible in the event of a host failure (hosting instances not using
   shared
storage). I just can't find where this has been addressed/discussed.
   
Someone help a brother out? ; )
  
   I'm sure some of that is possible, but it's a cloud, so why not do
 things
   the cloud way?
  
   Spin up redundant bits in disparate availability zones. Replicate only
   what must be replicated. Use volumes for DR only when replication
 would
   be too expensive.
  
   Instances are cattle, not pets. Keep them alive just long enough to
 make
   your profit.
  
   ___
   Mailing list:
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
   Post to : openst...@lists.openstack.org
   Unsubscribe :
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
  



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-13 Thread Adam Lawson

 *I think Adam is talking about this
 bp: 
 https://blueprints.launchpad.net/nova/+spec/evacuate-instance-automatically
 https://blueprints.launchpad.net/nova/+spec/evacuate-instance-automatically 
 *


Correct - yes. Sorry about that. ; )

So it would seem the question is not whether to support auto-evac but how
it should be handled. If not handled by Nova, it gets complicated. Asking a
user to configure a custom Nagios trigger/action... not sure if we'd
recommend that as our definition of ideal.

   - I can foresee Congress being used to control whether auto-evac is
   required and what other policies come into play by virtue of an unplanned
   host removal from service. But that seems like a bit overkill.
   - i can foresee Nova/scheduler being used to perform the evac itself.
   Are they still pushing back?
   - I can foresee Ceilometer being used to capture service state and
   define how long a node should be inaccessible before it's considered
   offline. But seems a bit out of scope for what ceilometer was meant to do.

I'm all about making this super easy to do a simple task though, at least
so the settings are all defined in one place. Nova seems logical but I'm
wondering if there is still resistance.

So curious; how are these higher-level discussions initiated/facilitated?
TC?



*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Mon, Oct 13, 2014 at 3:21 PM, Russell Bryant rbry...@redhat.com wrote:

 On 10/13/2014 06:18 PM, Jay Lau wrote:
  This is also a use case for Congress, please check use case 3 in the
  following link.
 
 
 https://docs.google.com/document/d/1ExDmT06vDZjzOPePYBqojMRfXodvsk0R8nRkX-zrkSw/edit#

 Wow, really?  That honestly makes me very worried about the scope of
 Congress being far too big (so early, and maybe period).

 --
 Russell Bryant

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] TC candidacy

2014-10-08 Thread Adam Lawson
It seems I left out a response. Sorry for the follow-on but here's what was
missing.

*Topic: Technical Committee Mission*
*How do you feel the technical committee is doing in meeting the technical
committee mission?*

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

I believe the TC has thus far done a pretty fair job given the team and its
charter are both rather new. While the TC has been providing leadership for
individual components, I would not characterize the TC today as providing
highly visible leadership (necessary for openness and transparency) which I
would like to see improved. Much of the TC's work today coalesces around
providing a safe harbor for meaningful program integration and ensure
challenges are resolved optimally but the TC needs to get better at
identifying the good/poorly-defined boundaries of this kind of technical
governance model. In other words, the TC needs to get better at being a
good TC. The instantiation of a TC is a perfect first step but the pink
elephant in the room seems to be around cross-project and architectural
guidance; ensuring Openstack as a whole is moving in a direction that
doesn't require accommodating things we shouldn't be doing in the first
place. The lack of API standardization is a great example of moving in a
direction without a big picture context.
 Communications that have gone back and forth and debated about the big
tent model, layers/cascading, scaling documentation, etc have been visible
and the candor of opposing viewpoints have been awesome to follow. But we
could really benefit from some structural adjustments so more decisions
placed before the team are equally visible, a visible and transparent
decision-making process enabling those who use Openstack understand the
architectural perspectives shepherding it. Not just the decision that have
100+ replies on the mailing list
 Oversight over all the projects is an area that I'm anticipating where
we have some easy low-hanging fruit. Where we are today with regard to
focus is understandable given the number of fires affecting individual
programs that cannot be ignored. But we have a big opportunity (there's
that word again) to get some traction on the larger architectural decisions
that may require more work up front but produce some big wins over the long
term. Customers who want to use Openstack have often played the constant
change = unstable card for good reason; Openstack has a long way to go
before it gets to Production-quality for the masses (i.e. without heavy
re-development requirements). I believe the TC can and should influence
that with better solution-level leadership.
 - The deployment challenge is beyond ready for attention.
- A working default 'out-of-the-box' config that can boot an instance
accessible over the network is STILL a challenge. Long past due in my mind.
- Programs like Oslo that address library requirements moves a cloud closer
to Production-capable but really shouldn't be optional. Doing something
well shouldn't be optional. In fact, a Production context shouldn't be one
option of many despite the prevalence of Openstack PoC and pilots; it
should be a consistent design assumption. Gating a feature to the point
that it's 'good enough' is part of the problem. It must be
Production-worthy otherwise it is NOT good enough. That's ready for
attention.
 We might not be able to address all of these and some ideas could use a
lot more cross-talk, but if elected I would like to champion improving how
the TC approaches problems and vets their potential solutions.


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Tue, Oct 7, 2014 at 7:06 PM, Adam Lawson alaw...@aqorn.com wrote:

 Hello everyone!

 I'll be perfectly straight and dedicate paragraph #1 to address the
 painfully obvious. A number of you are probably reading this after seeing
 'TC Candidacy', looked at my name and wondered 'who is this guy?' In short,
 I'm pretty low-key but I've been heavily involved in Openstack since the
 Folsom release - advising, architecting and deploying Openstack-based
 application clouds for numerous companies and end users. I'm probably a lot
 like many of you in fact; not the loudest or most witty voice in the room,
 I read more than I write, I don't bully ideas and I've never run for
 anything in my life because I hate the spotlight. But the importance of
 Openstack in the cloud marketplace is increasingly important as is the
 integrity of its technical direction. So I'm going to step

Re: [openstack-dev] Suggestions for students final year project

2014-10-07 Thread Adam Lawson
Is the OP looking to help patch bugs with an individual program or to use
Openstack to deploy an interesting use case? The latter is how I
interpreted the question.


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Tue, Oct 7, 2014 at 11:24 AM, Duncan Thomas duncan.tho...@gmail.com
wrote:

 On 7 October 2014 19:01, Anita Kuno ante...@anteaya.info wrote:
  On 10/07/2014 01:38 PM, Adam Young wrote:
  On 10/06/2014 05:28 PM, Anita Kuno wrote:
  On 10/06/2014 04:11 PM, Adam Young wrote:
  I am looking to get someone to work on a Javascript based web client
 to
  replace Horizon.

  Can I just say that I think using new people looking to have work
  experience with OpenStack to further pet projects, without telling them
  it is a pet project and not considered a project which others may
  consider OpenStack to be not the best approach for encouraging new
  people.

 I think writing a client / gui for openstack is one of the best single
 projects you can do to get a good overview of the whole stack.

  Not knocking your project, Adam, since I know nothing about it, and
 this
  isn't the first time I have seen this happen. But I do believe that
  folks asking to help out with something are looking to gain
 transferable
  skills so that they have something to offer a potential employeer who
 is
  looking for work experience with OpenStack. That would be what I would
  be looking for anyway.

  No offense taken.  I think you are looking out for the interest of the
  poster and people wityh similar interests.

 snip

   It would not be appropriate for
  someone in Patricia's position to try and come in and get a bug fix
  through.

  Now on this point, I'm going to disagree, simply because I don't have
  enough information on what Patricia's position actually is. I can guess
  but until I hear from Patricia herself, I'm just guessing and I would
  much rather know. It was my desire to know more about Patricia's
  position that motivated my suggestion she join irc and perhaps ask a few
  questions, allowing others to ask questions of her.
 
  When interacting with other folks who enter under similar circumstances,
  my first question invariably is What is your goal?. I truly hope
  Patricia has something better than to get a good mark because folks
  with that goal rarely interest me, but who knows. I haven't had the
  chance to ask.

 If you're doing a final year project and your highest goal isn't 'to
 get a good mark', then you're doing yourself a serious disservice. You
 can have all sorts of secondary goals, but by the point in your
 academic career where you're doing your final year project, your main
 goal is to prove you're learnt and can apply all of the skills that
 your course has covered. This actually involves a very different
 process to getting something done in the 'real world'.

   That limits the number of projects available.
  Now here is where I would like to interact with program administrators
  at institutions such as Patricia's to ask them why a project? We have
  over 300 including stackforge, why task a student with starting their
  own, why not encourage them to learn our development process which then
  can enable them to work on any of the 300 in various stages of
 development.

 Extremely difficult to get a decent academic project and therefore a
 good mark out of an existing project that has had any substantial
 amount of work done on it. Not impossible, but flicking through a pile
 of old final year projects that got good marks shows that stand-alone
 start-to-finish projects tend to get better marks. (I've looked into
 this quite a bit)





 --
 Duncan Thomas

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] TC candidacy

2014-10-07 Thread Adam Lawson
Hello everyone!

I'll be perfectly straight and dedicate paragraph #1 to address the
painfully obvious. A number of you are probably reading this after seeing
'TC Candidacy', looked at my name and wondered 'who is this guy?' In short,
I'm pretty low-key but I've been heavily involved in Openstack since the
Folsom release - advising, architecting and deploying Openstack-based
application clouds for numerous companies and end users. I'm probably a lot
like many of you in fact; not the loudest or most witty voice in the room,
I read more than I write, I don't bully ideas and I've never run for
anything in my life because I hate the spotlight. But the importance of
Openstack in the cloud marketplace is increasingly important as is the
integrity of its technical direction. So I'm going to step on a limb here
and enter the circle.

My involvement has been primarily focused on large designs and deployments
of custom automated Openstack clouds. And while I am more than proficient
in Python and numerous other languages including .NET/J2EE and others, my
greatest pleasure has been architecting solutions that are powered by
Openstack. Focusing on that has really given me a unique perspective. Not
just on individual components and how they interact with each other, but
also how they collectively perform within the context of a heterogenous
hybrid cloud solution while adhering to industry best practices. This
perspective is one that I hope to bring to the technical committee if the
Openstack community is so inclined. Not only to shepherd how Openstack is
put together but to help enable an easier and more seamless adoption cycle
within the enterprise.

Lastly in the spirit of full disclosure, I am the principal architect for
an Openstack consulting company I founded which strives for an accelerated
enterprise adoption of the open cloud through, in part, the successes of
Openstack. So one could say I am vested in Openstack in a pretty unique way
compared to most others. So where technical direction is concerned, I
believe I have a deep well of experience from which to draw via designing
and developing production Openstack clouds in the real world - day in and
day out - which I believe would be of immense value to the TC and the
community supporting the project itself.

I know there are some really smart people who want to also serve on the TC
with focuses on various areas of Openstack and thankfully the committee was
designed to accommodate multiple unique perspectives for that very reason.
My hope is that the community chooses to include my program-agnostic
architectural influence to the TC while maintaining the same work ethic and
unyielding commitment to efforts that will deliver excellence to and within
the Openstack platform.

So without any further adieu, below are my thoughts re the requested
questions and thanks for your consideration!

*My name is Adam Lawson, running for election to the Openstack Technical
Committee, and I approve this message.* ; )

*Topic: OpenStack Mission*
*How do you feel the technical community is doing in meeting the OpenStack
Mission?*

*“To produce the ubiquitous Open Source Cloud Computing platform that will
meet the needs of public and private clouds regardless of size, by being
simple to implement and massively scalable.”*

The whole point of mission statements is merely to identify what we are
striving to achieve or accomplish within the organization. With that said,
I feel that technical leadership is the first step to accomplishing a
technical goal. So to that end, the existence of the TC is a positive first
step. But it's just one step or many more to come.
 Within this particular TC cycle, I'd like to see the TC demonstrate
leadership to drive a reduction of lingering technical debt and address API
and module standardization. Openstack in its current form has a number of
challenges that are affecting our ability to scale and while some of this
can be solved organizationally, technical debt and standardization are
challenges that will not be easy to resolve and might not even be 100
percent solvable within a single release cycle. But I look forward to how
the TC *will* shepherd improvements to both process and the product and
help drive the mission.
 On a side note, easy to implement is still just a goal and the
engineering requirement to deploy and manage Openstack is still a
prohibitive hurdle for many organizations. But we have more than one tool
in front of us that will help us to help others who want to use Openstack
but .. can't. That's something I'd really like to see change soon.

*Topic: Contributor Motivation*
*How would you characterize the various facets of contributor motivation?*
 I like what I read earlier today: People want to do work that matters and
enjoy doing it. This sums up Openstack contributors very well but it sums
up a lot of us too though, doesn't it.
 Many of us are lucky enough to be able to work on Openstack full-time as a
job. There are many

Re: [openstack-dev] [all][docs][tc] How to scale Documentation

2014-10-06 Thread Adam Lawson
I personally believe that delegating the task of documentation to
individual projects would be a huge mistake for one big reason:
documentation exists to understand how everything works within the context
of the solution as a whole. Very hard to do that consistently across all
projects with the docs team entrenched in developing individual products.

Plus, enterprise adoption of the open cloud *requires* documentation that
isn't an after thought. Writing code and trying to set aside some time to
document is the sheer definition of turning documentation an afterthought -
and no superior product has ever come from that sort of model.



*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Mon, Oct 6, 2014 at 8:40 AM, Zane Bitter zbit...@redhat.com wrote:

 On 06/10/14 06:07, Thierry Carrez wrote:

 Jay Pipes wrote:

 On 10/03/2014 09:18 PM, Zane Bitter wrote:

 The prospect of a much larger tent with many more projects in
 OpenStack-proper shines a spotlight on the scalability of the Docs team,
 and in particular how they decide which projects are important to work
 on directly.


 I don't believe that a ticket to live under the OpenStack tent should
 come with the expectation that the Docs team is required to write
 documentation for the project.

 IMHO, it should be up to the project itself to provide the resources to
 work *under the guidance* of the Docs team to write developer, end user
 and operator documentation. The Docs team members should be able to play
 an advisory role for new projects, helping them understand the automated
 doc processes, the way that common doc infrastructure works, and
 techniques for writing useful documentation consistent with other
 projects.


 I'd like to generalize that beyond Docs, because the same issue applies
 to all other horizontal teams.

 There are multiple ways an horizontal team can declare its commitment,
 and I agree we should never assume that a TC decision (new integrated
 project!) implies more work for the team (Docs now has to support this
 as well). That's the way it currently works, and yes, it doesn't scale.
 It didn't scale early with Docs, so they opted out of supporting all
 integrated projects early on.

 So in summary:
 - ticket to live under the OpenStack big tent should never come with
 expectation that any horizontal team will do the work for that project
 directly
 - horizontal teams may decide to directly do the work for any number of
 projects
 - corollary #1: horizontal teams may decide to commit to directly doing
 the work for a mostly-static ring0 (or not)
 - corollary #2: horizontal teams may decide to not directly do the work
 for any project
 - horizontal teams should build processes and tools to facilitate and
 guide the work of projects in the big tent in their area of expertise


 +1

 So it seems like there is general agreement that we don't need/want the TC
 to tell horizontal teams what to work on, and that isn't one of the reasons
 for ring0/ring compute/Layer 1 to be a thing?

 cheers,
 Zane.


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Openstacl] [Glance] Container format

2014-10-06 Thread Adam Lawson
Hi all, is there a reason that specifying a 'bare' container format option
is required from the operator given it isn't used by any Openstack
services? [1]

[1]
http://docs.openstack.org/trunk/install-guide/install/apt/content/glance-verify.html
(step4)


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][docs][tc] How to scale Documentation

2014-10-06 Thread Adam Lawson
I like your suggestion about the Docs team being advisors. I would submit
however (my opinion here) that whether or not there are enough resources on
the Doc'n team to handle Openstack's current list of integrated programs,
offloading the work to individual projects exchanges one challenge
(scalability) with another problem (quality). Using that approach, doc bugs
will get triaged with the other project bugs and potentially distracts
developers from doing what they do best - writing and fixing code. And what
happens when you only have time to fix a feature or work on documentation?
Focus on features and performance/stability are going to win. Every time.
And they should because that what the program teams should be focused on.
That means we start down the road heavy on code because developers can't do
everything, making them light on documentation forcing a catch-up process
to ensure which requires a special team to preserve momentum, bringing us
back to where we are now. I've been there before. And I'm sure others have
as well.

I've always been a big proponent of exploiting strengths vs building on
weaknesses and I'm going to step out on a limb here and speak to strengths
which may get me into hot water with some so I want to apologize in
advance. ; )

If a team of developers is tasked to produce all of the documentation for
enterprise consumers, I hate to say it like this but you'll end up with
highly-targeted documentation that makes sense to a developer and possibly
low-level engineers. That level of detail is probably best served in
README, wikis and mailing lists. It isn't effective as a user's manual.
Even with coaching, we'd be coaching folks to do things they aren't good
at. Same goes for a solution architect writing documentation the other way
around - you end up with documentation that speaks so broad, it fails to
make the impact that a targeted/focused approach is needed by the
engineering consumers.

While documentation produced by each individual project makes a special
kind of impact, it must be one spoke - not the entire wheel. I love the
idea of advisors and they should provide the first draft but I also believe
a dedicated team is needed to ensure quality doesn't suffer.


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Mon, Oct 6, 2014 at 9:59 AM, Jay Pipes jaypi...@gmail.com wrote:

 On 10/06/2014 12:44 PM, Adam Lawson wrote:

 I personally believe that delegating the task of documentation to
 individual projects would be a huge mistake for one big reason:
 documentation exists to understand how everything works within the
 context of the solution as a whole. Very hard to do that consistently
 across all projects with the docs team entrenched in developing
 individual products.

 Plus, enterprise adoption of the open cloud /requires/ documentation
 that isn't an after thought. Writing code and trying to set aside some
 time to document is the sheer definition of turning documentation an
 afterthought - and no superior product has ever come from that sort of
 model.


 I hear your concerns about the possibility of getting documentation that
 is either inconsistent (with respect to the other OpenStack projects) or
 not written for the right audience if we only have developer contributors
 writing documentation. You have an excellent and prescient point.

 However, with my proposal, I was only saying that being under the
 OpenStack tent should not come with an automatic gift of resources from the
 excellent OpenStack Docs horizontal team. This process cannot scale.
 Instead, I believe it should be incumbent on the joining project to provide
 resources to work *with* the horizontal Docs team to provide foundational
 documentation for end users and operators. The Docs team can and should be
 advisors to the project contributors in how to write effective
 documentation targeted at non-developer contributors.

 In addition, please see my proposal that projects applying to be in the
 OpenStack tent would have a requirement to name both a Docs liaison as well
 as a Release Management liaison. [1]

 Best,
 -jay

 [1] http://www.joinfu.com/2014/09/answering-the-existential-
 question-in-openstack/


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Suggestions for students final year project

2014-10-06 Thread Adam Lawson
Patricia,

Perhaps someone from the Sahara team has a need for help to resolve a
problem. If patching or implementing a new feature isn't your idea of a
final project, maybe create a big data job that analyses real-time Twitter
trends on a virtualized Hadoop cluster. Or maybe a comparison running that
same job between multiple virtual clusters with Hortonworks versus Cloudera
versus Vanilla Apache Hadoop and compare which one performs better and why.

Just some suggestions. ; )

Mahalo,
Adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Mon, Oct 6, 2014 at 12:25 PM, Patricia Ellis patricia.el...@mycit.ie
wrote:

 Hi Adam,

 Thanks for taking the time to reply.

 I'm more of a web development type than security. I have some maths
 background so perhaps something with data analysis.

 To date I have done mostly Java, some JavaScript, Html, and MySQL. I am
 interested in learning Python. I co-developed a web app to check and commit
 time-sheets to a database during my work experience this summer; I did the
 database and the checking of the sheets. I, have also, created an Android
 app to monitor the fuel consumption in multiple vehicles, using the Android
 SQLite Database for storage.



 On 6 October 2014 18:37, Adam Young ayo...@redhat.com wrote:

  On 10/06/2014 01:14 PM, Patricia Ellis wrote:

  My name is Patricia Ellis, I am a fourth year software development
 student at Cork Institute of Technology. I am looking for ideas for my
 final year project. I have six weeks to get my proposal together and then
 13 weeks to implement it. I am hoping you might have a suitable project on
 your wish list, one which is of the ”low hanging fruit” variety as my time
 frame is tight.


 ___
 OpenStack-dev mailing 
 listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

  Patricia,

 I am Keystone core developer.  I have several ideas.   It really depends
 on your skills and interests.

 Are you a security person?

 If not,  are you a web development type person?

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Thoughts on OpenStack Layers and a Big Tent model

2014-09-19 Thread Adam Lawson
Can someone do a small little Visio or other visual to explain what's being
proposed here? My head sported a small crack at around the 5-6th page...

; ) But seriously, I couldn't understand the proposal. Maybe I'm not the
audience which is fine, just saying, the words got in the way. Sounds like
a song!


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Fri, Sep 19, 2014 at 5:46 AM, John Griffith john.griff...@solidfire.com
wrote:



 On Fri, Sep 19, 2014 at 4:33 AM, Thierry Carrez thie...@openstack.org
 wrote:

 Vishvananda Ishaya wrote:
  Great writeup. I think there are some great concrete suggestions here.
 
  A couple more:
 
  1. I think we need a better name for Layer #1 that actually represents
 what the goal of it is: Infrastructure Services?
  2. We need to be be open to having other Layer #1s within the
 community. We should allow for similar collaborations and group focus to
 grow up as well. Storage Services? Platform Services? Computation Services?

 I think that would nullify most of the benefits of Monty's proposal. If
 we keep on blessing themes or special groups, we'll soon be back at
 step 0, with projects banging on the TC door to become special, and
 companies not allocating resources to anything that's not special.

 --
 Thierry Carrez (ttx)

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ​Great stuff, mixed on point 2 raised by Vish but honestly I think that's
 something that could evolve over time, but I looked at that differently as
 in Cinder, SWIFT and some day Manilla live under a Storage Services
 umbrella, and ideally at some point there's some convergence there.

 Anyway, I don't want to start a rat-hole on that, it's kind of irrelevant
 right now.  Bottom line is I think the direction and initial ideas in
 Monty's post are what a lot of us have been thinking about and looking for.
  I'm in!!​


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Zaqar] Comments on the concerns arose during the TC meeting

2014-09-09 Thread Adam Lawson
*should OpenStack include, in the integrated release,
a messaging-as-a-service component*

Assuming this is truly a question that represents where we are and not
exploratory of what we might want to address, I would say the answer is a
resounding no, as queuing is within the scope of what Openstack is and has
always been. If we get into integrated messaging, I'm struggling to
understand what value it adds to the IaaS goal. We might as well start
integrating office and productivity applications while we're at it.

Sorry if i sound cheeky but considering this seems rather odd to me.


*Adam Lawson*
*CEO, Principal Architect*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Tue, Sep 9, 2014 at 5:03 PM, Clint Byrum cl...@fewbar.com wrote:

 Excerpts from Devananda van der Veen's message of 2014-09-09 16:47:27
 -0700:
  On Tue, Sep 9, 2014 at 4:12 PM, Samuel Merritt s...@swiftstack.com
 wrote:
   On 9/9/14, 12:03 PM, Monty Taylor wrote:
  [snip]
   So which is it? Because it sounds like to me it's a thing that
 actually
   does NOT need to diverge in technology in any way, but that I've been
   told that it needs to diverge because it's delivering a different set
 of
   features - and I'm pretty sure if it _is_ the thing that needs to
   diverge in technology because of its feature set, then it's a thing I
   don't think we should be implementing in python in OpenStack because
 it
   already exists and it's called AMQP.
  
  
   Whether Zaqar is more like AMQP or more like email is a really strange
   metric to use for considering its inclusion.
  
 
  I don't find this strange at all -- I had been judging the technical
  merits of Zaqar (ex-Marconi) for the last ~18 months based on the
  understanding that it aimed to provide Queueing-as-a-Service, and
  found its delivery of that to be lacking on technical grounds. The
  implementation did not meet my view of what a queue service should
  provide; it is based on some serious antipatterns (storing a queue in
  an RDBMS is probably the most obvious); and in fact, it isn't even
  queue-like in the access patterns enabled by the REST API (random
  access to a set != a queue). That was the basis for a large part of my
  objections to the project over time, and a source of frustration for
  me as the developers justified many of their positions rather than
  accepted feedback and changed course during the incubation period. The
  reason for this seems clear now...
 
  As was pointed out in the TC meeting today, Zaqar is (was?) actually
  aiming to provide Messaging-as-a-Service -- not queueing as a service!
  This is another way of saying it's more like email and less like
  AMQP, which means my but-its-not-a-queue objection to the project's
  graduation is irrelevant, and I need to rethink about all my previous
  assessments of the project.

 Well said.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-09 Thread Adam Lawson
Deleting unnecessary code, introducing a stabilization cycle and/or making
definite steps towards a unified SDK are definitely my votes.


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Tue, Sep 9, 2014 at 5:09 PM, Joe Gordon joe.gord...@gmail.com wrote:



 On Wed, Sep 3, 2014 at 8:37 AM, Joe Gordon joe.gord...@gmail.com wrote:

 As you all know, there has recently been several very active discussions
 around how to improve assorted aspects of our development process. One
 idea
 that was brought up is to come up with a list of cycle goals/project
 priorities for Kilo [0].

 To that end, I would like to propose an exercise as discussed in the TC
 meeting yesterday [1]:
 Have anyone interested (especially TC members) come up with a list of
 what they think the project wide Kilo cycle goals should be and post them
 on this thread by end of day Wednesday, September 10th. After which time we
 can begin discussing the results.
 The goal of this exercise is to help us see if our individual world views
 align with the greater community, and to get the ball rolling on a larger
 discussion of where as a project we should be focusing more time.




 1. Strengthen our north bound APIs

 * API micro-versioning
 * Improved CLI's and SDKs
 * Better capability discovery
 * Hide usability issues with client side logic
 * Improve reliability

 As others have said in this thread trying to use OpenStack as a user is a
 very frustrating experience. For a long time now we have focused on
 southbound APIs such as drivers, configuration options, supported
 architectures etc. But as a project we have not spent nearly enough time on
 the end user experience. If our northbound APIs aren't something developers
 want to use, our southbound API work doesn't matter.

 2. 'Fix' our development process

 * openstack-specs. Currently we don't have any good way to work on big
 entire-project efforts, hopefully something like a openstack-specs repo
 (with liasons from each core-team reviewing it) will help make it possible
 for us to tackle these issues.  I see us addressing the API
 micro-versioning and capability  discovery issues here.
 * functional testing and post merge testing. As discussed elsewhere in
 this thread our current testing model isn't meeting our current
 requirements.

 3. Pay down technical debt

 This is the one I am actually least sure about, as I can really only speak
 for nova on this one. In our constant push forward we have accumulated a
 lot of technical debt. The debt manifests itself as hard to maintain code,
 bugs (nova had over 1000 open bugs until yesterday), performance/scaling
 issues and missing basic features. I think its time for us to take
 inventory if our technical debt and fix some of the biggest issues.



 best,
 Joe Gordon

 [0]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
 [1]
 http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] SSL in Fuel

2014-09-08 Thread Adam Lawson
blueprints for non-self-signed certs/PKI for starters.


*Adam Lawson*
*CEO, Principal Architect*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072



On Mon, Sep 8, 2014 at 2:49 AM, Sebastian Kalinowski 
skalinow...@mirantis.com wrote:

 Hi all,

 As next step for improving Fuel security we are introducing SSL for both
 Fuel [1] and OS API endpoints [2]. Both specs assume usage of self-signed
 certificates generated by Fuel.
 It also required to allow users to use their own certs to secure their
 deployments
 (two blueprints that touch that part are [3] and [4])

 We would like to start a discussion to see what opinions (and maybe ideas)
 you
 have for that feature.

 Best,
 Sebastian

 [1] https://review.openstack.org/#/c/119330
 [2] https://review.openstack.org/#/c/102273
 [3] https://blueprints.launchpad.net/fuel/+spec/ca-deployment
 [4] https://blueprints.launchpad.net/fuel/+spec/manage-ssl-certificate

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] The future of the integrated release

2014-08-25 Thread Adam Lawson
I recognize I'm joining the discussion late but I've been following the
dialog fairly closely and want to offer my perspective FWIW. I have a lot
going through my head, not sure how to get it all out there so I'll do a
brain dump, get some feedback and apologize in advance.

One the things I like most about Openstack is its incredible flexibility -
a modular architecture where certain programs/capabilities can be leveraged
for a specific install - or not, and ideally the rest of the feature suite
remains functional irrespective of a program status. When it comes to a
program being approved as part of Openstack Proper (pardon my stepping over
that discussion), I think a LOT of what is being discussed here touches on
what Openstack will ultimately be about and what it won't.

With products like Cloudstack floating around consuming market share, all I
see is Citrix. A product billed as open source but so closely aligned with
one vendor that it almost doesn't matter. They have matured decision
structure, UI polish and organized support but they don't have community.
Not like us anyway. With Openstack the moral authority to call ourselves
the champions of open cloud and with that, we have competing interests that
make our products better. We don't have a single vendor (yet) that dictates
whether something will happen or not. The maturity of the Openstack
products themselves are driven by a community of consumers where the needs
are accommodated rather than sold.

A positive than comes with such a transparent design pipeline is the
increased capability for design agility and accommodating changes when a
change is needed. But I'm becoming increasingly disappointed at the mount
of attention being given to whether one product is blessed by Openstack or
not. In a modular design, these programs should be interchangeable with
only a couple exceptions. Does being blessed really matter? The consensus
I've garnered in this thread is the desperate need for the consuming
community's continued involvement. What I *haven't* heard much about is how
Openstack can standardize how these programs - blessed or not - can
interact with the rest of the suite to the extent they adhere to the
correct inputs/outputs which makes them functional. Program status is
irrelevant.

I guess when it comes right down to it, I love what Openstack is and where
we're going and I especially appreciate these discussions. But I'm
disappointed at the number of concerns I've been reading about things that
ultimately don't matter (like being blessed, about who has the power, etc)
and I have concerns we lose sight what this is all about to the point that
the vision for Openstack gets clouded.

We have a good thing and no project can accommodate every request so a
decision must be made as to what is 'included' and what is 'supported'. But
with modularity, it really doesn't matter one iota if a program is blessed
in the Openstack integrated release cycle or not.

But my goodness we have some brilliant minds on our team don't we!

Mahalo,
Adam


*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072



On Mon, Aug 25, 2014 at 6:36 AM, Sean Dague s...@dague.net wrote:

 On 08/20/2014 12:37 PM, Zane Bitter wrote:
  On 11/08/14 05:24, Thierry Carrez wrote:
  So the idea that being (and remaining) in the integrated release should
  also be judged on technical merit is a slightly different effort. It's
  always been a factor in our choices, but like Devananda says, it's more
  difficult than just checking a number of QA/integration checkboxes. In
  some cases, blessing one project in a problem space stifles competition,
  innovation and alternate approaches. In some other cases, we reinvent
  domain-specific solutions rather than standing on the shoulders of
  domain-specific giants in neighboring open source projects.
 
  I totally agree that these are the things we need to be vigilant about.
 
  Stifling competition is a big worry, but it appears to me that a lot of
  the stifling is happening even before incubation. Everyone's time is
  limited, so if you happen to notice a new project on the incubation
  trajectory doing things in what you think is the Wrong Way, you're most
  likely to either leave some drive-by feedback or to just ignore it and
  carry on with your life. What you're most likely *not* to do is to start
  a competing project to prove them wrong, or to jump in full time to the
  existing project and show them the light. It's really hard to argue
  against the domain experts too - when you're acutely aware of how
  shallow your knowledge is in a particular area it's very hard to know
  how hard to push. (Perhaps ironically, since becoming a PTL I feel I
  have to be much more cautious in what I say too, because people are
  inclined to read too much into my opinion - I wonder if TC members feel
  the same pressure

Re: [openstack-dev] [Fuel] Enable SSL between client and API exposed via public URL with HAProxy

2014-08-21 Thread Adam Lawson
IMHO, removing non-HA mode in Fuel would be a mistake as Fuel is also used
for smaller deployments. HA is required for Production sure but removing
support for smaller deployments would drive consumers of smaller clouds
elsewhere for orchestration. Maintaining support for smaller clouds
probably isn't a priority for Mirantis but I think it should be a priority
for the general community consumer base. This also goes for all of the
orchestrators out there whether it's SUSE, Juju, Piston, Nebulous, etc etc.

Just my two cents.


*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072



On Thu, Aug 21, 2014 at 7:24 AM, Guillaume Thouvenin thouv...@gmail.com
wrote:


 On Thu, Aug 21, 2014 at 5:02 PM, Mike Scherbakov mscherba...@mirantis.com
  wrote:



 Guillaume, do I understand right that without implementation of
 https://blueprints.launchpad.net/fuel/+spec/ca-deployment, SSL support
 will not be fully automated? And, consequently, we can not call it as
 complete production ready feature for Fuel users?


 Yes you are right.  Without the implementation of the CA deployment  we
 can not consider it as ready to use.
 To test my deployment I manually copy a self-signed certificate on all
 controllers on a predefined location according to what I have in the puppet
 manifest. So it's really just for testing. I also write a small puppet
 manifest to generate a self signed certificate to deploy it automatically
 but it works only for one controller so this solution is also only for
 testing.

 So to have the feature ready for production we need to manage certificate
 maybe as a new option into the fuel dashboard.

 Best Regards,
 Guillaume

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] generate Windows exe

2014-08-20 Thread Adam Lawson
Curious, did you follow the link and follow the Gerrit workflow? Seems your
rejection letter (unlike mine I received from my sweetheart in high school)
was due to process rather than merit. (
http://wiki.openstack.org/GerritWorkflow)


*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072



On Wed, Aug 20, 2014 at 11:15 AM, Szépe Viktor vik...@szepe.net wrote:

 Is it the right list?

 The PR was rejected: https://github.com/openstack/
 python-swiftclient/pull/14



 Idézem/Quoting Szépe Viktor vik...@szepe.net:

  Now bin\swift can only be started by python Scripts\swift
 Windows does not support extensionless scripts.
 Maybe I did it wrong, this is my first encounter with setuptools.


 Please consider modifying setup.py

 import setuptools

 setuptools.setup(
 setup_requires=['pbr'],
 pbr=True,
 entry_points={
 console_scripts: [
 swift=swiftclient.shell:main
 ]
 })

 Thank you!


 Szépe Viktor
 --
 +36-20-4242498  s...@szepe.net  skype: szepe.viktor
 Budapest, XX. kerület





 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [QA] Picking a Name for the Tempest Library

2014-08-16 Thread Adam Lawson
I like tempest-lib personally. Especially for those just starting out and
getting their feet wet.
On Aug 16, 2014 5:36 AM, Chris Dent chd...@redhat.com wrote:

 On Fri, 15 Aug 2014, Jay Pipes wrote:

  I suggest that tempest should be the name of the import'able library,
 and that the integration tests themselves should be what is pulled out of
 the current Tempest repository, into their own repo called
 openstack-integration-tests or os-integration-tests.


 This idea is best, but if a new name is required, tempit is good because it
 is a) short b) might subconsciously remind people that testing ought to
 be fast(-ish).

 --
 Chris Dent tw:@anticdent freenode:cdent
 https://tank.peermore.com/tanks/cdent

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Time to Samba! :-)

2014-08-16 Thread Adam Lawson
Doesn't Murano address this already?
On Aug 16, 2014 2:35 PM, Martinx - ジェームズ thiagocmarti...@gmail.com
wrote:

 I think that it would be great too! OpenLDAP-as-a-Service... With
 multi-domain support! :-)

 Nevertheless, last time I used Samba, was back in 2001... It is impressive
 these days! It worth take a look... I'm using it for about two months now,
 it is great!

 Cheers!


 On 16 August 2014 18:01, Clint Byrum cl...@fewbar.com wrote:

 Excerpts from Martinx - ジェームズ's message of 2014-08-16 12:03:20 -0700:
  Hey Stackers,
 
   I'm wondering here... Samba4 is pretty solid (up coming 4.2 rocks), I'm
  using it on a daily basis as an AD DC controller, for both Windows and
  Linux Instances! With replication, file system ACLs - cifs, built-in
 LDAP,
  dynamic DNS with Bind9 as a backend (no netbios) and etc... Pretty cool!
 
   In OpenStack ecosystem, there are awesome solutions like Trove, Solum,
  Designate and etc... Amazing times BTW! So, why not try to integrate
  Samba4, working as an AD DC, within OpenStack itself?!
 

 But, if we did that, what would be left for us to reinvent in our own
 slightly different way?

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Time to Samba! :-)

2014-08-16 Thread Adam Lawson
Also, don't forget that AD != LDAP. ;)
On Aug 16, 2014 5:16 PM, Adam Lawson alaw...@aqorn.com wrote:

 Doesn't Murano address this already?
 On Aug 16, 2014 2:35 PM, Martinx - ジェームズ thiagocmarti...@gmail.com
 wrote:

 I think that it would be great too! OpenLDAP-as-a-Service... With
 multi-domain support! :-)

 Nevertheless, last time I used Samba, was back in 2001... It is
 impressive these days! It worth take a look... I'm using it for about two
 months now, it is great!

 Cheers!


 On 16 August 2014 18:01, Clint Byrum cl...@fewbar.com wrote:

 Excerpts from Martinx - ジェームズ's message of 2014-08-16 12:03:20 -0700:
  Hey Stackers,
 
   I'm wondering here... Samba4 is pretty solid (up coming 4.2 rocks),
 I'm
  using it on a daily basis as an AD DC controller, for both Windows and
  Linux Instances! With replication, file system ACLs - cifs, built-in
 LDAP,
  dynamic DNS with Bind9 as a backend (no netbios) and etc... Pretty
 cool!
 
   In OpenStack ecosystem, there are awesome solutions like Trove, Solum,
  Designate and etc... Amazing times BTW! So, why not try to integrate
  Samba4, working as an AD DC, within OpenStack itself?!
 

 But, if we did that, what would be left for us to reinvent in our own
 slightly different way?

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] OS or os are not acronyms for OpenStack

2014-08-15 Thread Adam Lawson
I really think we have much bigger fish to fry than to start policing
community shorthand where nearly every meeting and communication is typed.
That's just my two cents for what it's worth.

Mahalo,
Adam


*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072



On Fri, Aug 15, 2014 at 10:49 AM, Russell Bryant rbry...@redhat.com wrote:

 On 08/15/2014 01:28 PM, Mike Spreitzer wrote:
  Anita Kuno ante...@anteaya.info wrote on 08/15/2014 01:08:44 PM:
 
  ...
  I think you hit the nail on the head here, Russell, it's fine in the
  right context.
 
  The definition of the right context however is somewhat elusive. I have
  chosen (it is my own fault) to place myself in the area where the folks
  I deal with struggle with understanding context. The newcomers to the
  third party space and folks creating stackforge repos don't have the
  benefit of the understanding that core reviewers have (would I be
  accurate in saying that it is mostly nova reviewers who have responded
  to my initial post thus far?).
 
  I suffered from an instance of this confusion myself when I was just
  getting started,
  and have seen colleagues get confused too.  I suspect this problem hits
  many
  newcomers.

 but surely when it comes to learning OpenStack itself, the OpenStack
 community, dev processes, tools, etc  this has got to be extremely
 far down the list of barriers to entry.

 --
 Russell Bryant

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] introducing cyclops

2014-08-12 Thread Adam Lawson
I am also highly interested. A very large adoption inhibitor has been the
ability to control cloud consumption with charge-back and/or cost center
billing support. Would love to talk about this.


*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072



On Tue, Aug 12, 2014 at 8:48 AM, Stephane Albert sheepr...@nullplace.com
wrote:

 On Tue, Aug 12, 2014 at 05:47:49PM +1200, Fei Long Wang wrote:
  Our suggestion for the first IRC meeting is 25/August 8PM-10PM UTC time
 on
  Freenodes's #openstack-rating channel.
 
  Thoughts? Please reply with the best date/time for you so we can figure
 out a
  time to start.
 

 I'll like to participate to this meeting, but one of my colleagues will
 not be available on the 25th. Maybe we can shift the date to the 26th?

 Thanks

  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Openstack Capacity Planning

2014-08-12 Thread Adam Lawson
Something was presented at a meeting recently which had me curious: what
sort of capacity planning tools/capabilities are being developed as an
Openstack program? It's another area where non-proprietary cloud control is
needed and would be another way to kick a peg away from the stool of cloud
resistance. Also, this ties quite nicely into Software Defined Datacenter
but appropriateness for the Openstack suite itself is another matter...

Has this been given much thought at this stage of the game? I'd be more
than happy to host a meeting to talk about it.

Mahalo,
Adam

*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev