Re: [openstack-dev] [horizon][heat] heat-dashboard is ready for Horizon team's review

[Kaz Shinohara]

Hi Akihiro,


Thanks for your quick response!

As you requested, we will check & update your patch to slit out heat
support from Horizon repo.
https://review.openstack.org/#/c/523402/

Also replied for your comment in our etherpad, please kindly check.
https://etherpad.openstack.org/p/heat-dashboard-review-point

Regards,
Kaz

2017-11-28 21:08 GMT+09:00 Akihiro Motoki :
> Hi Kaz,
>
> Good hear the good progress of heat-dashboard. Thanks.
>
> I created a blueprint in horizon to track the effort (mainly in
> horizon side) and assign it to you:
> https://blueprints.launchpad.net/horizon/+spec/heat-dashboard-split-out
> I also left comments in your etherpad.
>
> I think it is time to prepare a patch which drops heat-dashboard code
> from horizon and test the new dashboard with it. Could you propose the
> patch?
>
> Thanks,
> Akihiro
>
>
> 2017-11-28 16:32 GMT+09:00 Kaz Shinohara :
>> Hi Horizon team,
>>
>>
>> As I talked with Rob & Ying in Sydney, now heat-dashboard repo is
>> ready, please kindly review it.
>>
>> http://git.openstack.org/cgit/openstack/heat-dashboard
>>
>> Also we described points to be clarified in this review, if you find
>> anything to be noted/fixed, please feel free to put your comment on
>> this etherpad, we will respond to them.
>>
>> https://etherpad.openstack.org/p/heat-dashboard-review-point
>>
>> We are planning to land heat-dashboard in queens-2, hopefully we will
>> fix any issue until then.
>>
>> Your cooperation will be highly appreciated.
>>
>> Regards,
>> Kaz Shinohara
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all] Dublin PTG format

[Masayuki Igawa]

On 11/28, Ghanshyam Mann wrote:
> Mon-Tue/Wed-Fri works as most suitable format. There are always
> conflict for many of us but that can be adjusted by working with team
> planning.
> 
> Another thing can help is to give flexibility to team to have team
> topic even on Mon-Tue, which mean team need dedicated room on Mon-Tue
> also. For example, if QA want to discuss few of the topic on Mon-Tue
> and have Code sprint/Help room etc on rest of week. This can help me
> or other QA members to join other team discussion on Wed-Fri. But that
> is based on special request and team requirement of number of topics
> to discuss.
> 
> morning/afternoon format will be little hectic and less productive due
> to changing rooms and topic etc, at least for me :)

Yeah, I totally agree with that. Regarding to the QA team members,
most of members are not dedicated to the upstream work. So, if we can
concentrate on it during the rest of 3 days, the days could be really
productive. And I felt it in the past PTG.

-- Masayuki


> 
> -gmann
> 
> 
> On Mon, Nov 27, 2017 at 7:58 PM, Thierry Carrez  wrote:
> > Hi everyone,
> >
> > We are in the final step in the process of signing the contract with the
> > PTG venue. We should be able to announce the location this week !
> >
> > So it's time to start preparing. We'll have 5 days, like in Denver. One
> > thing we'd like to change for this round is to give a bit more
> > flexibility in the topics being discussed, especially in the first two days.
> >
> > In Denver, we selected a number of general "themes" and gave them all a
> > room for 2 days on Monday-Tuesday. Then all the "teams" that wanted a
> > project team meeting could get a room for 2 or 3 days on
> > Wednesday-Friday. That resulted in a bit of flux during the first two
> > days, with a lot of empty rooms as most of the themes did not really
> > need 2 days, and a lot of conflicts were present.
> >
> > For Dublin, the idea would be to still predetermine topics (themes and
> > teams) and assign them rooms in advance. But we would be able to assign
> > smaller amounts of time (per half-day) based on the expressed needs.
> > Beyond those pre-assigned themes/teams we'd add flexibility for other
> > groups to book the remaining available rooms in 90-min slots on-demand.
> > A bit like how we did reservable rooms in the past, but more integrated
> > with the rest of the event. It would all be driven by the PTGbot, which
> > would show which topic is being discussed in which room, in addition to
> > the current discussion subject within each topic.
> >
> > We have two options in how we do the split for predetermined topics. We
> > used to split the week between Mon-Tue (themes) and Wed-Fri (teams). The
> > general idea there was to allow some people only interested in a team
> > meeting to only attend the second part of the week. However most people
> > attend all 5 days, and during event feedback some people suggested that
> > "themes" should be in the mornings and "teams" in the afternoons (and
> > all Friday).
> >
> > What would be your preference ? The Mon-Tue/Wed-Fri split means less
> > room changes, which make it easier on the events team. So all else being
> > equal we'd rather keep it the way it is, but I'm open to changing it if
> > attendees think it's a good idea.
> >
> > If you have any other suggestion (that we could implement in the 3
> > months we have between now and the event) please let me know :)
> >
> > --
> > 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

-- 


signature.asc
Description: PGP signature
__
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] [charms] evolving the ha interface type

[Billy Olsen]

On 11/28/2017 01:50 PM, Dmitrii Shcherbakov wrote:

Hi James,

The side effect of using JSON is that we will lose type information:

In [0]: json.loads(json.dumps([{1: 2}]))
Out[0]: [{'1': 2}]

In [1]: ast.literal_eval(repr([{1: 2}]))
Out[1]: [{1: 2}]


I'm not sure this is really an issue for the hacluster interface. To my 
knowledge, all of the keys used for resources today are strings defining 
the pacemaker resource options (clones, groups, colocation options etc). 
The hacluster charm simply formats crm commands with the name/value 
pairs anyways [0]. It is true that type information is lost, but I don't 
think its an issue for this interface.


[0] - 
https://github.com/openstack/charm-hacluster/blob/master/hooks/hooks.py#L314




This is a hard requirement in the JSON spec:

https://tools.ietf.org/html/rfc7159#section-4
"An object structure is represented as a pair of curly brackets
surrounding zero or more name/value pairs (or members).  A name is
a string. "

I wonder if we could use some type-aware serialization format but I do
not have any suggestions without trade-offs because we need to keep in
mind that, in general, charms may not be python charms, may run on
hosts with different protocol parsing libraries etc.

If we only cared about python I would suggest using "pickle" but this
is not universal and not human-readable:

https://docs.python.org/3/library/pickle.html#comparison-with-json
"JSON, by default, can only represent a subset of the Python built-in
types, and no custom classes; pickle can represent an extremely large
number of Python types"

JSON has an advantage of being readable as opposed to a binary protocol
so we can explore what's available in relation data by doing relation-
get without additional tools. It is also ubiquitous so we don't have to
worry about spec changes, parsing bugs and other potential problems.

Thanks for bringing this topic up.

Dmitrii Shcherbakov

__
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] [kolla] Ansiblize init-runonce script

[Jeffrey Zhang]

yes. it is not
​recommend to use in prod env, i never used this script. But
the reality is
lots users are using it, at least in the test environment.
and there are patches trying to make this script ​
idempotent
​ recently.​

2017年11月28日 23:28，"Sam Yaple" 写道：

> For what its worth, this init-runonce script was never meant for
> production usage. Ops *shouldn't* be running it like you suggest. It was
> historically for use in the gate and a quick-n-dirty environment setup for
> testing.
>
> If you want to get into writing operations scripts, thats your
> prerogative, but it was discussed before and mostly considered a bad idea.
>
> Thanks,
> SamYaple
>
>
>
>  Original Message 
> Subject: Re: [openstack-dev] [kolla] Ansiblize init-runonce script
> Local Time: November 28, 2017 8:10 AM
> UTC Time: November 28, 2017 1:10 PM
> From: zhang.lei@gmail.com
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
>
> in my opinion,
>
>
> idempotent scrip
> t is very necessary.
> for several reason
>
> - there is already some idempotent logical in the script
> - it is common that this script failed by wrong configuration,
>   after fix the config,
> ops will want to run this script again.
>
> On Tue, Nov 28, 2017 at 7:14 PM, Paul Bourke 
> wrote:
>
>> I think this came up before at one stage. My position is I don't see the
>> need to ansible-ise small shell scripts. init-runonce is currently just an
>> easy to understand sequence of openstack commands provided to help people
>> test/demo their setups. Unless we want to make it more than that, i.e. make
>> it idempotent, customizable, etc. I don't see the need to wheel in Ansible.
>>
>> On 28/11/17 03:23, Jeffrey Zhang wrote:
>>
>>> hi
>>>
>>> check this [0]. I tried to convert it  to ansible playbooks.
>>>
>>> [0] https://review.openstack.org/523072
>>>
>>> On Tue, Nov 28, 2017 at 2:57 AM, Ravi Shekhar Jethani <
>>> rsjeth...@gmail.com > wrote:
>>>
>>> Hi,
>>>
>>> While exploring kolla-ansible I ran into a few issues with
>>> init-runonce script. This lead to following bugs and patches:
>>>
>>> https://launchpad.net/bugs/1732963 >> 32963>
>>> https://review.openstack.org/51
>>> 
>>> https://review.openstack.org/521190
>>> 
>>>
>>> But it was highlighted that instead of fixing/changing the
>>> script, 'ansibilzing' it would be the ideal solution.
>>> Hence I hereby formally propose the same.
>>>
>>> My thoughts:
>>> * Playbook Name: init-stack.yml
>>>
>>> * Playbook path can be:
>>> kolla-ansible/ansible/init-stack.yml
>>>
>>> * The play can be executed like:
>>> $ kolla-ansible init-stack -i 
>>>
>>> * The cirros test image should be downloaded in /tmp
>>>
>>> * What should be the behavior if the play is run multiple times
>>> against the same stack?
>>>- some error message OR
>>>- simply ignore the action
>>>
>>> Kindly provide suggestions.
>>>
>>> --
>>> Best Regards,
>>> Ravi J.
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> >> subscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Jeffrey Zhang
>>> Blog: http://xcodest.me 
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
>
>
> __
> 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: 

Re: [openstack-dev] [magnum] Questions about Caas with Magnum

[Sergio Morales Acuña]

Can you help explain or point me to more information about your comments on
this:

"For RBAC, you need 1.8 and with Pike you can get it. just by changing
one parameter." I checked the repo on github and RBAC was referenced only
in a comment.  No labels. What parameter?

"In fedora atomic 27 kubernetes etcd and flannel are removed from the
base image so running them in containers is the only way". I tried this on
my new Pike cloud but only kubernetes-* was running on containers. No signs
of etcd or flannel.  Do I need a special image of atomic 27? I can't find
the install process of etcd in the driver code (i'm using magnum 5.0.1).

Thanks for your help.

El mié., 22 nov. 2017 a las 5:30, Spyros Trigazis ()
escribió:

> Hi Sergio,
>
> On 22 November 2017 at 03:31, Sergio Morales Acuña 
> wrote:
> > I'm using Openstack Ocata and trying Magnum.
> >
> > I encountered a lot of problems but I been able to solved many of them.
>
> Which problems did you encounter? Can you be more specific? Can we solve
> them
> for everyone else?
>
> >
> > Now I'm curious about some aspects of Magnum:
> >
> > ¿Do I need a newer version of Magnum to run K8S 1.7? ¿Or I just need to
> > create a custom fedora-atomic-27? What about RBAC?
>
> Since Pike, magnum is running kubernetes in containers on fedora 26.
> In fedora atomic 27 kubernetes etcd and flannel are removed from the
> base image so running them in containers is the only way.
>
> For RBAC, you need 1.8 and with Pike you can get it. just by changing
> one parameter.
>
> >
> > ¿Any one here using Magnum on daily basis? If yes, What version are you
> > using?
>
> In our private cloud at CERN we have ~120 clusters with ~450 vms, we are
> running
> Pike and we use only the fedora atomic drivers.
>
> http://openstack-in-production.blogspot.ch/2017/01/containers-on-cern-cloud.html
> Vexxhost is running magnum:
> https://vexxhost.com/public-cloud/container-services/kubernetes/
> Stackhpc:
> https://www.stackhpc.com/baremetal-cloud-capacity.html
>
> >
> > ¿What driver is, in your opinion, better: Atomic or CoreOS? ¿Do I need to
> > upgrade Magnum to follow K8S's crazy changes?
>
> Atomic is maintained and supported much more than CoreOS in magnum.
> There wasn't much interest from developers for CoreOS.
>
> >
> > ¿Any tips on the CaaS problem?¿It's Magnum Ocata too old for this world?
>
> Magnum Ocata is not too old but it will eventually be since it misses the
> capability of running kubernetes on containers. Pike allows this option
> and can
> keep up with kubernetes easily.
>
> >
> > ¿Where I can found updated articles about the state of Magnum and it's
> > future?
>
> I did the project update presentation for magnum at the Sydney summit.
> https://www.openstack.org/videos/sydney-2017/magnum-project-update
>
> Chees,
> Spyros
>
> >
> > Cheers
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oaktree] Follow up to Multi-cloud Management in OpenStack Summit session

[Joshua Harlow]

Small side-question,

Why would this just be limited to openstack clouds?

Would it be?

Monty Taylor wrote:

Hey everybody!

https://etherpad.openstack.org/p/sydney-forum-multi-cloud-management

I've CC'd everyone who listed interest directly, just in case you're not
already on the openstack-dev list. If you aren't, and you are in fact
interested in this topic, please subscribe and make sure to watch for
[oaktree] subject headings.

We had a great session in Sydney about the needs of managing resources
across multiple clouds. During the session I pointed out the work that
had been started in the Oaktree project [0][1] and offered that if the
people who were interested in the topic thought we'd make progress best
by basing the work on oaktree, that we should bootstrap a new core team
and kick off some weekly meetings. This is, therefore, the kickoff email
to get that off the ground.

All of the below is thoughts from me and a description of where we're at
right now. It should all be considered up for debate, except for two
things:

- gRPC API
- backend implementation based on shade

As those are the two defining characteristics of the project. For those
who weren't in the room, justifications for those two characteristics are:

gRPC API


There are several reasons why gRPC.

* Make it clear this is not a competing REST API.

OpenStack has a REST API already. This is more like a 'federation' API
that knows how to talk to one or more clouds (similar to the kubernetes
federation API)

* Streaming and async built in

One of the most costly things in using the OpenStack API is polling.
gRPC is based on HTTP/2 and thus supports streaming and other exciting
things. This means an oaktree running in or on a cloud can do its
polling loops over the local network and the client can just either wait
on a streaming call until the resource is ready, or can fire an async
call and deal with it later on a notification channel.

* Network efficiency

Protobuf over HTTP/2 is a super-streamlined binary protocol, which
should actually be really nice for our friends in Telco land who are
using OpenStack for Edge-related tasks in 1000s of sites. All those
roundtrips add up at scale.

* Multi-language out of the box

gRPC allows us to directly generate consistent consumption libs for a
bunch of languages - or people can grab the proto files and integrate
those into their own build if they prefer.

* The cool kids are doing it

To be fair, Jay Pipes and I tried to push OpenStack to use Protobuf
instead of JSON for service-to-service communication back in 2010 - so
it's not ACTUALLY a new idea... but with Google pushing it and support
from the CNCF, gRPC is actually catching on broadly. If we're writing a
new thing, let's lean forward into it.

Backend implementation in shade
---

If the service is defined by gRPC protos, why not implement the service
itself in Go or C++?

* Business logic to deal with cloud differences

Adding a federation API isn't going to magically make all of those
clouds work the same. We've got that fairly well sorted out in shade and
would need to reimplement basically all of shade in other other language.

* shade is battle tested at scale

shade is what Infra's nodepool uses. In terms of high-scale API
consumption, we've learned a TON of lessons. Much of the design inside
of shade is the result of real-world scaling issues. It's Open Source,
so we could obviously copy all of that elsewhere - but why? It exists
and it works, and oaktree itself should be a scale-out shared-nothing
kind of service anyway.

The hard bits here aren't making API calls to 3 different clouds, the
hard bits are doing that against 3 *different* clouds and presenting the
results sanely and consistently to the original user.

Proposed Structure
==

PTL
---

As the originator of the project, I'll take on the initial PTL role.
When the next PTL elections roll around, we should do a real election.

Initial Core Team
-

oaktree is still small enough that I don't think we need to be super
protective - so I think if you're interested in working on it and you
think you'll have the bandwidth to pay attention, let me know and I'll
add you to the team.

General rules of thumb I try to follow on top of normal OpenStack
reviewing guidelines:

* Review should mostly be about suitability of design/approach. Style
issues should be handled by pep8/hacking (with one exception, see
below). Functional issues should be handled with tests. Let the machines
be machines and humans be humans.

* Use followup patches to fix minor things rather than causing an
existing patch to get re-spun and need to be re-reviewed.

The one style exception ... I'm a big believer in not using visual
indentation - but I can't seem to get pep8 or hacking to complain about
its use. This isn't just about style - visual indentation causes more
lines to be touched during a refactor than are necessary making the

Re: [openstack-dev] [oaktree] Follow up to Multi-cloud Management in OpenStack Summit session

[Joshua Harlow]

Monty Taylor wrote:

On 11/28/2017 06:05 PM, Joshua Harlow wrote:
 > So just curious.
 >
 > I didn't think shade had any federation logic in it; so I assume it will
 > start getting some?

It's possible that we're missing each other on the definition of the
word 'federation' ... but shade's entire purpose in life is to allow
sane use of multiple clouds from the same application.


Ya I think u got it, shade is like what I would call the rubber hits the 
road part of federation; so it will be interesting to see how such 
rubber can be used to build what I would call the higher level 
federation (without screwing it up, lol).




 > Has there been any prelim. design around what the APIs of this would be
 > and how they would work and how they would return data from X other
 > clouds in a uniform manner? (I'd really be interested in how a high
 > level project is going to combine various resources from other clouds in
 > a way that doesn't look like crap).

(tl;dr - yes)

Ah - I grok what you're saying now. Great question!

There are (at least) four sides to this.

* Creating a resource in a specific location (boot a VM in OVH BHS1)
* Fetching resources from a specific location (show me the image in
vexxhost)

* Creating a resource everywhere (upload an image to all cloud regions)
* Fetching resources from all locations (show me all my VMs)

The first two are fully handled, as you might imagine, although the
mechanism is slightly different in shade and oaktree (I'll get back to
that in a sec)

Creating everywhere isn't terribly complex - when I need to do that
today it's a simple loop:

for cloud in shade.openstack_clouds():
cloud.create_image('my-image', filename='my-image.qcow2')


Ya, scatter/gather (with some kind of new grpc streaming response..)



But we can (and should and will) add some syntactic sugar to make that
easier. Like (*waving hands*)

all_clouds = shade.everwhere()
all_clouds.create_image('my-image', filename='my-image.qcow2')


Might as well just start to call it scatter/gather, lol



It's actually more complex than that, because Rackspace wants a VHD and
OVH wants a RAW but can take a qcow2 as well... but this is an email, so
for now let's assume that we can handle the general 'create everywhere'
with a smidge of meta programming, some explicit overrides for the
resources that need extra special things - and probably something like
concurrent.futures.ThreadPoolExecutor.

The real fun, as you hint at, comes when we want to read from everywhere.

To prep for this (and inspired specifically be this use-case), shade now
adds a "location" field to every resource it returns. That location
field contains cloud, region, domain and project information - so that
in a list of server objects from across 14 regions of 6 clouds all the
info about who and what they are is right there in the object.

When we shift to the oaktree gRPC interface, we carry over the Location
concept:


http://git.openstack.org/cgit/openstack/oaktreemodel/tree/oaktreemodel/common.proto#n31


which we keep on all of the resources:


http://git.openstack.org/cgit/openstack/oaktreemodel/tree/oaktreemodel/image.proto#n49


So listing all the things should work the same way as the above
list-from-everywhere method.

The difference I mentioned earlier in how shade and oaktree present the
location interface is that in shade there is a an OpenStackCloud object
per cloud-region, and as a user you select which cloud you operate on
via instantiating an OpenStackCloud pointed at the right thing. We need
to add the AllTheClouds meta object for the shade interface.

In oaktree, there is the one oaktree instance and it contains
information about all of your cloud-regions, so Locations and Filters
become a parameters on operations.

 > Will this thing also have its own database (or something like a DB)?

It's an open question. Certainly not at the moment or in the near future
- there's no need for one, as the constituent OpenStack clouds are the
actual source of truth, the thing we need is caching rather than data
that is canonical itself.


That's fine, it prob only becomes a problem if there is a need for some 
kind of cross cloud consistency requirements (which ideally this whole 
thing would strongly avoid)




This will almost certainly change as we work on the auth story, but the
specifics of that are ones that need to be sorted out collectively -
preferably with operators involved.

 > I can imagine if there is a `create_many_servers` call in oaktree that
 > it will need to have some sort of lock taken by the process doing this
 > set of XYZ calls (in the right order) so that some other
 > `create_many_servers` call doesn't come in and screw everything the
 > prior one up... Or maybe cross-cloud consistency issues aren't a
 > concern... What's the thoughts here?
That we have already, actually, and you've even landed code in it. :)
shade executes all of its remote operations through a TaskManager. The
default one that you get 

Re: [openstack-dev] [oaktree] Follow up to Multi-cloud Management in OpenStack Summit session

[Monty Taylor]

On 11/28/2017 06:05 PM, Joshua Harlow wrote:
> So just curious.
>
> I didn't think shade had any federation logic in it; so I assume it will
> start getting some?

It's possible that we're missing each other on the definition of the 
word 'federation' ... but shade's entire purpose in life is to allow 
sane use of multiple clouds from the same application.


> Has there been any prelim. design around what the APIs of this would be
> and how they would work and how they would return data from X other
> clouds in a uniform manner? (I'd really be interested in how a high
> level project is going to combine various resources from other clouds in
> a way that doesn't look like crap).

(tl;dr - yes)

Ah - I grok what you're saying now. Great question!

There are (at least) four sides to this.

* Creating a resource in a specific location (boot a VM in OVH BHS1)
* Fetching resources from a specific location (show me the image in 
vexxhost)


* Creating a resource everywhere (upload an image to all cloud regions)
* Fetching resources from all locations (show me all my VMs)

The first two are fully handled, as you might imagine, although the 
mechanism is slightly different in shade and oaktree (I'll get back to 
that in a sec)


Creating everywhere isn't terribly complex - when I need to do that 
today it's a simple loop:


  for cloud in shade.openstack_clouds():
cloud.create_image('my-image', filename='my-image.qcow2')

But we can (and should and will) add some syntactic sugar to make that 
easier. Like (*waving hands*)


  all_clouds = shade.everwhere()
  all_clouds.create_image('my-image', filename='my-image.qcow2')

It's actually more complex than that, because Rackspace wants a VHD and 
OVH wants a RAW but can take a qcow2 as well... but this is an email, so 
for now let's assume that we can handle the general 'create everywhere' 
with a smidge of meta programming, some explicit overrides for the 
resources that need extra special things - and probably something like 
concurrent.futures.ThreadPoolExecutor.


The real fun, as you hint at, comes when we want to read from everywhere.

To prep for this (and inspired specifically be this use-case), shade now 
adds a "location" field to every resource it returns. That location 
field contains cloud, region, domain and project information - so that 
in a list of server objects from across 14 regions of 6 clouds all the 
info about who and what they are is right there in the object.


When we shift to the oaktree gRPC interface, we carry over the Location 
concept:



http://git.openstack.org/cgit/openstack/oaktreemodel/tree/oaktreemodel/common.proto#n31

which we keep on all of the resources:


http://git.openstack.org/cgit/openstack/oaktreemodel/tree/oaktreemodel/image.proto#n49

So listing all the things should work the same way as the above 
list-from-everywhere method.


The difference I mentioned earlier in how shade and oaktree present the 
location interface is that in shade there is a an OpenStackCloud object 
per cloud-region, and as a user you select which cloud you operate on 
via instantiating an OpenStackCloud pointed at the right thing. We need 
to add the AllTheClouds meta object for the shade interface.


In oaktree, there is the one oaktree instance and it contains 
information about all of your cloud-regions, so Locations and Filters 
become a parameters on operations.


> Will this thing also have its own database (or something like a DB)?

It's an open question. Certainly not at the moment or in the near future 
- there's no need for one, as the constituent OpenStack clouds are the 
actual source of truth, the thing we need is caching rather than data 
that is canonical itself.


This will almost certainly change as we work on the auth story, but the 
specifics of that are ones that need to be sorted out collectively - 
preferably with operators involved.


> I can imagine if there is a `create_many_servers` call in oaktree that
> it will need to have some sort of lock taken by the process doing this
> set of XYZ calls (in the right order) so that some other
> `create_many_servers` call doesn't come in and screw everything the
> prior one up... Or maybe cross-cloud consistency issues aren't a
> concern... What's the thoughts here?
That we have already, actually, and you've even landed code in it. :) 
shade executes all of its remote operations through a TaskManager. The 
default one that you get if you're just running some ansible is a 
pass-through. However, in nodepool we have a multi-threaded 
rate-limiting TaskManager that ensures that we're only ever doing one 
operation at a time for a given cloud-region, and that we're keeping 
ourselves inside of a configurable rate limit (learned the hard-way from 
crashing a few public clouds)


It's worth noting that shade is not transactional (although there are a 
few places where, if shade created a resource on the user's behalf that 
the user doesn't know about, it will delete it on error) 

Re: [openstack-dev] [oaktree] Follow up to Multi-cloud Management in OpenStack Summit session

[Joshua Harlow]

So just curious.

I didn't think shade had any federation logic in it; so I assume it will 
start getting some?


Has there been any prelim. design around what the APIs of this would be 
and how they would work and how they would return data from X other 
clouds in a uniform manner? (I'd really be interested in how a high 
level project is going to combine various resources from other clouds in 
a way that doesn't look like crap).


Will this thing also have its own database (or something like a DB)?

I can imagine if there is a `create_many_servers` call in oaktree that 
it will need to have some sort of lock taken by the process doing this 
set of XYZ calls (in the right order) so that some other 
`create_many_servers` call doesn't come in and screw everything the 
prior one up... Or maybe cross-cloud consistency issues aren't a 
concern... What's the thoughts here?


What happens in the above if a third user Y is creating resources in one 
of those clouds outside the view of oaktree... ya da ya da... What 
happens if they are both targeting the same tenant...


Perhaps a decent idea to start some kind of etherpad to start listing 
these questions (and at least think about them a wee bit) down?


Monty Taylor wrote:

Hey everybody!

https://etherpad.openstack.org/p/sydney-forum-multi-cloud-management

I've CC'd everyone who listed interest directly, just in case you're not
already on the openstack-dev list. If you aren't, and you are in fact
interested in this topic, please subscribe and make sure to watch for
[oaktree] subject headings.

We had a great session in Sydney about the needs of managing resources
across multiple clouds. During the session I pointed out the work that
had been started in the Oaktree project [0][1] and offered that if the
people who were interested in the topic thought we'd make progress best
by basing the work on oaktree, that we should bootstrap a new core team
and kick off some weekly meetings. This is, therefore, the kickoff email
to get that off the ground.

All of the below is thoughts from me and a description of where we're at
right now. It should all be considered up for debate, except for two
things:

- gRPC API
- backend implementation based on shade

As those are the two defining characteristics of the project. For those
who weren't in the room, justifications for those two characteristics are:

gRPC API


There are several reasons why gRPC.

* Make it clear this is not a competing REST API.

OpenStack has a REST API already. This is more like a 'federation' API
that knows how to talk to one or more clouds (similar to the kubernetes
federation API)

* Streaming and async built in

One of the most costly things in using the OpenStack API is polling.
gRPC is based on HTTP/2 and thus supports streaming and other exciting
things. This means an oaktree running in or on a cloud can do its
polling loops over the local network and the client can just either wait
on a streaming call until the resource is ready, or can fire an async
call and deal with it later on a notification channel.

* Network efficiency

Protobuf over HTTP/2 is a super-streamlined binary protocol, which
should actually be really nice for our friends in Telco land who are
using OpenStack for Edge-related tasks in 1000s of sites. All those
roundtrips add up at scale.

* Multi-language out of the box

gRPC allows us to directly generate consistent consumption libs for a
bunch of languages - or people can grab the proto files and integrate
those into their own build if they prefer.

* The cool kids are doing it

To be fair, Jay Pipes and I tried to push OpenStack to use Protobuf
instead of JSON for service-to-service communication back in 2010 - so
it's not ACTUALLY a new idea... but with Google pushing it and support
from the CNCF, gRPC is actually catching on broadly. If we're writing a
new thing, let's lean forward into it.

Backend implementation in shade
---

If the service is defined by gRPC protos, why not implement the service
itself in Go or C++?

* Business logic to deal with cloud differences

Adding a federation API isn't going to magically make all of those
clouds work the same. We've got that fairly well sorted out in shade and
would need to reimplement basically all of shade in other other language.

* shade is battle tested at scale

shade is what Infra's nodepool uses. In terms of high-scale API
consumption, we've learned a TON of lessons. Much of the design inside
of shade is the result of real-world scaling issues. It's Open Source,
so we could obviously copy all of that elsewhere - but why? It exists
and it works, and oaktree itself should be a scale-out shared-nothing
kind of service anyway.

The hard bits here aren't making API calls to 3 different clouds, the
hard bits are doing that against 3 *different* clouds and presenting the
results sanely and consistently to the original user.

Proposed Structure
==

PTL
---

As the originator 

Re: [openstack-dev] [all] Community managed tech/dev blog: Call for opinions and ideas

[Jimmy McArthur]

Please feel free to reach out to me if you're interested in contributing 
and/or playing editor. I'll be happy to get anyone that needs it a login.


Cheers,
Jimmy

Mike Perez wrote:

On 10:45 Nov 28, Jimmy McArthur wrote:

Thierry Carrez wrote:

What Josh wants is a curated technical blog, so if we reused blog.o.o
for this (and I think it's a good idea), we'd likely want to have a bit
more rules on what's appropriate.

Agreed. It's almost solely used for developer digest now and isn't
frequently updated. Most of the promotion of sponsors and news goes into
o.o/News, SuperUser, or one of our other marketing channels. It's a good
time for the community to repurpose it :)


+1 from me to bring more life to the blog than just the dev digest!

__
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] Community managed tech/dev blog: Call for opinions and ideas

[Mike Perez]

On 10:45 Nov 28, Jimmy McArthur wrote:
> Thierry Carrez wrote:
> >
> >What Josh wants is a curated technical blog, so if we reused blog.o.o
> >for this (and I think it's a good idea), we'd likely want to have a bit
> >more rules on what's appropriate.
> 
> Agreed. It's almost solely used for developer digest now and isn't
> frequently updated. Most of the promotion of sponsors and news goes into
> o.o/News, SuperUser, or one of our other marketing channels. It's a good
> time for the community to repurpose it :)

+1 from me to bring more life to the blog than just the dev digest!

-- 
Mike Perez (thingee)


pgpdODcUhXcyI.pgp
Description: PGP signature
__
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] [oaktree] Follow up to Multi-cloud Management in OpenStack Summit session

[Jeremy Stanley]

On 2017-11-28 15:20:10 -0600 (-0600), Monty Taylor wrote:
[...]
> To be fair, Jay Pipes and I tried to push OpenStack to use
> Protobuf instead of JSON for service-to-service communication back
> in 2010 - so it's not ACTUALLY a new idea... but with Google
> pushing it and support from the CNCF, gRPC is actually catching on
> broadly. If we're writing a new thing, let's lean forward into it.
[...]

Not to be "that guy" but... why not ASN.1? Sure the new shiny wore
off decades ago, but it's more broadly supported even than PB and
had all that extra time to get the corner cases cleared of cobwebs.
I know this particular train has already sailed, but PB just always
struck me as though it were either designed by someone who had no
idea the same problems had already been solved long ago, or who
didn't (want to be bothered to) read the X.690 spec.

/me goes back to shaking a cane at the kids on his lawn

-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
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] PTG Dublin 2018- Registration is Live!

[Erin Disney]

The third Project Teams Gathering will be held February 26-March 2nd at Croke 
Park in Dublin, Ireland! Registration, Travel Support Program, discounted hotel 
block, and sponsorships are now live!  

REGISTRATION AND HOTEL 
Registration is now available here: https://rockyptg.eventbrite.com 

 
We've reserved a very limited block of discounted hotel rooms including full 
breakfast at €155 per night (single occupancy, double is €175) with the Croke 
Park Hotel , next 
door to where the event will be held. Please move quickly to reserve a room  
by
 February 2nd or until they sell out! Please note- the Gaelic Athletic 
Association has an event at Croke Park the Saturday prior to our event 
(February 24th) so the hotel is sold out that evening. 

To book a room, call the Croke Park Hotel reservations team directly at + 353 1 
871 4550 or by emailing crokep...@doylecollection.com 
 and quoting the block code: BOOK250218. 

EUROPEAN VISA APPLICATIONS 
Please allow as much time as possible for the application process if a visa is 
required in order to travel to Ireland. If you are unsure whether you require a 
visa or not, please visit this page 
 for more information. 
Requests for invitation letters may be submitted here 
 and must 
be received by Friday, February 16, 2018.
 
TRAVEL SUPPORT PROGRAM
The OpenStack Travel Support Program's aim is to facilitate participation of 
key contributors to the OpenStack Project Teams Gathering (PTG) covering costs 
for travel, accommodation, and event pass. Please fill out this form 
 to 
apply; the application deadline for the first round of sponsorships is January 
4th, and the final deadline to apply is January 25th. More information 
available here . 
 
SPONSORSHIP
We are seeking sponsors for the week-long PTG to help cover the event costs, 
while continuing to keep distractions and onsite branding/marketing to a 
minimum. We have created a sponsorship package that is community focused so 
that all sponsors receive equal recognition and contribute an equal amount. If 
your organization is interested in sponsoring the Rocky PTG in Dublin, please 
review the sponsorship prospectus here 
, and send any questions to 
p...@openstack.org . Deadline for full sponsorship 
benefits is Friday, February 2. 

Feel free to reach out to me directly with any questions, looking forward to 
seeing everyone in Dublin! 

Erin Disney
OpenStack Marketing
e...@openstack.org 
__
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] [trove] Changes to the Trove core team

[Manoj Kumar]

I would like to announce the following changes to the Trove core 
reviewers:

+jian.song 
-mariamj

Mariam has moved on to other projects and unfortunately has not been able 
to contribute recently.
Jian Song has been an active contributor/reviewer for the last few cycles.


- Manoj

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

[openstack-dev] [all] [tc] Community Goals for Rocky

[Emilien Macchi]

Hi everyone,

It's time to plan what goals we would like to achieve during the Rocky cycle.
If you're not familiar with goals, I suggest this reading first:
https://governance.openstack.org/tc/goals/

Chandan and Lance did an more-than-awesome work in championing the 2
goals for Queens cycle, I think we should continue to have goal
champions in the future.
This decision is currently under discussion here:
https://review.openstack.org/#/c/510656/

Looking forward, it's time to discuss about the goals we want to work
on during Rocky.
As a reminder, the full list of proposed goals is documented here:
https://etherpad.openstack.org/p/community-goals
Based on our experience, we would like our goals to:
- have at least one or multiple champions, who commit to work with the
project teams so they know what to do in order to achieve the goal.
The champion(s) aren't supposed (but free) to actually implement the
goals.
- be achievable in one cycle. A goal that isn't doable in 6 months is
probably too wide and need to be split into smaller steps to achieve
the goal.
- meet OpenStack roadmap. There are some goals more urgent than
others, we need to take that in consideration.

With that said, the discussion is open. So far we already have one proposal:
https://review.openstack.org/#/c/513875/ (Migration to Storyboard,
championed by Kendall).

Suggestions are welcome:
- on the mailing-list, in a new thread per goal [all] [tc] Proposing
goal XYZ for Rocky
- on Gerrit in openstack/governance like Kendall did.

Thanks,
-- 
Emilien Macchi

__
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] [qa] feedback on OPNFV test tools and extreme testing

[Georg Kunz]

Hi Gautam,

Thanks for the update. Just reach out to me if you need further infos, contact 
persons, support, etc.

Best regards
Georg

From: Gautam Divgi [mailto:gautamdi...@gmail.com]
Sent: Tuesday, November 28, 2017 4:59 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [qa] feedback on OPNFV test tools and extreme 
testing

Hi Georg,
I am working with Sampath on extreme testing. Have not had a chance to look at 
the tools past the cursory glance through the documents. It is however on my 
list to do a complete eval of them.
Thanks,
Gautam.

On Tue, Nov 28, 2017 at 2:49 AM, Georg Kunz 
> wrote:
Hi guys,

I wanted to come back to you regarding conversion we had in Sydney about the 
OPNFV tools. I am curious about your thoughts on tools such as Yardstick (and 
Functest) and in which way they meet or do not meet your requirements for 
extreme testing. In case you found the time to look at them - I know we are all 
busy - it would be great to learn your feedback. Next week is an OPNFV hackfest 
(the OPNFV equivalent to the PTG) and that's a good opportunity to discuss and 
incorporate new features and improvements. So, just let me know.

Best regards
Georg

__
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] [oaktree] Follow up to Multi-cloud Management in OpenStack Summit session

[Monty Taylor]

Hey everybody!

https://etherpad.openstack.org/p/sydney-forum-multi-cloud-management

I've CC'd everyone who listed interest directly, just in case you're not 
already on the openstack-dev list. If you aren't, and you are in fact 
interested in this topic, please subscribe and make sure to watch for 
[oaktree] subject headings.


We had a great session in Sydney about the needs of managing resources 
across multiple clouds. During the session I pointed out the work that 
had been started in the Oaktree project [0][1] and offered that if the 
people who were interested in the topic thought we'd make progress best 
by basing the work on oaktree, that we should bootstrap a new core team 
and kick off some weekly meetings. This is, therefore, the kickoff email 
to get that off the ground.


All of the below is thoughts from me and a description of where we're at 
right now. It should all be considered up for debate, except for two things:


- gRPC API
- backend implementation based on shade

As those are the two defining characteristics of the project. For those 
who weren't in the room, justifications for those two characteristics are:


gRPC API


There are several reasons why gRPC.

* Make it clear this is not a competing REST API.

OpenStack has a REST API already. This is more like a 'federation' API 
that knows how to talk to one or more clouds (similar to the kubernetes 
federation API)


* Streaming and async built in

One of the most costly things in using the OpenStack API is polling. 
gRPC is based on HTTP/2 and thus supports streaming and other exciting 
things. This means an oaktree running in or on a cloud can do its 
polling loops over the local network and the client can just either wait 
on a streaming call until the resource is ready, or can fire an async 
call and deal with it later on a notification channel.


* Network efficiency

Protobuf over HTTP/2 is a super-streamlined binary protocol, which 
should actually be really  nice for our friends in Telco land who are 
using OpenStack for Edge-related tasks in 1000s of sites. All those 
roundtrips add up at scale.


* Multi-language out of the box

gRPC allows us to directly generate consistent consumption libs for a 
bunch of languages - or people can grab the proto files and integrate 
those into their own build if they prefer.


* The cool kids are doing it

To be fair, Jay Pipes and I tried to push OpenStack to use Protobuf 
instead of JSON for service-to-service communication back in 2010 - so 
it's not ACTUALLY a new idea... but with Google pushing it and support 
from the CNCF, gRPC is actually catching on broadly. If we're writing a 
new thing, let's lean forward into it.


Backend implementation in shade
---

If the service is defined by gRPC protos, why not implement the service 
itself in Go or C++?


* Business logic to deal with cloud differences

Adding a federation API isn't going to magically make all of those 
clouds work the same. We've got that fairly well sorted out in shade and 
would need to reimplement basically all of shade in other other language.


* shade is battle tested at scale

shade is what Infra's nodepool uses. In terms of high-scale API 
consumption, we've learned a TON of lessons. Much of the design inside 
of shade is the result of real-world scaling issues. It's Open Source, 
so we could obviously copy all of that elsewhere - but why? It exists 
and it works, and oaktree itself should be a scale-out shared-nothing 
kind of service anyway.


The hard bits here aren't making API calls to 3 different clouds, the 
hard bits are doing that against 3 *different* clouds and presenting the 
results sanely and consistently to the original user.


Proposed Structure
==

PTL
---

As the originator of the project, I'll take on the initial PTL role. 
When the next PTL elections roll around, we should do a real election.


Initial Core Team
-

oaktree is still small enough that I don't think we need to be super 
protective - so I think if you're interested in working on it and you 
think you'll have the bandwidth to pay attention, let me know and I'll 
add you to the team.


General rules of thumb I try to follow on top of normal OpenStack 
reviewing guidelines:


* Review should mostly be about suitability of design/approach. Style 
issues should be handled by pep8/hacking (with one exception, see 
below). Functional issues should be handled with tests. Let the machines 
be machines and humans be humans.


* Use followup patches to fix minor things rather than causing an 
existing patch to get re-spun and need to be re-reviewed.


The one style exception ... I'm a big believer in not using visual 
indentation - but I can't seem to get pep8 or hacking to complain about 
its use. This isn't just about style - visual indentation causes more 
lines to be touched during a refactor than are necessary making the 
impact of a change harder to see.


good:

[openstack-dev] [charms] evolving the ha interface type

[Dmitrii Shcherbakov]

Hi James,

The side effect of using JSON is that we will lose type information:

In [0]: json.loads(json.dumps([{1: 2}]))
Out[0]: [{'1': 2}]

In [1]: ast.literal_eval(repr([{1: 2}]))
Out[1]: [{1: 2}]

This is a hard requirement in the JSON spec:

https://tools.ietf.org/html/rfc7159#section-4
"An object structure is represented as a pair of curly brackets
surrounding zero or more name/value pairs (or members).  A name is
a string. "

I wonder if we could use some type-aware serialization format but I do
not have any suggestions without trade-offs because we need to keep in
mind that, in general, charms may not be python charms, may run on
hosts with different protocol parsing libraries etc.

If we only cared about python I would suggest using "pickle" but this
is not universal and not human-readable:

https://docs.python.org/3/library/pickle.html#comparison-with-json
"JSON, by default, can only represent a subset of the Python built-in
types, and no custom classes; pickle can represent an extremely large
number of Python types"

JSON has an advantage of being readable as opposed to a binary protocol
so we can explore what's available in relation data by doing relation-
get without additional tools. It is also ubiquitous so we don't have to
worry about spec changes, parsing bugs and other potential problems.

Thanks for bringing this topic up.

Dmitrii Shcherbakov

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

Re: [openstack-dev] nova diagnostics in client library/SDK

[Monty Taylor]

On 11/03/2017 11:31 AM, Gordon, Kent S wrote:

Do any of the python client libraries implement the nova diagnostics API?

https://wiki.openstack.org/wiki/Nova_VM_Diagnostics


Not to my knowledge, no. However, adding support for it should be easy 
enough to accomplish and would be a welcome addition.


This is the API you're talking about?

https://developer.openstack.org/api-ref/compute/#servers-diagnostics-servers-diagnostics

If you feel like hacking on it, a patch to openstack/python-openstacksdk 
would be the best way to go.


However, this is microversion-protected, and this would be the first 
such feature in the SDK. So if diving that far down the rabbithole 
sounds like too much, either bug me until I get around to it - or do as 
much of it as makes sense (like adding a Resource class based on 
openstack.resource2) but ignore the microversion bit and I can help 
finish it off.


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-dev] [shade][sdk] Retiring #openstack-shade IRC channel - come join #openstack-sdks

[Monty Taylor]

With the adoption of python-openstacksdk into the shade team and the 
merging of the shade code into the python-openstacksdk codebase, having 
both an #openstack-shade and an #openstack-sdks channel is more 
confusing than helpful. [0]


To solve that, I'd like to shift shade-related development discussion 
into #openstack-sdks with the rest of it.


Thanks!
Monty

[0] Why is there still shade-related development discussion if the code 
has been merged into python-openstacksdk? WELL- we still need to turn 
the existing shade codebase into a compatibilty shim layer on top of the 
code in python-openstacksdk. That's probably going to take at *least* a 
cycle ... and we'll need to make sure that the shade layer continues to 
work for as long as we're still around and kicking.


__
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] Dublin PTG format

[Matt Riedemann]

On 11/28/2017 3:46 AM, Chris Dent wrote:

On Tue, 28 Nov 2017, Flavio Percoco wrote:

Others have raised concerns about being able to properly keep the 
momentum of

the day going if we adopt the new format. I have to admit that I'm also
concerned about this. Switching context every half day may not be ideal.


This is the real crux of the biscuit. For team oriented work being
able to get into the nova-zone (or whatever) for an extended period
is important. Having to switch in and out of that per day would not
be pleasant and would also make the time less effective.

At base, I think part of the challenge with how we manage this stuff
is that because the available time is such a scarce resource (10
days out of 365) we want to make sure we touch upon everything that
matters. But bouncing from topic to topic means that each topic and
the people involved do not get the depth of engagement for it to
really matter. In the end what matters is not so much that we talk
about any particular topic, but that we talk about any topic, so
that we develop the shared language that allows us to talk about it
more later.

Which is just a long-winded way of saying: Let's not parcel time
into small chunks.



Agree with Chris. And stepping back, the more things get split up and 
time sliced, the more the PTG becomes like a summit with a very rigid 
schedule - which is something teams were trying very hard to get away 
from when we started doing midcycle meetups. The 2-3 days of just 
focusing on a few set of things at a deep level to move forward was 
necessary because 40 minutes every 6 months doesn't cut it.


--

Thanks,

Matt

__
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] [tripleo][ui][ux] Manage Roles UI Design

[Liz Blanchard]

Hi All,

I've put together a set of designs as we are starting to discuss how a user
should be able to manage the roles in a deployment plan. I'd love to hear
if anyone has any feedback on this direction!

1) The user can choose to "Manage Role" in order to get the Roles panel
into an edit mode:
https://lizsurette.github.io/OpenStack-Design/tripleo-ui/2-preparation-before-edge-technician-deploys/img/2017-7-24-TripleO-UI_13_PrepWork22.png


2) At this point any roles available (not just those already selected for
this plan) will become available for the user to enable/disabled. Selecting
those via checkboxes will allow the user to choose which they would like to
use for this plan. In the future, we will look to supporting creating a new
role from here as well:
https://lizsurette.github.io/OpenStack-Design/tripleo-ui/2-preparation-before-edge-technician-deploys/img/2017-7-24-TripleO-UI_13_PrepWork23.png

3) Any changes made can be saved:
https://lizsurette.github.io/OpenStack-Design/tripleo-ui/2-preparation-before-edge-technician-deploys/img/2017-7-24-TripleO-UI_13_PrepWork26.png

That's all for now! If you'd like to check out the whole flow that we are
envisioning for this persona, you can take a look here:
https://lizsurette.github.io/OpenStack-Design/tripleo-ui/2-preparation-before-edge-technician-deploys/2.usingui

Let me know what you think.

Thanks!
Liz
__
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] [tc] Policy Goal Queens-2 Update

[Lance Bragstad]

We have quite a bit in progress already. The following are little things
people can do that make a big difference, outside of picking up the
implementation for a given project:

- Reviews are huge. If we can get things reviewed and +1'd from a goal
perspective (e.g. does this meet the requirements? are policies
documented? is it consistent?), then it makes things easier when a core
reviewer comes along. I'm sort of expecting the core reviewers of the
projects to ensure the policies are documented in a way that makes sense
from a project-perspective.
- Updating patches with the `policy-and-docs-in-code` topic. A lot of
patches are getting missed in tracking because sometimes the topic gets
updated with new patch sets.
- Reviewing and proposing patches to governance for projects that have
completed all the work. This just consists of double checking the work
against the goal criteria [1] and making sure we include planning and
completion artifacts for the project if they have everything done.

That should really help us push what we have in progress through to
completion.

[0] https://review.openstack.org/#/c/458677/
[1]
https://governance.openstack.org/tc/goals/queens/policy-in-code.html#completion-criteria

On 11/28/2017 11:18 AM, Harry Rybacki wrote:
> On Tue, Nov 28, 2017 at 12:14 PM, Lance Bragstad  wrote:
>> Hi all,
>>
>> As Queens 2 comes to a close next week, I figured it was a good time to
>> recap the policy goal [0]. The following is the breakdown of where projects
>> stand with how I've been tracking things.
>>
>> Not Started
>>
>> openstack/ceilometer
>> openstack/congress
>> openstack/networking-bgpvpn
>> openstack/networking-midonet
>> openstack/networking-odl
>> openstack/neutron-dynamic-routing
>> openstack/neutron-fwaas
>> openstack/neutron-lib
>> openstack/solum
>> openstack/swift
>>
> Okay, I think I can jump into these and help out a bit. Any of the
> above you would recommend as a starter?
>
>> In Progress
>>
>> openstack/barbican
>> openstack/cinder
>> openstack/cloudkitty
>> openstack/glance
>> openstack/heat
>> openstack/manila
>> openstack/mistral
>> openstack/neutron
>> openstack/panko
>> openstack/python-heatclient
>> openstack/tacker
>> openstack/tricircle
>> openstack/trove
>> openstack/vitrage
>> openstack/watcher
>> openstack/zaqar
>>
>> Completed
>>
>> openstack/designate
>> openstack/freezer
>> openstack/ironic
>> openstack/keystone
>> openstack/magnum
>> openstack/murano
>> openstack/nova
>> openstack/octavia
>> openstack/sahara
>> openstack/searchlight
>> openstack/senlin
>> openstack/zun
>>
>> Note that a lot of the projects "In Progress" are only pending reviews to
>> publish sample policy documentation. If a project you're working on has
>> already done this, please let me know and I'll get a patch posted to
>> governance to mark the status as completed. If you have patches in flight
>> the works towards this goal, please be sure to use the
>> `policy-and-docs-in-code` topic in Gerrit. It will be picked up and tracked
>> automatically [1]. With such a large change, visualizing and leaning on
>> automation in any way we can really helps in managing the goal.
>>
>> Finally, I'd like to give a huge "Thank You" to Dai Dang Van, Nam Nguyen
>> Hoai, and Hieu LE. They've all dug into to help other projects complete the
>> goal and review patches. We certainly wouldn't be seeing as many projects in
>> the Completed or In Progress list if not for their help.
>>
>> As always, feel free to come find me on IRC if you have questions. If I'm
>> missing status for your project(s), just ping me and I'll make sure things
>> get tracked and recorded.
>>
>> Thanks for the time!
>>
>> Lance
>>
>>
>> [0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
>> [1] https://www.lbragstad.com/policy-burndown/
>>
>> __
>> 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




signature.asc
Description: OpenPGP digital signature
__
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] [tc] Policy Goal Queens-2 Update

[Harry Rybacki]

On Tue, Nov 28, 2017 at 12:14 PM, Lance Bragstad  wrote:
> Hi all,
>
> As Queens 2 comes to a close next week, I figured it was a good time to
> recap the policy goal [0]. The following is the breakdown of where projects
> stand with how I've been tracking things.
>
> Not Started
>
> openstack/ceilometer
> openstack/congress
> openstack/networking-bgpvpn
> openstack/networking-midonet
> openstack/networking-odl
> openstack/neutron-dynamic-routing
> openstack/neutron-fwaas
> openstack/neutron-lib
> openstack/solum
> openstack/swift
>
Okay, I think I can jump into these and help out a bit. Any of the
above you would recommend as a starter?

> In Progress
>
> openstack/barbican
> openstack/cinder
> openstack/cloudkitty
> openstack/glance
> openstack/heat
> openstack/manila
> openstack/mistral
> openstack/neutron
> openstack/panko
> openstack/python-heatclient
> openstack/tacker
> openstack/tricircle
> openstack/trove
> openstack/vitrage
> openstack/watcher
> openstack/zaqar
>
> Completed
>
> openstack/designate
> openstack/freezer
> openstack/ironic
> openstack/keystone
> openstack/magnum
> openstack/murano
> openstack/nova
> openstack/octavia
> openstack/sahara
> openstack/searchlight
> openstack/senlin
> openstack/zun
>
> Note that a lot of the projects "In Progress" are only pending reviews to
> publish sample policy documentation. If a project you're working on has
> already done this, please let me know and I'll get a patch posted to
> governance to mark the status as completed. If you have patches in flight
> the works towards this goal, please be sure to use the
> `policy-and-docs-in-code` topic in Gerrit. It will be picked up and tracked
> automatically [1]. With such a large change, visualizing and leaning on
> automation in any way we can really helps in managing the goal.
>
> Finally, I'd like to give a huge "Thank You" to Dai Dang Van, Nam Nguyen
> Hoai, and Hieu LE. They've all dug into to help other projects complete the
> goal and review patches. We certainly wouldn't be seeing as many projects in
> the Completed or In Progress list if not for their help.
>
> As always, feel free to come find me on IRC if you have questions. If I'm
> missing status for your project(s), just ping me and I'll make sure things
> get tracked and recorded.
>
> Thanks for the time!
>
> Lance
>
>
> [0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
> [1] https://www.lbragstad.com/policy-burndown/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [all] [tc] Policy Goal Queens-2 Update

[Lance Bragstad]

Hi all,

As Queens 2 comes to a close next week, I figured it was a good time to
recap the policy goal [0]. The following is the breakdown of where
projects stand with how I've been tracking things.
*
Not Started**
*
openstack/ceilometer
openstack/congress
openstack/networking-bgpvpn
openstack/networking-midonet
openstack/networking-odl
openstack/neutron-dynamic-routing
openstack/neutron-fwaas
openstack/neutron-lib
openstack/solum
openstack/swift
*
In Progress*

openstack/barbican
openstack/cinder
openstack/cloudkitty
openstack/glance
openstack/heat
openstack/manila
openstack/mistral
openstack/neutron
openstack/panko
openstack/python-heatclient
openstack/tacker
openstack/tricircle
openstack/trove
openstack/vitrage
openstack/watcher
openstack/zaqar
*
Completed

*openstack/designate
openstack/freezer
openstack/ironic
openstack/keystone
openstack/magnum
openstack/murano
openstack/nova
openstack/octavia
openstack/sahara
openstack/searchlight
openstack/senlin
openstack/zun
**
Note that a lot of the projects "In Progress" are only pending reviews
to publish sample policy documentation. If a project you're working on
has already done this, please let me know and I'll get a patch posted to
governance to mark the status as completed. If you have patches in
flight the works towards this goal, please be sure to use the
`policy-and-docs-in-code` topic in Gerrit. It will be picked up and
tracked automatically [1]. With such a large change, visualizing and
leaning on automation in any way we can really helps in managing the goal.

Finally, I'd like to give a huge "Thank You" to Dai Dang Van, Nam Nguyen
Hoai, and Hieu LE. They've all dug into to help other projects complete
the goal and review patches. We certainly wouldn't be seeing as many
projects in the Completed or In Progress list if not for their help.

As always, feel free to come find me on IRC if you have questions. If
I'm missing status for your project(s), just ping me and I'll make sure
things get tracked and recorded.

Thanks for the time!

Lance


[0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
[1] https://www.lbragstad.com/policy-burndown/


signature.asc
Description: OpenPGP digital signature
__
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] Community managed tech/dev blog: Call for opinions and ideas

[Jimmy McArthur]

Thierry Carrez wrote:

Flavio Percoco wrote:

On 27/11/17 13:14 -0600, Jimmy McArthur wrote:

Joshua Harlow wrote:

With say an editor that solicits (and backlogs topics and stories
and such) various developers/architects at various companies and
creates a actually human curated place for developers and technology
and architecture to be spot-lighted.

To me personal blogs can be used for this, sure, but that sort of
misses the point of having a place that is targeted for this (and no
I don't really care about finding and subscribing to 100+ random joe
blogs that I will never look at more than once). Ideally that place
would not become `elitist` as some others have mentioned in this
thread (ie, don't pick an elitist editor? lol).

The big desire for me is to actually have a editor (a person or
people) involved that is keeping such a blog going and editing it
and curating it and ensuring it gets found in google searches and is
*developer* focused...

This is basically what https://www.openstack.org/blog/ is for. It's
using Wordpress. It's developer-centric. Anyone can submit to it and
we have editors that can publish it. We also have pretty solid SEO.

Interestingly enough, not many folks are (were) aware of this. It was not
brought up during the discussion at the forum. I'm glad you did, though.

If we already have a platform for this then I would say we need to
promote it
more and find someone (Josh? ;) that will actively seek for content.

Thanks for pointing us to o.o/blog, Jimmy.


Historically blog.o.o used to be our only blog outlet, so almost
anything would go in:

"OpenStack Events Sponsorship Webinar"
"New Foundation Gold Members&  Corporate Sponsors"
"HP Announces Private Beta Program for OpenStack Cloud"
"2016 OpenStack T-Shirt Design Contest"

What Josh wants is a curated technical blog, so if we reused blog.o.o
for this (and I think it's a good idea), we'd likely want to have a bit
more rules on what's appropriate.


Agreed. It's almost solely used for developer digest now and isn't 
frequently updated. Most of the promotion of sponsors and news goes into 
o.o/News, SuperUser, or one of our other marketing channels. It's a good 
time for the community to repurpose it :)


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


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

[openstack-dev] [tc] [all] TC Report 48

[Chris Dent]

https://anticdent.org/tc-report-48.html>

Due to the recent Summit in Sydney, related travel, and Thanksgiving,
it has been a while since I put a TC Report together. It is hard to
get back in the groove. Much of the recent discussion has either been
reflecting on Summit-initiated discussions or trying to integrate
results from those discussions into plans for the future.

#  Summit Reflections

A lot of my TC-related summit thinking is in a series of blog posts I
made last week. This isn't the "Chris promotes his blog report" but I
do think that these represent some important OpenStack issues, related
to stuff the TC talks about often, so here they are:

* [OpenStack Developer
  Satisfaction](https://anticdent.org/openstack-developer-satisfaction.html)
* [OpenStack Casual
  Contribution](https://anticdent.org/openstack-casual-contribution.html)
* [OpenStack Forum
  View](https://anticdent.org/openstack-forum-view.html)

Some other summit summaries that might be of interest:

* [Sydney OpenStack
  Summit](http://graham.hayes.ie/posts/sydney-openstack-summit/)
* [Sydney Summit Recap](https://blog.leafe.com/sydney-summit-recap/)
* [OpenStack Summit Sydney
  Recap](http://www.gazlene.net/sydney-summit.html)

Graham mentions a few things of interest from the joint leadership
meeting that happened the Sunday before summit:

* The potential expansion of the Foundation to include other projects,
  separate from OpenStack and with separate governance, to address the
  complexities of integrating all the pieces that get involved in
  doing stuff with clouds. OpenStack itself continues with its focus
  on the base infrastructure. There's a [press
  
release](https://www.openstack.org/news/view/359/openstack-summit-sydney-spotlights-open-infrastructure-integration)
  with a bit more information, and it was talked about during the
  
[keynote](https://www.openstack.org/videos/sydney-2017/tackling-the-biggest-challenge-in-open-source-integration).

* A somewhat bizarre presentation suggesting the Board and the TC
  manage the OpenStack roadmap. There wasn't time to actually discuss
  this as previous topics ran _way_ over, but at a superficial glance
  it appeared to involve a complete misunderstanding of not just how
  open source works in OpenStack, but how open source works in
  general.

# A Tech/Dev/? Blog

Throughout the past week there's been a lot of discussion of how to
address the desire for a blog that's been variously described as a "dev
blog" (news of what's going on with OpenStack development) or a "tech
blog" (a kind of "humble brag" about any cool (dev-related) stuff going
on, to remind people that OpenStack does interesting things).

On
[Thursday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-11-23.log.html#t2017-11-23T15:01:54)
there was talk about technology to use, differences of opinion on
what content should be present, and the extent to which curation should
be involved. If none, why not just carry on with
[planet](http://planet.openstack.org/)?

There was more on
[Monday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-11-27.log.html#t2017-11-27T14:41:02)
and then [an email
thread](http://lists.openstack.org/pipermail/openstack-dev/2017-November/124902.html).

The eventual outcome is that the existing but rarely used [OpenStack
Blog](https://www.openstack.org/blog/) would make sense for this but
only if there were human involvement in choosing what content should be
present. An Acquisitions Editor was suggested. Josh Harlow was press
ganged, but it's not clear if the hook set.

# PTL Meeting (or tech leadership void filling)

Another topic on
[Thursday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-11-23.log.html#t2017-11-23T15:26:03)
was the notion of having some kind of formal process whereby project
roadmaps were more actively visible to other projects in the OpenStack
ecosystem. There's an
[etherpad](https://etherpad.openstack.org/p/ptl-meeting) started but
probably best to start with the log which also links to some twitter
discussion. A summary (common throughout all the discussion this past
week) is "maybe we should get people talking to each other more
often?"

The topic evolved and went what might look like two ways: how do we
address the perceived void of technical leadership and


I think underlying all of this is that there are people in the
commu[n]ity who are concerned that sometimes we have bad or at least
not on the same page actors, and we have no mechanism for dealing
with that.
[_me_](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-11-23.log.html#t2017-11-23T15:44:48)


but to some extent that's part and parcel of the same thing.

# PTG Timing

Yet more on
[Thursday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-11-23.log.html#t2017-11-23T15:44:31):
initial discussion of how to divide up time and otherwise format
things at the 

Re: [openstack-dev] [qa] feedback on OPNFV test tools and extreme testing

[Gautam Divgi]

Hi Georg,

I am working with Sampath on extreme testing. Have not had a chance to look
at the tools past the cursory glance through the documents. It is however
on my list to do a complete eval of them.

Thanks,
Gautam.

On Tue, Nov 28, 2017 at 2:49 AM, Georg Kunz  wrote:

> Hi guys,
>
> I wanted to come back to you regarding conversion we had in Sydney about
> the OPNFV tools. I am curious about your thoughts on tools such as
> Yardstick (and Functest) and in which way they meet or do not meet your
> requirements for extreme testing. In case you found the time to look at
> them - I know we are all busy - it would be great to learn your feedback.
> Next week is an OPNFV hackfest (the OPNFV equivalent to the PTG) and that's
> a good opportunity to discuss and incorporate new features and
> improvements. So, just let me know.
>
> Best regards
> Georg
>
> __
> 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] [kolla] Ansiblize init-runonce script

[Sam Yaple]

For what its worth, this init-runonce script was never meant for production 
usage. Ops *shouldn't* be running it like you suggest. It was historically for 
use in the gate and a quick-n-dirty environment setup for testing.

If you want to get into writing operations scripts, thats your prerogative, but 
it was discussed before and mostly considered a bad idea.

Thanks,
SamYaple

>  Original Message 
> Subject: Re: [openstack-dev] [kolla] Ansiblize init-runonce script
> Local Time: November 28, 2017 8:10 AM
> UTC Time: November 28, 2017 1:10 PM
> From: zhang.lei@gmail.com
> To: OpenStack Development Mailing List (not for usage questions) 
> 
>
> in my opinion,
>
> idempotent scrip
> t is very necessary.
> for several reason
>
> - there is already some idempotent logical in the script
> - it is common that this script failed by wrong configuration,
>   after fix the config,
> ops will want to run this script again.
>
> On Tue, Nov 28, 2017 at 7:14 PM, Paul Bourke  wrote:
>
>> I think this came up before at one stage. My position is I don't see the 
>> need to ansible-ise small shell scripts. init-runonce is currently just an 
>> easy to understand sequence of openstack commands provided to help people 
>> test/demo their setups. Unless we want to make it more than that, i.e. make 
>> it idempotent, customizable, etc. I don't see the need to wheel in Ansible.
>>
>> On 28/11/17 03:23, Jeffrey Zhang wrote:
>>
>>> hi
>>>
>>> check this [0]. I tried to convert it  to ansible playbooks.
>>>
>>> [0] https://review.openstack.org/523072
>>>
>>> On Tue, Nov 28, 2017 at 2:57 AM, Ravi Shekhar Jethani >> > wrote:
>>>
>>> Hi,
>>>
>>> While exploring kolla-ansible I ran into a few issues with
>>> init-runonce script. This lead to following bugs and patches:
>>>
>>> https://launchpad.net/bugs/1732963 
>>> https://review.openstack.org/51
>>> 
>>> https://review.openstack.org/521190
>>> 
>>>
>>> But it was highlighted that instead of fixing/changing the
>>> script, 'ansibilzing' it would be the ideal solution.
>>> Hence I hereby formally propose the same.
>>>
>>> My thoughts:
>>> * Playbook Name: init-stack.yml
>>>
>>> * Playbook path can be:
>>> kolla-ansible/ansible/init-stack.yml
>>>
>>> * The play can be executed like:
>>> $ kolla-ansible init-stack -i 
>>>
>>> * The cirros test image should be downloaded in /tmp
>>>
>>> * What should be the behavior if the play is run multiple times
>>> against the same stack?
>>>- some error message OR
>>>- simply ignore the action
>>>
>>> Kindly provide suggestions.
>>>
>>> --
>>> Best Regards,
>>> Ravi J.
>>>
>>> 
>>> __
>>> 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
>>> 
>>>
>>> --
>>> Regards,
>>> Jeffrey Zhang Blog: http://xcodest.me 
>>>
>>> __
>>> 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
>
> --
> Regards,
> Jeffrey Zhang
> Blog: [http://xcodest.me](http://xcodest.me/)__
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] [octavia] connection to external network

[Volodymyr Litovka]

Hi colleagues,

found the solution, it need to be done manually. No corresponding 
Octavia configuration responsible for this.


Everything works, thank you :-)


On 11/27/17 11:30 AM, Volodymyr Litovka wrote:


Hello colleagues,

I think I'm missing something architectural in LBaaS / Octavia, thus 
asking there - how to connect Amphora agent to external network? My 
current lab topology is the following:


    +
    |
    |    ++
    +   ++ n1 |
    |    +-+    |    ++
    ++ Amphora ++
    |    +-+    |    ++
  m | n ++ n2 |
  g | b |    ++    + e
  m | t |  | x
  t |   |    ++    | t
    | s ++ vR ++ e
    | u |    ++    | r
   ++ b |  | n
   | Controller | n |    ++    | a
   ++ e |+ n3 |    + l
  t |    ++
    +

where "Amphora" is agent which loadbalances requests between "n1" and 
"n2":


  * openstack loadbalancer create --name lb1 --vip-subnet-id
nbt-subnet --project bush
  * openstack loadbalancer listener create --protocol TCP
--protocol-port 80 --name lis1 lb1
  * openstack loadbalancer pool create --protocol TCP --listener lis1
--name lpool1 --lb-algorithm ROUND_ROBIN
  * openstack loadbalancer member create --protocol-port 80 --name n1
--address 1.1.1.11 lpool1
  * openstack loadbalancer member create --protocol-port 80 --name n2
--address 1.1.1.14 lpool1

Everything works (n3-sourced connections to Amphora-agent return 
answers from n1 and n2 respectively in round robin way) and the 
question is how to connect Amphora-agent to external network in order 
to service requests from outside?


In example above, nbt-subnet (which is VIP network) has a virtual 
router which is connected to external network and has all abilities to 
provide e.g. floating ip to Amphora, but I see nothing in octavia 
config files regarding floating ip functions.


Am I missing something? Any ways on connect Web-servers in closed 
(project's) networks with Internet using Octavia / LBaaS?


Thank you!

--
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison


--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

__
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] [tripleo] Tripleo CI Community meeting tomorrow

[Arx Cruz]

Hello

We are going to have a TripleO CI Community meeting tomorrow 11/29/2017 at
1 pm UTC time.
The meeting is going to happen on BlueJeans [1] and also on IRC on #tripleo
 channel.

After that, we will hold Office Hours starting at 4PM UTC in case someone
from community have any questions related to CI.

Hope to see you there.

1 - https://bluejeans.com/7071866728



Kind regards,
Arx Cruz
__
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] [ironic] networking-generic-switch core team update

[Vasyl Saienko]

Hello Ironic!

Recently networking-generic-switch was added to OpenStack baremetal program
[0]. And I would like to announce n-g-s core team changes:

 * add ironic-core to n-g-s-core as it is done for other ironic sub-projects
 * add mgoddard to n-g-s-core team as his reviews/commits are very useful



[0] https://review.openstack.org/#/c/521894/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Status of adding global-req-id support in neutron

[Bhor, Dinesh]

Hi Neutron devs,

This is regarding adding global-req-id support in Neutron projects.

Below is the spec and URL for reference:
spec: https://review.openstack.org/#/c/464746/
status of patches submitted: 
https://review.openstack.org/#/q/message:I65de8261746b25d45e105394f4eeb95b9cb3bd42

Is anyone working on adding global-req-id support in neutron project ?
I would like to know the status of this feature.
I was having information that Sean Dague is working on this.

@Sean-
It will be great if your share the status of adding global-req-id support in 
neutron.
I will be happy to help if required.

Thanks and Regards,
Dinesh Bhor | App. Software Dev. Cnslt.
dinesh.b...@nttdata.com | m. +91.9730809841 | 
VOIP. 8833 8622
NTT DATA Services | nttdataservices.com | 
@nttdataservices  | Digital & Application Services


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [kolla] Ansiblize init-runonce script

[Jeffrey Zhang]

in my opinion,
​
​
idempotent scrip
​t is very necessary.
for several reason

- there is already some idempotent logical in the script
- it is common that this script failed by wrong configuration,
  after fix the config,
ops will want to run this script again.

On Tue, Nov 28, 2017 at 7:14 PM, Paul Bourke  wrote:

> I think this came up before at one stage. My position is I don't see the
> need to ansible-ise small shell scripts. init-runonce is currently just an
> easy to understand sequence of openstack commands provided to help people
> test/demo their setups. Unless we want to make it more than that, i.e. make
> it idempotent, customizable, etc. I don't see the need to wheel in Ansible.
>
> On 28/11/17 03:23, Jeffrey Zhang wrote:
>
>> hi
>>
>> check this [0]. I tried to convert it  to ansible playbooks.
>>
>> [0] https://review.openstack.org/523072
>>
>> On Tue, Nov 28, 2017 at 2:57 AM, Ravi Shekhar Jethani <
>> rsjeth...@gmail.com > wrote:
>>
>> Hi,
>>
>> While exploring kolla-ansible I ran into a few issues with
>> init-runonce script. This lead to following bugs and patches:
>>
>> https://launchpad.net/bugs/1732963 > 32963>
>> https://review.openstack.org/51
>> 
>> https://review.openstack.org/521190
>> 
>>
>> But it was highlighted that instead of fixing/changing the
>> script, 'ansibilzing' it would be the ideal solution.
>> Hence I hereby formally propose the same.
>>
>> My thoughts:
>> * Playbook Name: init-stack.yml
>>
>> * Playbook path can be:
>> kolla-ansible/ansible/init-stack.yml
>>
>> * The play can be executed like:
>> $ kolla-ansible init-stack -i 
>>
>> * The cirros test image should be downloaded in /tmp
>>
>> * What should be the behavior if the play is run multiple times
>> against the same stack?
>>- some error message OR
>>- simply ignore the action
>>
>> Kindly provide suggestions.
>>
>> --
>> Best Regards,
>> Ravi J.
>>
>> 
>> __
>> 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
>> 
>>
>>
>>
>>
>> --
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me 
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [docs] Documentation meeting Wednesday

[Petr Kovar]

Hi all,

The docs meeting will continue tomorrow, Wednesday at 16:00 UTC in
#openstack-doc, as scheduled. For more details, and the agenda, see the meeting 
page:

https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

Cheers,
pk

__
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] [docs] Summary of Summit docs sessions

[Petr Kovar]

Hi all,

To keep everybody updated on the recent docs meetups and IRL conversations,
I wanted to share a summary of the Sydney Summit docs sessions that I
took part in. Though a bit belated, posting it just in time before the next
docs meeting this Wednesday.

https://www.rdoproject.org/blog/2017/11/summary-openstack-summit-docs-sessions/

If I missed any docs-related discussions at the Summit, please let the
community know in this thread.

Cheers,
pk

__
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] [horizon][heat] heat-dashboard is ready for Horizon team's review

[Akihiro Motoki]

Hi Kaz,

Good hear the good progress of heat-dashboard. Thanks.

I created a blueprint in horizon to track the effort (mainly in
horizon side) and assign it to you:
https://blueprints.launchpad.net/horizon/+spec/heat-dashboard-split-out
I also left comments in your etherpad.

I think it is time to prepare a patch which drops heat-dashboard code
from horizon and test the new dashboard with it. Could you propose the
patch?

Thanks,
Akihiro


2017-11-28 16:32 GMT+09:00 Kaz Shinohara :
> Hi Horizon team,
>
>
> As I talked with Rob & Ying in Sydney, now heat-dashboard repo is
> ready, please kindly review it.
>
> http://git.openstack.org/cgit/openstack/heat-dashboard
>
> Also we described points to be clarified in this review, if you find
> anything to be noted/fixed, please feel free to put your comment on
> this etherpad, we will respond to them.
>
> https://etherpad.openstack.org/p/heat-dashboard-review-point
>
> We are planning to land heat-dashboard in queens-2, hopefully we will
> fix any issue until then.
>
> Your cooperation will be highly appreciated.
>
> Regards,
> Kaz Shinohara
>
> __
> 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] [tripleo] configuring qemu.conf using puppet or ansible

[Saravanan KR]

On Fri, Nov 24, 2017 at 10:09 PM, Alex Schultz  wrote:
> On Fri, Nov 24, 2017 at 5:03 AM, Saravanan KR  wrote:
>> Hello,
>>
>> For dpdk in ovs2.8, the default permission of vhost user ports are
>> modified from root:root  to openvswitch:hugeltbfs. The vhost user
>> ports are shared between ovs and libvirt (qemu). More details on BZ
>> [1].
>>
>> The "group" option in /etc/libvirt/qemu.conf [2] need to set as
>> "hugetlbfs" for vhost port to be shared between ovs and libvirt. In
>> order to configure qemu.conf, I could think of multiple options:
>>
>> * By using puppet-libvirt[3] module, but this module is altering lot
>> of configurations on the qemu.conf as it is trying to rewrite the
>> complete qemu.conf file. It may be different version of conf file
>> altogether as we might override the package defaults, depending on the
>> package version used.
>>
>
> We currently do not use puppet-libvirt and qemu settings are managed
> via puppet-nova with augeas[0][1].

Thanks Alex for this pointer.
>
>> * Other possibility is to configure the qemu.conf file directly using
>> the "init_setting" module like [4].
>>
>> * Considering the move towards ansible, I would prefer if we can add
>> ansible based configuration along with docker-puppet for any new
>> modules going forward. But I am not sure of the direction.
>>
>
> So you could use ansible provided that the existing settings are not
> managed via another puppet module. The problem with mixing both puppet
> and ansible is ensuring that only one owns the thing being touched.
> Since we use augeas in puppet-nova, this should not conflict with the
> usage of ini_setting with ansible.  Unfortunately libvirt is not
> currently managed as a standalone service so perhaps it's time to
> evaluate how we configure it since multiple services (nova/ovs) need
> to factor into it's configuration.
>
I was under the assumption that a new puppet module need to be
included for it, which made me to drift towards ansible. Since we are
configuring qemu.conf via puppet-nova (hiera data), I don't want to
create an intermediary step with ansible ini_setting, as the final
goal would be to create ansible-role-k8s-novalibvirt, which will
configure qemu.conf. I will stick to the existing puppet approach,
unless I find a solid reason to switch.

Regards,
Saravanan KR

> Thanks,
> -Alex
>
> [0] 
> https://github.com/openstack/puppet-nova/blob/30f9d47ec43519599f63f8a6f8da43b7dcb86242/manifests/compute/libvirt/qemu.pp
> [1] 
> https://github.com/openstack/puppet-nova/blob/9b98e3b0dee5f103c9fa32b37ff1a29df4296957/manifests/migration/qemu.pp
>
>> Prefer the feedback before proceeding with an approach.
>>
>> Regards,
>> Saravanan KR
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1515269
>> [2]  https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu.conf#L412
>> [3] https://github.com/thias/puppet-libvirt
>> [4] https://review.openstack.org/#/c/522796/1/manifests/profile/base/dpdk.pp
>>
>> __
>> 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-dev] [oslo] Oslo weekly meeting time has changed!

[ChangBo Guo]

Oslo folks,

As we discussed in last two weekly meeting, we decide adjust the meeting
time to let more people join in easier [1].  That means  we schedule weekly
meeting in chanel #openstack-oslo at UTC 15:00 from next Monday

[1] https://review.openstack.org/522740

-- 
ChangBo Guo(gcb)
Community Director @EasyStack
__
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] [kolla] Ansiblize init-runonce script

[Paul Bourke]

I think this came up before at one stage. My position is I don't see the 
need to ansible-ise small shell scripts. init-runonce is currently just 
an easy to understand sequence of openstack commands provided to help 
people test/demo their setups. Unless we want to make it more than that, 
i.e. make it idempotent, customizable, etc. I don't see the need to 
wheel in Ansible.


On 28/11/17 03:23, Jeffrey Zhang wrote:

hi

check this [0]. I tried to convert it  to ansible playbooks.

[0] https://review.openstack.org/523072

On Tue, Nov 28, 2017 at 2:57 AM, Ravi Shekhar Jethani 
> wrote:


Hi,

While exploring kolla-ansible I ran into a few issues with
init-runonce script. This lead to following bugs and patches:

https://launchpad.net/bugs/1732963 
https://review.openstack.org/51

https://review.openstack.org/521190


But it was highlighted that instead of fixing/changing the
script, 'ansibilzing' it would be the ideal solution.
Hence I hereby formally propose the same.

My thoughts:
* Playbook Name: init-stack.yml

* Playbook path can be:
kolla-ansible/ansible/init-stack.yml

* The play can be executed like:
$ kolla-ansible init-stack -i 

* The cirros test image should be downloaded in /tmp

* What should be the behavior if the play is run multiple times
against the same stack?
   - some error message OR
   - simply ignore the action

Kindly provide suggestions.

--
Best Regards,
Ravi J.

__
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





--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me 


__
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] Dublin PTG format

[Davanum Srinivas]

On Tue, Nov 28, 2017 at 4:46 AM, Chris Dent  wrote:
> On Tue, 28 Nov 2017, Flavio Percoco wrote:
>
>> Others have raised concerns about being able to properly keep the momentum
>> of
>> the day going if we adopt the new format. I have to admit that I'm also
>> concerned about this. Switching context every half day may not be ideal.
>
>
> This is the real crux of the biscuit. For team oriented work being
> able to get into the nova-zone (or whatever) for an extended period
> is important. Having to switch in and out of that per day would not
> be pleasant and would also make the time less effective.
>
> At base, I think part of the challenge with how we manage this stuff
> is that because the available time is such a scarce resource (10
> days out of 365) we want to make sure we touch upon everything that
> matters. But bouncing from topic to topic means that each topic and
> the people involved do not get the depth of engagement for it to
> really matter. In the end what matters is not so much that we talk
> about any particular topic, but that we talk about any topic, so
> that we develop the shared language that allows us to talk about it
> more later.
>
> Which is just a long-winded way of saying: Let's not parcel time
> into small chunks.

+1 to " Let's not parcel time into small chunks."

> --
> Chris Dent  (⊙＿⊙') https://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> 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
>



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

Re: [openstack-dev] [all] Dublin PTG format

[Chris Dent]

On Tue, 28 Nov 2017, Flavio Percoco wrote:


Others have raised concerns about being able to properly keep the momentum of
the day going if we adopt the new format. I have to admit that I'm also
concerned about this. Switching context every half day may not be ideal.


This is the real crux of the biscuit. For team oriented work being
able to get into the nova-zone (or whatever) for an extended period
is important. Having to switch in and out of that per day would not
be pleasant and would also make the time less effective.

At base, I think part of the challenge with how we manage this stuff
is that because the available time is such a scarce resource (10
days out of 365) we want to make sure we touch upon everything that
matters. But bouncing from topic to topic means that each topic and
the people involved do not get the depth of engagement for it to
really matter. In the end what matters is not so much that we talk
about any particular topic, but that we talk about any topic, so
that we develop the shared language that allows us to talk about it
more later.

Which is just a long-winded way of saying: Let's not parcel time
into small chunks.

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
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] Community managed tech/dev blog: Call for opinions and ideas

[Thierry Carrez]

Flavio Percoco wrote:
> On 27/11/17 13:14 -0600, Jimmy McArthur wrote:
>>
>>
>> Joshua Harlow wrote:
>>> With say an editor that solicits (and backlogs topics and stories
>>> and such) various developers/architects at various companies and
>>> creates a actually human curated place for developers and technology
>>> and architecture to be spot-lighted.
>>>
>>> To me personal blogs can be used for this, sure, but that sort of
>>> misses the point of having a place that is targeted for this (and no
>>> I don't really care about finding and subscribing to 100+ random joe
>>> blogs that I will never look at more than once). Ideally that place
>>> would not become `elitist` as some others have mentioned in this
>>> thread (ie, don't pick an elitist editor? lol).
>>>
>>> The big desire for me is to actually have a editor (a person or
>>> people) involved that is keeping such a blog going and editing it
>>> and curating it and ensuring it gets found in google searches and is
>>> *developer* focused...
>>
>> This is basically what https://www.openstack.org/blog/ is for. It's
>> using Wordpress. It's developer-centric. Anyone can submit to it and
>> we have editors that can publish it. We also have pretty solid SEO.
> 
> Interestingly enough, not many folks are (were) aware of this. It was not
> brought up during the discussion at the forum. I'm glad you did, though.
> 
> If we already have a platform for this then I would say we need to
> promote it
> more and find someone (Josh? ;) that will actively seek for content.
> 
> Thanks for pointing us to o.o/blog, Jimmy.

Historically blog.o.o used to be our only blog outlet, so almost
anything would go in:

"OpenStack Events Sponsorship Webinar"
"New Foundation Gold Members & Corporate Sponsors"
"HP Announces Private Beta Program for OpenStack Cloud"
"2016 OpenStack T-Shirt Design Contest"

What Josh wants is a curated technical blog, so if we reused blog.o.o
for this (and I think it's a good idea), we'd likely want to have a bit
more rules on what's appropriate.

-- 
Thierry Carrez (ttx)



signature.asc
Description: OpenPGP digital signature
__
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] Dublin PTG format

[Flavio Percoco]

On 27/11/17 14:21 -0500, Doug Hellmann wrote:

Excerpts from Thierry Carrez's message of 2017-11-27 11:58:04 +0100:

Hi everyone,

We are in the final step in the process of signing the contract with the
PTG venue. We should be able to announce the location this week !

So it's time to start preparing. We'll have 5 days, like in Denver. One
thing we'd like to change for this round is to give a bit more
flexibility in the topics being discussed, especially in the first two days.

In Denver, we selected a number of general "themes" and gave them all a
room for 2 days on Monday-Tuesday. Then all the "teams" that wanted a
project team meeting could get a room for 2 or 3 days on
Wednesday-Friday. That resulted in a bit of flux during the first two
days, with a lot of empty rooms as most of the themes did not really
need 2 days, and a lot of conflicts were present.

For Dublin, the idea would be to still predetermine topics (themes and
teams) and assign them rooms in advance. But we would be able to assign
smaller amounts of time (per half-day) based on the expressed needs.
Beyond those pre-assigned themes/teams we'd add flexibility for other
groups to book the remaining available rooms in 90-min slots on-demand.
A bit like how we did reservable rooms in the past, but more integrated
with the rest of the event. It would all be driven by the PTGbot, which
would show which topic is being discussed in which room, in addition to
the current discussion subject within each topic.

We have two options in how we do the split for predetermined topics. We
used to split the week between Mon-Tue (themes) and Wed-Fri (teams). The
general idea there was to allow some people only interested in a team
meeting to only attend the second part of the week. However most people
attend all 5 days, and during event feedback some people suggested that
"themes" should be in the mornings and "teams" in the afternoons (and
all Friday).

What would be your preference ? The Mon-Tue/Wed-Fri split means less
room changes, which make it easier on the events team. So all else being
equal we'd rather keep it the way it is, but I'm open to changing it if
attendees think it's a good idea.

If you have any other suggestion (that we could implement in the 3
months we have between now and the event) please let me know :)



What sort of options do we have for trying the new morning/afternoon
split approach without increasing the burden on the events team?

Can we print the signs so they have both the project team names and
a theme listed on the same sign so we can avoid changing them at
all?

Can we have the project teams or theme room organizers manage their
own signs, placing them in prepared holders outside of the rooms?


Regardless of the format, I think we can experiment with something like this.
It will give teams more flexibility.


Or do we need signs at all? The rooms all have names or numbers
already right?


Or this!

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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] [vitrage] required changes on existing devstacks

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

Due to the latest changes of the event persistor service in Vitrage[1], there 
is a need to run vitrage-dbsync on any existing devstack:

· Pull the latest changes of vitrage (if you pulled yesterday you 
should pull again)

· Run: vitrage-dbsync

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

Thanks,
Ifat.

__
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] Community managed tech/dev blog: Call for opinions and ideas

[Flavio Percoco]

On 27/11/17 13:14 -0600, Jimmy McArthur wrote:



Joshua Harlow wrote:

With say an editor that solicits (and backlogs topics and stories
and such) various developers/architects at various companies and
creates a actually human curated place for developers and technology
and architecture to be spot-lighted.

To me personal blogs can be used for this, sure, but that sort of
misses the point of having a place that is targeted for this (and no
I don't really care about finding and subscribing to 100+ random joe
blogs that I will never look at more than once). Ideally that place
would not become `elitist` as some others have mentioned in this
thread (ie, don't pick an elitist editor? lol).

The big desire for me is to actually have a editor (a person or
people) involved that is keeping such a blog going and editing it
and curating it and ensuring it gets found in google searches and is
*developer* focused...


This is basically what https://www.openstack.org/blog/ is for. It's
using Wordpress. It's developer-centric. Anyone can submit to it and
we have editors that can publish it. We also have pretty solid SEO.


Interestingly enough, not many folks are (were) aware of this. It was not
brought up during the discussion at the forum. I'm glad you did, though.

If we already have a platform for this then I would say we need to promote it
more and find someone (Josh? ;) that will actively seek for content.

Thanks for pointing us to o.o/blog, Jimmy.
Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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] Dublin PTG format

[Flavio Percoco]

On 27/11/17 11:58 +0100, Thierry Carrez wrote:

Hi everyone,

We are in the final step in the process of signing the contract with the
PTG venue. We should be able to announce the location this week !

So it's time to start preparing. We'll have 5 days, like in Denver. One
thing we'd like to change for this round is to give a bit more
flexibility in the topics being discussed, especially in the first two days.

In Denver, we selected a number of general "themes" and gave them all a
room for 2 days on Monday-Tuesday. Then all the "teams" that wanted a
project team meeting could get a room for 2 or 3 days on
Wednesday-Friday. That resulted in a bit of flux during the first two
days, with a lot of empty rooms as most of the themes did not really
need 2 days, and a lot of conflicts were present.

For Dublin, the idea would be to still predetermine topics (themes and
teams) and assign them rooms in advance. But we would be able to assign
smaller amounts of time (per half-day) based on the expressed needs.
Beyond those pre-assigned themes/teams we'd add flexibility for other
groups to book the remaining available rooms in 90-min slots on-demand.
A bit like how we did reservable rooms in the past, but more integrated
with the rest of the event. It would all be driven by the PTGbot, which
would show which topic is being discussed in which room, in addition to
the current discussion subject within each topic.

We have two options in how we do the split for predetermined topics. We
used to split the week between Mon-Tue (themes) and Wed-Fri (teams). The
general idea there was to allow some people only interested in a team
meeting to only attend the second part of the week. However most people
attend all 5 days, and during event feedback some people suggested that
"themes" should be in the mornings and "teams" in the afternoons (and
all Friday).


If most of the people attend the full week, then I would argue that the format
we used in Denver is the one that will bring more people together, People
interested in attending the full PTG and those interested only in team
discussions will participate.

If we change the format, there's a risk that we'll exclude folks only interested
in team specific rooms as it'll likely increase their travel expense and travel
time.

If we were to adopt this new format, we could work on making sure that team
discussions happen in consecutive days to avoid teams like Sahara to have
sessions on Monday afternoon and then Thursday afternoon. However, I doubt this
will work well for everyone interested only in team discussions.


What would be your preference ? The Mon-Tue/Wed-Fri split means less
room changes, which make it easier on the events team. So all else being
equal we'd rather keep it the way it is, but I'm open to changing it if
attendees think it's a good idea.


Others have raised concerns about being able to properly keep the momentum of
the day going if we adopt the new format. I have to admit that I'm also
concerned about this. Switching context every half day may not be ideal.


If you have any other suggestion (that we could implement in the 3
months we have between now and the event) please let me know :)


My suggestion is to keep it as-is. This is our 3rd PTG and the first one outside
the U.S. I would prefer us to gather some extra data and feedback before we do
any drastic change to the format of the event.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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] Creating an instance with specified subNet via Dashboard

[David Gabriel]

Dears,

I cretaed a network with 2 sub-networks.
Now, I want to create an instance and specify that this instance should get
an adsress from the second sub-network.
I am using the Dashboard but I do not know how to make this preference ?
Currently I have found some links (below) but all of them are suggesting
solution using commands.
Could you please explain to how to make the sub-network preference ?

Best regards.
Thanks in advance.

https://specs.openstack.org/openstack/nova-specs/specs/juno/approved/selecting-subnet-when-creating-vm.html
https://blueprints.launchpad.net/nova/+spec/selecting-subnet-when-creating-vm
http://ibm-blue-box-help.github.io/help-documentation/openstack/userdocs/Creating-an-Instance-with-a-Specific-Fixed-IP/
__
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] [qa] feedback on OPNFV test tools and extreme testing

[Georg Kunz]

Hi guys,

I wanted to come back to you regarding conversion we had in Sydney about the 
OPNFV tools. I am curious about your thoughts on tools such as Yardstick (and 
Functest) and in which way they meet or do not meet your requirements for 
extreme testing. In case you found the time to look at them - I know we are all 
busy - it would be great to learn your feedback. Next week is an OPNFV hackfest 
(the OPNFV equivalent to the PTG) and that's a good opportunity to discuss and 
incorporate new features and improvements. So, just let me know.

Best regards
Georg

__
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