Re: [Openstack] compute nodes down

[Adam Lawson]

Be careful, a compute node showing as down may not actually be down at all
but the agent not being able to report back or frm the conductor not being
able to update the db. I was about to ask if the VM's were offline or not.
Glad you got it figured out!

//adam

On Dec 29, 2017 1:04 PM, "Jim Okken"  wrote:

> I believe this issue turned out to be the shared storage device we are
> using for shared storage to each compute node.
>
> it had an access issue and one instance's vHD files had access attempts
> that hung forever and never timed out.
> this make sense for one node to be having nova issues. But could this
> cause all compute nodes to have nova services to stop after some time? (in
> a shared storage setup does each node access/query each vHD on the storage
> periodically?)
>
> thanks!
>
> -- Jim
>
> On Tue, Dec 19, 2017 at 3:45 AM, Tobias Urdin 
> wrote:
>
>> Enable debug in nova.conf and check conductor and compute logs.
>>
>> Check that your clock is in-sync with NTP or you might experience that
>> the alive checks in the database exceeds the service_down_time config value.
>>
>> On 12/19/2017 12:09 AM, Jim Okken wrote:
>>
>> hi list,
>>
>> hoping someone could shed some light on this issue I just started seeing
>> today
>>
>> all my compute nodes started showing as "Down" in the Horizon ->
>> Hypervisors -> Compute Nodes tab
>>
>>
>> root@node-1:~# nova service-list
>> +-+--+---+--+---
>> --+---++-+
>> | Id  | Binary   | Host  | Zone | Status  | State
>> | Updated_at | Disabled Reason |
>> +-+--+---+--+---
>> --+---++-+
>> | 325 | nova-compute | node-9.mydom.com  | nova | enabled |
>> down  | 2017-12-18T21:59:38.00 | -   |
>> | 448 | nova-compute | node-14.mydom.com | nova | enabled | up
>>   | 2017-12-18T22:41:42.00 | -   |
>> | 451 | nova-compute | node-17.mydom.com | nova | enabled | up
>>   | 2017-12-18T22:42:04.00 | -   |
>> | 454 | nova-compute | node-11.mydom.com | nova | enabled | up
>>   | 2017-12-18T22:42:02.00 | -   |
>> | 457 | nova-compute | node-12.mydom.com | nova | enabled | up
>>   | 2017-12-18T22:42:12.00 | -   |
>> | 472 | nova-compute | node-16.mydom.com | nova | enabled |
>> down  | 2017-12-18T00:16:01.00 | -   |
>> | 475 | nova-compute | node-10.mydom.com | nova | enabled |
>> down  | 2017-12-18T00:26:09.00 | -   |
>> | 478 | nova-compute | node-13.mydom.com | nova | enabled |
>> down  | 2017-12-17T23:54:06.00 | -   |
>> | 481 | nova-compute | node-15.mydom.com | nova | enabled | up
>>   | 2017-12-18T22:41:34.00 | -   |
>> | 484 | nova-compute | node-8.mydom.com  | nova | enabled |
>> down  | 2017-12-17T23:55:50.00 | -   |
>>
>>
>> if I stop and the start nova-compute on the down nodes the stop will take
>> several minutes and then the start will be quick and fine. but after about
>> 2 hours the nova-compute service will show down again.
>>
>> i am not seeing any ERRORS in nova logs.
>>
>> I get this for the status of a node that is showing as "UP"
>>
>>
>>
>> root@node-14:~# systemctl status nova-compute.service
>> â nova-compute.service - OpenStack Compute
>>Loaded: loaded (/lib/systemd/system/nova-compute.service; enabled;
>> vendor preset: enabled)
>>Active: active (running) since Mon 2017-12-18 21:57:10 UTC; 35min ago
>>  Docs: man:nova-compute(1)
>>   Process: 32193 ExecStartPre=/bin/chown nova:adm /var/log/nova
>> (code=exited, status=0/SUCCESS)
>>   Process: 32190 ExecStartPre=/bin/chown nova:nova /var/lock/nova
>> /var/lib/nova (code=exited, status=0/SUCCESS)
>>   Process: 32187 ExecStartPre=/bin/mkdir -p /var/lock/nova /var/log/nova
>> /var/lib/nova (code=exited, status=0/SUCCESS)
>>  Main PID: 32196 (nova-compute)
>>CGroup: /system.slice/nova-compute.service
>>ââ32196 /usr/bin/python /usr/bin/nova-compute
>> --config-file=/etc/nova/nova-compute.conf --config-file=/etc/nova/nova.conf
>> --log-file=/var/log/nova/nova-compute.log
>>
>> Dec 18 22:31:47 node-14.mydom.com nova-compute[32196]: 2017-12-18
>> 22:31:47.570 32196 DEBUG oslo_messaging._drivers.amqpdriver
>> [req-f30b2331-2097-4981-89c8-acea4a81f7f2 - - - - -] CALL msg_id:
>> 2877b9707da144f3a91e7b80e2705fb3 exchange 'nova' topic 'conductor' _send
>> /usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/
>> amqpdriver.py:448
>> Dec 18 22:31:47 node-14.mydom.com nova-compute[32196]: 2017-12-18
>> 22:31:47.604 32196 DEBUG oslo_messaging._drivers.amqpdriver [-] received
>> reply msg_id: 2877b9707da144f3a91e7b80e2705fb3 __call__
>> 

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

[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

[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

[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

[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

[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

[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

[Openstack] [TC] Vision?

[Adam Lawson]

I don't mean to be inflammatory. First off.

That said, I was emailed a link to review the drafted TC vision. When going
through it I did not see a vision but rather a 'yay for our to-date
accomplishments' statement. What are the actual plans for the future as
envisioned by the TC?

//adam

*Adam Lawson*

Principal Architect
Office: +1-916-794-5706
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] controller redundancy

[Adam Lawson]

Fyi, the idea of controllers are a bit of a misnomer. You should have
redundant services; they don't necessarily need to be on the same box.
Since your asking as a new user. Have fun!

//adam

On Apr 12, 2017 5:27 PM, "Konstantin Raskoshnyi"  wrote:

> Yes, machines are still running, but since neutron is down none of them
> can be accessible.
>
> On Wed, Apr 12, 2017 at 5:10 PM ron ramos  wrote:
>
>> hi,
>>
>> depends on what you mean by inaccessible, your VM is probably still up
>> and running on the compute node. but you won't be able to access them
>> remotely as your controller node ( which is hosting neutron ) is down.
>>
>> regards,
>> nhadie
>>
>>
>> On Apr 12, 2017 11:31, "Konstantin Raskoshnyi" 
>> wrote:
>>
>> Hi guys,
>> I'm new to openstack.
>> Installed mirantis os 9,
>> If one of controllers goes down - vm machines are not accesible, I though
>> openstack supposed to work even if one controller is alive
>>
>> Any thoughts?
>>
>> ___
>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack
>>
>>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] controller redundancy

[Adam Lawson]

Another FYI, OpenStack services don't have to be running to access a
virtual machine. Period. Amy other condition that prevents this is a
serious design flaw.

//adam

On Apr 13, 2017 5:31 AM, wrote:

> Fyi, the idea of controllers are a bit of a misnomer. You should have
> redundant services; they don't necessarily need to be on the same box.
> Since your asking as a new user. Have fun!
>
> //adam
>
> On Apr 12, 2017 5:27 PM, "Konstantin Raskoshnyi" 
> wrote:
>
>> Yes, machines are still running, but since neutron is down none of them
>> can be accessible.
>>
>> On Wed, Apr 12, 2017 at 5:10 PM ron ramos  wrote:
>>
>>> hi,
>>>
>>> depends on what you mean by inaccessible, your VM is probably still up
>>> and running on the compute node. but you won't be able to access them
>>> remotely as your controller node ( which is hosting neutron ) is down.
>>>
>>> regards,
>>> nhadie
>>>
>>>
>>> On Apr 12, 2017 11:31, "Konstantin Raskoshnyi" 
>>> wrote:
>>>
>>> Hi guys,
>>> I'm new to openstack.
>>> Installed mirantis os 9,
>>> If one of controllers goes down - vm machines are not accesible, I
>>> though openstack supposed to work even if one controller is alive
>>>
>>> Any thoughts?
>>>
>>> ___
>>> Mailing list: http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>> Post to : openstack@lists.openstack.org
>>> Unsubscribe : http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>>
>>>
>> ___
>> Mailing list: http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>>
>>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] VM can receive traffic, but not send it

[Adam Lawson]

For downloads, you're using probably DNAT or SNAT. For *uploads*, you're
using floating IP's I'm guessing. Does uploads work for other VM's with a
similar configuration? It's rare that this would occur so I would presume
it's firewall related (either security group via OpenStack) or firewall on
the VM itself.

Another question, are incoming connections timing out, is the security
group allowing connections from everyone or a subset? i ask because I
haven't seen the easy questions asked up front.

//adam


*Adam Lawson*

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

On Wed, Mar 22, 2017 at 11:31 AM, Kaustubh Kelkar <
kaustubh.kel...@casa-systems.com> wrote:

> The select_all = 1 is supposed to mirror all the packets.
>
>
>
> Referring to the documentation (http://openvswitch.org/
> support/dist-docs/ovs-vswitchd.conf.db.5.html),
>
> “*select_all*: boolean
>
>   If true, every packet arriving  or  departing  on  any  port  is
>
>   selected for mirroring.
>
> ”
>
>
>
> And for OVS 2.5,
>
>
>
> “In Open
>
>vSwitch 2.5 and later, mirroring  occurs  just  after  a  packet  first
>
>becomes  eligible, using the packet as it exists at that point; …
>
>
>
> in  Open  vSwitch  2.4, the modifications are never visible to
>
>mirrors, whereas in Open  vSwitch  2.5  and  later  modifications
> made
>
>before  the first output that makes it eligible for mirroring to a
> par‐
>
>ticular destination are visible.
>
> ”
>
> I believe, if the very first flow is dropping unicast packets, you might
> not be able to mirror them.
>
>
>
> Maybe you can monitor the flow-tables on each OVS bridge while sending
> traffic and see which flows’ count increases. Something like,
>
> watch –n 2 “ovs-ofctl dump-flows ”
>
>
>
> -Kaustubh
>
>
>
> *From:* Sterdnot Shaken [mailto:sterdnotsha...@gmail.com]
> *Sent:* Wednesday, March 22, 2017 12:24 PM
> *To:* Kaustubh Kelkar <kaustubh.kel...@casa-systems.com>
> *Subject:* Re: [Openstack] VM can receive traffic, but not send it
>
>
>
> Here's was my first mirror setup:
>
> ip link add name dummy3 type dummy
> ip link set dev dummy3 up
>
>
>
> ovs-vsctl add-port br-ex3 dummy3
>
> ovs-vsctl -- set bridge br-ex3 mirrors=@m \
> -- --id=@src get port pat-ex3-bss \
> -- --id=@mir get port dummy3 \
> -- --id=@m create mirror name=ovs_mirror3 select-dst-port=@src
> select-src-port=@src output-port=@mir select-all=true
>
>
>
> And here's the one I did by copying your example:
>
> ip link add name dummy3 type dummy
> ip link set dev dummy3 up
>
>
>
> ovs-vsctl add-port br-ex3 dummy3
>
> ovs-vsctl -- set Bridge br-ex3 mirrors=@m  \
> -- --id=@dummy3 get Port dummy3 \
> -- --id=@pat-ex3-bss get Port pat-ex3-bss \
> -- --id=@m create Mirror name=mirror0 \
> select-dst-port=@pat-ex3-bss select-src-port=@pat-ex3-bss \
> output-port=@dummy3 select_all=1
>
>
>
> Both yield the same results. When I tcpdump the respective dummy interface
> attached to br-ex3, I only see broadcast traffic for the VM in question, I
> never see unicast traffic (case and point, if I ping the broadcast address
> on the VM, then traffic show's up in the tcpdump). I can do a tcpdump on
> the external interface and see the unicast traffic though, but I need to
> see where it's breaking in the OVS bridges.
>
> Is there some trick to mirror unicast dataplane traffic?
>
> Thanks in advance!
>
>
>
>
>
>
>
> On Wed, Mar 22, 2017 at 10:07 AM, Kaustubh Kelkar <
> kaustubh.kel...@casa-systems.com> wrote:
>
>
>
> *From:* Sterdnot Shaken [mailto:sterdnotsha...@gmail.com]
> *Sent:* Tuesday, March 21, 2017 8:54 PM
> *To:* Kaustubh Kelkar <kaustubh.kel...@casa-systems.com>
> *Cc:* Richard Jones <rjo...@suse.com>; openstack@lists.openstack.org
> *Subject:* Re: [Openstack] VM can receive traffic, but not send it
>
>
>
> Thanks for everyone's kind help!
>
> Steve: I will try and turn off the offload features and see if that helps.
> Thanks!
>
> Neil: I will also check and make sure neither RPF nor TTL are posing any
> issues.
>
>
> Kaustubh: Is there a reason the mirror approach only seems to work on some
> of the OVS bridges, but not others? if I follow your instructions, I can
> see traffic when I set up a mirror on some bridges, but not others... Do I
> need to put these OVS bridges into promiscuous mode before the mirror will
> work?
>
> [Kaustubh] I don’t recall putting the bridge in promiscuous mode, but it
> has been a while since I had looked at this. How are you setting up the
> mirrors? You would need to mirror a spe

Re: [Openstack-operators] Flavors

[Adam Lawson]

One way I know some providers work around this when using OpenStack is by
fronting the VM request with some code in the web server that checks if the
requested spec has an existing flavor. if so, use the flavor, if not, use
an admin account that creates a new flavor and assign use it for that user
request then remove if when the build is complete. This naturally impacts
your control over hardware efficiency but it makes your scenario possible
(for better or for worse). I also hate being forced to do what someone else
decided was going to be best for me. That's my decision and thanksully with
openStack, this kind of thing is rather easy to do.

//adam


*Adam Lawson*

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

On Thu, Mar 16, 2017 at 7:52 AM, Jonathan D. Proulx <j...@csail.mit.edu>
wrote:

>
> I have always hated flavors and so do many of my users.
>
> On Wed, Mar 15, 2017 at 03:22:48PM -0700, James Downs wrote:
> :On Wed, Mar 15, 2017 at 10:10:00PM +, Fox, Kevin M wrote:
> :> I think the really short answer is something like: It greatly
> simplifies scheduling and billing.
> :
> :The real answer is that once you buy hardware, it's in a fixed radio of
> CPU/Ram/Disk/IOPS, etc.
>
> This while apparently reasonable is BS (at least in private cloud
> space).  What users request and what they actualy use are wildly
> divergent.
>
> *IF* usage of claimed resorces were at or near optimal then this might
> be true .  But if people are claiming 32G of ram because that how much
> you assigned to a 16 vCPU instance type but really just need 16
> threads with 2G or 4G then you packing still sucks.
>
> I'm mostly bound on memory so I mostly have my users select on that
> basis and over provide and over provision CPU since that can be
> effectively shared between VMs where memory needs to be dedicated
> (well mostly)
>
> I'm sure I've ranted abotu this before but as you see from other
> responses we seem to be in the minority position so mostly I rant at
> the walls while my office mates look on perplexed (actually they're
> pretty used to it by now and ignore me :) )
>
> -Jon
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Neutron][Contrail] packet flow

[Adam Lawson]

Question:

Is it by design that all packets originating from behind the vRouters must
pass through the control plane? I recently spoke to a rather large Contrail
consumer who are dealing with performance issues because the control plane
is getting overloaded and unable to scale to accommodate the amount of VM
traffic flowing through it.

That seems completely wacky to me as I expect the control plane to handle
administrative tasks only - not production traffic.

Did something fundamentally change of which I'm unaware?

//adam

*Adam Lawson*

Principal Architect, CEO
Office: +1-916-794-5706
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Neutron] Prefer local Neutron nodes?

[Adam Lawson]

Hey everyone,

If we want to implement multiple dedicated neutron routers in multiple
racks (same cloud), is there a means of which I'm unaware that forces
instances to route cross-tenant and public traffic to a neutron node within
the local rack as opposed to load balancing L3 across all neutron nodes in
all racks?

*Example:*
6 racks,3 dedicated Neutron nodes per rack

//adam

*Adam Lawson*

Principal Architect, CEO
Office: +1-916-794-5706
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack] Openstack+KVM+overcommit, VM priority

[Adam Lawson]

With 4 physical cpu cores, you'll have 8 with HT so you likely don't need
anything managing overcommitting. But you also have memory contention in
your design. OpenStack facilitates resource limits to prevent the
contention from happening but does not get into managing vm priorities. The
assumption I presume is that high priority instances will be placed on high
priority hosts where overcommit ratios are safe for the VM's hosted on that
machine.

I know guys don't like to hear this when things are running but you need to
reassess what you're doing and rethink the 'why' factor to understand if
that level of manual management is really necessary. Remember this is a
cloud but your setup is basically complicated pet management. Add another
compute host and put your low priority instances on it rather than trying
to manage two SLA's yourself. Let OpenStack do it for you. ; )

//adam

All the best.

//adam

On Jan 12, 2017 9:17 AM, "Kostyantyn Volenbovskyi" 
wrote:

Hi,

I have provided the answer to that on https://ask.openstack.org/en/
question/101374 where you asked this question as well.
That elaborates slightly on 'There are facilities to allow one VM or
another to have CPU priority’ which James mentioned below.
For RAM such things as Memory Tuning https://libvirt.org/formatdomain.html#
elementsMemoryTuning is not supported
as well as memory ballooning (which might be part of answer I think) are
not supported in Nova.
And well, ‘don’t overcommit RAM’ is often a good principle to stick to.


BR,
Konstantin
> On Jan 12, 2017, at 1:33 PM, Ivan Derbenev 
wrote:
>
> What are the facilities for cpu? That's the initial question - how can I
do it if this is possible
>
>
> Best Regards
> Tech-corps IT Engineer
> Ivan Derbenev
> Phone: +79633431774
>
> -Original Message-
> From: James Downs [mailto:e...@egon.cc]
> Sent: Thursday, January 12, 2017 12:56 AM
> To: Ivan Derbenev 
> Cc: openstack@lists.openstack.org
> Subject: Re: [Openstack] Openstack+KVM+overcommit, VM priority
>
> On Wed, Jan 11, 2017 at 09:34:32PM +, Ivan Derbenev wrote:
>
>> if both vms start using all 64gb memory, both of them start using swap
>
> Don't overcommit RAM.
>
>> So, the question is - is it possible to prioritize 1st vm above 2nd? so
the second one will fail before the 1st, to leave maximum possible
perfomance to the most importan one?
>
> Do you mean CPU prioritization? There are facilities to allow one VM or
another to have CPU priority, but what, if a high priority VM wants RAM,
you want to OOM the other? That doesn't exist, AFAIK.
>
> Cheers,
> -j
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
openstack


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Openstack+KVM+overcommit, VM priority

[Adam Lawson]

This is a scheduler thing. Kvm/Linux has it's own scheduler built in for
any process that needs to share CPU cycles aside from the filter scheduler
used by OpenStack. My understanding is that any optimizations assigned to
resource consumption will not be handled by OpenStack but with manual
tweaks.

And I may be wrong about it not handled within nova. Also I know you're
doing it now but that is way against best practice my friend
(over-committing RAM).

//adam

On Jan 12, 2017 4:46 AM, "Ivan Derbenev" 
wrote:

> What are the facilities for cpu? That's the initial question - how can I
> do it if this is possible
>
>
> Best Regards
> Tech-corps IT Engineer
> Ivan Derbenev
> Phone: +79633431774
>
> -Original Message-
> From: James Downs [mailto:e...@egon.cc]
> Sent: Thursday, January 12, 2017 12:56 AM
> To: Ivan Derbenev 
> Cc: openstack@lists.openstack.org
> Subject: Re: [Openstack] Openstack+KVM+overcommit, VM priority
>
> On Wed, Jan 11, 2017 at 09:34:32PM +, Ivan Derbenev wrote:
>
> > if both vms start using all 64gb memory, both of them start using swap
>
> Don't overcommit RAM.
>
> > So, the question is - is it possible to prioritize 1st vm above 2nd? so
> the second one will fail before the 1st, to leave maximum possible
> perfomance to the most importan one?
>
> Do you mean CPU prioritization? There are facilities to allow one VM or
> another to have CPU priority, but what, if a high priority VM wants RAM,
> you want to OOM the other? That doesn't exist, AFAIK.
>
> Cheers,
> -j
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] [Glance] [Nova] Multiple backends / Qcow Derived Images

[Adam Lawson]

Just a friendly bump. To clarify, the ideas being tossed around are to host
QCOW images on each Compute node so the provisioning is faster (i.e. less
dependency on network connectivity to a shared back-end). I need to know if
this is possible or not. So far, I've seen nothing that suggests that it is
but i want to confirm that.

Also, derived images is a QCOW thing[1], I'm wondering if creating these
dynamically is supported by Nova and/or Glance.

[1]
http://nairobi-embedded.org/manipulating_disk_images_with_qemu-img.html#creating-derived-images

//adam


*Adam Lawson*

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

On Tue, Jan 3, 2017 at 5:01 PM, Adam Lawson <alaw...@aqorn.com> wrote:

> Greetings fellow Stackers!
>
> Question re GlanceNova: Does Glance and/or Nova support attaching volumes
> built with derived images (created from a master registered with Glance
> (ref qcow))?
>
> Glance-only question: Can Glance be configured to place images on separate
> hosts (i.e. imageX on ComputeX and imageY on ComputeY)?
>
> //adam
>
>
> *Adam Lawson*
>
> Principal Architect, CEO
> Office: +1-916-794-5706 <(916)%20794-5706>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Glance] [Nova] Multiple backends / Qcow Derived Images

[Adam Lawson]

Greetings fellow Stackers!

Question re GlanceNova: Does Glance and/or Nova support attaching volumes
built with derived images (created from a master registered with Glance
(ref qcow))?

Glance-only question: Can Glance be configured to place images on separate
hosts (i.e. imageX on ComputeX and imageY on ComputeY)?

//adam


*Adam Lawson*

Principal Architect, CEO
Office: +1-916-794-5706
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Neutron][LBaaS] Architecture/Wiring for LBaaS service extension

[Adam Lawson]

Greetings fellow stackers.

So I found the list of service extensions [1,] the modular architecture [2]
and info re the driver API [3]. The architecture diagram [4] doesn't show
up in link3 and furthermore shows it was last updated in 2014 which tells
me it has probably changed since then.

Where is the best/most recent info for Neutron's LBaaS service extension?

[1]
http://docs.openstack.org/developer/neutron/devref/service_extensions.html
[2] https://wiki.openstack.org/wiki/Neutron/LBaaS/Architecture
[3] https://wiki.openstack.org/wiki/Neutron/LBaaS/DriverAPI
[4] https://wiki.openstack.org/wiki/File:Lbaas_arch.JPG

//adam

*Adam Lawson*

Principal Architect, CEO
Office: +1-916-794-5706
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[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

[Openstack-operators] [ansible] Best practice for single interface cconfig

[Adam Lawson]

It's been a while since I deployed OpenStack from scratch so I'm using the
Ansible install guide [1] and ran into a problem:

How should the hosts be configured for hosts that have one NIC? The test
environment layout with one interface [2] is what I'm following but the
/etc/network/interface content [3] does not follow the test environment
layout (presumes the presence of four interfaces).

How would the network be configured with hosts with only 1 NIC to ensure
Ansible runs properly?

[1]
http://docs.openstack.org/developer/openstack-ansible/install-guide/index.html
[2]
http://docs.openstack.org/developer/openstack-ansible/install-guide/overview-host-layout.html#test-environment
[3]
http://docs.openstack.org/developer/openstack-ansible/install-guide/app-targethosts-networkexample.html#test-environment

//adam

*Adam Lawson*

Principal Architect, CEO
Office: +1-916-794-5706
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[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

[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

[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

[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

[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-operators] Nova

[Adam Lawson]

Hi Jonathan,

What is being reported is that a guest was running Ubuntu v12 with kernel
3.9.x-generic on a host that was running Ubuntu v14 with kernel
3.13.x-generic and the engineer had problems with reliably
mounting/unmounting volumes and that problem was corrected by upgrading the
gusts to kernel 3.13.x-generic.

Have you run into this or has anyone else run into this before?

I'm CC'ing a colleague who can offer additional insight.

//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, Sep 6, 2016 at 4:22 AM, Jonathan D. Proulx <j...@csail.mit.edu>
wrote:

> On Fri, Sep 02, 2016 at 04:00:17PM -0700, Adam Lawson wrote:
> :Mike that's just as I suspected. To be super clear, does KVM in particular
> :know how to distinguish between Ubuntu v12 versus v16? In other words, do
> I
> :need to be running a specific version of KVM hypervisor so it can host
> :guests running the latest version of Ubuntu?
>
> You'll be fine.  Paravirtualized Xen could run you into trouble but
> KVM doesn't support paravirtualized cpu, just full virtualization so
> it's completely agnostic about what you run on top.
>
> I'm definitely running 16 and 12 ontop of 14, but also much weirder
> things like Gnu-Herd, FreeBSD and  Windows...
>
> -Jon
>
> :
> :Again, this was brought up as being a firm requirement but I've never ever
> :heard of such a requirement unless we're debating KVM versus ESXi so I
> :wanted to get my facts straight before I confirmed to the team one way or
> :another.
> :
> ://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, Sep 2, 2016 at 1:53 PM, Mike Smith <mism...@overstock.com> wrote:
> :
> :> Hi Adam -
> :>
> :> The OS of the guest is independent of the Openstack version.  Your
> choice
> :> of hypervisor (KVM, VMWare, HyperV, etc) would just need to support the
> OS
> :> version that you want to run on your guests.
> :>
> :> Mike Smith
> :> Lead Cloud Systems Architect
> :> Overstock.com <http://overstock.com>
> :>
> :>
> :>
> :> On Sep 2, 2016, at 2:46 PM, Adam Lawson <alaw...@aqorn.com> wrote:
> :>
> :> Hey everyone, do specific versions of OpenStack necessitate specific
> :> versions of guest os's? I.e. if I'm running a mitaka cloud platform, do
> the
> :> guest vm operating systems need to be a specific version of Linux? My
> :> understanding is the two are totally unrelated when the VM's are running
> :> Linux but I wanted to check if things have recently changed without my
> :> knowledge.
> :>
> :> //adam
> :> ___
> :> OpenStack-operators mailing list
> :> OpenStack-operators@lists.openstack.org
> :> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> :>
> :>
> :>
> :> --
> :>
> :> CONFIDENTIALITY NOTICE: This message is intended only for the use and
> :> review of the individual or entity to which it is addressed and may
> contain
> :> information that is privileged and confidential. If the reader of this
> :> message is not the intended recipient, or the employee or agent
> responsible
> :> for delivering the message solely to the intended recipient, you are
> hereby
> :> notified that any dissemination, distribution or copying of this
> :> communication is strictly prohibited. If you have received this
> :> communication in error, please notify sender immediately by telephone or
> :> return email. Thank you.
> :>
>
> :___
> :OpenStack-operators mailing list
> :OpenStack-operators@lists.openstack.org
> :http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> --
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] OpenStack Consult Opp (Network/Horizon/VNC)

[Adam Lawson]

I'm not looking for sales reps to contact me to sell me professional
services. Aptira did that already, not what I'm looking for.

I'm trying to find the right way to contact OpenStack guys ego want to know
about immediate short-term OpenStack-related problems & projects on the
side.

//adam

On Sep 3, 2016 9:25 PM, "John van Ommen" <john.vanom...@gmail.com> wrote:

> Hewlett Packard Enterprise has a professional services team dedicated to
> fulfilling projects like this. We've been doing this for years now, with
> numerous clients, all over the world.
>
> I can connect you with a sales rep if you'd like. (I'm on the integration
> side, not sales)
>
> John
>
> On Sep 3, 2016 7:40 PM, "Adam Lawson" <alaw...@aqorn.com> wrote:
>
>> Is anyone *against* creating a mailing-list this sort of dialog? It's
>> for short-term immediate need/troubleshooting/my hair is on fire soert s of
>> requests.
>>
>> Also, if i wanted to push this forward, what the next step since I'm not
>> seeing anyone volunteering other than JJ who tried and that's the last I
>> heard of it.
>>
>> //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, Feb 8, 2016 at 5:20 PM, Robert Starmer <rob...@kumul.us> wrote:
>>
>>> I thought this got stuck in the "do we need another list" and "well,
>>> what is our alternative" discussion.  So, no I don't recall any progress.
>>> I still think it'd be useful to have a list. for this class of discussion.
>>>
>>> Robert
>>>
>>> On Wed, Feb 3, 2016 at 6:01 PM, Adam Lawson <alaw...@aqorn.com> wrote:
>>>
>>>> Hey all,
>>>>
>>>> Just curious how this was progressing. Is there an approval waiting to
>>>> happen or something in the background?
>>>>
>>>> //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, Nov 24, 2015 at 1:55 PM, JJ Asghar <j...@chef.io> wrote:
>>>>
>>>>> -BEGIN PGP SIGNED MESSAGE-
>>>>> Hash: SHA512
>>>>>
>>>>> On 11/24/15 3:13 PM, Adam Lawson wrote:
>>>>> > Yep. I knew I was walking a gray line. If I had time to let folks
>>>>> > know about an opportunity and wait for folks to visit and reply I
>>>>> > totally would. Otherwise, I would definitely echo a job-related
>>>>> > mailing list if that could be setup?
>>>>> >
>>>>> >
>>>>> > On Tue, Nov 24, 2015 at 12:51 PM, JJ Asghar <j...@chef.io
>>>>> > <mailto:j...@chef.io>> wrote:
>>>>> >
>>>>> >
>>>>> > As another place, other than the job posting site I just created
>>>>> > this review[1].
>>>>> >
>>>>> > If you like this idea please +1 it.
>>>>> >
>>>>> >
>>>>> > [1]: https://review.openstack.org/249415
>>>>>
>>>>>
>>>>> Yep, that's that review above. Go ahead and +1 it also, and we'll see
>>>>> if we can the list put together. :D
>>>>>
>>>>>
>>>>> - --
>>>>> Best Regards,
>>>>> JJ Asghar
>>>>> c: 512.619.0722 t: @jjasghar irc: j^2
>>>>> -BEGIN PGP SIGNATURE-
>>>>> Version: GnuPG/MacGPG2 v2
>>>>> Comment: GPGTools - https://gpgtools.org
>>>>>
>>>>> iQIcBAEBCgAGBQJWVNy8AAoJEDZbxzMH0+jTpEAP/3qnKoVP/iVKlFmZG7CrhLxC
>>>>> TveL3xNyTBGt+cMVQAJGChSH8v0l1+XuUKeIkRBsPCppe7PnPfIqPuCFJKuvCU+v
>>>>> gFDUvJbpqSXL+D7vfvc/83GUPa9rgvV//ovicbrvvJIsvl5LMuLpUgBVhZRDWzu2
>>>>> Q+VjdRFkHVCAHepQxBiyRav6Cwa5Sng3ODHrjlhKc4Kr2me25B+NDCqPbQz4/h6a
>>>>> T/nnHFrvZ0PQcYmNBONRe2WX7IqwJx/igV3+HuHXUtrtpKPRX7V12k5WdEGqbVDn
>>>>> LBEwJDYJWFXa8uo/WsbiaQfsO4iP8TZwP8aU/kcEB685HnRVr6Naw19VZwEvp8ZZ
>>>>> 5+WoT861u1VwWe244MvWgWLkWPVYsZIzCJAfcNmqVTQByc2VnozTUDoYWirjCPfS
>>>>> ka5Fj/t2jEh5fr6cR8x/h4yaq3DO345yVL2U9oj0NhczEpNYpFCdg66Huh8sMgca
>>>>> BwZmzd50UGTxq1tp5etT+XBeAqxhwd0iqgNZLXsTLQgJZ58giqgTymtgOGoROz1c
>>>>> PbvUoUgSgLTzr9PnyEAV09gZvyYr+8goR6RtfbDTWyykSqDrByr8qqef4DnxkyoM
>>>>> Y4lzp+vGkMK3RxJcVgM7fUmbIJTo42fpuwDFC39FmoSICJVqzYuNKcM6NlUmzXHE
>>>>> GbKDfBTzXrWTkgo1+0uW
>>>>> =T6en
>>>>> -END PGP SIGNATURE-
>>>>>
>>>>
>>>>
>>>> ___
>>>> OpenStack-operators mailing list
>>>> OpenStack-operators@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>
>>>>
>>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] OpenStack Consult Opp (Network/Horizon/VNC)

[Adam Lawson]

i ask because I have another opportunity but I don't know where to
evangelize it if not among those who might be interested.

//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 3, 2016 at 7:34 PM, Adam Lawson <alaw...@aqorn.com> wrote:

> Is anyone *against* creating a mailing-list this sort of dialog? It's for
> short-term immediate need/troubleshooting/my hair is on fire soert s of
> requests.
>
> Also, if i wanted to push this forward, what the next step since I'm not
> seeing anyone volunteering other than JJ who tried and that's the last I
> heard of it.
>
> //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, Feb 8, 2016 at 5:20 PM, Robert Starmer <rob...@kumul.us> wrote:
>
>> I thought this got stuck in the "do we need another list" and "well, what
>> is our alternative" discussion.  So, no I don't recall any progress.  I
>> still think it'd be useful to have a list. for this class of discussion.
>>
>> Robert
>>
>> On Wed, Feb 3, 2016 at 6:01 PM, Adam Lawson <alaw...@aqorn.com> wrote:
>>
>>> Hey all,
>>>
>>> Just curious how this was progressing. Is there an approval waiting to
>>> happen or something in the background?
>>>
>>> //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, Nov 24, 2015 at 1:55 PM, JJ Asghar <j...@chef.io> wrote:
>>>
>>>> -BEGIN PGP SIGNED MESSAGE-
>>>> Hash: SHA512
>>>>
>>>> On 11/24/15 3:13 PM, Adam Lawson wrote:
>>>> > Yep. I knew I was walking a gray line. If I had time to let folks
>>>> > know about an opportunity and wait for folks to visit and reply I
>>>> > totally would. Otherwise, I would definitely echo a job-related
>>>> > mailing list if that could be setup?
>>>> >
>>>> >
>>>> > On Tue, Nov 24, 2015 at 12:51 PM, JJ Asghar <j...@chef.io
>>>> > <mailto:j...@chef.io>> wrote:
>>>> >
>>>> >
>>>> > As another place, other than the job posting site I just created
>>>> > this review[1].
>>>> >
>>>> > If you like this idea please +1 it.
>>>> >
>>>> >
>>>> > [1]: https://review.openstack.org/249415
>>>>
>>>>
>>>> Yep, that's that review above. Go ahead and +1 it also, and we'll see
>>>> if we can the list put together. :D
>>>>
>>>>
>>>> - --
>>>> Best Regards,
>>>> JJ Asghar
>>>> c: 512.619.0722 t: @jjasghar irc: j^2
>>>> -BEGIN PGP SIGNATURE-
>>>> Version: GnuPG/MacGPG2 v2
>>>> Comment: GPGTools - https://gpgtools.org
>>>>
>>>> iQIcBAEBCgAGBQJWVNy8AAoJEDZbxzMH0+jTpEAP/3qnKoVP/iVKlFmZG7CrhLxC
>>>> TveL3xNyTBGt+cMVQAJGChSH8v0l1+XuUKeIkRBsPCppe7PnPfIqPuCFJKuvCU+v
>>>> gFDUvJbpqSXL+D7vfvc/83GUPa9rgvV//ovicbrvvJIsvl5LMuLpUgBVhZRDWzu2
>>>> Q+VjdRFkHVCAHepQxBiyRav6Cwa5Sng3ODHrjlhKc4Kr2me25B+NDCqPbQz4/h6a
>>>> T/nnHFrvZ0PQcYmNBONRe2WX7IqwJx/igV3+HuHXUtrtpKPRX7V12k5WdEGqbVDn
>>>> LBEwJDYJWFXa8uo/WsbiaQfsO4iP8TZwP8aU/kcEB685HnRVr6Naw19VZwEvp8ZZ
>>>> 5+WoT861u1VwWe244MvWgWLkWPVYsZIzCJAfcNmqVTQByc2VnozTUDoYWirjCPfS
>>>> ka5Fj/t2jEh5fr6cR8x/h4yaq3DO345yVL2U9oj0NhczEpNYpFCdg66Huh8sMgca
>>>> BwZmzd50UGTxq1tp5etT+XBeAqxhwd0iqgNZLXsTLQgJZ58giqgTymtgOGoROz1c
>>>> PbvUoUgSgLTzr9PnyEAV09gZvyYr+8goR6RtfbDTWyykSqDrByr8qqef4DnxkyoM
>>>> Y4lzp+vGkMK3RxJcVgM7fUmbIJTo42fpuwDFC39FmoSICJVqzYuNKcM6NlUmzXHE
>>>> GbKDfBTzXrWTkgo1+0uW
>>>> =T6en
>>>> -END PGP SIGNATURE-
>>>>
>>>
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] OpenStack Consult Opp (Network/Horizon/VNC)

[Adam Lawson]

Is anyone *against* creating a mailing-list this sort of dialog? It's for
short-term immediate need/troubleshooting/my hair is on fire soert s of
requests.

Also, if i wanted to push this forward, what the next step since I'm not
seeing anyone volunteering other than JJ who tried and that's the last I
heard of it.

//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, Feb 8, 2016 at 5:20 PM, Robert Starmer <rob...@kumul.us> wrote:

> I thought this got stuck in the "do we need another list" and "well, what
> is our alternative" discussion.  So, no I don't recall any progress.  I
> still think it'd be useful to have a list. for this class of discussion.
>
> Robert
>
> On Wed, Feb 3, 2016 at 6:01 PM, Adam Lawson <alaw...@aqorn.com> wrote:
>
>> Hey all,
>>
>> Just curious how this was progressing. Is there an approval waiting to
>> happen or something in the background?
>>
>> //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, Nov 24, 2015 at 1:55 PM, JJ Asghar <j...@chef.io> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>>
>>> On 11/24/15 3:13 PM, Adam Lawson wrote:
>>> > Yep. I knew I was walking a gray line. If I had time to let folks
>>> > know about an opportunity and wait for folks to visit and reply I
>>> > totally would. Otherwise, I would definitely echo a job-related
>>> > mailing list if that could be setup?
>>> >
>>> >
>>> > On Tue, Nov 24, 2015 at 12:51 PM, JJ Asghar <j...@chef.io
>>> > <mailto:j...@chef.io>> wrote:
>>> >
>>> >
>>> > As another place, other than the job posting site I just created
>>> > this review[1].
>>> >
>>> > If you like this idea please +1 it.
>>> >
>>> >
>>> > [1]: https://review.openstack.org/249415
>>>
>>>
>>> Yep, that's that review above. Go ahead and +1 it also, and we'll see
>>> if we can the list put together. :D
>>>
>>>
>>> - --
>>> Best Regards,
>>> JJ Asghar
>>> c: 512.619.0722 t: @jjasghar irc: j^2
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG/MacGPG2 v2
>>> Comment: GPGTools - https://gpgtools.org
>>>
>>> iQIcBAEBCgAGBQJWVNy8AAoJEDZbxzMH0+jTpEAP/3qnKoVP/iVKlFmZG7CrhLxC
>>> TveL3xNyTBGt+cMVQAJGChSH8v0l1+XuUKeIkRBsPCppe7PnPfIqPuCFJKuvCU+v
>>> gFDUvJbpqSXL+D7vfvc/83GUPa9rgvV//ovicbrvvJIsvl5LMuLpUgBVhZRDWzu2
>>> Q+VjdRFkHVCAHepQxBiyRav6Cwa5Sng3ODHrjlhKc4Kr2me25B+NDCqPbQz4/h6a
>>> T/nnHFrvZ0PQcYmNBONRe2WX7IqwJx/igV3+HuHXUtrtpKPRX7V12k5WdEGqbVDn
>>> LBEwJDYJWFXa8uo/WsbiaQfsO4iP8TZwP8aU/kcEB685HnRVr6Naw19VZwEvp8ZZ
>>> 5+WoT861u1VwWe244MvWgWLkWPVYsZIzCJAfcNmqVTQByc2VnozTUDoYWirjCPfS
>>> ka5Fj/t2jEh5fr6cR8x/h4yaq3DO345yVL2U9oj0NhczEpNYpFCdg66Huh8sMgca
>>> BwZmzd50UGTxq1tp5etT+XBeAqxhwd0iqgNZLXsTLQgJZ58giqgTymtgOGoROz1c
>>> PbvUoUgSgLTzr9PnyEAV09gZvyYr+8goR6RtfbDTWyykSqDrByr8qqef4DnxkyoM
>>> Y4lzp+vGkMK3RxJcVgM7fUmbIJTo42fpuwDFC39FmoSICJVqzYuNKcM6NlUmzXHE
>>> GbKDfBTzXrWTkgo1+0uW
>>> =T6en
>>> -END PGP SIGNATURE-
>>>
>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Nova

[Adam Lawson]

Mike that's just as I suspected. To be super clear, does KVM in particular
know how to distinguish between Ubuntu v12 versus v16? In other words, do I
need to be running a specific version of KVM hypervisor so it can host
guests running the latest version of Ubuntu?

Again, this was brought up as being a firm requirement but I've never ever
heard of such a requirement unless we're debating KVM versus ESXi so I
wanted to get my facts straight before I confirmed to the team one way or
another.

//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, Sep 2, 2016 at 1:53 PM, Mike Smith <mism...@overstock.com> wrote:

> Hi Adam -
>
> The OS of the guest is independent of the Openstack version.  Your choice
> of hypervisor (KVM, VMWare, HyperV, etc) would just need to support the OS
> version that you want to run on your guests.
>
> Mike Smith
> Lead Cloud Systems Architect
> Overstock.com <http://overstock.com>
>
>
>
> On Sep 2, 2016, at 2:46 PM, Adam Lawson <alaw...@aqorn.com> wrote:
>
> Hey everyone, do specific versions of OpenStack necessitate specific
> versions of guest os's? I.e. if I'm running a mitaka cloud platform, do the
> guest vm operating systems need to be a specific version of Linux? My
> understanding is the two are totally unrelated when the VM's are running
> Linux but I wanted to check if things have recently changed without my
> knowledge.
>
> //adam
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> --
>
> CONFIDENTIALITY NOTICE: This message is intended only for the use and
> review of the individual or entity to which it is addressed and may contain
> information that is privileged and confidential. If the reader of this
> message is not the intended recipient, or the employee or agent responsible
> for delivering the message solely to the intended recipient, you are hereby
> notified that any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please notify sender immediately by telephone or
> return email. Thank you.
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Nova

[Adam Lawson]

Hey everyone, do specific versions of OpenStack necessitate specific
versions of guest os's? I.e. if I'm running a mitaka cloud platform, do the
guest vm operating systems need to be a specific version of Linux? My
understanding is the two are totally unrelated when the VM's are running
Linux but I wanted to check if things have recently changed without my
knowledge.

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

Re: [openstack-dev] Upstream - Barcelona

[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

[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

[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

[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

[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-operators] VPNaaS and FWaaS

[Adam Lawson]

We don't use FWaaS but we certainly are interested in LBaaS and VPNaaS.
Chalk us up to a vendor trying to implement these. VPNaaS is huge as it
allows customers to non-disruptively attach their organizations to a public
cloud with the same IP space as is the case with AWS. I'd be open to
letting this go IF it being addressed elsewhere in some other manner.

//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, May 19, 2016 at 6:52 PM, Joseph Bajin <josephba...@gmail.com> wrote:

> We have actually started to look at VPNaaS as a way to tie two different
> region's Tenant Networks together..  This will hopefully allow us to not
> have to look at users using too many Floating IPs to just support tools and
> products that have issues with Floating IPs.
>
> On Tue, May 10, 2016 at 4:18 AM, Matt Jarvis <
> matt.jar...@datacentred.co.uk> wrote:
>
>> We see FWaaS generally being used by customers with larger deployments,
>> where they want overall firewall rules at the boundary as well as security
>> groups. Since my original post on this thread, I went to look at the
>> numbers - it's actually being used more widely than I originally thought on
>> our platform, including many of our largest customers.
>>
>> On 10 May 2016 at 09:03, Mariano Cunietti <mcunie...@enter.it> wrote:
>>
>>> Hi Kyle,
>>>
>>> > I know there are operators relying on these functions, particularly in
>>> the
>>> > public cloud space in Europe, so this would impact those people. I
>>> also know
>>> > this list doesn't necessarily reach all of them either, so I will try
>>> and
>>> > reach out by other means as well, but it would be very useful to try
>>> and get
>>> > a clearer picture of how many people are using VPNaaS and FWaaS. If
>>> you are,
>>> > could you please respond to this thread ?
>>>
>>>
>>> We are using VPNaaS and FWaaS on entercloudsuite.com, on Juno.
>>> With VPNaaS it basically works (or: works basically) but there are some
>>> issues with the configuration of MTU and some other server side
>>> configurations that drop some client connections. I can can provide more
>>> details if you want on a private thread.
>>> With FWaaS we are providing it but we also deprecate it; moreover, it’s
>>> generating a lot of confusion and overlap with Security Groups
>>>
>>>
>>> >
>>> I'm actually really surprised that people are *using* FWaaS. It's been
>>> marked experimental for over 3 years now, and it only recently in
>>> Liberty received work which made it somewhat useful, which was the
>>> ability to apply a firewall on a specific Neutron router rather than
>>> all tenant routers. FWaaS in production sounds pretty risky to me, but
>>> I supposed that our fault for not being clear on it's readiness.
>>>
>>>
>>> Agree, but the words EXPERIMENTAL and NOT PRODUCTION READY are pretty
>>> visible in the documentation.
>>> So, not your fault at all
>>>
>>>
>>> > If we have metrics that a constituent part of the user community need
>>> these
>>> > functions, then we can try and find a way to help the Neutron team to
>>> cover
>>> > the resourcing gaps.
>>> >
>>> If people are using these, IMHO that's another reason to keep them
>>> around. I've already said that we have at least one large user of VPN,
>>> so that project will continue to be worked on even if it's removed
>>> from Neutron.
>>>
>>>
>>> Here’s what WE’D LOVE to have:
>>>
>>>- VPNaaS
>>>- IDS or some TAPaaS to redirect router traffic to a tenant’s
>>>instance (remember we all sell instances)
>>>- IPS, that is the ability not only to eavesdrop but also to drop
>>>traffic using Snort or better Suricata + ELK (
>>>https://github.com/StamusNetworks/SELKS/blob/master/README.rst)
>>>- FWaaS meant as multiple firewall “flavors”. Lots of customers ask
>>>for PFSense or their own Linux/FreeBSD solution
>>>- Network analytics in general (with InfluxDB or Monasca)
>>>
>>> Thanks
>>>
>>> Mariano
>>>
>>>
>>>
>>
>> DataCentred Limited registered in England and Wales no. 05611763
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Cinder] Question about cinder API v2

[Adam Lawson]

When I request cinder pool capacity and usage via cinder's API v2, is my
client talking to the backend storage directly or cached information stored
in the DB?

//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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Neutron][Contrail] openvswitch between brother and VM's?

[Adam Lawson]

Hey all, Is it possible to put an OpenVSwitch between local VM's on a
compute host and its local vRouter so that VM's use the local vRouter and
if that fails or crashes, OpenVSwitch connects the VM's to a vRouter on
another compute host nearby? Trying to solve for potential vRouter
crashing...

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

[Openstack] [Neutron][mpls][bgp] l3vpn

[Adam Lawson]

Hey everyone!

Does Neutron support mpls/bgp presently? I'm looking for use cases/methods
where it's done outside Calico or Contrail.

Anyone have a link to a doc or steps where it's been done successfully?

//adam
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack-operators] 3 OpenStack Summit Full Passes Available

[Adam Lawson]

Hello fellow Operators,

My company has 3 full passes available to give away to an OpenStack
Operator who desires to attend the OpenStack Summit in Austin but has not
yet registered and affordability is a factor. Please email me directly and
I'll give you a promotional code so your summit pass will be free. Since
our community is one about giving back for the greater good, this is my way
of maintaining that spirit.

Simply, the first 3 individuals to reply to me offline gets one of the
codes and remember t*hese must be redeemed by or before April 15th* (And
yes we received advance approval to do whatever we wanted to do with the
passes we don't use with our summit sponsorship).

We also have 6 Expo/Keynote Only passes available as well if that is of
interest to anyone. 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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack] all projects status?

[Adam Lawson]

Thanks everyone!
On Apr 8, 2016 11:41 AM, "CHOW Anthony" <anthony.c...@al-enterprise.com>
wrote:

> This link is for the Mikata release and I find it useful:
>
>
>
> http://releases.openstack.org/mitaka/index.html
>
>
>
> *From:* Francisco Araya [mailto:franci...@sentinel.la]
> *Sent:* Wednesday, April 06, 2016 4:39 PM
> *To:* CHOW Anthony
> *Cc:* Adam Lawson; openstack
> *Subject:* Re: [Openstack] all projects status?
>
>
>
> The Project Navigator http://www.openstack.org/software/project-navigator/
> should address that, but it seems a little bit outdated =(
>
>
>
>
>
>
>
> On Wed, Apr 6, 2016 at 6:29 PM, CHOW Anthony <
> anthony.c...@al-enterprise.com> wrote:
>
> Adam,
>
>
>
> This one list the projects:
> http://governance.openstack.org/reference/projects/index.html
>
>
>
> Under the “Big Tent”, I think there is no more incubated and integrated
> status, all projects are tagged and I think existing tags can be found
> here: http://governance.openstack.org/reference/tags/
>
>
>
> I think there used to be a “integrated-release” to tag those existing
> projects for transition into “Big Tent” but I do not see this now (
> http://governance.openstack.org/reference/tags/integrated-release.html).
>
>
>
> Anthony.
>
>
>
> *From:* Adam Lawson [mailto:alaw...@aqorn.com]
> *Sent:* Wednesday, April 06, 2016 3:42 PM
> *To:* openstack
> *Subject:* [Openstack] all projects status?
>
>
>
> Of all of the projects unde the big tent on their respective flight paths,
> is there a central repo where their integration status is
> listed/maintained? I.e. incubated/integrated/core etc)? I can't find it but
> I know it exists...
>
>
>
> //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
>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
>
>
>
> --
>
> Francisco J Araya
>
> Co-founder & CEO | sentinel.la
>
> Enjoy a better OpenStack Experience
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

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

[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

[Openstack] all projects status?

[Adam Lawson]

Of all of the projects unde the big tent on their respective flight paths,
is there a central repo where their integration status is
listed/maintained? I.e. incubated/integrated/core etc)? I can't find it but
I know it exists...

//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
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] [neutron][ml2] Gutting ML2 from Neutron - possible?

[Adam Lawson]

Hi Dan - thanks I think that answers the core plugin question. What is
Contrail doing with the Neutron service plugin? Are there two plugins?

//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 2:13 PM, Dan Sneddon <dsned...@redhat.com> wrote:

> On 04/01/2016 02:07 PM, Dan Sneddon wrote:
> > On 04/01/2016 01:07 PM, Adam Lawson wrote:
> >> The Contrail team that said they are using their network product with
> >> OpenStack without requiring a mechanism driver with the ML2 plugin.
> >> More specifically, they said they don't use or need ML2. I didn't have
> >> a chance to ask them to clarify so I'm wondering how that works and
> >> what is current best practice? I think the individual misspoke but I
> >> wanted to see if this is actually being done today.
> >>
> >> Perhaps they replaced ML2 with something - exactly what though?
> >>
> >> //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-operators mailing list
> >> OpenStack-operators@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>
> >
> > ML2 is what's known as a "core driver" for Neutron. This means that the
> > main API implementation is done inside this driver. The ML2 driver is
> > modular, and can load sub-drivers (mechanism and type drivers) to
> > implement the specific actions such as creating virtual ethernet ports.
> >
> > Contrail replaces this driver with the NeutronPluginContrailCoreV2,
> > which implements the main API itself, without subdrivers. There is no
> > support planned for ML2 mechanism or type drivers within the Contrail
> > plugin. Contrail implements its own intelligent virtual ethernet ports,
> > each of which is routing-aware, and the routing is made redundant using
> > dynamic multipath routing. This replaces the Open vSwitch
> > bridge/patch/port mechanism.
> >
> > The current documentation [1] for Contrail/RDO covers Packstack. The
> > initial installation is done with ML2+OVS, then the Neutron
> > configuration is modified to load the Contrail driver instead.
> >
> > In OSP-Director 8, it is possible to load the Contrail driver during
> > installation instead of ML2. This is done by including the environment
> > file:
> >
> > openstack overcloud deploy --templates /path/to/templates \
> > -e /path/to/templates/environments/neutron-opencontrail.yaml \
> > [...]
> >
> > This environment file will set the following:
> >
> > ###
> > resource_registry:
> >   OS::TripleO::ControllerExtraConfigPre:
> > ../puppet/extraconfig/pre_deploy/controller/neutron-opencontrail.yaml
> >   OS::TripleO::ComputeExtraConfigPre:
> > ../puppet/extraconfig/pre_deploy/compute/neutron-opencontrail.yaml
> >
> > parameter_defaults:
> >   NeutronCorePlugin:
> >
> neutron_plugin_contrail.plugins.opencontrail.contrail_plugin.NeutronPluginContrailCoreV2
> >   NeutronServicePlugins:
> >
> neutron_plugin_contrail.plugins.opencontrail.loadbalancer.plugin.LoadBalancerPlugin
> >   NeutronEnableDHCPAgent: false
> >   NeutronEnableL3Agent: false
> >   NeutronEnableMetadataAgent: false
> >   NeutronEnableOVSAgent: false
> >   NeutronEnableTunnelling: false
> > 
> >
> > The files in the resource_registry section contain configuration
> > settings such as the IP address of the Contrail API server, and the
> > authentication credentials.
> >
> > In the parameter_defaults section, the NeutronCorePlugin is changed
> > from ML2 to the Contrail core plugin. The loadbalancer plugin is also
> > relegated to the Contrail load balancer plugin.
> >
> > [1] -
> http://www.opencontrail.org/rdo-openstack-opencontrail-integration/
> >
> > The same kind of approach applies to some other 3rd-party Neutron
> > plugin providers, although there are also some that use ML2 and do the
> > customization at the mechanism and type driver layer. Does that answer
> > your questions?
> >
>
> I probably sho

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

[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-operators] [Contrail][DevStack] contrail-installer error

[Adam Lawson]

The contrail-installer repo seems to be broken - complaining about missing
Cassandra directories. It appears this was a known issue [1] and was
planning a fix but it seems the fellow who planned to do the work
disappeared from the interweb (dsetia).

Do any of the Contrail folks watching this list know the work-around?

[1] https://github.com/Juniper/contrail-installer/issues/113

//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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [vmware][nova] "could not find capabilities for domaintype=kvm"

[Adam Lawson]

Hey all,

We're testing OpenStack Liberty on an ESX host and it installs fine. When
attempting to create a VM, receiving an error:

*libvirtError: invalid argument : could not find capabilities for
domaintype=kvm*

VMware environment is ESX 5.5:
*Capabilities*

nestedHVSupported = true

Intel VT-X = Supported


Is there any obvious ways to solve this or clarify whether this is a
physical or ESX configuration issue?

//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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Setting affinity based on instance type

[Adam Lawson]

Mathieu,

Blame it on my scattered brain but I'm now curious. How would this be
approached practically speaking? I.e. how would ram_weight_multiplier
enable the scenario I mentioned in my earliest post ?

//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, Mar 3, 2016 at 10:43 AM, Silence Dogood <m...@nycresistor.com>
wrote:

> cool!
>
> On Thu, Mar 3, 2016 at 1:39 PM, Mathieu Gagné <mga...@internap.com> wrote:
>
>> On 2016-03-03 12:50 PM, Silence Dogood wrote:
>> > We did some early affinity work and discovered some interesting problems
>> > with affinity and scheduling. =/  by default openstack used to ( may
>> > still ) deploy nodes across hosts evenly.
>> >
>> > Personally, I think this is a bad approach.  Most cloud providers stack
>> > across a couple racks at a time filling them then moving to the next.
>> > This allows older equipment to age out instances more easily for removal
>> > / replacement.
>> >
>> > The problem then is, if you have super large capacity instances they can
>> > never be deployed once you've got enough tiny instances deployed across
>> > the environment.  So now you are fighting with the scheduler to ensure
>> > you have deployment targets for specific instance types ( not very
>> > elastic / ephemeral ).  goes back to the wave scheduling model being
>> > superior.
>> >
>> > Anyways we had the braindead idea of locking whole physical nodes out
>> > from the scheduler for a super ( full node ) instance type.  And I
>> > suppose you could do this with AZs or regions if you really needed to.
>> > But, it's not a great approach.
>> >
>> > I would say that you almost need a wave style scheduler to do this sort
>> > of affinity work.
>> >
>>
>> You can already do it with the RAMWeigher using the
>> ram_weight_multiplier config:
>>
>>   Multiplier used for weighing ram.  Negative
>>   numbers mean to stack vs spread.
>>
>> Default is 1.0 which means spread.
>>
>> --
>> Mathieu
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[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-operators] Setting affinity based on instance type

[Adam Lawson]

Hi Kris,

When using aggregates as an example, anyone can assign
workloadA<>aggregateA and workloadB<>aggregateB. That's easy. But if we
have outstanding requests for workloadB and have a glut of capacity in
aggregateA, workloadB won't be able to use those hosts so we have spare
capacity and no way to utilize it.

So I want to set an affinity for workloads and not at the host level. That
way, hosts remain fungible, workload affinity policies are respected and
cloud capacity is properly utilizing capacity.

Does that make sense?

//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, Mar 2, 2016 at 3:08 PM, Kris G. Lindgren <klindg...@godaddy.com>
wrote:

> You can set attributes on flavors that must match the attributes on hosts
> or the host aggregates.  So you can basically always make sure a specific
> flavors goes to a specific compute node or type (like disks=ssd or
> class=gpu).  Look at nova flavor extra_specs documentation and the
> aggregate_Instance_extra_specs under the scheduler options.
>
>
> ___
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
> From: "Fox, Kevin M" <kevin@pnnl.gov>
> Date: Wednesday, March 2, 2016 at 3:58 PM
> To: Adam Lawson <alaw...@aqorn.com>, "
> openstack-operators@lists.openstack.org" <
> openstack-operators@lists.openstack.org>
> Subject: Re: [Openstack-operators] Setting affinity based on instance type
>
> you usually do that on an instance level with server groups. do you have
> an example where you might want to do it at the flavor level?
>
> Thanks,
> Kevin
> --
> *From:* Adam Lawson [alaw...@aqorn.com]
> *Sent:* Wednesday, March 02, 2016 2:48 PM
> *To:* openstack-operators@lists.openstack.org
> *Subject:* [Openstack-operators] Setting affinity based on instance type
>
> I'm sure this is possible but I'm trying to find the info I need in the
> docs so I figured I'd pitch this to you guys while I continue looking:
>
> Is it possible to set an affinity/anti-affinity policy to ensure instance
> Type A is weighted for/against co-location on the same physical host with
> instance Type B?
>
> Basically I have no requirement for server-group affinity but rather to
> ensure specific workloads are as separate as possible.
>
> Thoughts?
>
> //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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Workload Management (post-instantiation)

[Adam Lawson]

Okay that is pretty much aligned with what I was thinking - custom
monitor/trigger/action. An ask coming out of one of our design discussions
today was what products exist that do (or attempt to) address what is
normally handled by workload management toolkits such as VMware DRS.

//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, Mar 2, 2016 at 3:38 PM, Kris G. Lindgren <klindg...@godaddy.com>
wrote:

> We would love to have something like that as well.
>
> However, to do it in openstack would mean that something would have to
> gather/monitor the health of the HV's and not only disable new provisions
> but kick off/monitor the migrations off the host and onto the new chosen
> destinations .  Also, due to the fact that some migration may never
> complete (dirtying pages faster than you can copy them) it would have to
> have some smarts to select the vm's that have the higher chance of being
> migrated.
>
> ___
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
> From: Edgar Magana <edgar.mag...@workday.com>
> Date: Wednesday, March 2, 2016 at 4:31 PM
> To: Adam Lawson <alaw...@aqorn.com>, "
> openstack-operators@lists.openstack.org" <
> openstack-operators@lists.openstack.org>
> Subject: Re: [Openstack-operators] Workload Management
> (post-instantiation)
>
> We have done it with nagios checks and customize ruby code.
>
> Edgar
>
> From: Adam Lawson <alaw...@aqorn.com>
> Date: Wednesday, March 2, 2016 at 1:48 PM
> To: "openstack-operators@lists.openstack.org" <
> openstack-operators@lists.openstack.org>
> Subject: [Openstack-operators] Workload Management (post-instantiation)
>
> Hello fellow Ops-minded stackers!
>
> I understand OpenStack uses scheduler logic to place a VM on a host to
> ensure the load is balanced across hosts. My 64 million dollar question is:
> Has anyone identified a way to monitor capacity across all hosts on an
> ongoing basis and automatically live migrate VM's as needed to ensure hosts
> resource consumption is balanced over time?
>
> It seems the scheduler addresses capacity at the time of instantiation but
> there's nothing that addresses optimal usage AFTER the VM is initially
> placed.
>
> Thoughts/experiences?
>
> //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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Setting affinity based on instance type

[Adam Lawson]

We're looking at two workloads with different usage patterns: Type A
follows a typical cyclical performance pattern (high/low day/night). Type B
represents a consistent pattern (constant/predictable pattern). We want a
way to ensure Patterns A will have an affinity to stick together, Patterns
B with its own affinity to stick together and an Anti-Affinity policy for
the two Types to avoid being hosted on the same machine (not necessarily
prevention but avoidance).

Does that make sense?

//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, Mar 2, 2016 at 3:08 PM, Kris G. Lindgren <klindg...@godaddy.com>
wrote:

> You can set attributes on flavors that must match the attributes on hosts
> or the host aggregates.  So you can basically always make sure a specific
> flavors goes to a specific compute node or type (like disks=ssd or
> class=gpu).  Look at nova flavor extra_specs documentation and the
> aggregate_Instance_extra_specs under the scheduler options.
>
>
> ___
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
> From: "Fox, Kevin M" <kevin@pnnl.gov>
> Date: Wednesday, March 2, 2016 at 3:58 PM
> To: Adam Lawson <alaw...@aqorn.com>, "
> openstack-operators@lists.openstack.org" <
> openstack-operators@lists.openstack.org>
> Subject: Re: [Openstack-operators] Setting affinity based on instance type
>
> you usually do that on an instance level with server groups. do you have
> an example where you might want to do it at the flavor level?
>
> Thanks,
> Kevin
> --
> *From:* Adam Lawson [alaw...@aqorn.com]
> *Sent:* Wednesday, March 02, 2016 2:48 PM
> *To:* openstack-operators@lists.openstack.org
> *Subject:* [Openstack-operators] Setting affinity based on instance type
>
> I'm sure this is possible but I'm trying to find the info I need in the
> docs so I figured I'd pitch this to you guys while I continue looking:
>
> Is it possible to set an affinity/anti-affinity policy to ensure instance
> Type A is weighted for/against co-location on the same physical host with
> instance Type B?
>
> Basically I have no requirement for server-group affinity but rather to
> ensure specific workloads are as separate as possible.
>
> Thoughts?
>
> //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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Setting affinity based on instance type

[Adam Lawson]

I'm sure this is possible but I'm trying to find the info I need in the
docs so I figured I'd pitch this to you guys while I continue looking:

Is it possible to set an affinity/anti-affinity policy to ensure instance
Type A is weighted for/against co-location on the same physical host with
instance Type B?

Basically I have no requirement for server-group affinity but rather to
ensure specific workloads are as separate as possible.

Thoughts?

//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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Workload Management (post-instantiation)

[Adam Lawson]

Hello fellow Ops-minded stackers!

I understand OpenStack uses scheduler logic to place a VM on a host to
ensure the load is balanced across hosts. My 64 million dollar question is:
Has anyone identified a way to monitor capacity across all hosts on an
ongoing basis and automatically live migrate VM's as needed to ensure hosts
resource consumption is balanced over time?

It seems the scheduler addresses capacity at the time of instantiation but
there's nothing that addresses optimal usage AFTER the VM is initially
placed.

Thoughts/experiences?

//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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Cloud Upgrade Strategies

[Adam Lawson]

Hey all,

So I've been discussing cloud design with the team and of course the topic
comes up about how upgrades will be handled.

Handling OpenStack code updates generally consists of three paths in my
experience:

   - CI/CD (continuous incremental upgrades)
   - In-place Full Release upgrades (upgrade an entire cloud from Icehouse
   to Kilo for instance)
   - Migrating old cloud to new cloud

Is there a cloud maintenance strategy I'm missing that doesn't fall into
the categories above? How are the rest of you adopting your cloud upgrade
strategies and how has cloud size impacted whatever strategy you ultimately
selected? Migrating workloads from an Icehouse cloud with 1000 nodes to a
Liberty cloud with similar capacity isn't always a realistic option due to
cost, upgrading a cloud in place is super-risky and CI/CD takes a lot of
development and testing overhead.

For CI/CD strategies, I'm also curious how the rest of you are handling
disruptive tasks (for example replacing a vRouter with a newer version,
updating the SQL schema etc etc)? Just looking to learn from everyone's
experiences to hopefully keep my own thinking on where it needs to be.

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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[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

[Openstack] [Ceilometer] Database back-ends - is list 100% accurate?

[Adam Lawson]

Hey everyone, is it true the only backend DB's supported by Ceilometer
(+Aodh et al) is PostgreSQL, MySQL, HBase and MongoDB?

Specifically, I don't see Cassandra listed but there was a spec back in
2013 tto inclue it as a plugin option.

//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
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] [Neutron][DVR] point of encapsulation/locating routing tables

[Adam Lawson]

To all who shared the content they know about - I definitely have plenty to
chew on. Thanks!

//adam
On Feb 17, 2016 4:57 AM, "Assaf Muller" <amul...@redhat.com> wrote:

> I wrote a fairly comprehensive blog series about DVR:
> assafmuller.com/category/dvr/
>
> On Tue, Feb 16, 2016 at 2:47 PM, Adam Lawson <alaw...@aqorn.com> wrote:
> > Hi everyone:
> >
> > Got a quick question for those of you with some knowledge of OVS and
> > namespaces within the context of DVR.
> >
> > I'm trying to document exactly where namespaces are defined and where
> > encapsulation occurs if using (for instance) VxLAN/GRE tunnels.
> >
> > Is there a quick and dirty slideshare or someone able to explain this
> quick
> > and dirty?
> >
> > The question came up today is if we use tunnels, where does encapsulation
> > occur and where are the tables maintained and what data specifically
> sits in
> > each of those tables.
> >
> > Is this an easy question to answer?
> >
> > //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-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Neutron][DVR] point of encapsulation/locating routing tables

[Adam Lawson]

Hi everyone:

Got a quick question for those of you with some knowledge of OVS and
namespaces within the context of DVR.

I'm trying to document exactly where namespaces are defined and where
encapsulation occurs if using (for instance) VxLAN/GRE tunnels.

Is there a quick and dirty slideshare or someone able to explain this quick
and dirty?

The question came up today is if we use tunnels, where does encapsulation
occur and where are the tables maintained and what data specifically sits
in each of those tables.

Is this an easy question to answer?

//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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] OpenStack Consult Opp (Network/Horizon/VNC)

[Adam Lawson]

Hey all,

Just curious how this was progressing. Is there an approval waiting to
happen or something in the background?

//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, Nov 24, 2015 at 1:55 PM, JJ Asghar <j...@chef.io> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 11/24/15 3:13 PM, Adam Lawson wrote:
> > Yep. I knew I was walking a gray line. If I had time to let folks
> > know about an opportunity and wait for folks to visit and reply I
> > totally would. Otherwise, I would definitely echo a job-related
> > mailing list if that could be setup?
> >
> >
> > On Tue, Nov 24, 2015 at 12:51 PM, JJ Asghar <j...@chef.io
> > <mailto:j...@chef.io>> wrote:
> >
> >
> > As another place, other than the job posting site I just created
> > this review[1].
> >
> > If you like this idea please +1 it.
> >
> >
> > [1]: https://review.openstack.org/249415
>
>
> Yep, that's that review above. Go ahead and +1 it also, and we'll see
> if we can the list put together. :D
>
>
> - --
> Best Regards,
> JJ Asghar
> c: 512.619.0722 t: @jjasghar irc: j^2
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2
> Comment: GPGTools - https://gpgtools.org
>
> iQIcBAEBCgAGBQJWVNy8AAoJEDZbxzMH0+jTpEAP/3qnKoVP/iVKlFmZG7CrhLxC
> TveL3xNyTBGt+cMVQAJGChSH8v0l1+XuUKeIkRBsPCppe7PnPfIqPuCFJKuvCU+v
> gFDUvJbpqSXL+D7vfvc/83GUPa9rgvV//ovicbrvvJIsvl5LMuLpUgBVhZRDWzu2
> Q+VjdRFkHVCAHepQxBiyRav6Cwa5Sng3ODHrjlhKc4Kr2me25B+NDCqPbQz4/h6a
> T/nnHFrvZ0PQcYmNBONRe2WX7IqwJx/igV3+HuHXUtrtpKPRX7V12k5WdEGqbVDn
> LBEwJDYJWFXa8uo/WsbiaQfsO4iP8TZwP8aU/kcEB685HnRVr6Naw19VZwEvp8ZZ
> 5+WoT861u1VwWe244MvWgWLkWPVYsZIzCJAfcNmqVTQByc2VnozTUDoYWirjCPfS
> ka5Fj/t2jEh5fr6cR8x/h4yaq3DO345yVL2U9oj0NhczEpNYpFCdg66Huh8sMgca
> BwZmzd50UGTxq1tp5etT+XBeAqxhwd0iqgNZLXsTLQgJZ58giqgTymtgOGoROz1c
> PbvUoUgSgLTzr9PnyEAV09gZvyYr+8goR6RtfbDTWyykSqDrByr8qqef4DnxkyoM
> Y4lzp+vGkMK3RxJcVgM7fUmbIJTo42fpuwDFC39FmoSICJVqzYuNKcM6NlUmzXHE
> GbKDfBTzXrWTkgo1+0uW
> =T6en
> -END PGP SIGNATURE-
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[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
>

[Openstack-operators] [Fuel] Trying to get past a 6.1 deployment error

[Adam Lawson]

Hola!

I'm seeing the following error in Fuel 6.1:

Deployment has failed. Method granular_deploy. Failed to execute hook
> 'puppet' Puppet run failed. Check puppet logs for details
> ---
> priority: 200
> fail_on_error: true
> type: puppet
> uids:
> - '1'
> parameters:
> puppet_modules: "/etc/puppet/modules"
> puppet_manifest:
> "/etc/puppet/modules/osnailyfacter/modular/virtual_ips/public_vip_ping.pp"
> timeout: 3600
> cwd: "/"
> .
> Inspect Astute logs for the details


*While troubleshooting, *I ran puppet apply -dv
/etc/puppet/modules/osnailyfacter/modular/virtual_ips/public_vip_ping.pp on
the master node and it gave me the following output (at the end):

Debug: hiera(): Looking for data source common
> Error: Could not find data item network_scheme in any Hiera data file and
> no default supplied at
> /etc/puppet/modules/osnailyfacter/modular/virtual_ips/public_vip_ping.pp:4
> on node fuel.fuel.tld
> Error: Could not find data item network_scheme in any Hiera data file and
> no default supplied at
> /etc/puppet/modules/osnailyfacter/modular/virtual_ips/public_vip_ping.pp:4
> on node fuel.fuel.tld


Thoughts/suggestions? Trying to build a Contrail demo in my lab. All nodes
are VMware instances. I'm suspecting it has something to do with the
Pacemaker VIP but I'm not clear on the path forward to resolve.

//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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack] [Neutron][OpenContrail] Difference btwn ext API's and int "Introspect" ports?

[Adam Lawson]

Edited subject line - forgot to add neutron. ; )


*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, Jan 11, 2016 at 10:50 AM, Adam Lawson <alaw...@aqorn.com> wrote:

> Is there an Open/Contrail document or other online resource I can read
> that explains the difference between the internal "introspect" ports and
> external GUI ports?
>
> //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
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OpenContrail] Difference btwn ext API's and int "Introspect" ports?

[Adam Lawson]

Is there an Open/Contrail document or other online resource I can read that
explains the difference between the internal "introspect" ports and
external GUI ports?

//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
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Fwd: About Openstack Installation.

[Adam Lawson]

As long as you manage to keep your networks separate(d) using VLANs or
something, NIC use is kind of irrelevant as far as requirements go.


*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, Dec 27, 2015 at 9:51 PM, Ajey Gore <ajeyg...@gmail.com> wrote:

> Not really.
>
>
> On Dec 27 2015, at 7:04 pm, madhuri kadam <madhurikadam...@gmail.com>
>> wrote:
>>
>> -- Forwarded message --
>> From: *madhuri kadam* <madhurikadam...@gmail.com>
>> Date: Sun, Dec 27, 2015 at 6:53 PM
>> Subject: About Openstack Installation.
>> To: openstack@lists.openstack.org
>>
>>
>>  Is it compulsory to use  Three NIC for the network node while forming
>> the cloud on physical machine.
>>
>>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [COA] How to get involved

[Adam Lawson]

I know Foundation is working on the exams and certification process for
OpenStack Administrators.

For someone who desires to participate/assist in this effort, who is
leading the charge? I can't seem to find reference to it anywhere although
I noticed a number of fellow sponsors were listed in the press release as
having participated thus far. I didn't know the opportunity even existed so
I am wondering is the COA effort invite-only or did I just miss the email?

//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
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack-operators] OpenStack Consult Opp (Network/Horizon/VNC)

[Adam Lawson]

For the consultants reading this (I've pretty much exhausted my Rolodex): I
have a remote engineering opportunity if someone wants a little side work
this week - maybe next week - assisting us with an OpenStack cloud project
for a large ISP with unique requirements. Please ping me if you're a decent
network/Neutron person and have some time this week and/or next week for
some excellent scratch? If available, we'll get you ramped up like
immediately and guaranteed we will make it worth your while. ; )

Ping me offline if interested ASAP? 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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] OpenStack Consult Opp (Network/Horizon/VNC)

[Adam Lawson]

Yep. I knew I was walking a gray line. If I had time to let folks know
about an opportunity and wait for folks to visit and reply I totally would.
Otherwise, I would definitely echo a job-related mailing list if that could
be setup?

//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, Nov 24, 2015 at 12:51 PM, JJ Asghar <j...@chef.io> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 11/24/15 2:41 PM, JJ Asghar wrote
> >
> > I think this brings in the conversation, where _should_ these types
> > of emails be sent?
> >
> > Maybe we should create a [openstack-jobs] list? So there is a one
> > stop shop that we can point these types of requests to?
>
> As another place, other than the job posting site I just created this
> review[1].
>
> If you like this idea please +1 it.
>
>
> [1]: https://review.openstack.org/249415
> - --
> Best Regards,
> JJ Asghar
> c: 512.619.0722 t: @jjasghar irc: j^2
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2
> Comment: GPGTools - https://gpgtools.org
>
> iQIcBAEBCgAGBQJWVM3rAAoJEDZbxzMH0+jTNFYQAIfteOLfF++FGuOqV2IHJ9Jm
> y1n9XsBhPCqCbpbFs1kieW6fbGnxaSBFxv6TdBqAGutqmAJCu8oZFlxLTdt2GEol
> a5zeyRozDreqwRDJBu+toMhFBpGBrX59VYsZwfE9XIaTwZ8utZrdJ8wcCVomx4x8
> QY4WniXU8OViUIsshQroDaBZ05/n2qV1kqQ7nW6VZ7UMBEso5is2YNOqnntqmRZb
> CYNTVRTWp87olc92sskHH5g79FN1KCVxGd9b0f1zNx1f4Zi/59D+01DzcMCDpH0k
> EZrlwhp+HHhOlqubUU+seCctIrNSmR+djB8IdGejZp2gxGf8zgMP9d0H4VJeX5rw
> usaEzreIPrECjZ8co0BLtkrAH4ZuCX6ztXQXMCXDE0zhBHTeRPPWTy51IYqg9Ark
> cJCa5FLloa96dcB2q4fWWQNWJb91yuR3gLoWipRhhKUfkL+veqprxCez1JUIMlhg
> fa0m4yWQbQFm2jvTdIBxzRXXlFxDoiX6TBfOYD/NPWpw3/xWvvhtLC6AZ304ff6+
> /Im/8xMB6+qGMfqb1hKYHWy8qww74FszhirohlYn4CLxdZV1QGxiCYwbxgDQ9cle
> 5bYVGBlG14h9JdFig5apHL9WEVJ97V+XFQUpohY39cqMxJ4U548fB/rBhYg1dIPH
> mi32puX35nZgFrshcNDJ
> =dGem
> -END PGP SIGNATURE-
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[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-operators] [Nova] Question about starting nova as service versus directly

[Adam Lawson]

Thanks I will remember this! Unfortunately the image is long gone but very
good info to keep handy.

What exactly does upstart do by the way (as I check the log on a known
working image)?

//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, Nov 20, 2015 at 8:27 AM, Joe Topjian <j...@topjian.net> wrote:

>
> Yes, most likely is related to permissions. Another good source of
>> information for troubleshooting is /var/log/upstart/nova-compute.log
>>
>
> Ah yes! Much easier.
>
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Nova] Question about starting nova as service versus directly

[Adam Lawson]

So I can start Nova on Ubuntu/Icehouse via *$ sudo python
/usr/bin/nova-compute* and it runs fine and stays online but it does not
run/stay online if I use *$ sudo service nova-compute start/restart*.

I guessed it might have been related to rootwrap but I ran out of time to
troubleshoot so I reverted the image to a previously-known good state.

Does anyone have an idea why this happens and how to correct? I checked and
/etc/nova/rootwrap.conf file looked correct and /etc/nova/nova.conf as well
via the root_helper parameter.

//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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[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] [openstack-dev] Nominations open for the N and O names of OpenStack

[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
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] [Ceph] Different storage types on different disk types

[Adam Lawson]

Thanks everyone, got several good ideas on how to proceed forward. Thanks!!

//adam
On Oct 28, 2015 11:55 AM, "Andrew Woodward" <xar...@gmail.com> wrote:

> Adam,
>
> Most deployments use different pools for each type as discussed above.
> These pools can then be mapped differently to disks, racks and so on by
> updating the CRUSH rules. This controls how pools are distributed in the
> cluster.
>
> On Tue, Oct 27, 2015 at 3:15 AM Warren Wang <war...@wangspeed.com> wrote:
>
>> There are some cases where it may be easier to run them as separate
>> clusters. Like when you start adding tuning changes that don't make sense
>> for types of clusters. Like the recent tcmalloc/jemalloc discovery for
>> SSDs. I'm not sure that makes sense for spinners, and that is at a library
>> level, not config.
>>
>> It isn't much more overhead to run multi backend cinder, which you kind
>> of need to do anyway to guarantee QoS on the default volume for BfV.
>>
>> --
>> Warren
>>
>> On Oct 27, 2015, at 12:32 AM, Arne Wiebalck <arne.wieba...@cern.ch>
>> wrote:
>>
>> Hi Adam,
>>
>> We provide various volume types which differ in
>>
>> - performance (implemented via different IOPS QoS specifications, not via
>> different hardware),
>> - service quality (e.g. volumes on a Ceph pool that is on Diesel-backed
>> servers, so via separate hardware),
>> - a combination of the two,
>> - geographical location (with a second Ceph instance in another data
>> centre).
>>
>> I think it is absolutely realistic/manageable to use the same Ceph
>> cluster for various use cases.
>>
>> HTH,
>>  Arne
>>
>> On 26 Oct 2015, at 14:02, Adam Lawson <alaw...@aqorn.com> wrote:
>>
>> Has anyone deployed Ceph and accommodate different disk/performance
>> requirements? I.e. Saving ephemeral storage and boot volumes on SSD and
>> less important content such as object storage, glance images on SATA or
>> something along those lines?
>>
>> Just looking at it's realistic (or discover best practice) on using the
>> same Ceph cluster for both use cases...
>>
>> //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-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Ceph] Different storage types on different disk types

[Adam Lawson]

Has anyone deployed Ceph and accommodate different disk/performance
requirements? I.e. Saving ephemeral storage and boot volumes on SSD and
less important content such as object storage, glance images on SATA or
something along those lines?

Just looking at it's realistic (or discover best practice) on using the
same Ceph cluster for both use cases...

//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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Neutron] public and private fixed IPs

[Adam Lawson]

I'm very very happy to hear this! I have one of my guys giving it a whirl
while I'm here in Japan.

Hope to see some of you soon!

//adam
On Oct 26, 2015 8:48 AM, "Matt Kassawara" <mkassaw...@gmail.com> wrote:

> Take a look at the installation guide for Liberty at docs.openstack.org...
> the architecture supports attaching VMs to public/external and
> private/project networks.
>
> On Sun, Oct 25, 2015 at 6:39 AM, Neil Jerram <neil.jer...@metaswitch.com>
> wrote:
>
>> For assigning a routable public IP to a VM, James and Kevin have
>> described using an external network, but I think there might be a second
>> possibility. Namely, a shared, non-external network, with a subnet with the
>> routable IP range that you want to assign from, and connected via a Neutron
>> router to the outside world.
>>
>> Would that also work? Would the L3 agent in that case avoid doing an
>> unnecessary NAT?
>>
>> Thanks,
>>   Neil
>>
>> PS. Adam - you might also like to check out my L3-only networking spec at
>> https://review.openstack.org/#/c/238895/, as it describes IP addressing
>> like what you describe, and might align more generally with what you have
>> in mind.
>>
>>
>> ‎
>> *From: *Kevin Benton
>> *Sent: *Sunday, 25 October 2015 06:34
>> *To: *James Denton
>> *Cc: *OpenStack Operators
>> *Subject: *Re: [Openstack-operators] [Neutron] public and private fixed
>> IPs
>>
>> Yes, as long as the network is marked as both 'shared' and external, a
>> tenant can attach VMs and router gateway interfaces directly to it.
>> On Oct 25, 2015 2:47 PM, "James Denton" <james.den...@rackspace.com>
>> wrote:
>>
>>> Hi Adam,
>>>
>>> If you're asking whether or not a VM can be attached to an 'external'
>>> network so that the 'public' ip is the fixed IP of them VM, then yes. A
>>> Neutron router can also be attached to the same network so that instances
>>> in non-routable tenant networks can obtain floating IPs from the same
>>> 'public' network. At one time non-admin users were not allowed to attach
>>> VMs to 'external' networks but I believe that restriction was removed
>>> around Kilo or so.
>>>
>>> James
>>>
>>> Sent from my iPhone
>>>
>>> > On Oct 25, 2015, at 2:15 PM, Adam Lawson <alaw...@aqorn.com> wrote:
>>> >
>>> > Hi everyone!
>>> >
>>> > When using KVM, does Neutron support binding a public routable address
>>> > to one VM in one tenant as a fixed IP that is accessible outside the
>>> > cloud (no floating IP for remote access) and a VM in a separate tenant
>>> > with private fixed IP's with optional floating IP? Would this be
>>> > possible on a per tenant or per region basis?
>>> >
>>> > I'm working on a cloud approach that allows either scenario.
>>> >
>>> > Long story short, I'm trying to support two options in the same cloud
>>> > (if possible) so a department/tenant can deploy instances with public
>>> > IP's that are directly accessible by the rest of the enterprise (no
>>> > NAT) and a second department/tenant that deploys all of their VM's
>>> > within the context of a private/isolated tenant network with optional
>>> > floating IP's.
>>> >
>>> > Thoughts on how this would be handled? Is it as simple as assigning a
>>> > public subnet to a tenant as the fixed/tenant network?
>>> >
>>> > //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-operators mailing list
>>> > OpenStack-operators@lists.openstack.org
>>> >
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack] [Fuel] v7.0 error during deployment

[Adam Lawson]

The customer doesn't have an internal NTP server to use and when I try to
run fuel-createmirror, it errors out FATAL saying archive.ubuntu.com does
not support rsync then dies.

Does Fuel create a local NTP server or do I have to create one myself?
Would be nice it something just worked for once.

//adam (frustrated)


*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 22, 2015 at 5:49 PM, Remo Mattei <r...@italy1.com> wrote:

> Yes you can build your own local ntp server and this should be fixed with
> that looks like it cannot go out to sync the time with what has been set in
> fuel. Have you set your ntp before you run the fuel server? It is in the
> boot option to change it.
>
> Remo.
>
> Inviato da iPhone
>
> Il giorno 22 ott 2015, alle ore 14:17, Adam Lawson <alaw...@aqorn.com> ha
> scritto:
>
> Can someone explain this error? It comes up every time and fails the whole
> deployment.
>
> Puppet logs:
> ERROR: Unable to communicate with at least one of NTP server, checked the
> following host(s): ["0.fuel.pool.ntp.org", "1.fuel.pool.ntp.org", "
> 2.fuel.pool.ntp.org"] on node node-6.x.com
>
> priority: 1500
> fail_on_error: true
> type: puppet
> uids:
> - '6'
> parameters:
>   puppet_modules: "/etc/puppet/modules"
>   puppet_manifest: 
> "/etc/puppet/modules/osnailyfacter/modular/ntp/ntp-check.pp"
>   timeout: 600
>   cwd: "/"
> .
> Inspect Astute logs for the details
>
> What is required for these nodes to talk to the internet and is it
> possible to disable external ntp?
>
> *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
>
> !DSPAM:1,562954ed134201142736362!
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
> !DSPAM:1,562954ed134201142736362!
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack-operators] [Fuel] Need help with Fuel's VNC settings

[Adam Lawson]

Looks like I may have hosed the VNC settings in tryng to fixz a bad DNS
issue with fuel inserting an unknown string "i.e. public.fuel.blah" into
the DNS access path.
.
What are the correct IP settings so I can connect to VNC within Horizon?

Currently, Horizon appears to be listening on 172.16.149.4
The controller currently has novncproxy_host=172.16.149.5 (if I set this to
172.16.149.4 I get a 503 error)

The compute node has
novncproxy_base_url=https://172.16.149.5:6080/vnc_auto.html (If I set this
.4 I also get a 503 error in Horizon)
vncserver_listen=0.0.0.0
vncserver_proxyclient_address=192.168.1.7 (I changed this manually; I know
it should be IP of compute node -- can't remember which IP to use)



*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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack] [fuel] fuel cli question

[Adam Lawson]

I'm being asked how to create a new environment using fuel cli. I need to
know how to define KVM, neutron/GRE with Ceph back-end for everything. The
docs gives examples but don't go into specifics.

*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
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] ephemeral storage

[Adam Lawson]

The path to where the disk files are kept I believe is
var/lib/nova/instances. That's different than the default path used by kvm
outside the context of OpenStack.

Or try searching for libvirt.xml and you'll find the disks in the same
directory/ies.
On Oct 16, 2015 5:11 AM, "Federico Michele Facca" <
federico.fa...@create-net.org> wrote:

> Instances by default are incrementaly stored in a path like /var/instances
> using kvm.
> On Oct 16, 2015 1:51 PM, "Heiko Krämer"  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi,
>>
>> ephemeral disks are configured in your flavor for each instance.
>>
>> Cheers
>> Heiko
>>
>> On 16.10.2015 13:36, Davíð Örn Jóhannsson wrote:
>> > I'm a bit new to openstack and all things related so bare with me
>> > :)
>> >
>> >
>> > I'm trying to configure disks for ephemeral? storage of compute
>> > nodes that have cinder already configured and I can't seem to find
>> > any documentation regarding that or how to configure local disks
>> > for storage.
>> >
>> >
>> > Could anybody point me in the right direction?
>> >
>> >
>> >
>> > ___
>> > OpenStack-operators mailing list
>> > OpenStack-operators@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operator
>> s
>> >
>> >
>> >
>> - --
>> Anynines.com
>>
>> B.Sc. Informatik
>> CIO
>> Heiko Krämer
>>
>>
>> Twitter: @anynines
>>
>> - - 
>> Geschäftsführer: Alexander Faißt, Dipl.-Inf.(FH) Julian Fischer
>> Handelsregister: AG Saarbrücken HRB 17413, Ust-IdNr.: DE262633168
>> Sitz: Saarbrücken
>> Avarteq GmbH
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJWIOR0AAoJELxFogM4ixOFQ2EIAMHCteyc9QM9/kFmU/m5LSz6
>> jfnnHKBnZp2BxwiHGsCPI8YWmr3z+BTuOSm110KYHtxZUV+EihNwGVWIdn7xVyrZ
>> u6UsHzzoCv2IwA88Pw98UxfYH2xAK55Iwg9VbKKgNE8Uo8fcToRBVjN8HmJ+se5Q
>> yVWuyh/n1TkjSroOPgorkrAXom2O3KTOKaOVKUuIbvLK0c12MUt3uY9PVY4peVzD
>> DyNmBFt/y+7ItxTM8slZHsGCPMI5YtzTW3DYH7TfYPZ87o9mYRp9mDhQffOhwa8U
>> yoc/xDiw5jdU83YaG+sccKqp6y+KNWKnpyumlIsNtuVMrIPPMputK9T1cf/T2hg=
>> =ch7f
>> -END PGP SIGNATURE-
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] Scheduler proposal

[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

Re: [Openstack-operators] Tokyo Ops Design Summit Tracks - Agenda on Sched

[Adam Lawson]

Do we have any interest in ways folks are installing OpenStack? I know we
have a fair number of consultants on this making list who deploy for
different companies, would be cool to do a show and tell for how folks are
installing OpenStack or hear creative ways they manage new clouds with
companies who don't have a highly developed devops capability...

If this was already covered, I'd be happy to moderate if we still need
someone...
On Oct 11, 2015 8:58 PM, "Tom Fifield"  wrote:

> Hi all,
>
> We are still lacking:
>
> * Moderator(s) for Quotas and Billing
> * Content for about 3 slots.
>
> If you have interest for any of this, please speak now - time is running
> out!
>
> Regards,
>
>
> Tom
>
> On 05/10/15 09:48, Tom Fifield wrote:
>
>> OK,
>>
>> Since no burning issues were raised, I'm going to start handing back
>> space, starting with the empty working group slots on Wednesday.
>>
>>
>> Regards,
>>
>>
>> Tom
>>
>> On 30/09/15 11:24, Tom Fifield wrote:
>>
>>>   Hi all,
>>>
>>> The agenda for Tokyo design summit's ops track is now on sched (buy
>>> Thierry wine if you see him):
>>>
>>> https://mitakadesignsummit.sched.org/overview/type/ops
>>>
>>> * Note that we have some unallocated slots (marked "TBC"). In order to
>>> help out our software development community who are short of slots,
>>> unless we can find something with a burning need to fill them, I propose
>>> we hand the slots back. Your thoughts welcome!
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Tom
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Tokyo Ops Design Summit Tracks - Agenda on Sched

[Adam Lawson]

Or it could be how they're testing new clouds, metering successes for ISPs,
how web hosts are using OpenStack with unique customers.. anything where we
can hear what others are doing would be pretty great I think.
On Oct 11, 2015 9:45 PM, "Adam Lawson" <alaw...@aqorn.com> wrote:

> Do we have any interest in ways folks are installing OpenStack? I know we
> have a fair number of consultants on this making list who deploy for
> different companies, would be cool to do a show and tell for how folks are
> installing OpenStack or hear creative ways they manage new clouds with
> companies who don't have a highly developed devops capability...
>
> If this was already covered, I'd be happy to moderate if we still need
> someone...
> On Oct 11, 2015 8:58 PM, "Tom Fifield" <t...@openstack.org> wrote:
>
>> Hi all,
>>
>> We are still lacking:
>>
>> * Moderator(s) for Quotas and Billing
>> * Content for about 3 slots.
>>
>> If you have interest for any of this, please speak now - time is running
>> out!
>>
>> Regards,
>>
>>
>> Tom
>>
>> On 05/10/15 09:48, Tom Fifield wrote:
>>
>>> OK,
>>>
>>> Since no burning issues were raised, I'm going to start handing back
>>> space, starting with the empty working group slots on Wednesday.
>>>
>>>
>>> Regards,
>>>
>>>
>>> Tom
>>>
>>> On 30/09/15 11:24, Tom Fifield wrote:
>>>
>>>>   Hi all,
>>>>
>>>> The agenda for Tokyo design summit's ops track is now on sched (buy
>>>> Thierry wine if you see him):
>>>>
>>>> https://mitakadesignsummit.sched.org/overview/type/ops
>>>>
>>>> * Note that we have some unallocated slots (marked "TBC"). In order to
>>>> help out our software development community who are short of slots,
>>>> unless we can find something with a burning need to fill them, I propose
>>>> we hand the slots back. Your thoughts welcome!
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>>
>>>> Tom
>>>>
>>>> ___
>>>> OpenStack-operators mailing list
>>>> OpenStack-operators@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>
>>>
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack] Cinder - Ceph RADOS with libvirt+Xen Project

[Adam Lawson]

That's the primary reason I've discovered why folks move away; I wasn't
sure cloudstack was or wasn't part of the overall picture so I figured just
outright mention the purple elephant in the room. ; )


Are your VM's able to see the disk when NOT using Cinder+Ceph?



*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 6, 2015 at 9:13 PM, Leandro Mendes <theflock...@gmail.com>
wrote:

> Hi Adam, actually i already moved from cloudstack. Some things related do
> architecture wasn't fitting well regarding my envirment and OpenStack
> solves a hundred % of my problems.
>
> My deployment is working well with Gluster, but i would like to make it
> work with Ceph.
>
> At this time, moving back to cloudstack is not an option. Maybe move to
> kvm, but first i'd like to try a little more.
> Em 07/10/2015 00:51, "Adam Lawson" <alaw...@aqorn.com> escreveu:
>
>> Are you married to OpenStack? I know xen works beautifully with
>> cloudstack... Just throwing it out there...
>> On Oct 6, 2015 7:17 PM, "Leandro Mendes" <theflock...@gmail.com> wrote:
>>
>>> Hi Guys,
>>>
>>> I would like to know if someone got success deploying Cinder using
>>> Libvirt+Xen Project with Ceph RADOS backend.
>>>
>>> I tried but Xen Project can't find the disk.
>>>
>>> Did someone tried to do the same?
>>>
>>> Thanks!
>>>
>>> ___
>>> Mailing list:
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> Post to : openstack@lists.openstack.org
>>> Unsubscribe :
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>
>>>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Cinder - Ceph RADOS with libvirt+Xen Project

[Adam Lawson]

Are you married to OpenStack? I know xen works beautifully with
cloudstack... Just throwing it out there...
On Oct 6, 2015 7:17 PM, "Leandro Mendes"  wrote:

> Hi Guys,
>
> I would like to know if someone got success deploying Cinder using
> Libvirt+Xen Project with Ceph RADOS backend.
>
> I tried but Xen Project can't find the disk.
>
> Did someone tried to do the same?
>
> Thanks!
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Cinder vs Swift architecture

[Adam Lawson]

Hi Ayushi,

The quick and dirty explanation:

Cinder can have different back-ends. With a Linux approach, Cinder uses
LVM2 to carve up local disks so they can be consumed by virtual machines
that need to attach to a volume (for data or to boot). A common way for
VM's to consume these volumes is via iSCSI (see iscsi targets and
initiators for more details). The end result is the VM's talk to the
volumes rather than talking to Cinder to get to the data.

Swift also carves up local disks and stores data on them but the data
itself is accessed using an API (similar to dropbox). No exceptions. VM's
don't mount the data on the back-end the way they do with Cinder-managed
volumes, but object storage is instead leveraged for things like user
storage, enterprise department data storage (similar to
Accounting/Marketing/IT share drive) or as a back-end for services that
need a safe place to store files for future use like Glance, Cinder
backups, Barbican, etc.

In terms of how the disks are consumed on a local machine, Cinder allows
the VM to mount and format the drive/volume then use however it wants to.
Swift formats it and presents a pre-formatted volume so you can just drop a
file and get it later.

Does that help at all?

//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 5, 2015 at 12:26 AM, Abhishek Shrivastava <
abhis...@cloudbyte.com> wrote:

> Hi Ayushi,
>
> If you had not gone through this link, then please have a look and let us
> know if it is useful:
>
>-
>
> http://www.computerweekly.com/feature/OpenStack-storage-Cinder-and-Swift-explained
>
>
> On Mon, Oct 5, 2015 at 12:27 PM, Ayushi Kumar <ayushi.03ma...@gmail.com>
> wrote:
>
>> Hi,
>>
>> Even after going through number of links and documents online , I am
>> unable to understand that exactly
>>
>>- * how file storage , cinder and swift work if I talk in terms of a
>>personal computer which has openstack insatlled on it.*
>>
>> Can anyone please explain that if I have a hard drive then
>>
>>- * how cinder uses it for block storage and and how swift uses it
>>for object storage.*
>>
>> Though the difference between the two storage is clear ,I am unable to
>> understand how the same hard drive is used for both object storage and
>> block storage .
>>
>> Regards
>> Ayushi
>>
>> ___
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>
>
> --
>
>
> *Thanks & Regards,*
> *Abhishek*
> *Cloudbyte Inc. <http://www.cloudbyte.com>*
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] [VMware][neutron]nova-network

[Adam Lawson]

Hi Gilles, ESXi uses linuxbridges or are you referring to a multi
hypervisor scenario? Curious you know the names in advance...
On Oct 4, 2015 2:15 PM, "Gilles Mocellin" <gilles.mocel...@nuagelibre.org>
wrote:

> Le 04/10/2015 03:29, Adam Lawson a écrit :
>
>>
>> So I have to ask, last I heard, you have to run nova network if you want
>> to use OpenStack with VMware without an nsx license. Is this still the case
>> or are there plans for changes in the near future that I missed where one
>> can run neutron with VMware without an NSX license procurement?
>>
>> Just wondering, haven't heard but I do know there are efforts to sunset
>> nova network at some point...
>>
>> //adam
>>
>> Hello,
>
> I've just manage to make it work with Neutron ML2 / Linuxbridge / VLAN
> provider networks.
> The only drawback is that you have to pre-create portGroups with the names
> of the linux bridges created on the compute node / network node.
> You also have to create a trunk portGroup br-int, with promiscuous,
> transmit forge and MAC modification accepted.
> This is where you connect the VLAN interface of your network node.
>
> It's a bit condensed, but now you know it's possible !
>
> PS:
> There a ML2 mechanism driver : vmware_dvs that should ease this, creating
> the portgroups, but :
> - It's not packages on Ubuntu cloud archive
> - I didn't manage to make it work. I had errors creating some access
> policies...
>
> --
> GillesMo
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Swift] deploying behind apache?

[Adam Lawson]

Hey everyone,

What are the advantages to deploying swift storage and/or proxy services
behind apache versus not? Are there performance improvements that come into
play at scale? Has this been addressed before and are there any conclusions
drawn around these considerations I can read up on?

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

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

[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

[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

[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

Re: [Openstack] [Juno] How to set the VxLAN UDP port number in Juno?

[Adam Lawson]

Got a strange mailman message when i sent that out, sending again just in
case the parsing borked it.

You're saying you had to manually create the
/etc/neutron/plugins/ml2/ml2_conf.ini
 file? Pretty sure it's created whenever Neutron is installed so I'd make
 sure Neutron installed correctly. Don't mean to presume so check the
 obvious first right? ; )


/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 Sun, Aug 9, 2015 at 8:15 PM, Adam Lawson alaw...@aqorn.com wrote:

 You're saying you had to manually create the
 /etc/neutron/plugins/ml2/ml2_conf.ini file? Pretty sure it's created
 whenever Neutron is installed so I'd make sure Neutron installed correctly.
 Don't mean to presume so check the obvious first right? ; )

 /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, Aug 8, 2015 at 4:38 AM, Danny Choi (dannchoi) dannc...@cisco.com
 wrote:

 It shows port 8472 (otv) is still being used:

 [root@G10-QA4 ~]# netstat -a | grep udp

 *udp*0  0 0.0.0.0:43320   0.0.0.0:*


 *udp*0  0 0.0.0.0:58635   0.0.0.0:*


 *udp*0  0 0.0.0.0:bootpc  0.0.0.0:*


 *udp*0  0 0.0.0.0:ntp 0.0.0.0:*


 *udp*0  0 localhost:323   0.0.0.0:*


 *udp*0  0 0.0.0.0:sagxtsds0.0.0.0:*


 *udp*0  0 0.0.0.0:mdns0.0.0.0:*


 *udp*0  0 0.0.0.0:otv 0.0.0.0:*


 *udp*0  0 0.0.0.0:memcache0.0.0.0:*


 *udp*6   0  0 [::]:62175  [::]:*


 *udp*6   0  0 [::]:ntp[::]:*


 *udp*6   0  0 localhost:323   [::]:*


 [root@G10-QA4 ~]# ss -u -a

 State  Recv-Q Send-Q
   Local Address:Port
 Peer Address:Port

 UNCONN 0  0
   *:43320
   *:*

 UNCONN 0  0
   *:58635
   *:*

 UNCONN 0  0
   *:bootpc
   *:*

 UNCONN 0  0
   *:ntp
   *:*

 UNCONN 0  0
   127.0.0.1:rpki-rtr
   *:*

 UNCONN 0  0
   *:sagxtsds
 *:*

 UNCONN 0  0
   *:mdns
   *:*

 UNCONN 0  0
   *:otv
   *:*

 UNCONN 0  0
   *:memcache
 *:*

 UNCONN 0  0
 :::62175
 :::*

 UNCONN 0  0
 :::ntp
 :::*

 UNCONN 0  0
 ::1:rpki-rtr
   :::*


 From: Remo Mattei r...@italy1.com
 Date: Friday, August 7, 2015 at 10:11 PM

 To: Danny Choi dannc...@cisco.com
 Cc: Erik McCormick emccorm...@cirrusseven.com, 
 openstack-operators-requ...@lists.openstack.org 
 openstack-operators-requ...@lists.openstack.org, 
 openstack@lists.openstack.org openstack@lists.openstack.org
 Subject: Re: [Openstack] [Juno] How to set the VxLAN UDP port number in
 Juno?

 You need to call for udp adding a switch to the command. The ss alone
 will not query look at the man page maybe -a works

 Inviato da iPhone

 Il giorno 07/ago/2015, alle ore 18:14, Danny Choi (dannchoi) 
 dannc...@cisco.com ha scritto:

 Don’t see anything using ss and netstat:

 [root@G10-QA4 ~(keystone_admin)]# ss | grep 4789

 [root@G10-QA4 ~(keystone_admin)]# netstat | grep 4789

 [root@G10-QA4 ~(keystone_admin)]#

 From: Remo Mattei r...@italy1.com
 Date: Friday, August 7, 2015 at 5:16 PM
 To: Danny Choi dannc...@cisco.com
 Cc: Erik McCormick emccorm...@cirrusseven.com, 
 openstack-operators-requ...@lists.openstack.org 
 openstack-operators-requ...@lists.openstack.org, 
 openstack@lists.openstack.org openstack@lists.openstack.org
 Subject: Re: [Openstack] [Juno] How to set the VxLAN UDP port number in
 Juno?

 Check using ss or netstat and see if the port is open.

 Remo

 Inviato da iPhone

 Il giorno 07/ago/2015, alle ore 13:44, Danny Choi (dannchoi) 
 dannc...@cisco.com ha scritto:

 Yes, I did restart the Neutron service.

 Danny

 From: Remo Mattei r...@italy1.com
 Date: Friday, August 7, 2015 at 4:42 PM
 To: Danny Choi dannc...@cisco.com
 Cc

Re: [Openstack] [Juno] How to set the VxLAN UDP port number in Juno?

[Adam Lawson]

You're saying you had to manually create the
/etc/neutron/plugins/ml2/ml2_conf.ini file? Pretty sure it's created
whenever Neutron is installed so I'd make sure Neutron installed correctly.
Don't mean to presume so check the obvious first right? ; )

/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, Aug 8, 2015 at 4:38 AM, Danny Choi (dannchoi) dannc...@cisco.com
wrote:

 It shows port 8472 (otv) is still being used:

 [root@G10-QA4 ~]# netstat -a | grep udp

 *udp*0  0 0.0.0.0:43320   0.0.0.0:*


 *udp*0  0 0.0.0.0:58635   0.0.0.0:*


 *udp*0  0 0.0.0.0:bootpc  0.0.0.0:*


 *udp*0  0 0.0.0.0:ntp 0.0.0.0:*


 *udp*0  0 localhost:323   0.0.0.0:*


 *udp*0  0 0.0.0.0:sagxtsds0.0.0.0:*


 *udp*0  0 0.0.0.0:mdns0.0.0.0:*


 *udp*0  0 0.0.0.0:otv 0.0.0.0:*


 *udp*0  0 0.0.0.0:memcache0.0.0.0:*


 *udp*6   0  0 [::]:62175  [::]:*


 *udp*6   0  0 [::]:ntp[::]:*


 *udp*6   0  0 localhost:323   [::]:*


 [root@G10-QA4 ~]# ss -u -a

 State  Recv-Q Send-Q
 Local Address:Port
   Peer Address:Port

 UNCONN 0  0
 *:43320
 *:*

 UNCONN 0  0
 *:58635
 *:*

 UNCONN 0  0
 *:bootpc
 *:*

 UNCONN 0  0
 *:ntp
 *:*

 UNCONN 0  0
 127.0.0.1:rpki-rtr
 *:*

 UNCONN 0  0
 *:sagxtsds
   *:*

 UNCONN 0  0
 *:mdns
 *:*

 UNCONN 0  0
 *:otv
   *:*

 UNCONN 0  0
 *:memcache
   *:*

 UNCONN 0  0
 :::62175
 :::*

 UNCONN 0  0
 :::ntp
 :::*

 UNCONN 0  0
   ::1:rpki-rtr
 :::*


 From: Remo Mattei r...@italy1.com
 Date: Friday, August 7, 2015 at 10:11 PM

 To: Danny Choi dannc...@cisco.com
 Cc: Erik McCormick emccorm...@cirrusseven.com, 
 openstack-operators-requ...@lists.openstack.org 
 openstack-operators-requ...@lists.openstack.org, 
 openstack@lists.openstack.org openstack@lists.openstack.org
 Subject: Re: [Openstack] [Juno] How to set the VxLAN UDP port number in
 Juno?

 You need to call for udp adding a switch to the command. The ss alone will
 not query look at the man page maybe -a works

 Inviato da iPhone

 Il giorno 07/ago/2015, alle ore 18:14, Danny Choi (dannchoi) 
 dannc...@cisco.com ha scritto:

 Don’t see anything using ss and netstat:

 [root@G10-QA4 ~(keystone_admin)]# ss | grep 4789

 [root@G10-QA4 ~(keystone_admin)]# netstat | grep 4789

 [root@G10-QA4 ~(keystone_admin)]#

 From: Remo Mattei r...@italy1.com
 Date: Friday, August 7, 2015 at 5:16 PM
 To: Danny Choi dannc...@cisco.com
 Cc: Erik McCormick emccorm...@cirrusseven.com, 
 openstack-operators-requ...@lists.openstack.org 
 openstack-operators-requ...@lists.openstack.org, 
 openstack@lists.openstack.org openstack@lists.openstack.org
 Subject: Re: [Openstack] [Juno] How to set the VxLAN UDP port number in
 Juno?

 Check using ss or netstat and see if the port is open.

 Remo

 Inviato da iPhone

 Il giorno 07/ago/2015, alle ore 13:44, Danny Choi (dannchoi) 
 dannc...@cisco.com ha scritto:

 Yes, I did restart the Neutron service.

 Danny

 From: Remo Mattei r...@italy1.com
 Date: Friday, August 7, 2015 at 4:42 PM
 To: Danny Choi dannc...@cisco.com
 Cc: Erik McCormick emccorm...@cirrusseven.com, 
 openstack-operators-requ...@lists.openstack.org 
 openstack-operators-requ...@lists.openstack.org, 
 openstack@lists.openstack.org openstack@lists.openstack.org
 Subject: Re: [Openstack] [Juno] How to set the VxLAN UDP port number in
 Juno?

 Did you restart the services?

 Inviato da iPhone

 Il giorno 07/ago/2015, alle ore 13:16, Danny Choi (dannchoi) 
 dannc...@cisco.com ha scritto:

 Hi Erik,

 I added the following in ml2_config.ini file but it did not work; still
 using port 8472 afterwards.

 [agent]
 vxlan_udp_port=4789

 Regards,
 Danny

 From: Erik McCormick emccorm...@cirrusseven.com
 Date: Friday, August 7, 2015 at 9:57 AM

[openstack-dev] Quick question..

[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

[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

[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

[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] [Openstack-operators] [openstack-dev] Rescinding the M name decision

[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

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack