[openstack-dev] [QA] Meeting Thursday July 13th at 8:00 UTC

[Ghanshyam Mann]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, July 13th at 8:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_July_13th_2017_.280800_UTC.29

Anyone is welcome to add an item to the agenda.

-gmann

__
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] [watcher] migration to storyboard

[Kendall Nelson]

Hello :)

I wanted to resurrect this thread and see how the discussion about the
migration was going? I haven't seen much activity on the etherpad lately
and we are eager to decide on a migration date for moving you to
Storyboard! Let us know if you have any questions here or in #storyboard.

Thanks,

-Kendall & the Storyboard Team

On Tue, Jun 13, 2017 at 2:24 AM Чадин Александр (Alexander Chadin) <
a.cha...@servionica.ru> wrote:

> Hi Watchers,
>
> I’ve prepared etherpad doc[1] to let you give your opinions about
> Storyboard migration.
> Feel free to fill it up.
>
> [1]: https://etherpad.openstack.org/p/watcher-storyboard
>
> Best Regards,
> _
> Alexander Chadin
> __
> 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] [trove][all][tc] A proposal to rearchitect Trove

[Fox, Kevin M]

There is a use case where some sites have folks buy whole bricks of compute 
nodes that get added to the overarching cloud, but using AZ's or 
HostAggregates/Flavors to dedicate the hardware to the users.

You might want to land the db vm on the hardware for that project and one would 
expect the normal quota would be dinged for it rather then a special trove 
quota. Otherwise they may have more quota then the hosts can actually handle.

Thanks,
Kevin

From: Doug Hellmann [d...@doughellmann.com]
Sent: Wednesday, July 12, 2017 6:57 AM
To: openstack-dev
Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Excerpts from Amrith Kumar's message of 2017-07-12 06:14:28 -0500:
> All:
>
> First, let me thank all of you who responded and provided feedback
> on what I wrote. I've summarized what I heard below and am posting
> it as one consolidated response rather than responding to each
> of your messages and making this thread even deeper.
>
> As I say at the end of this email, I will be setting up a session at
> the Denver PTG to specifically continue this conversation and hope
> you will all be able to attend. As soon as time slots for PTG are
> announced, I will try and pick this slot and request that you please
> attend.
>
> 
>
> Thierry: naming issue; call it Hoard if it does not have a migration
> path.
>
> 
>
> Kevin: use a container approach with k8s as the orchestration
> mechanism, addresses multiple issues including performance. Trove to
> provide containers for multiple components which cooperate to provide
> a single instance of a database or cluster. Don't put all components
> (agent, monitoring, database) in a single VM, decoupling makes
> migraiton and upgrades easier and allows trove to reuse database
> vendor supplied containers. Performance of databases in VM's poor
> compared to databases on bare-metal.
>
> 
>
> Doug Hellmann:
>
> > Does "service VM" need to be a first-class thing?  Akanda creates
> > them, using a service user. The VMs are tied to a "router" which is
> > the billable resource that the user understands and interacts with
> > through the API.
>
> Amrith: Doug, yes because we're looking not just for service VM's but all
> resources provisioned by a service. So, to Matt's comment about a
> blackbox DBaaS, the VM's, storage, snapshots, ... they should all be
> owned by the service, charged to a users quota but not visible to the
> user directly.

I still don't understand. If you have entities that represent the
DBaaS "host" or "database" or "database backup" or whatever, then
you put a quota on those entities and you bill for them. If the
database actually runs in a VM or the backup is a snapshot, those
are implementation details. You don't want to have to rewrite your
quota management or billing integration if those details change.

Doug

>
> 
>
> Jay:
>
> > Frankly, I believe all of these types of services should be built
> > as applications that run on OpenStack (or other)
> > infrastructure. In other words, they should not be part of the
> > infrastructure itself.
> >
> > There's really no need for a user of a DBaaS to have access to the
> > host or hosts the DB is running on. If the user really wanted
> > that, they would just spin up a VM/baremetal server and install
> > the thing themselves.
>
> and subsequently in follow-up with Zane:
>
> > Think only in terms of what a user of a DBaaS really wants. At the
> > end of the day, all they want is an address in the cloud where they
> > can point their application to write and read data from.
> > ...
> > At the end of the day, I think Trove is best implemented as a hosted
> > application that exposes an API to its users that is entirely
> > separate from the underlying infrastructure APIs like
> > Cinder/Nova/Neutron.
>
> Amrith: Yes, I agree, +1000
>
> 
>
> Clint (in response to Jay's proposal regarding the service making all
> resources multi-tenant) raised a concern about having multi-tenant
> shared resources. The issue is with ensuring separation between
> tenants (don't want to use the word isolation because this is database
> related).
>
> Amrith: yes, definitely a concern and one that we don't have today
> because each DB is a VM of its own. Personally, I'd rather stick with
> that construct, one DB per VM/container/baremetal and leave that be
> the separation boundary.
>
> 
>
> Zane: Discomfort over throwing out working code, grass is greener on
> the other side, is there anything to salvage?
>
> Amrith: Yes, there is certainly a 'grass is greener with a rewrite'
> fallacy. But, there is stuff that can be salvaged. The elements are
> still good, they are separable and can be used with the new
> project. Much of the controller logic however will fall by the
> wayside.
>
> In a similar vein, Clint asks about the elements that Trove provides,
> "how has that worked out".
>
> Amrith: Honestly, not well. Trove only provided reference 

Re: [openstack-dev] [Shaker] Shaker Image Builder fails in Ocata due to OS::Glance::Image deprecation

[Sai Sindhur Malleni]

Awesome Ilya. Thanks a lot.  Let me look at bringing CentOS to parity.

On Fri, Mar 3, 2017 at 8:36 AM, Ilya Shakhat  wrote:
> Hi Sai,
>
> As we discussed at PTG, I've added an option to build image using
> diskimage-builder tool. The code is not merged yet, please see
> https://review.openstack.org/#/c/441126/. With this patch
> shaker-image-builder can automatically switch to do local build using
> diskimage-builder when Glance v1 is not available. The behavior can also be
> enforced by --image-builder-mode parameter.
>
> Thanks,
> Ilya
>
>
>
> 2017-02-03 13:16 GMT+04:00 Ilya Shakhat :
>>>
>>> Starting Ocata, looks like only glance v2 is enabled by default. This
>>> breaks the shaker image builder template since we make use of the resource
>>> type OS::Glance::Image and creating images from url links is not supported
>>> in v2. How do we want deal with this? Maybe have the user pass in the
>>> name/image-id and pass them as properties to the shaker image builder
>>> template or instead advise the use to turn on the v1 API?
>>> Thoughts/suggestions?
>>>
>>
>> Looks like the only way to deal with that is to build the image manually
>> and then pass its name via --image-name parameter (or name the image
>> 'shaker-image').
>>
>> Thanks,
>> Ilya
>
>



-- 
Sai Sindhur Malleni

Software Engineer
Red Hat Inc.
100 East Davie Street
Raleigh, NC, USA
Work: (919) 754-4557 | Cell: (919) 985-1055

__
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] bug triage experimentation

[Jeremy Stanley]

On 2017-07-12 15:50:26 -0500 (-0500), Jay S Bryant wrote:
[...]
> Looking for the, 'here is what everyone needs to know to start
> using StoryBoard' documentation so I can get that linked in our
> devref.
[...]

An excellent point, and as always a bit of a challenge when
designing software for use within and outside our community to
separate documentation on "how to use X" from "how the OpenStack
community uses X." There have been a number of summit/forum
presentations and some excellent blog posts (particularly at
https://storyboard-blog.io/ ) which touch on these subjects, but of
course those are point-in-time anecdotal prose unsuited to treatment
as long-term reference documentation.

The general idea, I think, is that documentation on using the WebUI
should be readily accessible hosted alongside storyboard-webclient,
e.g. https://storyboard.openstack.org/#!/page/about (which is
realistically just a stub for now). I think it's up for debate
whether its API documentation should be there, or where it lives now
at https://docs.openstack.org/infra/storyboard/ or maybe both. And
then workflow documentation specific to our community probably
belongs somewhere like https://docs.openstack.org/infra/manual/
(there's a little bit in the Developer’s Guide there under
Development Workflow, but as always it could use expanding on).

So in summary, like with any software the documentation is
perpetually insufficient but hopefully something we can all expand
on together given adequate experience and feedback.
-- 
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

Re: [openstack-dev] [tripleo] scenario006 conflict

[Emilien Macchi]

On Wed, Jul 12, 2017 at 2:23 PM, Emilien Macchi  wrote:
[...]
> Derek, it seems like you want to deploy Ironic on scenario006
> (https://review.openstack.org/#/c/474802). I was wondering how it
> would work with multinode jobs.

Derek, I also would like to point out that
https://review.openstack.org/#/c/474802 is missing the environment
file for non-containerized deployments & and also the pingtest file.
Just for the record, if we can have it before the job moves in gate.

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

[openstack-dev] [tripleo] scenario006 conflict

[Emilien Macchi]

Hey folks,

Derek, it seems like you want to deploy Ironic on scenario006
(https://review.openstack.org/#/c/474802). I was wondering how it
would work with multinode jobs.
Also, Flavio would like to test k8s on scenario006:
https://review.openstack.org/#/c/471759/ . To avoid having too much
scenarios and complexity, I think if ironic tests can be done on a
2nodes job, then we can deploy ironic on scenario004 maybe. If not,
then please give the requirements so we can see how to structure it.

For Flavio's need, I think we need a dedicated scenario for now, since
he's not going to deploy any OpenStack service on the overcloud for
now, just k8s.

Thanks for letting us know the plans, so we can keep the scenarios in
good shape.
Note: Numans also wants to test OVN and I suggested to create
scenario007 (since we can't deploy OVN before Pike, so upgrades
wouldn't work).
Note2: it seems like efforts done to test complex HA architectures
weren't finished in scenario005 - Michele: any thoughts on this one?
should we remove it now or do we expect it working one day?


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] [nova] bug triage experimentation

[Jeremy Stanley]

On 2017-07-12 14:36:21 -0600 (-0600), Sean Dague wrote:
[...]
> It would be really nice if we could this as first class support
> and not bolt on later, because I fear we're going to get pretty
> complicated adhoc schema definitions here that have to be done
> client side.

It's still not entirely clear to me what you're looking for. Like in
LP, tags aren't applied to individual tasks. In LP they're applied
to entire bugs or in SB they're applied to entire stories. Like LP
bugs, stories in SB can have tasks from multiple "projects" (which
in our case with SB map to individual Git repos). Are you requesting
some sort of namespace/prefix selector surfaced in the WebUI when
setting tag names on a story? And if so, where do we take those
namespaces from?

It seems like as a community we can just have a convention that if
someone sets a nova-foo tag on a random story that has nothing to do
with the semantics the nova team expects around the nova-foo tag,
then when that shows up in the Nova team's queries they can unset
that tag on the offending story without worry they're stepping on
anyone else's toes.

The only alternative I can think of is that we, as OpenStack, decide
how we will collectively perform all story tagging. Individual teams
have preferred to use their own workflows for defect tracking in the
past, so if they're all going to play together in a cross-project
system they either need to agree on what different tags mean or
agree to all use distinct tags. I can only assume we'll run into the
same problem in Gerrit with global review tags too, once we have
them.
-- 
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

Re: [openstack-dev] [nova] bug triage experimentation

[Jay S Bryant]

On 7/12/2017 3:44 PM, Kendall Nelson wrote:

@Jay: I would definitely urge projects to update the places they have 
any info about bug tracking since different projects use tags 
differently. I suppose we could add to the SB documentation what the 
common practices are, but I imagine there will be a lot of project 
specific details about how the project sets up their boards and 
worklists, what tags they use, how things are formatted etc that would 
be better kept elsewhere.


Agreed, this is an opportunity to for Cinder to document how we use 
StoryBoard as we migrate to it and anything that is specific to our 
usage is something we document.  :-)  I am asking if there is a high 
level common documentation location.  I found development documentation 
and links in your Wiki.  Looking for the, 'here is what everyone needs 
to know to start using StoryBoard' documentation so I can get that 
linked in our devref.


Hope that makes sense.

@Sean: Agreed! Having it dealt with before we reach critical mass in 
SB will save us later. As one of the people helping people migrate to 
sb, I will include this decision in the information I give projects 
that are migrating. I think we have a FAQ somewhere we can add the 
decision to as well.


-Kendall (diablo_rojo)

On Wed, Jul 12, 2017 at 1:34 PM Jay S Bryant > wrote:


Kendall,

It looks like our current bug tracking documentation is quite
minimal:
https://docs.openstack.org/cinder/latest/devref/launchpad.html#bug-tracking

Is there going to be a place where SB is going to be documented
with some of these details that we can link to under our
bug-tracking section?

Thanks!

Jay



On 7/12/2017 3:19 PM, Kendall Nelson wrote:

Hey Sean :)

So we discussed the issue of tag collisions in the SB meeting we
had today. Basically, we came to the conclusion that projects
should append their project to the start of the tag, thereby
avoiding collision i.e. ironic-compute, nova-compute,
manila-storage, swift-storage, cinder-storage. If we can ask bug
triagers in their respective projects to follow and uphold the
convention, we should be fine. It might also be helpful to add
this to any directions projects might have about filing bugs so
new contributors start off on the right foot.

Thanks for bringing this concern up before it becomes a problem!
If anyone has other questions or concerns, please attend our
meetings or drop into our channel (#storyboard)!

-Kendall Nelson(diablo_rojo)

[1] https://wiki.openstack.org/wiki/Meetings/StoryBoard

On Wed, Jul 12, 2017 at 5:47 AM Sean Dague > wrote:

On 07/11/2017 04:31 PM, Jeremy Stanley wrote:
> On 2017-07-10 07:33:28 -0400 (-0400), Sean Dague wrote:
> [...]
>> Ideally storyboard would just be a lot more receptive to
these kinds of
>> things, by emitting a more native event stream,
>
> Well, there is
> http://git.openstack.org/cgit/openstack-infra/storyboard/tree/storyboard/notifications/publisher.py
>
> so replacing or partnering its RabbitMQ publisher with
something
> like an MQTT publisher into firehose.openstack.org
 is probably not
> terribly hard for someone with interest in that and would be
> generally useful.
>
>> and having really good tag support (preferably actually
project
>> scoped tags, so setting it on the nova task doesn't impact the
>> neutron tasks on the same story, as an for instance)
> [...]
>
> Your queries (including those used to build automatic
tasklists and
> boards) could just include project in addition to tag,
right? Or is
> this more of a UI concern, being able to click on an
arbitrary tag
> in the webclient and only get back a set of tagged stories
for the
> same project rather than across all projects?

My concern is based on current limitations in launchpad, and
to make
sure they don't get encoded into Storyboard.

Tags in launchpad are at the Bug level. Bugs map to projects
as Tasks.
Which is why you can have 1 Bug set to be impacting both Nova and
Neutron. You get lots of weirdness today when for instance a
bug is
assigned to Nova and Ironic, and the Nova team tags it
"ironic" in
triage, but that means that now Ironic has a bug with the
"ironic" tag.
Then if later Nova is removed from the bug, it ends up really all
looking odd and confusing.

Or the fact that "compute" as a Nova tag means the compute
worker, but
other teams tag things with compute to just mean Nova is
involved.

Re: [openstack-dev] [nova] bug triage experimentation

[Kendall Nelson]

@Jay: I would definitely urge projects to update the places they have any
info about bug tracking since different projects use tags differently. I
suppose we could add to the SB documentation what the common practices are,
but I imagine there will be a lot of project specific details about how the
project sets up their boards and worklists, what tags they use, how things
are formatted etc that would be better kept elsewhere.

@Sean: Agreed! Having it dealt with before we reach critical mass in SB
will save us later. As one of the people helping people migrate to sb, I
will include this decision in the information I give projects that are
migrating. I think we have a FAQ somewhere we can add the decision to as
well.

-Kendall (diablo_rojo)

On Wed, Jul 12, 2017 at 1:34 PM Jay S Bryant  wrote:

> Kendall,
>
> It looks like our current bug tracking documentation is quite minimal:
> https://docs.openstack.org/cinder/latest/devref/launchpad.html#bug-tracking
>
> Is there going to be a place where SB is going to be documented with some
> of these details that we can link to under our bug-tracking section?
>
> Thanks!
>
> Jay
>
>
>
> On 7/12/2017 3:19 PM, Kendall Nelson wrote:
>
> Hey Sean :)
>
> So we discussed the issue of tag collisions in the SB meeting we had
> today. Basically, we came to the conclusion that projects should append
> their project to the start of the tag, thereby avoiding collision i.e.
> ironic-compute, nova-compute, manila-storage, swift-storage,
> cinder-storage. If we can ask bug triagers in their respective projects to
> follow and uphold the convention, we should be fine. It might also be
> helpful to add this to any directions projects might have about filing bugs
> so new contributors start off on the right foot.
>
> Thanks for bringing this concern up before it becomes a problem! If anyone
> has other questions or concerns, please attend our meetings or drop into
> our channel (#storyboard)!
>
> -Kendall Nelson(diablo_rojo)
>
> [1] https://wiki.openstack.org/wiki/Meetings/StoryBoard
>
> On Wed, Jul 12, 2017 at 5:47 AM Sean Dague  wrote:
>
>> On 07/11/2017 04:31 PM, Jeremy Stanley wrote:
>> > On 2017-07-10 07:33:28 -0400 (-0400), Sean Dague wrote:
>> > [...]
>> >> Ideally storyboard would just be a lot more receptive to these kinds of
>> >> things, by emitting a more native event stream,
>> >
>> > Well, there is
>> > > http://git.openstack.org/cgit/openstack-infra/storyboard/tree/storyboard/notifications/publisher.py
>> >
>> > so replacing or partnering its RabbitMQ publisher with something
>> > like an MQTT publisher into firehose.openstack.org is probably not
>> > terribly hard for someone with interest in that and would be
>> > generally useful.
>> >
>> >> and having really good tag support (preferably actually project
>> >> scoped tags, so setting it on the nova task doesn't impact the
>> >> neutron tasks on the same story, as an for instance)
>> > [...]
>> >
>> > Your queries (including those used to build automatic tasklists and
>> > boards) could just include project in addition to tag, right? Or is
>> > this more of a UI concern, being able to click on an arbitrary tag
>> > in the webclient and only get back a set of tagged stories for the
>> > same project rather than across all projects?
>>
>> My concern is based on current limitations in launchpad, and to make
>> sure they don't get encoded into Storyboard.
>>
>> Tags in launchpad are at the Bug level. Bugs map to projects as Tasks.
>> Which is why you can have 1 Bug set to be impacting both Nova and
>> Neutron. You get lots of weirdness today when for instance a bug is
>> assigned to Nova and Ironic, and the Nova team tags it "ironic" in
>> triage, but that means that now Ironic has a bug with the "ironic" tag.
>> Then if later Nova is removed from the bug, it ends up really all
>> looking odd and confusing.
>>
>> Or the fact that "compute" as a Nova tag means the compute worker, but
>> other teams tag things with compute to just mean Nova is involved.
>> Project scoped tags would help clarify what context it is in.
>>
>> -Sean
>>
>> >
>> >
>> >
>> >
>> __
>> > 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
>> >
>>
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>> __
>> 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] [nova] bug triage experimentation

[Sean Dague]

On 07/12/2017 02:19 PM, Kendall Nelson wrote:

Hey Sean :)

So we discussed the issue of tag collisions in the SB meeting we had 
today. Basically, we came to the conclusion that projects should append 
their project to the start of the tag, thereby avoiding collision i.e. 
ironic-compute, nova-compute, manila-storage, swift-storage, 
cinder-storage. If we can ask bug triagers in their respective projects 
to follow and uphold the convention, we should be fine. It might also be 
helpful to add this to any directions projects might have about filing 
bugs so new contributors start off on the right foot.


It would be really nice if we could this as first class support and not 
bolt on later, because I fear we're going to get pretty complicated 
adhoc schema definitions here that have to be done client side.


-Sean

--
Sean Dague
http://dague.net

__
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] bug triage experimentation

[Jay S Bryant]

Kendall,

It looks like our current bug tracking documentation is quite minimal: 
https://docs.openstack.org/cinder/latest/devref/launchpad.html#bug-tracking


Is there going to be a place where SB is going to be documented with 
some of these details that we can link to under our bug-tracking section?


Thanks!

Jay



On 7/12/2017 3:19 PM, Kendall Nelson wrote:

Hey Sean :)

So we discussed the issue of tag collisions in the SB meeting we had 
today. Basically, we came to the conclusion that projects should 
append their project to the start of the tag, thereby avoiding 
collision i.e. ironic-compute, nova-compute, manila-storage, 
swift-storage, cinder-storage. If we can ask bug triagers in their 
respective projects to follow and uphold the convention, we should be 
fine. It might also be helpful to add this to any directions projects 
might have about filing bugs so new contributors start off on the 
right foot.


Thanks for bringing this concern up before it becomes a problem! If 
anyone has other questions or concerns, please attend our meetings or 
drop into our channel (#storyboard)!


-Kendall Nelson(diablo_rojo)

[1] https://wiki.openstack.org/wiki/Meetings/StoryBoard

On Wed, Jul 12, 2017 at 5:47 AM Sean Dague > wrote:


On 07/11/2017 04:31 PM, Jeremy Stanley wrote:
> On 2017-07-10 07:33:28 -0400 (-0400), Sean Dague wrote:
> [...]
>> Ideally storyboard would just be a lot more receptive to these
kinds of
>> things, by emitting a more native event stream,
>
> Well, there is
> http://git.openstack.org/cgit/openstack-infra/storyboard/tree/storyboard/notifications/publisher.py
>
> so replacing or partnering its RabbitMQ publisher with something
> like an MQTT publisher into firehose.openstack.org
 is probably not
> terribly hard for someone with interest in that and would be
> generally useful.
>
>> and having really good tag support (preferably actually project
>> scoped tags, so setting it on the nova task doesn't impact the
>> neutron tasks on the same story, as an for instance)
> [...]
>
> Your queries (including those used to build automatic tasklists and
> boards) could just include project in addition to tag, right? Or is
> this more of a UI concern, being able to click on an arbitrary tag
> in the webclient and only get back a set of tagged stories for the
> same project rather than across all projects?

My concern is based on current limitations in launchpad, and to make
sure they don't get encoded into Storyboard.

Tags in launchpad are at the Bug level. Bugs map to projects as Tasks.
Which is why you can have 1 Bug set to be impacting both Nova and
Neutron. You get lots of weirdness today when for instance a bug is
assigned to Nova and Ironic, and the Nova team tags it "ironic" in
triage, but that means that now Ironic has a bug with the "ironic"
tag.
Then if later Nova is removed from the bug, it ends up really all
looking odd and confusing.

Or the fact that "compute" as a Nova tag means the compute worker, but
other teams tag things with compute to just mean Nova is involved.
Project scoped tags would help clarify what context it is in.

-Sean

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


--
Sean Dague
http://dague.net

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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


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

Re: [openstack-dev] [nova] bug triage experimentation

[Kendall Nelson]

Hey Sean :)

So we discussed the issue of tag collisions in the SB meeting we had today.
Basically, we came to the conclusion that projects should append their
project to the start of the tag, thereby avoiding collision i.e.
ironic-compute, nova-compute, manila-storage, swift-storage,
cinder-storage. If we can ask bug triagers in their respective projects to
follow and uphold the convention, we should be fine. It might also be
helpful to add this to any directions projects might have about filing bugs
so new contributors start off on the right foot.

Thanks for bringing this concern up before it becomes a problem! If anyone
has other questions or concerns, please attend our meetings or drop into
our channel (#storyboard)!

-Kendall Nelson(diablo_rojo)

[1] https://wiki.openstack.org/wiki/Meetings/StoryBoard

On Wed, Jul 12, 2017 at 5:47 AM Sean Dague  wrote:

> On 07/11/2017 04:31 PM, Jeremy Stanley wrote:
> > On 2017-07-10 07:33:28 -0400 (-0400), Sean Dague wrote:
> > [...]
> >> Ideally storyboard would just be a lot more receptive to these kinds of
> >> things, by emitting a more native event stream,
> >
> > Well, there is
> >  http://git.openstack.org/cgit/openstack-infra/storyboard/tree/storyboard/notifications/publisher.py
> >
> > so replacing or partnering its RabbitMQ publisher with something
> > like an MQTT publisher into firehose.openstack.org is probably not
> > terribly hard for someone with interest in that and would be
> > generally useful.
> >
> >> and having really good tag support (preferably actually project
> >> scoped tags, so setting it on the nova task doesn't impact the
> >> neutron tasks on the same story, as an for instance)
> > [...]
> >
> > Your queries (including those used to build automatic tasklists and
> > boards) could just include project in addition to tag, right? Or is
> > this more of a UI concern, being able to click on an arbitrary tag
> > in the webclient and only get back a set of tagged stories for the
> > same project rather than across all projects?
>
> My concern is based on current limitations in launchpad, and to make
> sure they don't get encoded into Storyboard.
>
> Tags in launchpad are at the Bug level. Bugs map to projects as Tasks.
> Which is why you can have 1 Bug set to be impacting both Nova and
> Neutron. You get lots of weirdness today when for instance a bug is
> assigned to Nova and Ironic, and the Nova team tags it "ironic" in
> triage, but that means that now Ironic has a bug with the "ironic" tag.
> Then if later Nova is removed from the bug, it ends up really all
> looking odd and confusing.
>
> Or the fact that "compute" as a Nova tag means the compute worker, but
> other teams tag things with compute to just mean Nova is involved.
> Project scoped tags would help clarify what context it is in.
>
> -Sean
>
> >
> >
> >
> >
> __
> > 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
> >
>
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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] Queens Project Teams Gathering- Denver September 11-15th

[Erin Disney]

We are less than two months out from the upcoming Project Teams Gathering in 
Denver, Colorado! 

Registration is live , and a limited 
discounted block of hotel rooms 

 are available for $149 USD until August 20th or they sell out.

Also, please remember to submit your applications for United States visas if 
needed as soon as possible due a recent increase in delays. Requests for 
invitation letters may be submitted here 
 and must 
be received by Friday, August 25, 2017. 

Please reach out to me directly or email p...@openstack.org with any questions. 

Erin Disney
OpenStack Marketing
e...@openstack.org 
> On Jun 7, 2017, at 2:30 PM, Erin Disney  wrote:
> 
> The second Project Teams Gathering will be held September 11-15th at the 
> Renaissance Hotel 
> 
>  in Denver, Colorado (3801 Quebec Street, Denver, Colorado 80207). 
> Registration, travel support program, and the discounted hotel block are now 
> live!  
>  
> PTG SCHEDULE
> The PTG will run for 5 days, Monday - Friday, September 11-15, 2017:
> Inter-project team work will be done Monday and Tuesday
> Single project meetings will be held Wednesday-Friday
> Be sure to check with your PTL before booking travel as some teams may not 
> meet all three days of the Single Project meetings during the second half of 
> the week. A work in progress schedule can be found here 
> 
>  for reference.
> 
> REGISTRATION AND HOTEL 
> Registration is now available here: https://queensptg.eventbrite.com 
> 
>  
> We've reserved a very limited block of discounted hotel rooms at $149/night 
> USD with the Renaissance Denver Stapleton Hotel where the event will be held. 
> Please move quickly to reserve a room here 
> 
>  by August 20th or until they sell out!
>  
> USA VISA APPLICATIONS 
> Please note: Due to recent delays in the visa system, please allow as much 
> time as possible for the application process if a visa is required in order 
> to travel to the United States. We normally recommend applying no later than 
> 60 days prior to the event, but based on our experience with slower 
> processing times leading into the Boston Summit, more time than that is 
> likely needed. 
>  
> If you are unsure whether you require a visa or not, please visit this page 
>  and enter 
> the country that issued your passport and the reason for your trip, and it 
> will tell you what visa to apply for if a visa is required for your travel.
>  
> Requests for invitation letters may be submitted here 
>  and 
> must be received by Friday, August 25, 2017.
>  
> 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 July 
> 2nd. More information available here 
> . 
>  
> SPONSORSHIP
> We are looking for a limited number of companies to sponsor 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 Queens PTG in Denver, please review the sponsorship prospectus and 
> contract here , and send any 
> questions to p...@openstack.org . 
> 
> Feel free to reach out to me directly with any questions, looking forward to 
> seeing everyone in Denver! 
> 
> Erin Disney
> OpenStack Marketing
> e...@openstack.org 
> 

Re: [openstack-dev] [zun] "--image-driver glance" doesn't seem to work @ master

[Waines, Greg]

k, thanks.

I changed the name of the image in Glance because I wanted to prove to myself 
that zun/docker was pulling the image from Glance and not Docker Hub.

Greg.

From: Hongbin Lu 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Wednesday, July 12, 2017 at 3:01 PM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [zun] "--image-driver glance" doesn't seem to work 
@ master

Hi Greg,

I created a bug to record the issue: 
https://bugs.launchpad.net/zun/+bug/1703955 . Due to this bug, Zun couldn’t 
find the docker image if the image was uploaded to glance under a different 
name. I think it will work if you can upload the image to glance with name 
“cirros”. For example:

$ docker pull cirros
$ docker save cirros | glance image-create --visibility public 
--container-format=docker --disk-format=raw --name cirros
$ zun run -i --name ctn-ping --image-driver glance cirros ping 8.8.8.8

Best regards,
Hongbin

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: July-12-17 1:01 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [zun] "--image-driver glance" doesn't seem to work @ 
master

Just tried this, this morning.
I can not launch a container when I specify to pull the container image from 
glance (instead of docker hub).
I get an error back from docker saying the “:latest” can not be 
found.
I tried renaming the glance image to “:latest” ... but that didn’t 
work either.


stack@devstack-zun:~/devstack$ glance image-list

+--+--+

| ID   | Name |

+--+--+

| 6483d319-69d8-4c58-b0fb-7338a1aff85f | cirros-0.3.5-x86_64-disk |

| 3055d450-d780-4699-bc7d-3b83f3391fe9 | gregos   |  <-- it 
is of container format docker

| e8f3cab8-056c-4851-9f67-141dda91b9a2 | kubernetes/pause |

+--+--+

stack@devstack-zun:~/devstack$ docker images

REPOSITORY  TAG IMAGE IDCREATED 
SIZE

scratch latest  019a481dc9ea5 days ago  
0B

kuryr/busybox   latest  a3bb6046b1195 days ago  
1.21MB

cirros  latest  f8ce316a37a718 months ago   
7.74MB

kubernetes/pauselatest  f9d5de0795392 years ago 
240kB

stack@devstack-zun:~/devstack$ zun run --name ctn-ping --image-driver glance 
gregos ping 8.8.8.8

...

...
stack@devstack-zun:~/devstack$ zun show ctn-ping
+---+-+
| Property  | Value 


  |
+---+-+
| addresses | 10.0.0.6, fdac:1365:7242:0:f816:3eff:fea4:fb65


  |
| links | ["{u'href': 
u'http://10.10.10.17:9517/v1/containers/cb83a98c-776c-4ea8-83a7-ef3430f5e6d2', 
u'rel': u'self'}", "{u'href': 
u'http://10.10.10.17:9517/containers/cb83a98c-776c-4ea8-83a7-ef3430f5e6d2', 
u'rel': u'bookmark'}"] |
| image | gregos


  |
  

 |
| status| Error 


  |

| status_reason | Docker internal error: 404 Client Error: Not Found ("No 
such image: gregos:latest").

|


stack@devstack-zun:~/devstack$



Am I doing 

Re: [openstack-dev] [zun] "--nets network=..." usage question

[Hongbin Lu]

Hi Greg,

This parameter has just been added to the CLI and it hasn’t been fully 
implemented yet. Sorry for the confusion. Here is how I expect this parameter 
to work:

1. Create from neutron network name:
$ zun run --name ctn-ping --nets network=private …

2. Create from neutron network uuid:
$ zun run --name ctn-ping --nets network=c59455d9-c103-4c05-b28c-a1f5d041d804 …

3. Create from neutron port uuid/name:
$ zun run --name ctn-ping --nets port= …

4. Give me a network:
$ zun run --name ctn-ping --nets auto …

For now, please simply ignore this parameter. Zun will find a usable network 
under your tenant to boot the container.

Best regards,
Hongbin

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: July-12-17 1:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [zun] "--nets network=..." usage question

What is expected for the “--nets network=...” parameter on zun run or create ?
Is it the network name, the subnet name, the network uuid, the subnet uuid, ... 
I think I’ve tried them all and none work.

Full logs:

stack@devstack-zun:~/devstack$ neutron net-list

neutron CLI is deprecated and will be removed in the future. Use openstack CLI 
instead.

+--+-+--+--+

| id   | name| tenant_id
| subnets  |

+--+-+--+--+

| c1731d77-c849-4b6b-b5e9-85030c8c6b52 | public  | 
dcea3cea809f40c1a53b85ec3522de36 | aec0bc66-fb6a-453b-93c7-d04537a6bb05 
2001:db8::/64   |

|  | |  
| 8c881229-982e-417b-bbaa-e86d6192afa6 172.24.4.0/24   |

| c59455d9-c103-4c05-b28c-a1f5d041d804 | private | 
c8398b3154094049960e86b3caba1a4a | e12679b1-87e6-42cf-a2fe-e0f954dbd15f 
fdac:1365:7242::/64 |

|  | |  
| a1fc0a84-8cae-4193-8d33-711b612529b7 10.0.0.0/26 |

+--+-+--+--+

stack@devstack-zun:~/devstack$

stack@devstack-zun:~/devstack$

stack@devstack-zun:~/devstack$

stack@devstack-zun:~/devstack$

stack@devstack-zun:~/devstack$ zun run --name ctn-ping --nets network=private 
cirros ping 8.8.8.8
...
stack@devstack-zun:~/devstack$ zun list
+--+--++++---+---+
| uuid | name | image  | status | 
task_state | addresses | ports |
+--+--++++---+---+
| 649724f6-2ccd-4b21-8684-8f6616228d86 | ctn-ping | cirros | Error  | None  
 |   | []|
+--+--++++---+---+
stack@devstack-zun:~/devstack$ zun show ctn-ping | fgrep reason
| status_reason | Docker internal error: 404 Client Error: Not Found 
("network private not found").  

 |
stack@devstack-zun:~/devstack$

stack@devstack-zun:~/devstack$ zun delete ctn-ping

Request to delete container ctn-ping has been accepted.

stack@devstack-zun:~/devstack$

stack@devstack-zun:~/devstack$ zun run --name ctn-ping --nets 
network=c59455d9-c103-4c05-b28c-a1f5d041d804 cirros ping 8.8.8.8

...
stack@devstack-zun:~/devstack$ zun list
+--+--++++---+---+
| uuid | name | image  | status | 
task_state | addresses | ports |
+--+--++++---+---+
| 6093bdc2-d288-4ea9-a98b-3ca055318c9e | ctn-ping | cirros | Error  | None  
 |   | []|
+--+--++++---+---+
stack@devstack-zun:~/devstack$ zun show ctn-ping | fgrep reason
| status_reason | Docker internal error: 404 Client Error: Not Found 
("network c59455d9-c103-4c05-b28c-a1f5d041d804 not found"). 

 |
stack@devstack-zun:~/devstack$



Any ideas ?

Greg.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [zun] "--image-driver glance" doesn't seem to work @ master

[Pradeep Singh]

Hi Greg,

Would be great if you log the issues at, https://bugs.launchpad.net/zun/.

Thanks,
Pradeep

On Wed, Jul 12, 2017 at 10:31 PM, Waines, Greg 
wrote:

> Just tried this, this morning.
>
> I can not launch a container when I specify to pull the container image
> from glance (instead of docker hub).
>
> I get an error back from docker saying the “:latest” can not be
> found.
>
> I tried renaming the glance image to “:latest” ... but that
> didn’t work either.
>
>
>
> *stack@devstack-zun*:*~/devstack*$ glance image-list
>
> +--+--+
>
> | ID   | Name |
>
> +--+--+
>
> | 6483d319-69d8-4c58-b0fb-7338a1aff85f | cirros-0.3.5-x86_64-disk |
>
> | 3055d450-d780-4699-bc7d-3b83f3391fe9 | gregos   |  ß
> it is of container format docker
>
> | e8f3cab8-056c-4851-9f67-141dda91b9a2 | kubernetes/pause |
>
> +--+--+
>
> *stack@devstack-zun*:*~/devstack*$ docker images
>
> REPOSITORY  TAG IMAGE IDCREATED
>   SIZE
>
> scratch latest  019a481dc9ea5 days ago
>   0B
>
> kuryr/busybox   latest  a3bb6046b1195 days ago
>   1.21MB
>
> cirros  latest  f8ce316a37a718 months ago
> 7.74MB
>
> kubernetes/pauselatest  f9d5de0795392 years ago
>   240kB
>
> *stack@devstack-zun*:*~/devstack*$ zun run --name ctn-ping --image-driver
> glance gregos ping 8.8.8.8
>
> ...
>
> ...
>
> *stack@devstack-zun*:*~/devstack*$ zun show ctn-ping
>
> +---+---
> 
> 
> --+
>
> | Property  | Value
>
>
> |
>
> +---+---
> 
> 
> --+
>
> | addresses | 10.0.0.6, fdac:1365:7242:0:f816:3eff:fea4:fb65
>
>
> |
>
> | links | ["{u'href': u'http://10.10.10.17:9517/v1/
> containers/cb83a98c-776c-4ea8-83a7-ef3430f5e6d2', u'rel': u'self'}",
> "{u'href': u'http://10.10.10.17:9517/containers/cb83a98c-776c-4ea8-
> 83a7-ef3430f5e6d2', u'rel': u'bookmark'}"] |
>
> | image | gregos
>
>
> |
>
> 
>
>   |
>
> | status| Error
>
>
> |
>
> 
>
> | status_reason | Docker internal error: 404 Client Error: Not Found
> ("No such image: gregos:latest").
>
> |
>
>
>
> 
>
> *stack@devstack-zun*:*~/devstack*$
>
>
>
>
>
> Am I doing something wrong ?
>
>
>
> Greg.
>
>
>
>
>
>
>
>
>
>
>
> FULL logs below
>
>
>
> *stack@devstack-zun*:*~/devstack*$ source openrc admin demo
>
> WARNING: setting legacy OS_TENANT_NAME to support cli tools.
>
> *stack@devstack-zun*:*~/devstack*$ docker images
>
> REPOSITORY  TAG IMAGE IDCREATED
>   SIZE
>
> kuryr/busybox   latest  a3bb6046b1195 days ago
>   1.21MB
>
> scratch latest  019a481dc9ea5 days ago
>   0B
>
> kubernetes/pauselatest  f9d5de0795392 years ago
>   240kB
>
> *stack@devstack-zun*:*~/devstack*$ docker pull cirros
>
> Using default tag: latest
>
> latest: Pulling from library/cirros
>
> a3ed95caeb02: Pull complete
>
> 8c4568d40636: Pull complete
>
> e6cc72aea3e6: Pull complete
>
> b5a1edf1e076: Pull complete
>
> Digest: sha256:9aa75497b46cc15eef625acee6
> 017d7f3e78db9bd5f7b6b933feaa38e3ae
>
> Status: Downloaded newer image for cirros:latest
>
> *stack@devstack-zun*:*~/devstack*$ docker images
>
> REPOSITORY  TAG IMAGE IDCREATED
>   SIZE
>
> scratch latest  019a481dc9ea5 days ago
>   0B
>
> kuryr/busybox   latest  a3bb6046b1195 days ago
>   1.21MB
>
> cirros  latest  f8ce316a37a718 months ago
> 7.74MB
>
> kubernetes/pauselatest  f9d5de0795392 years ago
>   240kB
>
> *stack@devstack-zun*:*~/devstack*$ glance image-list
>
> +--+--+
>
> | ID   | Name |
>
> +--+--+
>
> | 6483d319-69d8-4c58-b0fb-7338a1aff85f | cirros-0.3.5-x86_64-disk |
>
> | e8f3cab8-056c-4851-9f67-141dda91b9a2 | kubernetes/pause |
>
> 

Re: [openstack-dev] [zun] "--image-driver glance" doesn't seem to work @ master

[Hongbin Lu]

Hi Greg,

I created a bug to record the issue: 
https://bugs.launchpad.net/zun/+bug/1703955 . Due to this bug, Zun couldn’t 
find the docker image if the image was uploaded to glance under a different 
name. I think it will work if you can upload the image to glance with name 
“cirros”. For example:

$ docker pull cirros
$ docker save cirros | glance image-create --visibility public 
--container-format=docker --disk-format=raw --name cirros
$ zun run -i --name ctn-ping --image-driver glance cirros ping 8.8.8.8

Best regards,
Hongbin

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: July-12-17 1:01 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [zun] "--image-driver glance" doesn't seem to work @ 
master

Just tried this, this morning.
I can not launch a container when I specify to pull the container image from 
glance (instead of docker hub).
I get an error back from docker saying the “:latest” can not be 
found.
I tried renaming the glance image to “:latest” ... but that didn’t 
work either.


stack@devstack-zun:~/devstack$ glance image-list

+--+--+

| ID   | Name |

+--+--+

| 6483d319-69d8-4c58-b0fb-7338a1aff85f | cirros-0.3.5-x86_64-disk |

| 3055d450-d780-4699-bc7d-3b83f3391fe9 | gregos   |  <-- it 
is of container format docker

| e8f3cab8-056c-4851-9f67-141dda91b9a2 | kubernetes/pause |

+--+--+

stack@devstack-zun:~/devstack$ docker images

REPOSITORY  TAG IMAGE IDCREATED 
SIZE

scratch latest  019a481dc9ea5 days ago  
0B

kuryr/busybox   latest  a3bb6046b1195 days ago  
1.21MB

cirros  latest  f8ce316a37a718 months ago   
7.74MB

kubernetes/pauselatest  f9d5de0795392 years ago 
240kB

stack@devstack-zun:~/devstack$ zun run --name ctn-ping --image-driver glance 
gregos ping 8.8.8.8

...

...
stack@devstack-zun:~/devstack$ zun show ctn-ping
+---+-+
| Property  | Value 


  |
+---+-+
| addresses | 10.0.0.6, fdac:1365:7242:0:f816:3eff:fea4:fb65


  |
| links | ["{u'href': 
u'http://10.10.10.17:9517/v1/containers/cb83a98c-776c-4ea8-83a7-ef3430f5e6d2', 
u'rel': u'self'}", "{u'href': 
u'http://10.10.10.17:9517/containers/cb83a98c-776c-4ea8-83a7-ef3430f5e6d2', 
u'rel': u'bookmark'}"] |
| image | gregos


  |
  

 |
| status| Error 


  |

| status_reason | Docker internal error: 404 Client Error: Not Found ("No 
such image: gregos:latest").

|


stack@devstack-zun:~/devstack$



Am I doing something wrong ?

Greg.





FULL logs below


stack@devstack-zun:~/devstack$ source openrc admin demo

WARNING: setting legacy OS_TENANT_NAME to support cli tools.

stack@devstack-zun:~/devstack$ docker images

REPOSITORY  TAG IMAGE IDCREATED 
SIZE

kuryr/busybox   latest  a3bb6046b1195 days ago  
1.21MB

scratch latest  019a481dc9ea5 days ago  
0B

kubernetes/pauselatest 

[openstack-dev] [tripleo] CI Squad Meeting Summary (week 27)

[Wesley Hayutin]

Greetings,

Apologies for the delayed notes with regards to the last tripleo-ci-squad
meeting.

Highlights:

* Tempest
  * master/pike is down to 2 tempest failures [1] out of 1,337 tests
executed.
  * stable/ocata is a full pass on tempest
  * proposed tempest test to replace the tripleo ping test [3]
  * additional work is being closed out around notifications of
tempest failures and reporting.

* The periodic/promotion jobs for tripleo are migrating to rdo software
factory
  * multinode nodepool is nearly complete
  * ovb work is on going
  * containers promotion is moving to use multinode nodepool and on-going
  * Jenkins is being removed from software factory
 * Options for reporting
* request for openstack-health to be deployed in software factory
* update [4] to report on rdo software factory jobs
  * Work has started in integrating the delorean-api for promotions

* Default network isolation is moving towards multi-nic across jobs [5]

That is about it, till next time.. be cool :)

[1]
http://logs.openstack.org/periodic/periodic-tripleo-ci-centos-7-ovb-nonha-tempest-oooq-master/85815d1/logs/oooq/stackviz/#/stdin
[2]
http://logs.openstack.org/periodic/periodic-tripleo-ci-centos-7-ovb-nonha-tempest-oooq-ocata/44dab99/logs/oooq/stackviz/#/stdin
[3] https://review.openstack.org/#/c/480429/
[4] http://cistatus.tripleo.org/#periodictab
[5]
https://review.openstack.org/#/q/status:open+branch:master+topic:libvirt-multi-nic


Notes:
https://etherpad.openstack.org/p/tripleo-ci-squad-meeting
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [zun] "--nets network=..." usage question

[Waines, Greg]

What is expected for the “--nets network=...” parameter on zun run or create ?
Is it the network name, the subnet name, the network uuid, the subnet uuid, ... 
I think I’ve tried them all and none work.

Full logs:

stack@devstack-zun:~/devstack$ neutron net-list

neutron CLI is deprecated and will be removed in the future. Use openstack CLI 
instead.

+--+-+--+--+

| id   | name| tenant_id
| subnets  |

+--+-+--+--+

| c1731d77-c849-4b6b-b5e9-85030c8c6b52 | public  | 
dcea3cea809f40c1a53b85ec3522de36 | aec0bc66-fb6a-453b-93c7-d04537a6bb05 
2001:db8::/64   |

|  | |  
| 8c881229-982e-417b-bbaa-e86d6192afa6 172.24.4.0/24   |

| c59455d9-c103-4c05-b28c-a1f5d041d804 | private | 
c8398b3154094049960e86b3caba1a4a | e12679b1-87e6-42cf-a2fe-e0f954dbd15f 
fdac:1365:7242::/64 |

|  | |  
| a1fc0a84-8cae-4193-8d33-711b612529b7 10.0.0.0/26 |

+--+-+--+--+

stack@devstack-zun:~/devstack$

stack@devstack-zun:~/devstack$

stack@devstack-zun:~/devstack$

stack@devstack-zun:~/devstack$

stack@devstack-zun:~/devstack$ zun run --name ctn-ping --nets network=private 
cirros ping 8.8.8.8
...
stack@devstack-zun:~/devstack$ zun list
+--+--++++---+---+
| uuid | name | image  | status | 
task_state | addresses | ports |
+--+--++++---+---+
| 649724f6-2ccd-4b21-8684-8f6616228d86 | ctn-ping | cirros | Error  | None  
 |   | []|
+--+--++++---+---+
stack@devstack-zun:~/devstack$ zun show ctn-ping | fgrep reason
| status_reason | Docker internal error: 404 Client Error: Not Found 
("network private not found").  

 |
stack@devstack-zun:~/devstack$

stack@devstack-zun:~/devstack$ zun delete ctn-ping

Request to delete container ctn-ping has been accepted.

stack@devstack-zun:~/devstack$

stack@devstack-zun:~/devstack$ zun run --name ctn-ping --nets 
network=c59455d9-c103-4c05-b28c-a1f5d041d804 cirros ping 8.8.8.8

...
stack@devstack-zun:~/devstack$ zun list
+--+--++++---+---+
| uuid | name | image  | status | 
task_state | addresses | ports |
+--+--++++---+---+
| 6093bdc2-d288-4ea9-a98b-3ca055318c9e | ctn-ping | cirros | Error  | None  
 |   | []|
+--+--++++---+---+
stack@devstack-zun:~/devstack$ zun show ctn-ping | fgrep reason
| status_reason | Docker internal error: 404 Client Error: Not Found 
("network c59455d9-c103-4c05-b28c-a1f5d041d804 not found"). 

 |
stack@devstack-zun:~/devstack$



Any ideas ?

Greg.
__
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] [zun] "--image-driver glance" doesn't seem to work @ master

[Waines, Greg]

Just tried this, this morning.
I can not launch a container when I specify to pull the container image from 
glance (instead of docker hub).
I get an error back from docker saying the “:latest” can not be 
found.
I tried renaming the glance image to “:latest” ... but that didn’t 
work either.


stack@devstack-zun:~/devstack$ glance image-list

+--+--+

| ID   | Name |

+--+--+

| 6483d319-69d8-4c58-b0fb-7338a1aff85f | cirros-0.3.5-x86_64-disk |

| 3055d450-d780-4699-bc7d-3b83f3391fe9 | gregos   |  <-- it 
is of container format docker

| e8f3cab8-056c-4851-9f67-141dda91b9a2 | kubernetes/pause |

+--+--+

stack@devstack-zun:~/devstack$ docker images

REPOSITORY  TAG IMAGE IDCREATED 
SIZE

scratch latest  019a481dc9ea5 days ago  
0B

kuryr/busybox   latest  a3bb6046b1195 days ago  
1.21MB

cirros  latest  f8ce316a37a718 months ago   
7.74MB

kubernetes/pauselatest  f9d5de0795392 years ago 
240kB

stack@devstack-zun:~/devstack$ zun run --name ctn-ping --image-driver glance 
gregos ping 8.8.8.8

...

...
stack@devstack-zun:~/devstack$ zun show ctn-ping
+---+-+
| Property  | Value 


  |
+---+-+
| addresses | 10.0.0.6, fdac:1365:7242:0:f816:3eff:fea4:fb65


  |
| links | ["{u'href': 
u'http://10.10.10.17:9517/v1/containers/cb83a98c-776c-4ea8-83a7-ef3430f5e6d2', 
u'rel': u'self'}", "{u'href': 
u'http://10.10.10.17:9517/containers/cb83a98c-776c-4ea8-83a7-ef3430f5e6d2', 
u'rel': u'bookmark'}"] |
| image | gregos


  |
  

 |
| status| Error 


  |

| status_reason | Docker internal error: 404 Client Error: Not Found ("No 
such image: gregos:latest").

|


stack@devstack-zun:~/devstack$



Am I doing something wrong ?

Greg.





FULL logs below


stack@devstack-zun:~/devstack$ source openrc admin demo

WARNING: setting legacy OS_TENANT_NAME to support cli tools.

stack@devstack-zun:~/devstack$ docker images

REPOSITORY  TAG IMAGE IDCREATED 
SIZE

kuryr/busybox   latest  a3bb6046b1195 days ago  
1.21MB

scratch latest  019a481dc9ea5 days ago  
0B

kubernetes/pauselatest  f9d5de0795392 years ago 
240kB

stack@devstack-zun:~/devstack$ docker pull cirros

Using default tag: latest

latest: Pulling from library/cirros

a3ed95caeb02: Pull complete

8c4568d40636: Pull complete

e6cc72aea3e6: Pull complete

b5a1edf1e076: Pull complete

Digest: sha256:9aa75497b46cc15eef625acee6017d7f3e78db9bd5f7b6b933feaa38e3ae

Status: Downloaded newer image for cirros:latest

stack@devstack-zun:~/devstack$ docker images

REPOSITORY  TAG IMAGE IDCREATED 
SIZE

scratch latest  019a481dc9ea5 days ago  
0B

kuryr/busybox   latest  a3bb6046b1195 days ago  
1.21MB

cirros  latest  

[openstack-dev] Identification Needed for Themes of Automatically Extracted Topics

[Ray Wen]

Dear OpenStack developer community member,

We have designed a research project to explore trends in code review as 
reviewers and the OpenStack developer community age. To do so, we apply Latent 
Dirichlet Allocation (LDA)—a popular Natural Language Processing (NLP) 
technique—to 506,590 archived review comments from the OpenStack Gerrit 
repositories. The LDA model automatically produced 15 topics based on the 
co-occurrence of words in review comments.

We would like to incorporate insights from the OpenStack developer 
community in order to identify the themes within these topics. Please suggest a 
theme title for each of the listed keywords from an extracted topic at 
https://goo.gl/forms/xAq98Rs9YWYUejlB3

Many thanks,
Ray Wen and Shane McIntosh
__
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] [glance][nova] Examples of how to set --block-device for disk passthrough to guest

[Lawrence J. Albinson]

Dear Colleagues,

I am trying to pass through a raw local disk from the hypervisor to one of its 
guests under openstack.

I have read https://wiki.openstack.org/wiki/Raw-device-mapping-support which 
seems to address my requirement.

I have done the first step, namely:

 glance image-update --property hw_scsi_model=virtio-scsi 

and the image seems to work and reflect the change in the libvirt XML.

What I cannot find (with apologies if I haven't looked hard enough) is examples 
of how to set the --block-device parameters for 'nova boot' / 'openstack server 
create'.

As ever, any help would be very gratefully received.

Kind regards, Lawrence

Lawrence J Albinson
__
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] [heat] Online video meet up this week (topic:review)

[Jeremy Stanley]

On 2017-07-12 21:28:28 +0800 (+0800), Rico Lin wrote:
> First, please don't worry about that replacing issue, because we
> never want to replace IRC meeting in anyway. And to make this
> clear, this is not even a experiment to do so.
[...]

Great, that's a relief.

> And thanks for correct my semantics issue, I already send another
> ML out for clearfy that. Will choose my word carefully. We
> definitely don't want and misstaken of the reason why we host the
> meetup here, so thank you for that.
[...]

Yes, I saw the updated invite information and it was much clearer as
to the intent. Thanks for clarifying!

> The sad, OpenStack already start to adopt something here (I'm
> actually agree with you and we should kill
> https://openstack.webex.com)

My understanding is that it exists primarily to host the OpenStack
Foundation Board of Directors meetings and as a bridge for
coordinating similar sorts of discussions between representatives of
member companies, but all that is outside the jurisdiction of our
technical community and is targeting a different audience with
sometimes significantly different priorities from ours. It's a
resource for the OpenStack Foundation in its day-to-day operations
as a nonprofit trade organization, and their needs and goals aren't
always the same as those of the community of contributors to the
OpenStack project itself.

I'm not thrilled by it either, but I've come to accept that the
users of that service are hamstrung by a dependence on specific
technologies due to frequent interaction with other demographics who
don't necessarily share our community ideals.
-- 
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

Re: [openstack-dev] [keystone] office hours report 2017-7-7

[Lance Bragstad]

On 07/12/2017 09:17 AM, Akihiro Motoki wrote:
> 2017-07-12 10:35 GMT+09:00 Lance Bragstad :
>> Hey all,
>>
>> This is a summary of what was worked on today during office hours. Full logs
>> of the meeting can be found below:
>>
>> http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-07-11-19.00.log.html
> It is not specific to keystone.
>
> I think it is better to use keystone-office-hours instead of
> office-hours as a meeting name.
> If we use the same meeting names, we will have office-hours logs of
> multiple projects
> in a same directory in eavesdrop.openstack.org.
>
> Thanks,
> Akihiro

Ah - good point. Thanks for the heads up! I'll be sure to do that for
next week's session.

>> The future of the templated catalog backend
>>
>> Some issues were uncovered, or just resurfaced, with the templated catalog
>> backend. The net of the discussion boiled down to - do we fix it or remove
>> it? The answer actually ended up being both. It was determined that instead
>> of trying to maintain and fix the existing templated backend, we should
>> deprecate it for removal [0]. Since it does provide some value, it was
>> suggested that we can start implementing a new backend based on YAML to fill
>> the purpose instead. The advantage here is that the approach is directed
>> towards a specific format (YAML). This should hopefully make things easier
>> for both developers and users.
>>
>> [0] https://review.openstack.org/#/c/482714/
>>
>> Policy fixes
>>
>> All the policy-in-code work has exposed several issues with policy defaults
>> in keystone. We spent time as a group going through several of the bugs [0]
>> [1] [2] [3], the corresponding fixes, and impact. One of which will be
>> backported specifically for the importance of communicating a release note
>> to stable users [0].
>>
>> [0] https://bugs.launchpad.net/keystone/+bug/1703369
>> [1] https://bugs.launchpad.net/keystone/+bug/1703392
>> [2] https://bugs.launchpad.net/keystone/+bug/1703467
>> [3] https://bugs.launchpad.net/keystone/+bug/1133435
>>
>> Additional bugs worked
>>
>> Transient bug with security compliance or PCI-DSS:
>> https://bugs.launchpad.net/keystone/+bug/1702211
>> Request header issues: https://bugs.launchpad.net/keystone/+bug/1689468
>>
>>
>> I hope to find ways to automate most of what is communicated in this
>> summary. Until then I'm happy to hear feedback if you find the report
>> lacking in a specific area.
>>
>>
>> Thanks,
>>
>> Lance
>>
>>
>> __
>> 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] [tripleo][ci] decreased coverage for telemetry

[Wesley Hayutin]

On Wed, Jul 12, 2017 at 10:33 AM, Pradeep Kilambi  wrote:

> On Tue, Jul 11, 2017 at 10:06 PM, Wesley Hayutin 
> wrote:
> >
> >
> > On Tue, Jul 11, 2017 at 9:04 PM, Emilien Macchi 
> wrote:
> >>
> >> On Tue, Jul 11, 2017 at 12:41 PM, Pradeep Kilambi 
> wrote:
> >> > On Tue, Jul 11, 2017 at 3:17 PM, Wesley Hayutin 
> >> > wrote:
> >> >> Greetings,
> >> >>
> >> >> I was looking through the mailing list and I did not see any emails
> >> >> explicitly calling out the decreased coverage for telemetry in
> tripleo
> >> >> due
> >> >> to [1].  A series of changes went into the CI system to disable
> >> >> telemetry
> >> >> [2].
> >> >>
> >> >> There is work being done to restore more coverage for telemetry by
> >> >> limiting
> >> >> the resources it consumes [3].  We are also working on additional
> >> >> scenarios
> >> >> in t-h-t/ci/environments/ to better cover ceilometer.
> >> >>
> >> >> If the CI environment you are working in has the resources to cover
> >> >> ceilometer that is great, however if you find issues like [1] we
> highly
> >> >> suggest you follow the same pattern until coverage is restored
> >> >> upstream.
> >> >>
> >> >> Thank you!
> >> >>
> >> >> [1] https://bugs.launchpad.net/tripleo/+bug/1693174
> >> >> [2] https://review.openstack.org/#/q/topic:bug/1680195
> >> >> [3]
> >> >> https://review.openstack.org/#/c/475838/
> >> >> https://review.openstack.org/#/c/474969/
> >> >> https://review.openstack.org/#/c/47/
> >> >>
> >> >>
> >> >
> >> > Thanks for starting this thread Wes. I concur with this. We got bitten
> >> > recently by many issues that we could have caught in ci had telemetry
> >> > been enabled. I spoke to trown and Emilien about this a few times
> >> > already. I do understand the resource footprint it causes.  But with
> >> > recent improvements and changes upstream, things should be back to
> >> > being more manageable. We do have telemetry tested in scenario001 job,
> >> > but that doesn't cover all scenarios. So there is a gap in coverage.
> >>
> >> What do you mean by gap in coverage?
> >> We have scenarios on purpose, so we can horizontally scale the
> >> coverage across multiple jobs and run the jobs only when we need (e.g.
> >> touching telemetry files for scenario001).
> >>
> >> Please elaborate on what isn't covered by scenario001, because we
> >> already cover Gnocchi, Panko, Aodh and Ceilometer (with RBD backend
> >> and soon with Swift backend in scenario002).
> >>
> >
> > Emilien,
> > Gap is the wrong word to use in the case.
> > Previously we had several jobs running with telemetry turned on including
> > ovb jobs in tripleo and other jobs outside of the upstream CI system.
> > The more jobs running, the more coverage.
> > I think that is what Pradeep was referring to, but maybe I am
> > misunderstanding this as well.
>
> Yea may be gap is not the right word. But mostly i meant what Wes
> said, but also I feel we are not testing Telemetry with full HA
> currently in CI. scenario jobs only test deploy with 1 controller not
> 3. We have seen some recent issues where things work on controller 0
> but controller 1 or 2 has statsd down for example. The ovb ha job
> would have shown us that, had the ovb ha job included telemetry
> enabled. Is it possible to run scenario001 job with full HA ?
>

Full HA is limited to ovb jobs atm and these jobs currently take longer to
run and are barely able to complete in the mandatory upstream timeout
period.
IMHO it's worth the time and effort to see if the performance improvements
currently being made to ceilometer will work properly with the OVB jobs,
but nothing I can guarantee atm.

Work is now starting on being able to deploy a full HA envrionment using
nodepool multinode jobs.  IMHO this is a better target.
I will keep you posted on the progress here.

Thank you Pradeep.


>
>
>
> >
> >
> >>
> >> >  I hope we can either re-enable these services by default in CI and
> >> > how things work or at least add a separate gate job to be able to test
> >> > HA scenario properly with telemetry enabled.
> >> >
> >> > --
> >> > Cheers,
> >> > ~ Prad
> >> >
> >> >
> >> > 
> __
> >> > 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
> >>
> >>
> >>
> >> --
> >> 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
> >
>
>
>
> --
> Cheers,
> ~ Prad
>
> __
> 

Re: [openstack-dev] [nova] Should PUT /os-services be idempotent?

[Blair Bethwaite]

Please don't make these 400s - it should not be a client error to be
unaware of the service status ahead of time.

On 12 July 2017 at 11:18, Matt Riedemann  wrote:
> I'm looking for some broader input on something being discussed in this
> change:
>
> https://review.openstack.org/#/c/464280/21/nova/api/openstack/compute/services.py
>
> This is collapsing the following APIs into a single API:
>
> Old:
>
> * PUT /os-services/enable
> * PUT /os-services/disable
> * PUT /os-services/disable-log-reason
> * PUT /os-services/force-down
>
> New:
>
> * PUT /os-services
>
> With the old APIs, if you tried to enable and already enabled service, it
> was not an error. The same is you tried to disable an already disabled
> service. It doesn't change anything, but it's not an error.
>
> The question is coming up in the new API if trying to enable an enabled
> service should be a 400, or trying to disable a disabled service. The way I
> wrote the new API, those are no 400 conditions. They don't do anything, like
> before, but they aren't errors.
>
> Looking at [1] it seems this should not be an error condition if you're
> trying to update the state of a resource and it's already at that state.
>
> I don't have a PhD in REST though so would like broader discussion on this.
>
> [1] http://www.restapitutorial.com/lessons/idempotency.html
>
> --
>
> 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



-- 
Cheers,
~Blairo

__
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][ci] decreased coverage for telemetry

[Pradeep Kilambi]

On Tue, Jul 11, 2017 at 10:06 PM, Wesley Hayutin  wrote:
>
>
> On Tue, Jul 11, 2017 at 9:04 PM, Emilien Macchi  wrote:
>>
>> On Tue, Jul 11, 2017 at 12:41 PM, Pradeep Kilambi  wrote:
>> > On Tue, Jul 11, 2017 at 3:17 PM, Wesley Hayutin 
>> > wrote:
>> >> Greetings,
>> >>
>> >> I was looking through the mailing list and I did not see any emails
>> >> explicitly calling out the decreased coverage for telemetry in tripleo
>> >> due
>> >> to [1].  A series of changes went into the CI system to disable
>> >> telemetry
>> >> [2].
>> >>
>> >> There is work being done to restore more coverage for telemetry by
>> >> limiting
>> >> the resources it consumes [3].  We are also working on additional
>> >> scenarios
>> >> in t-h-t/ci/environments/ to better cover ceilometer.
>> >>
>> >> If the CI environment you are working in has the resources to cover
>> >> ceilometer that is great, however if you find issues like [1] we highly
>> >> suggest you follow the same pattern until coverage is restored
>> >> upstream.
>> >>
>> >> Thank you!
>> >>
>> >> [1] https://bugs.launchpad.net/tripleo/+bug/1693174
>> >> [2] https://review.openstack.org/#/q/topic:bug/1680195
>> >> [3]
>> >> https://review.openstack.org/#/c/475838/
>> >> https://review.openstack.org/#/c/474969/
>> >> https://review.openstack.org/#/c/47/
>> >>
>> >>
>> >
>> > Thanks for starting this thread Wes. I concur with this. We got bitten
>> > recently by many issues that we could have caught in ci had telemetry
>> > been enabled. I spoke to trown and Emilien about this a few times
>> > already. I do understand the resource footprint it causes.  But with
>> > recent improvements and changes upstream, things should be back to
>> > being more manageable. We do have telemetry tested in scenario001 job,
>> > but that doesn't cover all scenarios. So there is a gap in coverage.
>>
>> What do you mean by gap in coverage?
>> We have scenarios on purpose, so we can horizontally scale the
>> coverage across multiple jobs and run the jobs only when we need (e.g.
>> touching telemetry files for scenario001).
>>
>> Please elaborate on what isn't covered by scenario001, because we
>> already cover Gnocchi, Panko, Aodh and Ceilometer (with RBD backend
>> and soon with Swift backend in scenario002).
>>
>
> Emilien,
> Gap is the wrong word to use in the case.
> Previously we had several jobs running with telemetry turned on including
> ovb jobs in tripleo and other jobs outside of the upstream CI system.
> The more jobs running, the more coverage.
> I think that is what Pradeep was referring to, but maybe I am
> misunderstanding this as well.

Yea may be gap is not the right word. But mostly i meant what Wes
said, but also I feel we are not testing Telemetry with full HA
currently in CI. scenario jobs only test deploy with 1 controller not
3. We have seen some recent issues where things work on controller 0
but controller 1 or 2 has statsd down for example. The ovb ha job
would have shown us that, had the ovb ha job included telemetry
enabled. Is it possible to run scenario001 job with full HA ?



>
>
>>
>> >  I hope we can either re-enable these services by default in CI and
>> > how things work or at least add a separate gate job to be able to test
>> > HA scenario properly with telemetry enabled.
>> >
>> > --
>> > Cheers,
>> > ~ Prad
>> >
>> >
>> > __
>> > 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
>>
>>
>>
>> --
>> 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
>



-- 
Cheers,
~ Prad

__
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] Queens Goal for policy-in-code

[Lance Bragstad]

Hi all,

I'd like to reach out and get ahead of the curve now that we established
the community goals for Queens. If you have any questions about the
policy-in-code work [0] and how it pertains to your project, please
don't hesitate to ping me in #openstack-dev. Once pike starts winding
down, I'll start dropping by individual team meetings. If I end up
getting similar questions from multiple projects, I can look into
organizing a slot at the PTG so we can work through things as a group.

Thanks,

Lance
irc: lbragstad


[0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html




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] [watcher] Nominate Yumeng Bao to the core team

[Susanne Balle]

+1

On Fri, Jun 30, 2017 at 4:31 AM, Hidekazu Nakamura <
hid-nakam...@vf.jp.nec.com> wrote:

> +1
>
> > -Original Message-
> > From: Чадин Александр (Alexander Chadin)
> > [mailto:a.cha...@servionica.ru]
> > Sent: Tuesday, June 27, 2017 10:44 PM
> > To: OpenStack Development Mailing List
> > 
> > Subject: [openstack-dev] [watcher] Nominate Yumeng Bao to the core team
> >
> > Hi watcher folks,
> >
> > I’d like to nominate Yumeng Bao to the core team. She has made a lot of
> > contributions including specifications,
> > features and bug fixes. Yumeng has attended PTG and Summit with her
> > presentation related to the Watcher.
> > Yumeng is active on IRC channels and take a part on weekly meetings as
> well.
> >
> > Please, vote with +1/-1.
> >
> > Best Regards,
> > _
> > Alexander Chadin
> > OpenStack Developer
>
> __
> 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] [keystone] office hours report 2017-7-7

[Akihiro Motoki]

2017-07-12 10:35 GMT+09:00 Lance Bragstad :
> Hey all,
>
> This is a summary of what was worked on today during office hours. Full logs
> of the meeting can be found below:
>
> http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-07-11-19.00.log.html

It is not specific to keystone.

I think it is better to use keystone-office-hours instead of
office-hours as a meeting name.
If we use the same meeting names, we will have office-hours logs of
multiple projects
in a same directory in eavesdrop.openstack.org.

Thanks,
Akihiro

>
> The future of the templated catalog backend
>
> Some issues were uncovered, or just resurfaced, with the templated catalog
> backend. The net of the discussion boiled down to - do we fix it or remove
> it? The answer actually ended up being both. It was determined that instead
> of trying to maintain and fix the existing templated backend, we should
> deprecate it for removal [0]. Since it does provide some value, it was
> suggested that we can start implementing a new backend based on YAML to fill
> the purpose instead. The advantage here is that the approach is directed
> towards a specific format (YAML). This should hopefully make things easier
> for both developers and users.
>
> [0] https://review.openstack.org/#/c/482714/
>
> Policy fixes
>
> All the policy-in-code work has exposed several issues with policy defaults
> in keystone. We spent time as a group going through several of the bugs [0]
> [1] [2] [3], the corresponding fixes, and impact. One of which will be
> backported specifically for the importance of communicating a release note
> to stable users [0].
>
> [0] https://bugs.launchpad.net/keystone/+bug/1703369
> [1] https://bugs.launchpad.net/keystone/+bug/1703392
> [2] https://bugs.launchpad.net/keystone/+bug/1703467
> [3] https://bugs.launchpad.net/keystone/+bug/1133435
>
> Additional bugs worked
>
> Transient bug with security compliance or PCI-DSS:
> https://bugs.launchpad.net/keystone/+bug/1702211
> Request header issues: https://bugs.launchpad.net/keystone/+bug/1689468
>
>
> I hope to find ways to automate most of what is communicated in this
> summary. Until then I'm happy to hear feedback if you find the report
> lacking in a specific area.
>
>
> Thanks,
>
> Lance
>
>
> __
> 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] [trove][all][tc] A proposal to rearchitect Trove

[Doug Hellmann]

Excerpts from Amrith Kumar's message of 2017-07-12 06:14:28 -0500:
> All:
> 
> First, let me thank all of you who responded and provided feedback
> on what I wrote. I've summarized what I heard below and am posting
> it as one consolidated response rather than responding to each
> of your messages and making this thread even deeper.
> 
> As I say at the end of this email, I will be setting up a session at
> the Denver PTG to specifically continue this conversation and hope
> you will all be able to attend. As soon as time slots for PTG are
> announced, I will try and pick this slot and request that you please
> attend.
> 
> 
> 
> Thierry: naming issue; call it Hoard if it does not have a migration
> path.
> 
> 
> 
> Kevin: use a container approach with k8s as the orchestration
> mechanism, addresses multiple issues including performance. Trove to
> provide containers for multiple components which cooperate to provide
> a single instance of a database or cluster. Don't put all components
> (agent, monitoring, database) in a single VM, decoupling makes
> migraiton and upgrades easier and allows trove to reuse database
> vendor supplied containers. Performance of databases in VM's poor
> compared to databases on bare-metal.
> 
> 
> 
> Doug Hellmann:
> 
> > Does "service VM" need to be a first-class thing?  Akanda creates
> > them, using a service user. The VMs are tied to a "router" which is
> > the billable resource that the user understands and interacts with
> > through the API.
> 
> Amrith: Doug, yes because we're looking not just for service VM's but all
> resources provisioned by a service. So, to Matt's comment about a
> blackbox DBaaS, the VM's, storage, snapshots, ... they should all be
> owned by the service, charged to a users quota but not visible to the
> user directly.

I still don't understand. If you have entities that represent the
DBaaS "host" or "database" or "database backup" or whatever, then
you put a quota on those entities and you bill for them. If the
database actually runs in a VM or the backup is a snapshot, those
are implementation details. You don't want to have to rewrite your
quota management or billing integration if those details change.

Doug

> 
> 
> 
> Jay:
> 
> > Frankly, I believe all of these types of services should be built
> > as applications that run on OpenStack (or other)
> > infrastructure. In other words, they should not be part of the
> > infrastructure itself.
> >
> > There's really no need for a user of a DBaaS to have access to the
> > host or hosts the DB is running on. If the user really wanted
> > that, they would just spin up a VM/baremetal server and install
> > the thing themselves.
> 
> and subsequently in follow-up with Zane:
> 
> > Think only in terms of what a user of a DBaaS really wants. At the
> > end of the day, all they want is an address in the cloud where they
> > can point their application to write and read data from.
> > ...
> > At the end of the day, I think Trove is best implemented as a hosted
> > application that exposes an API to its users that is entirely
> > separate from the underlying infrastructure APIs like
> > Cinder/Nova/Neutron.
> 
> Amrith: Yes, I agree, +1000
> 
> 
> 
> Clint (in response to Jay's proposal regarding the service making all
> resources multi-tenant) raised a concern about having multi-tenant
> shared resources. The issue is with ensuring separation between
> tenants (don't want to use the word isolation because this is database
> related).
> 
> Amrith: yes, definitely a concern and one that we don't have today
> because each DB is a VM of its own. Personally, I'd rather stick with
> that construct, one DB per VM/container/baremetal and leave that be
> the separation boundary.
> 
> 
> 
> Zane: Discomfort over throwing out working code, grass is greener on
> the other side, is there anything to salvage?
> 
> Amrith: Yes, there is certainly a 'grass is greener with a rewrite'
> fallacy. But, there is stuff that can be salvaged. The elements are
> still good, they are separable and can be used with the new
> project. Much of the controller logic however will fall by the
> wayside.
> 
> In a similar vein, Clint asks about the elements that Trove provides,
> "how has that worked out".
> 
> Amrith: Honestly, not well. Trove only provided reference elements
> suitable for development use. Never really production hardened
> ones. For example, the image elements trove provides don't bake the
> guest agent in; they assume that at VM launch, the guest agent code
> will be slurped (technical term) from the controller and
> launched. Great for debugging, not great for production. That is
> something that should change. But, equally, I've heard disagreements
> saying that slurping the guest agent at runtime is clever and good
> in production.
> 
> 
> 
> Zane: consider using Mistral for workflow.
> 
> > The disadvantage, obviously, is that it requires the cloud to offer
> > Mistral as-a-Service, 

Re: [openstack-dev] [nova] Should PUT /os-services be idempotent?

[Ghanshyam Mann]

On Wed, Jul 12, 2017 at 11:29 AM, Alex Xu  wrote:
>
>
> 2017-07-12 9:18 GMT+08:00 Matt Riedemann :
>>
>> I'm looking for some broader input on something being discussed in this
>> change:
>>
>>
>> https://review.openstack.org/#/c/464280/21/nova/api/openstack/compute/services.py
>>
>> This is collapsing the following APIs into a single API:
>>
>> Old:
>>
>> * PUT /os-services/enable
>> * PUT /os-services/disable
>> * PUT /os-services/disable-log-reason
>> * PUT /os-services/force-down
>>
>> New:
>>
>> * PUT /os-services
>>
>> With the old APIs, if you tried to enable and already enabled service, it
>> was not an error. The same is you tried to disable an already disabled
>> service. It doesn't change anything, but it's not an error.
>>
>> The question is coming up in the new API if trying to enable an enabled
>> service should be a 400, or trying to disable a disabled service. The way I
>> wrote the new API, those are no 400 conditions. They don't do anything, like
>> before, but they aren't errors.
>
>
> Sorry, I didn't describe clearly in the comment.
>
> Some of those comments about save a DB call with more conditions checks. It
> means if enable a enabled service, we needn't a db call, we can just return
> to the user 200 directly.
>
> One of those comments is about when the API user specified 'status=enabled'
> and 'disabled_reason' in the request body, then we just ignore the
> 'disabled_reason' and didn't save it into the db also. That sounds not
> right. We should return 400 to the API user, you can't specified the
> 'status=enabled' and 'disabled_reason'.

+1 for 400 in this case.


>
>>
>>
>> Looking at [1] it seems this should not be an error condition if you're
>> trying to update the state of a resource and it's already at that state.
>>
>> I don't have a PhD in REST though so would like broader discussion on
>> this.
>>
>> [1] http://www.restapitutorial.com/lessons/idempotency.html
>>
>> --
>>
>> 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 Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [nova] Should PUT /os-services be idempotent?

[Ghanshyam Mann]

On Wed, Jul 12, 2017 at 11:20 AM, Ed Leafe  wrote:
> On Jul 11, 2017, at 8:18 PM, Matt Riedemann  wrote:
>
>> With the old APIs, if you tried to enable and already enabled service, it 
>> was not an error. The same is you tried to disable an already disabled 
>> service. It doesn't change anything, but it's not an error.
>>
>> The question is coming up in the new API if trying to enable an enabled 
>> service should be a 400, or trying to disable a disabled service. The way I 
>> wrote the new API, those are no 400 conditions. They don't do anything, like 
>> before, but they aren't errors.
>
> These should not be errors. You are calling the API to set a particular 
> condition. The result of that call is that the service is in that condition. 
> That should be a 2xx, most likely a 204. So yeah, it should be idempotent.

My vote also to make(keep) it idempotent but with status code. if it
return 200 then on second call on same status should be 200 with same
response body otherwise API become difficult to use.


-gmann

>
> -- Ed Leafe
>
>
>
>
>
>
> __
> 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] [heat] Online video meet up this week (topic:review)

[Rico Lin]

>
>
> This seems like a game of semantics. In your earlier message (quoted
> above) you said, "we will make our meeting this week as an online
> video meeting," and you've scheduled it for the exact same time as
> your normal IRC meeting. I'm not sure how anyone can come to a
> different conclusion than that you're (at least experimenting with)
> replacing your weekly IRC meetings with teleconferencing.
>

First, please don't worry about that replacing issue, because we never want
to replace
IRC meeting in anyway. And to make this clear, this is not even a
experiment to do so.
The hole point of have this meetup is to help all team member got chances
to join future
face to face discussion and hopefully become a virtual+face-to-face
discussion (I only mean PTG here).
Just like what I said in the ML above "The reason for doing this is because
we're a global team
 which almost impossible for all of us to literally sit in the same room in
PTG/anywhere"

To deal that we got more then half cores missing in last PTG only because
they can't make it?
That the issue we have to solve here.
And thanks for correct my semantics issue, I already send another ML out
for clearfy that.
Will choose my word carefully. We definitely don't want and misstaken of
the reason why we host
the meetup here, so thank you for that.

As for why doing meetup this time, instead of meeting, because we don't
need anything other than to
review BPs and Goals. And would hope to make more patches landing before
freeze.

>
> The point wasn't whether there are open alternatives, just that
> you're expressly choosing convenience over software freedom. I get
> that different people place different priorities on this: for some
> free software is nice to have as long as it doesn't get in their
> way, while for others it's a mandate even if it means not getting to
> use some shiny new feature. The decision doesn't directly impact me
> as I only ever at most lurk in the Heat meeting in case anyone
> requests my input and maybe occasionally read the minutes/log, but
> as an example set by a long-standing team within the community it's
> certainly disappointing.
>
Thanks for share that concern out, I will raise this issue to team(maybe in
meeting next week).
The sad, OpenStack already start to adopt something here(I'm actually agree
with you and we should kill https://openstack.webex.com)
Again this is for one meetup and will seek on any feedback, so feedback
taken.
Thank you for fighting for this.
__
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] [keystone] office hours report 2017-7-7

[Lance Bragstad]

On 07/11/2017 09:28 PM, Mathieu Gagné wrote:
> Hi,
>
> So this email is relevant to my interests as an operator. =)

Glad to hear it!

>
> On Tue, Jul 11, 2017 at 9:35 PM, Lance Bragstad  > wrote:
>
> *The future of the templated catalog backend*
>
> Some issues were uncovered, or just resurfaced, with the templated
> catalog backend. The net of the discussion boiled down to - do we
> fix it or remove it? The answer actually ended up being both. It
> was determined that instead of trying to maintain and fix the
> existing templated backend, we should deprecate it for removal
> [0]. Since it does provide some value, it was suggested that we
> can start implementing a new backend based on YAML to fill the
> purpose instead. The advantage here is that the approach is
> directed towards a specific format (YAML). This should hopefully
> make things easier for both developers and users.
>
> [0] https://review.openstack.org/#/c/482714/
> ​
>
>
> We have been exclusively using the templated catalog backend for at
> least 5 years without any major issues. And it looks like we are now
> among the < 3% using templated according to the April 2017 user survey. 
> ¯\_(ツ)_/¯
>
> We choose the templated catalog backend for its simplicity (especially
> with our CMS) and because it makes no sense (to me) to use and rely on an 
> SQL server to serve what is essentially static content
> ​.​
>
>
> Regarding the v3 catalog support, we do have an in-house fix we
> intended to upstream
> ​ very soon (and just did right now)​
> . [1]
>
>
> So if the templated catalog backend gets deprecated, 
> ​my wish would be to have access to
>  a
> ​n alternate​
> ​ file based
> ​ implementation​, a production grade implementation
>  ready to be used
> ​ before I get spammed with deprecation warnings in the keystone logs.

I think that is fair. Morgan was working on an implementation yesterday,
but I don't think anything made it to Gerrit. As soon as it does, I'll
be sure to update the thread. Thanks for speaking up!

>
> Thanks
>
> [1] https://review.openstack.org/#/c/482766/
>
> --
> Mathieu
>
>
>
> __
> 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

[openstack-dev] [heat] No meeting this week(There will be a review meetup this week)

[Rico Lin]

Dear Team
Just to be clear
We will host a meet up for review (as what we pickup topic for just doing
review) this week.
*That means we not going to hold the meeting this week.*
And the purpose of doing meetup with video conference is to find a way for
the team to really able to join together and discuss when face to face
discussion is required (I mean PTG at this point).

We will resume meeting next week. Hope you all understand.

If you would like to join the meetup this week and help to review together,
here is info:

Topic: Review
Time: Wednesdays at 1500 UTC on 07/12 (1 hr)
Location: zoom.us (I will notify the specific room location in heat's irc
channel right before the meetup)
Agenda:

1. pre meetup discuss
2. We shall go with patches for BPs and Goals first
3. then pick out some worth review patch for review and land as many as we
can.
4. post meetup discuss (include feedback and suggestion time)

Host: Rico Lin
*Pre-requirement: Please register a Zoom account (zoom.us
) which will be the channel that we will use for this
meetup*

With that free account, you should be able to join the meetup. Just
remember to install zoom on your device. And don't worry it's easy to join
and operate.
__
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] Forming our plans around Ansible

[John Fulton]

On Wed, Jul 12, 2017 at 2:04 AM, Giulio Fidente  wrote:

> On 07/12/2017 01:53 AM, James Slagle wrote:
>
>> On Tue, Jul 11, 2017 at 5:53 PM, Steve Baker  wrote:
>>
>>>
>>> 
>
>> What would be nice is when a heat->mistral->ansible upgrade step fails,
>>> the
>>> operator is given an ansible-playbook command to run which skips
>>> directly to
>>> the failing step. This would dramatically reduce the debug cycle and also
>>> make it possible for the operator to automate any required fixes over
>>> every
>>> host in a role. This would likely mean rendering out ansible config
>>> files,
>>> playbooks, (and roles?) to the operator's working directory. What
>>> happens to
>>> these rendered files after deployment is an open question. Delete them?
>>> Encourage the operator to track them in source control?
>>>
>>
> interesting question, as long as we run playbooks from a filesystem, I
> suppose users can make customizations without "changing" anything in
> tripleo ... this is how we tested some of the ceph-ansible fixes!
>
> for upgrades we should maintain the tasks outside the templates do be able
> to do that though, assuming we want users to customize the upgrade tasks


I like this option too! Perhaps we could add a new task to a mistral
workflow that uses this approach to store the info that was generated
dynamically from Heat (e.g. inventory and extra-vars) somewhere (swift?)
and then make it easy for the user to get this info and run the playbook
manually. Kind of like a debug-on-error option with a dribble file [1] for
the deployer. Assuming they get it working again, and we have idempotence,
they should just be able to resume the deploy.

  John

[1]
https://ftp.gnu.org/old-gnu/Manuals/elisp-manual-20-2.5/html_chapter/elisp_18.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] bug triage experimentation

[Sean Dague]

On 07/11/2017 04:31 PM, Jeremy Stanley wrote:

On 2017-07-10 07:33:28 -0400 (-0400), Sean Dague wrote:
[...]

Ideally storyboard would just be a lot more receptive to these kinds of
things, by emitting a more native event stream,


Well, there is
http://git.openstack.org/cgit/openstack-infra/storyboard/tree/storyboard/notifications/publisher.py
 >
so replacing or partnering its RabbitMQ publisher with something
like an MQTT publisher into firehose.openstack.org is probably not
terribly hard for someone with interest in that and would be
generally useful.


and having really good tag support (preferably actually project
scoped tags, so setting it on the nova task doesn't impact the
neutron tasks on the same story, as an for instance)

[...]

Your queries (including those used to build automatic tasklists and
boards) could just include project in addition to tag, right? Or is
this more of a UI concern, being able to click on an arbitrary tag
in the webclient and only get back a set of tagged stories for the
same project rather than across all projects?


My concern is based on current limitations in launchpad, and to make 
sure they don't get encoded into Storyboard.


Tags in launchpad are at the Bug level. Bugs map to projects as Tasks. 
Which is why you can have 1 Bug set to be impacting both Nova and 
Neutron. You get lots of weirdness today when for instance a bug is 
assigned to Nova and Ironic, and the Nova team tags it "ironic" in 
triage, but that means that now Ironic has a bug with the "ironic" tag. 
Then if later Nova is removed from the bug, it ends up really all 
looking odd and confusing.


Or the fact that "compute" as a Nova tag means the compute worker, but 
other teams tag things with compute to just mean Nova is involved. 
Project scoped tags would help clarify what context it is in.


-Sean





__
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




--
Sean Dague
http://dague.net

__
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] [heat] Online video meet up this week (topic:review)

[Jeremy Stanley]

On 2017-07-12 10:24:00 +0800 (+0800), Rico Lin wrote:
> 2017-07-12 2:10 GMT+08:00 Jeremy Stanley :
> >
> > On 2017-07-12 01:47:02 +0800 (+0800), Rico Lin wrote:
> > [...]
> > > we will make our meeting this week as an online video meeting
> > [...]
> >
> > Friendly reminder: "If the project has meetings [...] they should be
> > public and in IRC. They should all be logged and published"
> > https://governance.openstack.org/tc/reference/new-projects-requirements.html
> 
> I would rather call this video meet as `meet up` as in title said,
> since we will not discuss any other thing but just review and
> share thought about each patch. (Which I will definitely share the
> information On IRC and WIKI for sure)

This seems like a game of semantics. In your earlier message (quoted
above) you said, "we will make our meeting this week as an online
video meeting," and you've scheduled it for the exact same time as
your normal IRC meeting. I'm not sure how anyone can come to a
different conclusion than that you're (at least experimenting with)
replacing your weekly IRC meetings with teleconferencing.

> > Also, while Zoom's service and client software may be "free" in the
> > gratis sense, they are not free in the libre sense. Moving your
> > meetings to a proprietary system (whether it charges money for you
> > to be able to use it or not) isn't in the spirit of an open
> > community and necessarily excludes participation by people who value
> > software freedom.
> 
> That's a great stand of point that we all agree on (or otherwise
> why we're here:)), but through the team meeting, we can't think
> out for a video channel that's happened to be a pure open source
> one (and stable to use). And of course, if people can help to
> provide such an environment for us to try on, then I'm happy to
> give it a test :)

The point wasn't whether there are open alternatives, just that
you're expressly choosing convenience over software freedom. I get
that different people place different priorities on this: for some
free software is nice to have as long as it doesn't get in their
way, while for others it's a mandate even if it means not getting to
use some shiny new feature. The decision doesn't directly impact me
as I only ever at most lurk in the Heat meeting in case anyone
requests my input and maybe occasionally read the minutes/log, but
as an example set by a long-standing team within the community it's
certainly disappointing.
-- 
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

Re: [openstack-dev] [all][infra] ask.o.o down and review.o.o slow

[Andreas Jaeger]

On 2017-07-12 09:58, Andreas Jaeger wrote:
> On 2017-07-12 08:51, Andreas Jaeger wrote:
>> FYI, ask.o.o is currently down and review.o.o is slow and needs
>> investigation and possible restart.
>>
>> I hope an admin can help soon with these two systems, for now please
>> have patience,
> 
> review.o.o has been restarted and is ready for reviews again.
> 
> thanks, Yolanda!

ask.o.o is up again as well,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] [trove][all][tc] A proposal to rearchitect Trove

[Amrith Kumar]

All:

First, let me thank all of you who responded and provided feedback
on what I wrote. I've summarized what I heard below and am posting
it as one consolidated response rather than responding to each
of your messages and making this thread even deeper.

As I say at the end of this email, I will be setting up a session at
the Denver PTG to specifically continue this conversation and hope
you will all be able to attend. As soon as time slots for PTG are
announced, I will try and pick this slot and request that you please
attend.



Thierry: naming issue; call it Hoard if it does not have a migration
path.



Kevin: use a container approach with k8s as the orchestration
mechanism, addresses multiple issues including performance. Trove to
provide containers for multiple components which cooperate to provide
a single instance of a database or cluster. Don't put all components
(agent, monitoring, database) in a single VM, decoupling makes
migraiton and upgrades easier and allows trove to reuse database
vendor supplied containers. Performance of databases in VM's poor
compared to databases on bare-metal.



Doug Hellmann:

> Does "service VM" need to be a first-class thing?  Akanda creates
> them, using a service user. The VMs are tied to a "router" which is
> the billable resource that the user understands and interacts with
> through the API.

Amrith: Doug, yes because we're looking not just for service VM's but all
resources provisioned by a service. So, to Matt's comment about a
blackbox DBaaS, the VM's, storage, snapshots, ... they should all be
owned by the service, charged to a users quota but not visible to the
user directly.



Jay:

> Frankly, I believe all of these types of services should be built
> as applications that run on OpenStack (or other)
> infrastructure. In other words, they should not be part of the
> infrastructure itself.
>
> There's really no need for a user of a DBaaS to have access to the
> host or hosts the DB is running on. If the user really wanted
> that, they would just spin up a VM/baremetal server and install
> the thing themselves.

and subsequently in follow-up with Zane:

> Think only in terms of what a user of a DBaaS really wants. At the
> end of the day, all they want is an address in the cloud where they
> can point their application to write and read data from.
> ...
> At the end of the day, I think Trove is best implemented as a hosted
> application that exposes an API to its users that is entirely
> separate from the underlying infrastructure APIs like
> Cinder/Nova/Neutron.

Amrith: Yes, I agree, +1000



Clint (in response to Jay's proposal regarding the service making all
resources multi-tenant) raised a concern about having multi-tenant
shared resources. The issue is with ensuring separation between
tenants (don't want to use the word isolation because this is database
related).

Amrith: yes, definitely a concern and one that we don't have today
because each DB is a VM of its own. Personally, I'd rather stick with
that construct, one DB per VM/container/baremetal and leave that be
the separation boundary.



Zane: Discomfort over throwing out working code, grass is greener on
the other side, is there anything to salvage?

Amrith: Yes, there is certainly a 'grass is greener with a rewrite'
fallacy. But, there is stuff that can be salvaged. The elements are
still good, they are separable and can be used with the new
project. Much of the controller logic however will fall by the
wayside.

In a similar vein, Clint asks about the elements that Trove provides,
"how has that worked out".

Amrith: Honestly, not well. Trove only provided reference elements
suitable for development use. Never really production hardened
ones. For example, the image elements trove provides don't bake the
guest agent in; they assume that at VM launch, the guest agent code
will be slurped (technical term) from the controller and
launched. Great for debugging, not great for production. That is
something that should change. But, equally, I've heard disagreements
saying that slurping the guest agent at runtime is clever and good
in production.



Zane: consider using Mistral for workflow.

> The disadvantage, obviously, is that it requires the cloud to offer
> Mistral as-a-Service, which currently doesn't include nearly as many
> clouds as I'd like.

Amrith: Yes, as we discussed, we are in agreement with both parts of
this recommendation.

Zane, Jay and Dims: a subtle distinction between Tessmaster and Magnum
(I want a database figure out the lower layers, vs. I want a k8s
cluster).



Zane: Fun fact: Trove started out as a *complete fork* of Nova(!).

Amrith: Not fun at all :) Never, ever, ever, ever f5g do that
again. Yeah, sure, if you can have i18n, and k8s, I can have f5g :)



Thierry:

> We generally need to be very careful about creating dependencies
> between OpenStack projects.
> ...
> I understand it's a hard trade-off: you want to reuse 

Re: [openstack-dev] [all][infra] ask.o.o down and review.o.o slow

[Andreas Jaeger]

On 2017-07-12 08:51, Andreas Jaeger wrote:
> FYI, ask.o.o is currently down and review.o.o is slow and needs
> investigation and possible restart.
> 
> I hope an admin can help soon with these two systems, for now please
> have patience,

review.o.o has been restarted and is ready for reviews again.

thanks, Yolanda!

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Flavio Percoco]

On 11/07/17 19:21 -0500, Monty Taylor wrote:

On 07/11/2017 06:47 AM, Flavio Percoco wrote:

On 11/07/17 14:20 +0300, Mikhail Fedosin wrote:

On Tue, Jul 11, 2017 at 1:43 AM, Monty Taylor
 wrote:


On 07/10/2017 04:31 PM, Mikhail Fedosin wrote:

Third, all these changes can be hidden in Glare client. So if we try a
little, we can achieve 100% compatibility there, and other
projects can use
Glare client instead of Glance's without even noticing the differences.



I think we should definitely not do this... I think instead, if
we decide
to go down this road, we want to look at adding an endpoint to
glare that
speaks glance v2 API so that users can have a transition period while
libraries and tools get updated to understand the artifacts API.



This is optional and depends on the project developers. For my
part, I can
only offer the most compatible client, so that the Glance module can be
simply copied into the new Glare module.


Unfortunately, adding this sort of logic to the client is almost
never the right
choice. To be completely honest, I'm not even convinced having a
Glance-like API
in Glare is the right thing to do. As soon as that API hits the
codebase, you'll
have to maintain it.

Anything that delays the transition to the new thing is providing a
fake bridge
to the users. It's a bridge that will be blown-up eventually.

To make a hypothetical transition from Glance to Glare works
smoothly, we should
first figure out how to migrate the database (assuming this has not
been done
yet), how to migrate the images, etc. Only when these things have
been figured
out, I'd start worrying about what compatibility layer we want to
provide. The
answer could also be: "Hey, we're sorry but, the best thing you can
do is to
migrate your code base as soon as possible".


I think this is a deal breaker. The problem is - if glare doesn't
provide a v2 compat layer, then a deployer is going to have to run
glance AND glare at the same time and we'll have to make sure both
glance and glare can write to the same backend.

The reason is that with our major version bumps both versions co-exist
for a period of time which allows consumers to gracefully start
consuming the nicer and newer api while not being immediately broken
when the old api isn't there.

What we'd be looking at is:

* a glare service that runs two endpoints - an /image endpoint and an
/artifact endpoint - and that registers the /image endpoint with the
catalog as the 'image' service_type and the /artifact endpoint with
the catalog as the 'artifact' service_type followed by a deprecation
period of the image endpoint from the bazillion things that use it and
a migration to the artifact service.

OR

First - immediately bump the glare api version to 3.0. This is affect
some glare users, but given the relative numbers of glance v. glare
users, it may be the right choice.

Run a single set of versioned endpoints - no /v1, /v2 has /image at
the root and /v3 has /artifact at the root. Register that endpoint
with the catalog as both artifact and image.

That means service and version discovery will find the /v2 endpoint of
the glare service if someone says "I want 'image' api 'v2'". It's
already fair game for a cloud to run without v1 - so that's not a
problem. (This, btw, is the reason glare has to bump its api to v3 -
if it still had a v1 in its version discovery document, glance users
would potentially find that but it would not be a v1 of the image API)

In both cases, /v2/images needs to be the same as glance /v2/images.
If both are running side-by-side, which is how we normally do major
version bumps, then client tools and libraries can use the normal
version discovery process to discover that the cloud has the new /v3
version of the api with service-type of 'image', and they can decide
if they want to use it or not.


Yes - this is going to provide a pile of suck for the glare team,
because they're going to have to maintain an API mapping layer, and
they're going to have to maintain it for a full glance v2 api
deprecation period. Becaue glance v2 is in DefCore, that is longer
than a normal deprecation period - but that's life.


Right! This is the extended version of what I tried to say. :D

I'm not a huge fan of the Glare team having a Glance v2 API but I think it's our
best option forward. FWIW, this WAS tried before but a bit different. Remeber
the Glance v3 discussion?

That Glance v3 was Glare living in the Glance's codebase. The main difference
now is that it would be Glare providing Glance's v2 and Glare's v3 rather than
Glance doing yet another major version change.

I still think we should figure out how to migrate a Glance deployment to Glare
(database, stores, etc) before the work on this API even starts. I would like to
see a good plan forward for this.

Ultimately, the thing I definitely don't want to see happening is any logic
being hard-coded inside client libraries.

Flavio

--
@flaper87
Flavio Percoco


signature.asc

[openstack-dev] [Acceleration]Cyborg Team Weekly Meeting Agenda 2017.07.12

[Zhipeng Huang]

Hi Team,

We will resume our meeting this week, an initial agenda could be found at :
https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda_for_next_meeting
.

Mostly we will concentrate on
1. Moving the stubs ahead
2. Discuss API framework design proposal https://review.openstack.org/481558

3. Sydney Summit CFP brainstorming.

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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][infra] ask.o.o down and review.o.o slow

[Andreas Jaeger]

FYI, ask.o.o is currently down and review.o.o is slow and needs
investigation and possible restart.

I hope an admin can help soon with these two systems, for now please
have patience,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] [infra] Gerrit slow

[Andreas Jaeger]

On 2017-07-12 08:06, Gary Kotton wrote:
> Hi,
> 
> Gerrit is very slow at the moment. Is anyone else hitting this issue?

Yes, we need an admin to help.

Btw. read https://docs.openstack.org/infra/manual/ on how to report
infra issues,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] [infra] Gerrit slow

[Gary Kotton]

Hi,
Gerrit is very slow at the moment. Is anyone else hitting this issue?
Thanks
Gary
__
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] Forming our plans around Ansible

[Giulio Fidente]

On 07/12/2017 01:53 AM, James Slagle wrote:

On Tue, Jul 11, 2017 at 5:53 PM, Steve Baker  wrote:




[...]


I think its important that we allow full support for both mistral-driven and
manually running playbooks. If there was no option to run ansible-playbook
directly then operators would miss one of the main benefits of using ansible
in the first place (which is leveraging their knowledge of inventory,
playbooks and roles to deploy things).


+1, I like this idea as well. If you have a few minutes could you
summarize it here:
https://etherpad.openstack.org/p/tripleo-ptg-queens-ansible


note that this is how option (3) currently operates; it runs an 
unmodified version of ceph-ansible, installed on the undercloud so what 
the user needs to do on failure is to look for the mistral task that 
triggered the playbook and rerun the command


what it misses, as pointed by Steven, is a dump of the execution 
environment, that provides the extra_vars given to the playbook ... heat 
has this data, it should be possible to dump it in a file on the 
undercloud if we want to


I believe Steven is, with (4), trying to improve/reuse the mechanim


I'm attempting to capture some of the common requirements from this
thread for discussion at the ptg so we can consider them when choosing
solution(s).




What would be nice is when a heat->mistral->ansible upgrade step fails, the
operator is given an ansible-playbook command to run which skips directly to
the failing step. This would dramatically reduce the debug cycle and also
make it possible for the operator to automate any required fixes over every
host in a role. This would likely mean rendering out ansible config files,
playbooks, (and roles?) to the operator's working directory. What happens to
these rendered files after deployment is an open question. Delete them?
Encourage the operator to track them in source control?


interesting question, as long as we run playbooks from a filesystem, I 
suppose users can make customizations without "changing" anything in 
tripleo ... this is how we tested some of the ceph-ansible fixes!


for upgrades we should maintain the tasks outside the templates do be 
able to do that though, assuming we want users to customize the upgrade 
tasks

--
Giulio Fidente
GPG KEY: 08D733BA

__
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