Re: [Openstack-operators] [Scale][Performance] / compute_nodes ratio experience

[Dina Belova]

Dan,

sure, I did not mean that we should collect this information without
understanding the workloads happening on the cloud, but still this is very
interesting information to gather.

Cheers,
Dina

On Thu, Nov 19, 2015 at 1:52 AM, Dan Smith  wrote:

> > As providing OpenStack community with understandable recommendations
> > and instructions on performant OpenStack cloud deployments is part
> > of Performance Team mission, I'm kindly asking you to share your
> > experience on safe cloud deployment ratio between various types of
> > nodes you're having right now and the possible issues you observed
> > (as an example: discussed GoDaddy's cloud is having 3 conductor boxes
> > vs 250 computes in the cell, and there was an opinion that it's
> > simply not enough and that's it).
>
> That was my opinion, and it was based on an apparently incorrect
> assumption that they had a lot of things coming and going on their
> cloud. I think they've demonstrated at this point that (other issues
> aside) three is enough for them, given their environment, workload, and
> configuration.
>
> The problem with coming up with any sort of metric that will apply to
> everyone is that it's highly variable. If you have 250 compute nodes and
> never create or destroy any instances, you'll be able to get away with
> *many* fewer conductors than if you have a very active cloud. Similarly,
> during a live upgrade (or following any upgrade where we do some online
> migration of data), your conductor load will be higher than normal. Of
> course, 4-core and 96-core conductor nodes aren't equal either.
>
> So, by all means, we should gather information on what people are doing
> successfully, but keep in mind that it depends *a lot* on what sort of
> workloads the cloud is supporting.
>
> --Dan
>



-- 

Best regards,

Dina Belova

Software Engineer

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

[Openstack-operators] [Nova] Support for server groups in cells v1

[Mike Dorman]

We recently patched Nova for support of server groups under cells v1.  It’s 
pretty rudimentary, but it works.

For anyone that’s interested, the patch is here:  
https://gist.github.com/misterdorm/5e9513bb1211b49e551c and I did a short 
write-up with some details at 
http://www.dorm.org/blog/nova-cells-v1-support-for-server-groups/

Mike

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

Re: [Openstack-operators] How to install magnum?

[JJ Asghar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/3/15 11:48 AM, Mike Perez wrote:
> On 18:51 Oct 28, Mike Perez wrote:
>> On 12:35 Oct 28, JJ Asghar wrote:
>>> On 10/28/15 10:35 AM, Mike Perez wrote:
 On 14:09 Oct 16, hittang wrote:
> Hello,everynoe. Can anybody help me for installing magnum?
> I have an openstack installtion,which has one controller
> node, one network node, and server computes node. Now, I
> want to install magnum, and  to manage docker containers
> with.
 
 I was not able to find this information in the Magnum wiki
 [1], except for the developer quick start. Doing a quick
 search, other related threads point to the dev docs for
 installation, which is developer centric.
 
 Adrian, is this something missing in documentation, or did we
 miss it?
 
 [1] - https://wiki.openstack.org/wiki/Magnum
 
>>> 
>>> Yep, this would be awesome. It's neat to see the integrations
>>> with DevStack, but getting it to work in a "prod" environment
>>> seems confusing at best.
>>> 
>>> I've attempted a couple times now, and failed each one. I'm
>>> more then willing to help debug/QA the docs that yall decide to
>>> put together.
>> 
>> Since we're doing so much talk about Magnum in Keynotes for the
>> Tokyo OpenStack summit, and there are install confusion, we
>> should probably work on that. I have raised this in the next
>> meeting [1], which I will bring up this thread in.
>> 
>> [1] -
>> https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-11-03_1600_UTC
>
>> 
> During the Magnum meeting today [1] it seems like this was
> previously discussed at the last Magnum midcycle to improve this
> documentation in the Mitaka release [2].
> 
> [1] -
> http://eavesdrop.openstack.org/meetings/containers/2015/containers.2015-11-03-16.01.log.html#l-150
>
> 
[2] - https://etherpad.openstack.org/p/magnum-mitaka-summit-meetup
> 


Just too keep track of this, has there been any progress? Is there any
review or anything we can watch?



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

iQIcBAEBCgAGBQJWTi6VAAoJEDZbxzMH0+jT9ngP/2LuzK3goGPll1FqeYeyDtA3
7BCnYmlwsYy+TvGYYVkWJGT6UN9O/m6acvOI2hADxMLDA05XEwjDa1kxbmx0P/Rk
tOgIw4g1xJNoXERIepI6gsEEbX01l55AjQYQFNhwmSFkB81SBoUfhIBiONHE4Zkj
tnDKc692+TyEsRfWHUa5bcx8LqYEWP+QdUfbDWdey/MpjX8oBugkg9npZKcKmnw1
zONZqP+JZFHZTvPRKH3hfhBWW384dfnMWR5mYB6ugE5r6cMzU1SVYgG8QvR4htlE
HOmo8fpLPztB58Ez/ZwFXyzauV5Pl1BazLy9p6eg9770iT+oPkG5DrpAwldOklaW
X/r5+7bahv8LDLVvIfqF9M76Cn5zcPU6Z/aJ4HGaKhPmHtWsL3M06PAsbeDS1EnX
wF73+gLlKKPO3AiVuFaW3Oa1iInqp7VJgiYyXISZNBU9odlTJvyvSm9/3deewea/
zmKHDd5vPsAc2TFp0S/Z7KEYTltbM00C4E/9+uWsk3NX5vUNWbqVFNUAqaRiRRVt
R8brO3MjlabRRwrlKABFK8amkK6j8gBqCdcYhSZ00y+iDqH67ThEguV/Mjh4M95J
dlwQdi6WfjxRggoLnDX4HAn/T4k/6+31EGPVhGQT8oNWO3mJbN7ke4Mfms4jdhLg
4rw1gJH4k9v8ca/7iDFW
=oATE
-END PGP SIGNATURE-

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

Re: [Openstack-operators] [openstack-dev] [all]Can we get some sanity in the Neutron logs please?

[Rochelle Grober]

Thanks both Armando and Matt!

I am cross posting this to the operators' list (as the main post -- operators, 
simple reply and no spam to dev).

The logging tag should be a tag in all projects.  I'm glad it's already there 
in Neutron.  And, this sort of feedback is exactly what we need operators and 
gate debuggers to provide when they hit stuff in the logs that is either 
classified at the wrong level (e.g., warning instead of info), is too verbose, 
generates a traceback rather than an error, or is too chatty, happens too often.

Please file these bugs to the appropriate projects and tag them "logging".  
Generally, these are easy fixes, or are "while you're in there" fixes while a 
bug is being addressed, so reporting them will most often get them fixed 
quickly.  I know that doesn't help the Ops folks as much as the developers, but 
it will help the developers when they upgrade to releases the logging has been 
fixed in.

These sorts of issues are major maintainability issues for operators, so a 
focus on this for the Mitaka release will help make it a release operators want 
to upgrade to :-)

Thanks for the ear and for the help with debugging OpenStack issues by 
improving the signal to noise ratio.

--Rocky

From: Armando M. [mailto:arma...@gmail.com]
Sent: Tuesday, November 10, 2015 11:39 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Can we get some sanity in the Neutron logs please?



On 10 November 2015 at 11:12, Matt Riedemann 
> wrote:


On 11/10/2015 1:10 PM, Matt Riedemann wrote:


On 11/10/2015 12:51 PM, Armando M. wrote:


On 10 November 2015 at 10:33, Matt Riedemann 

>> wrote:

Let me qualify by saying I'm not a Neutron person.

We know that gate-tempest-dsvm-neutron-full is failing hard as of
the last 24 hours [1].

An error that's been showing up in tempest runs with neutron a lot
is:

"AssertionError: 0 == 0 : No IPv4 addresses found in: []"

So checking logstash [2] it's hitting a lot. It's only recent
because that failure message is new to Tempest in the last day or
so, but it has a lot of hits, so whatever it is, it's failing a lot.

So the next step is usually digging into service logs looking for
errors. I check the q-svc logs first. Not many errors but a
bazillion warnings for things not found (networks and devices). [3]

For example:

2015-11-10 17:13:02.542 WARNING neutron.plugins.ml2.rpc
[req-15a73753-1512-4689-9404-9658a0cd0c09 None None] Device
aaa525be-14eb-44a5-beb0-ed722896be93 requested by agent
ovs-agent-devstack-trusty-rax-iad-5785199 not found in database

2015-11-10 17:14:17.754 WARNING neutron.api.rpc.handlers.dhcp_rpc
[req-3d7e9848-6151-4780-907f-43f11a2a8545 None None] Network
b07ad9b2-e63e-4459-879d-3721074704e5 could not be found, it might
have been deleted concurrently.

Are several hundred of these warnings useful to an operator trying
to debug a problem? The point of the CI gate testing is to try and
simulate a production cloud environment. When something goes wrong,
you check the logs. With the amount of warning/error level logging
that is in the neutron logs, finding a real problem is like looking
for a needle in a haystack. Since everything is async, 404s are
expected when racing to delete a resource and they should be handled
gracefully.

Anyway, the server log isn't useful so I go digging in the agent
logs and stacktraces there are aplenty. [4]

Particularly this:

"Exception: Port tapcea51630-e1 is not ready, resync needed"

That's due to a new change landing in the last 24 hours [5]. But the
trace shows up over 16K times since it landed [6].

Checking the code, it's basically a loop processing events and when
it hits an event it can't handle, it punts (breaking the loop so you
don't process the other events after it - which is a bug), and the
code that eventually handles it is just catching all Exception and
tracing them out assuming they are really bad.

At this point, as a non-neutron person, i.e. not well versed in the
operations of neutron or how to debug it in great detail, I assume
something is bad here but I don't really know - and the logs are so
full of noise that I can't distinguish real failures.

I don't mean to pick on this particular change, but it's a good
example of a recent thing.

I'd like to know if this is all known issue or WIP type stuff. I've
complained about excessively noisey neutron logs in channel before
and I'm usually told that they are either necessary (for whatever
reason) or that rather than complain about the verbosity, I should
fix the race that is causing it - which is not 

Re: [Openstack-operators] [Scale][Performance] / compute_nodes ratio experience

[Rochelle Grober]

Sorry this doesn't thread properly, but cut and pasted out of the digest...



> As providing OpenStack community with understandable recommendations

> and instructions on performant OpenStack cloud deployments is part of

> Performance Team mission, I'm kindly asking you to share your

> experience on safe cloud deployment ratio between various types of

> nodes you're having right now and the possible issues you observed (as

> an example: discussed GoDaddy's cloud is having 3 conductor boxes vs

> 250 computes in the cell, and there was an opinion that it's simply

> not enough and that's it).



That was my opinion, and it was based on an apparently incorrect assumption 
that they had a lot of things coming and going on their cloud. I think they've 
demonstrated at this point that (other issues

aside) three is enough for them, given their environment, workload, and 
configuration.



This information is great for building rules of thumb, so to speak.  GoDaddy 
has an example configuraton that is adequate for low frequency 
construct/destruct (low number of vm create/destroy) cloud architectures.  This 
provides a lower bounds and might be representative of a lot of enterprise 
cloud deployments.



The problem with coming up with any sort of metric that will apply to everyone 
is that it's highly variable. If you have 250 compute nodes and never create or 
destroy any instances, you'll be able to get away with

*many* fewer conductors than if you have a very active cloud. Similarly, during 
a live upgrade (or following any upgrade where we do some online migration of 
data), your conductor load will be higher than normal. Of course, 4-core and 
96-core conductor nodes aren't equal either.



And here we have another rule of thumb, but no numbers put to it yet.  If you 
have a low frequency construct/destruct cloud model, you will need to 
temporarily increase your number of conductors by {x amount OR x%} when 
performing OpenStack live upgrades.



So, by all means, we should gather information on what people are doing 
successfully, but keep in mind that it depends *a lot* on what sort of 
workloads the cloud is supporting.



Right, but we can start applying fuzzy logic (the human kind, not machine) and 
get a better understanding of working configurations and *why* they work, then 
start examining where the transition states between configurations are.   You 
need data before you can create information ;-)



--Rocky


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

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

[Joe Topjian]

Hi Adam,

I've seen this happen due to permission issues. Regardless of running with
sudo, upstart is dropping to the "nova" user.

I usually debug this by setting a shell on the nova user, sudoing/su'ing to
nova, then running nova-compute from there. It should die with an error
message of the cause.

Hope that helps,
Joe
On Nov 19, 2015 3:35 PM, "Adam Lawson"  wrote:

> 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
>
>
___
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-operators] [openstack-dev] [openstack-ansible] Fedora/CentOS/other Support

[Major Hayden]

On 11/18/2015 04:19 AM, Jesse Pretorius wrote:
> The current community has done some research into appropriate patterns to use 
> and has a general idea of how to do it - but in order to actually execute 
> there need to be enough people who commit to actually maintaining the work 
> once it's done. We don't want to carry the extra code if we don't also pick 
> up extra contributors to maintain the code.

Should there be a concept of primary and secondary operating systems supported 
by openstack-ansible?  I'm thinking something similar to the tiers of 
hypervisors in OpenStack where some are tested heavily with gating while others 
have a lighter amount of testing.

We might be able to have something along the lines of:

  * Primary OS: Used in gate checks, heavily tested
  * Secondary OS: Not used in gate checks, lightly tested
  * Tertiary OS: Support in WIP state, not tested

--
Major Hayden

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

Re: [Openstack-operators] Migrating from nova-network to Neutron in Kilo?

[Tom Fifield]

On 19/11/15 08:38, Ned Rhudy (BLOOMBERG/ 731 LEX) wrote:

Hello operator friends,

We're laying out our 2016 roadmaps now, and one of the projects the
Bloomberg cloud team would like to undertake is migrating from our
legacy nova-network setup to Neutron. Our current networking is pretty
simple, with tenancies getting /25s carved out from a single large
subnet for fixed IPs and floating IPs being assigned from another large
subnet as first-come-first serve. While there's room for improvement, we
are totally fine with the initial Neutron migration replicating as close
to the same user experience as possible; our primary interest now is
just getting to Neutron, then taking on larger overhauls once we're free
to navigate in the Neutron universe.

That being said, there's very little material out there on people
successfully pulling off nova-network to Neutron migrations. References
on the docs wiki to Neutron migration materials are unfinished and
mostly lead to some year-old abandoned changes in Gerrit, and Google
inexorably leads to the same eBay presentation about migrating from
Folsom nova-network to Havana Neutron+NSX SDN. It has some interesting
and useful information, but it's also about old releases and involved a
lot of additional changes (Folsom->Havana, integrating NSX, etc.),
whereas we're just interested in moving from nova-network to Neutron in
place on our Kilo clusters and carrying as little else along for the
ride as possible.

Therefore, I come to you all to ask for battle stories from anyone who's
gone up against migrating to Neutron and lived to tell the tale. Do your
users roundly curse you and speak angrily of the Great Networking
Betrayal, where you lost all their floating IPs and security groups, or
are you celebrated as the great warlord who slew the diabolical iptables
NAT monster and brought peace and stability (and LBaaS) to cloud
networks everywhere?


I heard NeCTAR used this script 
(https://github.com/NeCTAR-RC/novanet2neutron ) with some success to do 
a live nova-net to neutron, which might have been Juno or Kilo release.



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

Re: [Openstack-operators] [openstack-operators][osops] tools-contrib is open for business!

[Erik McCormick]

+1 for the "unless otherwise stated" bit. I seem to recall some
non-standard requirements from the likes of HP. Apache should be a good
default though.

-Erik
On Nov 19, 2015 11:31 PM, "Matt Fischer"  wrote:

> Is there a reason why we can't license the entire repo with Apache2 and if
> you want to contribute you agree to that? Otherwise it might become a bit
> of a nightmare.  Or maybe at least do "Apache2 unless otherwise stated"?
>
> On Thu, Nov 19, 2015 at 9:17 PM, Joe Topjian  wrote:
>
>> Thanks, JJ!
>>
>> It looks like David Wahlstrom submitted a script and there's a question
>> about license.
>>
>> https://review.openstack.org/#/c/247823/
>>
>> Though contributions to contrib do not have to follow a certain coding
>> style, can be very lax on error handling, etc, should they at least mention
>> a license? Thoughts?
>>
>>
>> On Wed, Nov 18, 2015 at 2:38 PM, JJ Asghar  wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>>
>>>
>>> Hey everyone,
>>>
>>> I just want to announce that tools-contrib[1] is now open for
>>> submissions. Please take a moment to read the README[2] to get
>>> yourself familiar with it. I'm hoping to see many scripts and tools
>>> start to trickle in.
>>>
>>> Remember, by committing to this repository, even a simple bash script
>>> you wrote, you're helping out your future Operators. This is for your
>>> future you, and our community, so treat em nice ;)!
>>>
>>> [1]: https://github.com/openstack/osops-tools-contrib
>>> [2]:
>>> https://github.com/openstack/osops-tools-contrib/blob/master/README.rst
>>>
>>> - --
>>> 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
>>>
>>> iQIcBAEBCgAGBQJWTO+/AAoJEDZbxzMH0+jTRxQQAK2DJdCTnihR7YJhJAXgbdIn
>>> NZizqkK4lEhnfdis0XZJekofAib7NytuAtTuWUQOTLQaFv02UAnMqSyX5ofX42PZ
>>> mGaLtZ452k+EhdeJprO5254fka8VSaRvFOZUJg0K0QjZrj5qFwtG0T1yqVBBCQmI
>>> wdUkxBB/cL8M0Ve6LaQNS4vmx03ZC81FLEtVX2O62EV8FrP8sxuXc7XDTCRbLnhR
>>> rb2HJC7R9/AZtr2gjwr7id714QFEEAgCKca79l+vsaE3VRfy+KbHsKqY9vPrxPVn
>>> qqXLQOm8ZDgXedjxYraCDBbay/FQqVrsEt/0RiAKrtAIRbLm2ZkiR/XL6J3BtNzi
>>> 2sNt12m/VkrMv9zWUT/8oqiBb73eg3TbUipVeKmh4TD12KK16EYMSF+mH9T7DY2Z
>>> eP2AT6XEs+BDohP+I3L7WM5r/AKl9r40ulLEqRR7y+jcn5qwAOEb+UzUpna4wTt/
>>> mZD5UNNemoN5h2P4eMPpfnZnpNcy4Qe/qoohZdAov4Gvdm3tmbG9jIzUKF3Q9Av5
>>> Uqpe6gUcp3Qd2EaKYGR47B2f+QRLlTs9Sk5lLBJSyOxpA53KcK9125fS0YM6VMVQ
>>> wETlxAggnmt4diwSoJt8VSYrqXlieo7eHkjv/s4hSGIcYBqtkCPZnNPliJmvMmfh
>>> s/wsl6ICrB7oe55ghDbM
>>> =EWDz
>>> -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
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-operators][osops] tools-contrib is open for business!

[Joe Topjian]

Thanks, JJ!

It looks like David Wahlstrom submitted a script and there's a question
about license.

https://review.openstack.org/#/c/247823/

Though contributions to contrib do not have to follow a certain coding
style, can be very lax on error handling, etc, should they at least mention
a license? Thoughts?


On Wed, Nov 18, 2015 at 2:38 PM, JJ Asghar  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
> Hey everyone,
>
> I just want to announce that tools-contrib[1] is now open for
> submissions. Please take a moment to read the README[2] to get
> yourself familiar with it. I'm hoping to see many scripts and tools
> start to trickle in.
>
> Remember, by committing to this repository, even a simple bash script
> you wrote, you're helping out your future Operators. This is for your
> future you, and our community, so treat em nice ;)!
>
> [1]: https://github.com/openstack/osops-tools-contrib
> [2]:
> https://github.com/openstack/osops-tools-contrib/blob/master/README.rst
>
> - --
> 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
>
> iQIcBAEBCgAGBQJWTO+/AAoJEDZbxzMH0+jTRxQQAK2DJdCTnihR7YJhJAXgbdIn
> NZizqkK4lEhnfdis0XZJekofAib7NytuAtTuWUQOTLQaFv02UAnMqSyX5ofX42PZ
> mGaLtZ452k+EhdeJprO5254fka8VSaRvFOZUJg0K0QjZrj5qFwtG0T1yqVBBCQmI
> wdUkxBB/cL8M0Ve6LaQNS4vmx03ZC81FLEtVX2O62EV8FrP8sxuXc7XDTCRbLnhR
> rb2HJC7R9/AZtr2gjwr7id714QFEEAgCKca79l+vsaE3VRfy+KbHsKqY9vPrxPVn
> qqXLQOm8ZDgXedjxYraCDBbay/FQqVrsEt/0RiAKrtAIRbLm2ZkiR/XL6J3BtNzi
> 2sNt12m/VkrMv9zWUT/8oqiBb73eg3TbUipVeKmh4TD12KK16EYMSF+mH9T7DY2Z
> eP2AT6XEs+BDohP+I3L7WM5r/AKl9r40ulLEqRR7y+jcn5qwAOEb+UzUpna4wTt/
> mZD5UNNemoN5h2P4eMPpfnZnpNcy4Qe/qoohZdAov4Gvdm3tmbG9jIzUKF3Q9Av5
> Uqpe6gUcp3Qd2EaKYGR47B2f+QRLlTs9Sk5lLBJSyOxpA53KcK9125fS0YM6VMVQ
> wETlxAggnmt4diwSoJt8VSYrqXlieo7eHkjv/s4hSGIcYBqtkCPZnNPliJmvMmfh
> s/wsl6ICrB7oe55ghDbM
> =EWDz
> -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-operators][osops] tools-contrib is open for business!

[Matt Fischer]

Is there a reason why we can't license the entire repo with Apache2 and if
you want to contribute you agree to that? Otherwise it might become a bit
of a nightmare.  Or maybe at least do "Apache2 unless otherwise stated"?

On Thu, Nov 19, 2015 at 9:17 PM, Joe Topjian  wrote:

> Thanks, JJ!
>
> It looks like David Wahlstrom submitted a script and there's a question
> about license.
>
> https://review.openstack.org/#/c/247823/
>
> Though contributions to contrib do not have to follow a certain coding
> style, can be very lax on error handling, etc, should they at least mention
> a license? Thoughts?
>
>
> On Wed, Nov 18, 2015 at 2:38 PM, JJ Asghar  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>>
>> Hey everyone,
>>
>> I just want to announce that tools-contrib[1] is now open for
>> submissions. Please take a moment to read the README[2] to get
>> yourself familiar with it. I'm hoping to see many scripts and tools
>> start to trickle in.
>>
>> Remember, by committing to this repository, even a simple bash script
>> you wrote, you're helping out your future Operators. This is for your
>> future you, and our community, so treat em nice ;)!
>>
>> [1]: https://github.com/openstack/osops-tools-contrib
>> [2]:
>> https://github.com/openstack/osops-tools-contrib/blob/master/README.rst
>>
>> - --
>> 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
>>
>> iQIcBAEBCgAGBQJWTO+/AAoJEDZbxzMH0+jTRxQQAK2DJdCTnihR7YJhJAXgbdIn
>> NZizqkK4lEhnfdis0XZJekofAib7NytuAtTuWUQOTLQaFv02UAnMqSyX5ofX42PZ
>> mGaLtZ452k+EhdeJprO5254fka8VSaRvFOZUJg0K0QjZrj5qFwtG0T1yqVBBCQmI
>> wdUkxBB/cL8M0Ve6LaQNS4vmx03ZC81FLEtVX2O62EV8FrP8sxuXc7XDTCRbLnhR
>> rb2HJC7R9/AZtr2gjwr7id714QFEEAgCKca79l+vsaE3VRfy+KbHsKqY9vPrxPVn
>> qqXLQOm8ZDgXedjxYraCDBbay/FQqVrsEt/0RiAKrtAIRbLm2ZkiR/XL6J3BtNzi
>> 2sNt12m/VkrMv9zWUT/8oqiBb73eg3TbUipVeKmh4TD12KK16EYMSF+mH9T7DY2Z
>> eP2AT6XEs+BDohP+I3L7WM5r/AKl9r40ulLEqRR7y+jcn5qwAOEb+UzUpna4wTt/
>> mZD5UNNemoN5h2P4eMPpfnZnpNcy4Qe/qoohZdAov4Gvdm3tmbG9jIzUKF3Q9Av5
>> Uqpe6gUcp3Qd2EaKYGR47B2f+QRLlTs9Sk5lLBJSyOxpA53KcK9125fS0YM6VMVQ
>> wETlxAggnmt4diwSoJt8VSYrqXlieo7eHkjv/s4hSGIcYBqtkCPZnNPliJmvMmfh
>> s/wsl6ICrB7oe55ghDbM
>> =EWDz
>> -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-operators][osops] tools-contrib is open for business!

[Joe Topjian]

Unless there's a reason why we *can't* do something like that (I have no
idea why, but I never assume anything when it comes to things like
licensing :) then I'm in favor of updating the README to state "Your code
will be licensed under Apache 2 unless you mention otherwise."

On Thu, Nov 19, 2015 at 9:37 PM, Erik McCormick 
wrote:

> +1 for the "unless otherwise stated" bit. I seem to recall some
> non-standard requirements from the likes of HP. Apache should be a good
> default though.
>
> -Erik
> On Nov 19, 2015 11:31 PM, "Matt Fischer"  wrote:
>
>> Is there a reason why we can't license the entire repo with Apache2 and
>> if you want to contribute you agree to that? Otherwise it might become a
>> bit of a nightmare.  Or maybe at least do "Apache2 unless otherwise stated"?
>>
>> On Thu, Nov 19, 2015 at 9:17 PM, Joe Topjian  wrote:
>>
>>> Thanks, JJ!
>>>
>>> It looks like David Wahlstrom submitted a script and there's a question
>>> about license.
>>>
>>> https://review.openstack.org/#/c/247823/
>>>
>>> Though contributions to contrib do not have to follow a certain coding
>>> style, can be very lax on error handling, etc, should they at least mention
>>> a license? Thoughts?
>>>
>>>
>>> On Wed, Nov 18, 2015 at 2:38 PM, JJ Asghar  wrote:
>>>
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512


 Hey everyone,

 I just want to announce that tools-contrib[1] is now open for
 submissions. Please take a moment to read the README[2] to get
 yourself familiar with it. I'm hoping to see many scripts and tools
 start to trickle in.

 Remember, by committing to this repository, even a simple bash script
 you wrote, you're helping out your future Operators. This is for your
 future you, and our community, so treat em nice ;)!

 [1]: https://github.com/openstack/osops-tools-contrib
 [2]:
 https://github.com/openstack/osops-tools-contrib/blob/master/README.rst

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

 iQIcBAEBCgAGBQJWTO+/AAoJEDZbxzMH0+jTRxQQAK2DJdCTnihR7YJhJAXgbdIn
 NZizqkK4lEhnfdis0XZJekofAib7NytuAtTuWUQOTLQaFv02UAnMqSyX5ofX42PZ
 mGaLtZ452k+EhdeJprO5254fka8VSaRvFOZUJg0K0QjZrj5qFwtG0T1yqVBBCQmI
 wdUkxBB/cL8M0Ve6LaQNS4vmx03ZC81FLEtVX2O62EV8FrP8sxuXc7XDTCRbLnhR
 rb2HJC7R9/AZtr2gjwr7id714QFEEAgCKca79l+vsaE3VRfy+KbHsKqY9vPrxPVn
 qqXLQOm8ZDgXedjxYraCDBbay/FQqVrsEt/0RiAKrtAIRbLm2ZkiR/XL6J3BtNzi
 2sNt12m/VkrMv9zWUT/8oqiBb73eg3TbUipVeKmh4TD12KK16EYMSF+mH9T7DY2Z
 eP2AT6XEs+BDohP+I3L7WM5r/AKl9r40ulLEqRR7y+jcn5qwAOEb+UzUpna4wTt/
 mZD5UNNemoN5h2P4eMPpfnZnpNcy4Qe/qoohZdAov4Gvdm3tmbG9jIzUKF3Q9Av5
 Uqpe6gUcp3Qd2EaKYGR47B2f+QRLlTs9Sk5lLBJSyOxpA53KcK9125fS0YM6VMVQ
 wETlxAggnmt4diwSoJt8VSYrqXlieo7eHkjv/s4hSGIcYBqtkCPZnNPliJmvMmfh
 s/wsl6ICrB7oe55ghDbM
 =EWDz
 -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
>>
>>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Spec Review Time :)

[Tom Fifield]

Ops,

In case you were interested in going through specs for your favourite 
project (or feature), many of them are happening around this time.


eg nova is at

https://review.openstack.org/#/q/status:open+AND+project:openstack/nova-specs,n,z

and you can find other project repos by changing nova in that URL.


You can login with your launchpad account and make comments. Be sure to 
note you're an op!



Regards,


Tom


 Forwarded Message 
Subject: [openstack-dev] [nova] Today, November 19 is Nova Spec Review Day
Date: Thu, 19 Nov 2015 11:40:12 +
From: John Garbutt 
Reply-To: OpenStack Development Mailing List (not for usage questions) 


To: OpenStack Development Mailing List 

Hi all,

A (late) reminder that today is Spec Review day:
https://wiki.openstack.org/wiki/Nova/Mitaka_Release_Schedule

I encourage everyone to help review the specs we still have up for review.
Any questions, as normal, chat in #openstack-nova in IRC.

If you are busy today, or today as already happened and you forgot,
feel free to pick another day in the next few days as your personal
Spec Review day.

Dec 3 is Nova spec freeze, for all specs, priority or non-priority.
There will be a very limited exception process, as normal.
Its likely to only include things that had a +2 before the deadline.

Current nova-spec stats (from reviews.johnthetubaguy.com):
Total Open Reviews: 104
Waiting on Reviewer: 45

Thanks,
John

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

Re: [Openstack-operators] [openstack-dev] [openstack-ansible] Fedora/CentOS/other Support

[Kevin Carter]

I don't believe we should have a class system in the OS's that we choose 
to support. If we're going to bring in a new OS I think we should first 
bring it in using non-voting jobs however once all of the bits have been 
finalized the supported OS should be able to pass the same sets of tests 
as everything else. Now, we may run into various applications that may 
not be compatible or available on different distros, which is fine, but 
in that case we should call out the deficiencies marking a specific job 
as non-voting until we can see about resolving the issues. I would like 
to avoid creating second class operating systems within OSA if at all 
possible.

--

Kevin Carter
IRC: cloudnull

On 11/19/2015 09:21 AM, Major Hayden wrote:
> On 11/18/2015 04:19 AM, Jesse Pretorius wrote:
>> The current community has done some research into appropriate patterns to 
>> use and has a general idea of how to do it - but in order to actually 
>> execute there need to be enough people who commit to actually maintaining 
>> the work once it's done. We don't want to carry the extra code if we don't 
>> also pick up extra contributors to maintain the code.
>
> Should there be a concept of primary and secondary operating systems 
> supported by openstack-ansible?  I'm thinking something similar to the tiers 
> of hypervisors in OpenStack where some are tested heavily with gating while 
> others have a lighter amount of testing.
>
> We might be able to have something along the lines of:
>
>* Primary OS: Used in gate checks, heavily tested
>* Secondary OS: Not used in gate checks, lightly tested
>* Tertiary OS: Support in WIP state, not tested
>
> --
> Major Hayden
>
> ___
> 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] setting dhcp_domain per project

[Clayton O'Neill]

I believe this is coming in Liberty,  based on this talk:
https://www.openstack.org/summit/tokyo-2015/videos/presentation/get-your-instance-by-name-integration-of-nova-neutron-and-designate

On Thu, Nov 19, 2015 at 7:10 AM, Davíð Örn Jóhannsson 
wrote:

> I've been looking into changing the search domain provided by the dhcp
> service that is propagated to /etc/resolv.conf via dhcp in openstack.
>
>
> The documentation points to changing dhcp_domain in dhcp_agent.ini but
> would that not result in all projects and all dhcp agents in openstack
> sending out the same search domain.
>
>
> I need to be able to configure for example
>
> example.com
>
> dev.example.com
>
>
> in different projects, is this not possible for example on a per dhcp per
> network in horizon or something like that?
>
> ___
> 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