Re: [openstack-dev] [all] All Hail our Newest Release Name - OpenStack Train

[Jeremy Freudberg]

Thanks Slawomir-- you're right. My mistake.
(I had been looking at
http://lists.openstack.org/pipermail/openstack-dev/2018-November/136309.html
, whose Condorcet link indicates private results.)


On Wed, Nov 14, 2018 at 1:45 AM Slawomir Kaplonski  wrote:
>
> Hi,
>
> I think it was published, see 
> http://lists.openstack.org/pipermail/openstack/2018-November/047172.html
>
> > Wiadomość napisana przez Jeremy Freudberg  w 
> > dniu 14.11.2018, o godz. 06:12:
> >
> > Hey Tony,
> >
> > What's the reason for the results of the poll not being public?
> >
> > Thanks,
> > Jeremy
> > On Tue, Nov 13, 2018 at 11:52 PM Tony Breeds  
> > wrote:
> >>
> >>
> >> Hi everybody!
> >>
> >> As the subject reads, the "T" release of OpenStack is officially
> >> "Train".  Unlike recent choices Train was the popular choice so
> >> congrats!
> >>
> >> Thanks to everybody who participated and help with the naming process.
> >>
> >> Lets make OpenStack Train the release so awesome that people can't help
> >> but choo-choo-choose to run it[1]!
> >>
> >>
> >> Yours Tony.
> >> [1] Too soon? Too much?
> >> __
> >> OpenStack Development Mailing 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
>
> —
> Slawek Kaplonski
> Senior software engineer
> Red Hat
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all] All Hail our Newest Release Name - OpenStack Train

[Jeremy Freudberg]

Hey Tony,

What's the reason for the results of the poll not being public?

Thanks,
Jeremy
On Tue, Nov 13, 2018 at 11:52 PM Tony Breeds  wrote:
>
>
> Hi everybody!
>
> As the subject reads, the "T" release of OpenStack is officially
> "Train".  Unlike recent choices Train was the popular choice so
> congrats!
>
> Thanks to everybody who participated and help with the naming process.
>
> Lets make OpenStack Train the release so awesome that people can't help
> but choo-choo-choose to run it[1]!
>
>
> Yours Tony.
> [1] Too soon? Too much?
> __
> OpenStack Development Mailing 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] [sahara] PTL out for a week

[Jeremy Freudberg]

Enjoy the PTO, Telles!

I don't really have much to share at a meeting. My vote is for no meeting.
Our other active core and other active community members can agree to
cancel or not, and I'll heed that decision.

On Wed, Oct 10, 2018 at 4:42 PM Telles Nobrega  wrote:

> Hi all,
>
> I'm taking PTO from tomorrow until Monday Oct 22nd. I won't cancel the
> meeting yet but let me know if you want me to.
>
> See you all in a couple weeks.
>
> Thanks,
> --
>
> TELLES NOBREGA
>
> SOFTWARE ENGINEER
>
> Red Hat Brasil  
>
> Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo
>
> tenob...@redhat.com
> 
> TRIED. TESTED. TRUSTED. 
>  Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
> pelo Great Place to Work.
> __
> OpenStack Development Mailing 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] [glance][horizon] Issues we found when using Community Images

[Jeremy Freudberg]

Hi again Andy,

Thanks for the update. Sounds like there is some work to do in various
client libraries first.

I also just tried to launch a Sahara cluster against a community
image-- it failed, because our current validation wants the image ID
to actually appear in the image list. So there will have to be a
server side tweak to Sahara as well (not necessarily using your
desired "list all" mechanism, but it could be).

Anyway, the Sahara team is aware, and we'll keep an eye on this moving forward.

Cheers,
Jeremy


On Thu, Aug 23, 2018 at 8:43 PM, Andy Botting  wrote:
> Hi Jeremy,
>
>>
>> Can you comment more on what needs to be updated in Sahara? Are they
>> simply issues in the UI (sahara-dashboard) or is there a problem
>> consuming community images on the server side?
>
>
> We haven't looked into it much yet, so I couldn't tell you.
>
> I think it would be great to extend the Glance API to include a
> visibility=all filter, so we can actually get ALL available images in a
> single request, then projects could switch over to this.
>
> It might need some thought on how to manage the new API request when using
> an older version of Glance that didn't support visibility=all, but I'm sure
> that could be worked out.
>
> It would be great to hear from one of the Glance devs what they think about
> this approach.
>
> cheers,
> Andy
>
> __
> OpenStack Development Mailing 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] [glance][horizon] Issues we found when using Community Images

[Jeremy Freudberg]

Hi Andy,

Can you comment more on what needs to be updated in Sahara? Are they
simply issues in the UI (sahara-dashboard) or is there a problem
consuming community images on the server side?

I'm happy to pitch in, just would like to do it efficiently.

Thanks,
Jeremy

On Wed, Aug 22, 2018 at 5:31 PM, Andy Botting  wrote:
> Hi all,
>
> We've recently moved to using Glance's community visibility on the Nectar
> Research Cloud. We had lots of public images (12255), and we found it was
> becoming slow to list them all and the community image visibility seems to
> fit our use-case nicely.
>
> We moved all of our user's images over to become community images, and left
> our 'official' images as the only public ones.
>
> We found a few issues, which I wanted to document, if anyone else is looking
> at doing the same thing.
>
> -> Glance API has no way of returning all images available to me in a single
> API request (https://bugs.launchpad.net/glance/+bug/1779251)
> The default list of images is perfect (all available to me, except
> community), but there's a heap of cases where you need to fetch all images
> including community. If we did have this, my next points would be a whole
> lot easier to solve.
>
> -> Horizon's support for Community images is very lacking
> (https://bugs.launchpad.net/horizon/+bug/1779250)
> On the surface, it looks like Community images are supported in Horizon, but
> it's only as far as listing images in the Images tab. Trying to boot a
> Community image from the Launch Instance wizard is actually impossible, as
> community images don't appear in that list at all. The images tab in Horizon
> dynamically builds the list of images on the Images tab through new Glance
> API calls when you use any filters (good).
> In contrast, the source tab on the Launch Images wizard loads all images at
> the start (slow with lots of images), then relies on javascript client-side
> filtering of the list. I've got a dirty patch to fix this for us by
> basically making two Glance API requests (one without specifying visibility,
> and another with visibility=community), then merging the data. This would be
> better handled the same way as the Images tab, with new Glance API requests
> when filtering.
>
> -> Users can't set their own images as Community from the dashboard
> Should be relatively easy to add this. I'm hoping to look into fixing this
> soon.
>
> -> Murano / Sahara image discovery
> These projects rely on images to be chosen when creating new environments,
> and it looks like they use a glance list for their discovery. They both
> suffer from the same issue and require their images to be non-community for
> them to find their images.
>
> -> Openstack Client didn't support listing community images at all
> (https://storyboard.openstack.org/#!/story/2001925)
> It did support setting images to community, but support for actually listing
> them was missing.  Support has  now been added, but not sure if it's made it
> to a release yet.
>
> Apart from these issues, our migration was pretty successful with minimal
> user complaints.
>
> cheers,
> Andy
>
> __
> OpenStack Development Mailing 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] Paste unmaintained

[Jeremy Freudberg]

On Thu, Aug 2, 2018 at 10:27 AM, Doug Hellmann  wrote:
> Excerpts from Stephen Finucane's message of 2018-08-02 15:11:25 +0100:
>> tl;dr: It seems Paste [1] may be entering unmaintained territory and we
>> may need to do something about it.
>>
>> I was cleaning up some warning messages that nova was issuing this
>> morning and noticed a few coming from Paste. I was going to draft a PR
>> to fix this, but a quick browse through the Bitbucket project [2]
>> suggests there has been little to no activity on that for well over a
>> year. One particular open PR - "Python 3.7 support" - is particularly
>> concerning, given the recent mailing list threads on the matter.
>>
>> Given that multiple projects are using this, we may want to think about
>> reaching out to the author and seeing if there's anything we can do to
>> at least keep this maintained going forward. I've talked to cdent about
>> this already but if anyone else has ideas, please let me know.
>>
>> Stephen
>>
>> [1] https://pypi.org/project/Paste/
>> [2] https://bitbucket.org/ianb/paste/
>> [3] https://bitbucket.org/ianb/paste/pull-requests/41
>>
>
> The last I heard, a few years ago Ian moved away from Python to
> JavaScript as part of his work at Mozilla. The support around
> paste.deploy has been sporadic since then, and was one of the reasons
> we discussed a goal of dropping paste.ini as a configuration file.
>
> Do we have a real sense of how many of the projects below, which
> list Paste in requirements.txt, actually use it directly or rely
> on it for configuration?
>
> Doug
>
> $ beagle search --ignore-case --file requirements.txt 'paste[><=! ]'
> +++--++
> | Repository | Filename   
> | Line | Text   |
> +++--++
> | airship-armada | requirements.txt   
> |8 | Paste>=2.0.3   |
> | airship-deckhand   | requirements.txt   
> |   12 | Paste # MIT|
> | anchor | requirements.txt   
> |9 | Paste # MIT|
> | apmec  | requirements.txt   
> |6 | Paste>=2.0.2 # MIT |
> | barbican   | requirements.txt   
> |   22 | Paste>=2.0.2 # MIT |
> | cinder | requirements.txt   
> |   37 | Paste>=2.0.2 # MIT |
> | congress   | requirements.txt   
> |   11 | Paste>=2.0.2 # MIT |
> | designate  | requirements.txt   
> |   25 | Paste>=2.0.2 # MIT |
> | ec2-api| requirements.txt   
> |   20 | Paste # MIT|
> | freezer-api| requirements.txt   
> |8 | Paste>=2.0.2 # MIT |
> | gce-api| requirements.txt   
> |   16 | Paste>=2.0.2 # MIT |
> | glance | requirements.txt   
> |   31 | Paste>=2.0.2 # MIT |
> | glare  | requirements.txt   
> |   29 | Paste>=2.0.2 # MIT |
> | karbor | requirements.txt   
> |   28 | Paste>=2.0.2 # MIT |
> | kingbird   | requirements.txt   
> |7 | Paste>=2.0.2 # MIT |
> | manila | requirements.txt   
> |   30 | Paste>=2.0.2 # MIT |
> | meteos | requirements.txt   
> |   29 | Paste # MIT|
> | monasca-events-api | requirements.txt   
> |6 | Paste # MIT|
> | monasca-log-api| requirements.txt   
> |6 | Paste>=2.0.2 # MIT |
> | murano | requirements.txt   
> |   28 | Paste>=2.0.2 # MIT |
> | neutron| requirements.txt   
> |6 | Paste>=2.0.2 # MIT |
> | nova   | requirements.txt   
> |   19 | Paste>=2.0.2 # MIT |
> | novajoin 

Re: [openstack-dev] [sahara][ptg] Sahara schedule

[Jeremy Freudberg]

Tuesday+Wednesday positive: gives time on Monday for the API SIG (I
personally would like to be there) and the Ask-me-anything/goal help
room

Tuesday+Wednesday negative: less time for Luigi (if he is at PTG) to
do QA things (but QA will also be there on Thursday)

Tuesday+Wednesday negative: the further we go into the week, the more
there is a risk that I am needed back at school (although from what I
can see now this will not be a problem)


Basically you can pick whatever days, and then I will make it work. I
don't want to be accountable for such a decision.


On Mon, Jul 2, 2018 at 12:50 PM, Telles Nobrega  wrote:
> Hi Saharans,
>
> as previously discussed, we are scheduled for Monday and Tuesday at the PTG
> in Denver. I would like to hear from folks who are planning to be there
> which days works best for you. Options are, Monday and Tuesday or Tuesday
> and Wednesday.
>
> Keep in mind that I can't guarantee a switch, I can only propose to the
> organizers and see what we can do.
>
> Thanks all,
> --
>
> TELLES NOBREGA
>
> SOFTWARE ENGINEER
>
> Red Hat Brasil
>
> Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo
>
> tenob...@redhat.com
>
> TRIED. TESTED. TRUSTED.
>  Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
> pelo Great Place to Work.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [sahara] Breathing new life into external Sahara CI

[Jeremy Freudberg]

I am happy to announce that I have finally acquired two machines to be
used towards our external CI infrastructure. (Thanks very much to
Cisco for their generosity!)

Now that we have accomplished the hard part, getting a hardware
donation, we can finally move on to the next step of actually
deploying the CI services. I call upon the Sahara community as a whole
to assist me in this endeavor. We can use the sahara-ci-config repo as
a starting point, but there are some tweaks to discuss.

Best,
Jeremy

__
OpenStack Development Mailing 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] [sahara][all] Outcomes of Sahara Rocky virtual PTG session

[Jeremy Freudberg]

Hi again all,

As promised, the outcomes of our recent virtual PTG session are made
public. Please view the Etherpad containing those outcomes here:
https://etherpad.openstack.org/p/sahara-rocky-VIRTUAL-ptg

(The Dublin outcomes are on this Etherpad:
https://etherpad.openstack.org/p/sahara-rocky-ptg )

Thanks to all who participated. I do think that it was a productive
enough session that we do not need to schedule another one. If,
however, someone has further points to raise, please let the team
know.

Looking forward to an excellent cycle,
Jeremy

__
OpenStack Development Mailing 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] Poll: S Release Naming

[Jeremy Freudberg]

My apologies... Frank paints a more accurate picture of the trademark
situation than I have done.

Let's defer to Frank on this one.


On Mar 14, 2018 8:33 AM, "Frank Kloeker" <eu...@arcor.de> wrote:

Hi,

it's critical, I would say. They canceled the registration just today [1],
but there are still copyrights for name parts like  "S-Bahn Halleipzig". I
would remove it from the voting list to prevent us from trouble. S-Bahn is
not really a location in Berlin. If it does, S-Bahn is broken ;-)

kind regards

Frank (from Berlin)

[1] https://register.dpma.de/DPMAregister/marke/registerHABM?AKZ=007392194


Am 2018-03-14 13:14, schrieb Jeremy Freudberg:

> Hi Dmitry,
>
> According to Wikipedia [0] the trademark was removed. The citation [1]
> is actually inaccurate; it was not the final ruling. Regardless [2]
> seems to reflect the final result which is that the trademark is
> cancelled.
>
> Hope this helps.
>
> [0]
> https://en.wikipedia.org/wiki/S-train#Germany,_Austria_and_Switzerland
> (end of paragraph
> [1]
> http://juris.bundespatentgericht.de/cgi-bin/rechtsprechung/
> document.py?Gericht=bpatg=en=Aktuell=23159=
> 1=323=1.pdf
> [2]
> http://www.eurailpress.de/news/bahnbetrieb/single-view/news/
> bundesgerichtshof-db-verliert-marke-s-bahn.html
>
> On Wed, Mar 14, 2018 at 7:50 AM, Dmitry Tantsur <dtant...@redhat.com>
> wrote:
>
> Hi,
>>
>> I suspect that S-Bahn may be a protected (copyright, trademark,
>> whatever) name. Did you have a chance to check it?
>>
>> On 03/14/2018 12:58 AM, Paul Belanger wrote:
>>
>> Greetings all,
>>>
>>> It is time again to cast your vote for the naming of the S
>>> Release. This time
>>> is little different as we've decided to use a public polling
>>> option over per
>>> user private URLs for voting. This means, everybody should proceed
>>> to use the
>>> following URL to cast their vote:
>>>
>>>
>>>
>>>
>> https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_40b95cb2be3
> fcdf1=8cfdc1f5df5fe4d3
>
>> [1]
>>>
>>>
>>> Because this is a public poll, results will currently be only
>>> viewable by myself
>>> until the poll closes. Once closed, I'll post the URL making the
>>> results
>>> viewable to everybody. This was done to avoid everybody seeing the
>>> results while
>>> the public poll is running.
>>>
>>> The poll will officially end on 2018-03-21 23:59:59[1], and
>>> results will be
>>> posted shortly after.
>>>
>>> [1]
>>>
>>>
>> http://git.openstack.org/cgit/openstack/governance/tree/refe
> rence/release-naming.rst
>
>> [2]
>>>
>>> ---
>>>
>>> According to the Release Naming Process, this poll is to determine
>>> the
>>> community preferences for the name of the R release of OpenStack.
>>> It is
>>> possible that the top choice is not viable for legal reasons, so
>>> the second or
>>> later community preference could wind up being the name.
>>>
>>> Release Name Criteria
>>>
>>> Each release name must start with the letter of the ISO basic
>>> Latin alphabet
>>> following the initial letter of the previous release, starting
>>> with the
>>> initial release of "Austin". After "Z", the next name should start
>>> with
>>> "A" again.
>>>
>>> The name must be composed only of the 26 characters of the ISO
>>> basic Latin
>>> alphabet. Names which can be transliterated into this character
>>> set are also
>>> acceptable.
>>>
>>> The name must refer to the physical or human geography of the
>>> region
>>> encompassing the location of the OpenStack design summit for the
>>> corresponding release. The exact boundaries of the geographic
>>> region under
>>> consideration must be declared before the opening of nominations,
>>> as part of
>>> the initiation of the selection process.
>>>
>>> The name must be a single word with a maximum of 10 characters.
>>> Words that
>>> describe the feature should not be included, so "Foo City" or "Foo
>>> Peak"
>>> would both be eligible as "Foo".
>>>
>>> Names which do not meet these criteria but otherwise sound really
>>> cool
>>> should be added to a separate section of the wiki page and the TC
>>> may make
>>> an exception for one or

Re: [openstack-dev] Poll: S Release Naming

[Jeremy Freudberg]

Hi Dmitry,

According to Wikipedia [0] the trademark was removed. The citation [1] is
actually inaccurate; it was not the final ruling. Regardless [2] seems to
reflect the final result which is that the trademark is cancelled.

Hope this helps.

[0] https://en.wikipedia.org/wiki/S-train#Germany,_Austria_and_Switzerland
(end of paragraph
[1]
http://juris.bundespatentgericht.de/cgi-bin/rechtsprechung/document.py?Gericht=bpatg=en=Aktuell=23159=1=323=1.pdf
[2]
http://www.eurailpress.de/news/bahnbetrieb/single-view/news/bundesgerichtshof-db-verliert-marke-s-bahn.html

On Wed, Mar 14, 2018 at 7:50 AM, Dmitry Tantsur  wrote:

> Hi,
>
> I suspect that S-Bahn may be a protected (copyright, trademark, whatever)
> name. Did you have a chance to check it?
>
>
> On 03/14/2018 12:58 AM, Paul Belanger wrote:
>
>> Greetings all,
>>
>> It is time again to cast your vote for the naming of the S Release. This
>> time
>> is little different as we've decided to use a public polling option over
>> per
>> user private URLs for voting. This means, everybody should proceed to use
>> the
>> following URL to cast their vote:
>>
>>https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_40b95cb2be
>> 3fcdf1=8cfdc1f5df5fe4d3
>>
>> Because this is a public poll, results will currently be only viewable by
>> myself
>> until the poll closes. Once closed, I'll post the URL making the results
>> viewable to everybody. This was done to avoid everybody seeing the
>> results while
>> the public poll is running.
>>
>> The poll will officially end on 2018-03-21 23:59:59[1], and results will
>> be
>> posted shortly after.
>>
>> [1] http://git.openstack.org/cgit/openstack/governance/tree/refe
>> rence/release-naming.rst
>> ---
>>
>> According to the Release Naming Process, this poll is to determine the
>> community preferences for the name of the R release of OpenStack. It is
>> possible that the top choice is not viable for legal reasons, so the
>> second or
>> later community preference could wind up being the name.
>>
>> Release Name Criteria
>>
>> Each release name must start with the letter of the ISO basic Latin
>> alphabet
>> following the initial letter of the previous release, starting with the
>> initial release of "Austin". After "Z", the next name should start with
>> "A" again.
>>
>> The name must be composed only of the 26 characters of the ISO basic Latin
>> alphabet. Names which can be transliterated into this character set are
>> also
>> acceptable.
>>
>> The name must refer to the physical or human geography of the region
>> encompassing the location of the OpenStack design summit for the
>> corresponding release. The exact boundaries of the geographic region under
>> consideration must be declared before the opening of nominations, as part
>> of
>> the initiation of the selection process.
>>
>> The name must be a single word with a maximum of 10 characters. Words that
>> describe the feature should not be included, so "Foo City" or "Foo Peak"
>> would both be eligible as "Foo".
>>
>> Names which do not meet these criteria but otherwise sound really cool
>> should be added to a separate section of the wiki page and the TC may make
>> an exception for one or more of them to be considered in the Condorcet
>> poll.
>> The naming official is responsible for presenting the list of exceptional
>> names for consideration to the TC before the poll opens.
>>
>> Exact Geographic Region
>>
>> The Geographic Region from where names for the S release will come is
>> Berlin
>>
>> Proposed Names
>>
>> Spree (a river that flows through the Saxony, Brandenburg and Berlin
>> states of
>> Germany)
>>
>> SBahn (The Berlin S-Bahn is a rapid transit system in and around Berlin)
>>
>> Spandau (One of the twelve boroughs of Berlin)
>>
>> Stein (Steinstraße or "Stein Street" in Berlin, can also be conveniently
>> abbreviated as )
>>
>> Steglitz (a locality in the South Western part of the city)
>>
>> Springer (Berlin is headquarters of Axel Springer publishing house)
>>
>> Staaken (a locality within the Spandau borough)
>>
>> Schoenholz (A zone in the Niederschönhausen district of Berlin)
>>
>> Shellhaus (A famous office building)
>>
>> Suedkreuz ("southern cross" - a railway station in Tempelhof-Schöneberg)
>>
>> Schiller (A park in the Mitte borough)
>>
>> Saatwinkel (The name of a super tiny beach, and its surrounding
>> neighborhood)
>> (The adjective form, Saatwinkler is also a really cool bridge
>> but
>> that form is too long)
>>
>> Sonne (Sonnenallee is the name of a large street in Berlin crossing the
>> former
>> wall, also translates as "sun")
>>
>> Savigny (Common place in City-West)
>>
>> Soorstreet (Street in Berlin restrict Charlottenburg)
>>
>> Solar (Skybar in Berlin)
>>
>> See (Seestraße or "See Street" in Berlin)
>>
>> Thanks,
>> Paul
>>
>> 
>> __
>> OpenStack Development Mailing List (not for 

[openstack-dev] [sahara][all] Sahara Rocky Virtual PTG is SCHEDULED

[Jeremy Freudberg]

Hi again all,

We will have a remote session tomorrow, March 14, beginning at 13:30
UTC. Best guess is that it will run two hours. Come and go as you need
to.

The session will be hosted by Bluejeans: https://bluejeans.com/6304900378
(Take a moment to make sure your browser and peripherals are configured nicely)

All interested parties are welcome. I reiterate that all outcomes of
the session will be logged to the dev list.

Till then,
Jeremy

__
OpenStack Development Mailing 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] [sahara] PTG Summary

[Jeremy Freudberg]

Thanks Luigi and Telles for striving to work hard, even in my absence. :)
Some notes inline.

On Mon, Mar 12, 2018 at 10:39 AM, Telles Nobrega 
wrote:

> Hello Saharans and interested folks,
>
> This PTG was a very interesting experience, for those not familiar with
> what happened there, here goes a quick summary.
>
> The event became known as SnowOpenStack PTG due to some snow that got in
> the way of event. But that didn't get in the way of determined people that
> wanted to do good work anyways.
> This PTG for Sahara was different, we only had 2 people present so a few
> topics couldn't be fully discussed.
>
> We started our week as Sahara joining the Storyboard room in order to
> understand better their status and what are the needed steps for us to
> migrate from launchpad to storyboard.
> The outcome of that meeting was better than expected. There are only a few
> things needed from our side to fully migrate. Tosky got ahead on this and
> already updated the migration script to support sahara and other projects
> needs and tested the migration with success. Now we only need to wait on
> the storyboard team to test it as well and then we need to document that we
> are migrating to storyboard.
> Action item on this for all involved in the project: Take some time to
> read on Storyboard and get familiar with it.
>
> Than we started Sahara meetings:
>
> We started with the traditional retrospective, we looked over the work
> list from Queens, marking them with Done, Partially Done and Unstarted.
> Please all take a look at that and let me know if anything not prioritized
> from that list is necessary.
>
> Now to specific discussion topics.
>
> Plugins upgrades, deprecation and removals
> 
>
> CDH:
>
>- Upgrade to 5.12, 5.13 and 5.14
>- Deprecate 5.7, 5.9 if we are able to upgrade all three version or
>two of them
>- Remove 5.5.0
>
> MapR:
>
>- Upgrade to 6.0 and update latest packages for 5.2
>
> Looks like MapR 6 offers some new management services which we should
acknowledge and add.

>
>-
>- Remove all references to 5.1
>
> Ambari:
>
>- Upgrade Ambari to 2.6 and HDP to 2.6 as well
>- Use the Ambari 2.6 image with both HDP 2.6 and 2.5 and 2.4
>- Deprecate HDP version 2.3 and work the removal of ambari 2.4 for S
>
> Spark:
>
>- Upgrade to 2.3.0 and check 2.2.1 as subversion as 2.2.0
>- Deprecate 1.6, 2.1 (see move out of trusty discussion)
>- Remove 1.3
>
> Storm:
>
>- Upgrade to 1.2.1 and 1.2.0 (under the same tag 1.2)
>- Deprecate 1.0.1
>- Remove 0.9.2
>
> Vanilla:
>
>- Upgrade to vanilla 3.0.0 and check if we can add 2.7.5
>
> 2.7.5 seems much lower priority to me. Even 2.8.3 or the eventual 2.8.4
seems more important. But I'm not sure.


>
> Sahara CI
> -
> We are still facing issues with our third-party CI. We plan to have
> nightly jobs running each day for a plugin so we won't need too much
> resources, that seems possible with zuulv3.
> Also there is an issue with experimental queue, now we run all
> experimental jobs even when not necessary, we plan to split this in
> separate queues so we can run specific tests.
>

It looks like the wheels of progress are starting to turn on my end...


>
> Python 3 support
> ---
> Python 2 support is closing and we need to fully migrate to Python 3.
> Right now we have unit tests in place, tempest should be easily resolved;
> Scenarios jobs are there but failing with swift issues. Once we have all of
> those we will have a better grasp of what we need to do and how much work
> will be. In any case, we need to get a jump on these soon.
>
> SSL/TLS everywhere
> 
> We need to check our status of secure communication with other projects as
> well as between Sahara and its clusters. Right now Sahara should be able to
> communicate with CDH using SSL but it is hard coded and we need to change
> that and test how it goes. Also we need to check certificate management.
> For Ambari, CA is generated but not reconized on RHEL/CentOS>=7.4, we need
> to make sure this works.
>
> Move out of trusty
> 
> Trusty support will be dropped soon and we need to make sure we don't have
> any dependencies on our side. For that we need to work on removing plugins
> versions that are only supported on trusty.
>
> Plugins outside Sahara
> ---
> After discussion with Doug Hellman, seems like we have a good plan to have
> this finally done. The goal is the have a new project (sahara-plugins) that
> will require stuff from sahara and sahara itself will load plugins from
> sahara-plugins project dinamically with stevedore, this way we don't have a
> circular dependency.
> The bulk of the work is done, spec should be on its way soon.
>

+1


>

> APIv2
> 
> We have it available as experimental, but we miss CLI, tempest 

[openstack-dev] [sahara][all] Sahara Rocky Virtual PTG scheduling

[Jeremy Freudberg]

Hi all,

Due to my unexpected absence from Dublin we have decided that a
virtual PTG is a good idea. Let's try to find 90-120 minutes somewhere
in our busy schedules to convene remotely.

https://www.when2meet.com/?6755109-XpWjd

Please use the poll linked above to choose some times which work for
you. I've already started it with times that potentially work for me,
but I can become even more flexible if needed.

(Be warned that the poll site is a bit glitchy... make sure that you
are seeing the right times. Whatever time zone you are viewing it in
should show the first slot on Monday as equivalent to 1300 UTC. Also
be warned that depending on what time zone you are viewing in, the
date may "roll over" mid-column.)

All interested parties are welcome.

We will decide the exact medium of communication based on what media
the confirmed participants are able to use. In any case the outcomes
will be logged to the mailing list.

Best,
Jeremy

__
OpenStack Development Mailing 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] [sahara] Pre-PTG Doc Day

[Jeremy Freudberg]

On Tue, Feb 6, 2018 at 10:45 AM, Telles Nobrega <tenob...@redhat.com> wrote:
>
>
> On Tue, Feb 6, 2018 at 12:37 PM Jeremy Freudberg <jeremyfreudb...@gmail.com> 
> wrote:
>>
>> On Tue, Feb 6, 2018 at 6:53 AM, Telles Nobrega <tenob...@redhat.com> wrote:
>> > Hi folks,
>> >
>> > as we discussed in our last meeting, tomorrow (Wednesday 7th) we are going
>> > to do a first overview of our documentation in order to gather the maximum
>> > information of where we need to fix, add or remove stuff so we don't waste
>> > time at PTG on this.
>>
>> +1
>>
>> >
>> > We can fix small problems but the main goal is to have a list of places 
>> > that
>> > need fixing, so we can use during Rocky cycle as a guide for documentation
>> > improvement.
>> >
>> > In order to maiximize our reach it would good to split where each of us 
>> > will
>> > be looking at the documentation, so I thought:
>> >
>> > From:
>> > https://docs.openstack.org/sahara/latest/ we can split in 4 parts, since
>> > user guide seems to be biggest one person would work on User Guide, and
>> > other 3 each work on 2 topics (we can choose freely)
>> >
>> > From:
>> > https://docs.openstack.org/sahara-tests/latest/ it seems very direct, maybe
>> > tosky and I can take a look at it (everyone is free to do so as well)
>>
>> There's the saharaclient docs as well - but they are quite short and I
>> already read through most of them when I was working on the APIv2
>> stuff. So I'll take the client docs, plus whatever other section in
>> the main doc that you want to assign me :)
>>
>> >
>> > If anyone needs help, or the rabbit hole grows too much we can always
>> > reorganize the split.
>> >
>> > What do you think of it?
>>
>> Good plan. Although we should define our focus a bit better. Are we
>> just trying to find outdated/incorrect stuff, or should we also be
>> trying to look at the big picture? By big picture I mean trying to
>> identify gaps, or thinking about organization and not just content.
>
>
>
> I don't believe this totally up to me, what do you think? I would say lets 
> consider both cases, but work mainly on the outdated/incorrect stuff and at 
> PTG/after we can work in more details on the big picture stuff.

That plan makes sense to me.

>>
>> >
>> > Thanks
>> >
>> >
>> >
>> >
>> > --
>> >
>> > TELLES NOBREGA
>> >
>> > SOFTWARE ENGINEER
>> >
>> > Red Hat Brasil
>> >
>> > Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo
>> >
>> > tenob...@redhat.com
>> >
>> > TRIED. TESTED. TRUSTED.
>> >  Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
>> > pelo Great Place to Work.
>> >
>> > __
>> > OpenStack Development Mailing 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
>
> --
>
> TELLES NOBREGA
>
> SOFTWARE ENGINEER
>
> Red Hat Brasil
>
> Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo
>
> tenob...@redhat.com
>
> TRIED. TESTED. TRUSTED.
>  Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil 
> pelo Great Place to Work.
>
> __
> OpenStack Development Mailing 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] [sahara] Pre-PTG Doc Day

[Jeremy Freudberg]

On Tue, Feb 6, 2018 at 6:53 AM, Telles Nobrega  wrote:
> Hi folks,
>
> as we discussed in our last meeting, tomorrow (Wednesday 7th) we are going
> to do a first overview of our documentation in order to gather the maximum
> information of where we need to fix, add or remove stuff so we don't waste
> time at PTG on this.

+1

>
> We can fix small problems but the main goal is to have a list of places that
> need fixing, so we can use during Rocky cycle as a guide for documentation
> improvement.
>
> In order to maiximize our reach it would good to split where each of us will
> be looking at the documentation, so I thought:
>
> From:
> https://docs.openstack.org/sahara/latest/ we can split in 4 parts, since
> user guide seems to be biggest one person would work on User Guide, and
> other 3 each work on 2 topics (we can choose freely)
>
> From:
> https://docs.openstack.org/sahara-tests/latest/ it seems very direct, maybe
> tosky and I can take a look at it (everyone is free to do so as well)

There's the saharaclient docs as well - but they are quite short and I
already read through most of them when I was working on the APIv2
stuff. So I'll take the client docs, plus whatever other section in
the main doc that you want to assign me :)

>
> If anyone needs help, or the rabbit hole grows too much we can always
> reorganize the split.
>
> What do you think of it?

Good plan. Although we should define our focus a bit better. Are we
just trying to find outdated/incorrect stuff, or should we also be
trying to look at the big picture? By big picture I mean trying to
identify gaps, or thinking about organization and not just content.
>
> Thanks
>
>
>
>
> --
>
> TELLES NOBREGA
>
> SOFTWARE ENGINEER
>
> Red Hat Brasil
>
> Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo
>
> tenob...@redhat.com
>
> TRIED. TESTED. TRUSTED.
>  Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
> pelo Great Place to Work.
>
> __
> OpenStack Development Mailing 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] [sahara] PTL Nomination

[Jeremy Freudberg]

Thanks for volunteering again, Telles. The project is in good hands
under your leadership.

On Mon, Jan 29, 2018 at 2:45 PM, Telles Nobrega  wrote:
> Hi Saharans, I would like to nominate myself to act as PTL for Sahara during
> the Rocky cycle.
>
> I've been acting as PTL for the last two cycles (Pike and Queens) and I
> believe that even though we lost a lot of resources we were able to improve
> Sahara considerably in the last year.
>
> Moving forward I aim to continue working on the direction of making Sahara
> more user oriented.
>
> * Bug triaging:
>
> We need to start testing and cleaning the bug list and sadly this queue did
> not decrease significantly and we need to keep working on it.
>
> * Documentation:
>
> We already had improvements this lasy cycle but we need to keep going and
> for that we are already planning a documentation day pre-PTG and during PTG.
>
> * Final APIv2 work
>
> We need to finally release APIv2 in Rocky. We released APIv2 as experimental
> in Queens and will work to have it as main API in Rocky.
>
> In the overall picture we need to continue improving user experience and
> asking what is necessary to make Sahara more usable so we can have Sahara in
> more and more OpenStack deployments.

+1, I could not have said it better myself. This is an admirable focus
to have for the coming cycle.

> --
>
> TELLES NOBREGA
>
> SOFTWARE ENGINEER
>
> Red Hat Brasil
>
> Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo
>
> tenob...@redhat.com
>
> TRIED. TESTED. TRUSTED.
>  Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
> pelo Great Place to Work.
>
> __
> OpenStack Development Mailing 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] [sahara] [api] [sdks] [keystone] Sahara APIv2: service discovery

[Jeremy Freudberg]

I've been delayed in actually starting the grunt work on this. If
anyone else besides Monty is also able to chime in, feel free.

I'm a bit lost in trying to find examples of clients doing version
discovery + endpoint manipulation the "right way". If I could find a
good example life would be easier.

Stuff that constitutes the "right way":
- use keystoneauth for version discovery (should we be using
add_catalog_discover_hack [0] in Sahara's case?)
- actually using keystoneauth discovery features when creating the
client object (in my case, modifying [1])
- somehow putting the project id back in the URL (depending on at what
point in the process this happens, can that just be "%(project_id)s"
or must it be the actual project id, not sure)

All help appreciated.

Thanks!

[0] 
https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/discover.py#L1224
[1] 
https://github.com/openstack/python-saharaclient/blob/master/saharaclient/api/client.py

On Thu, Nov 30, 2017 at 7:34 PM, Monty Taylor <mord...@inaugust.com> wrote:
>
> On 11/30/2017 03:07 PM, Jeremy Freudberg wrote:
>>
>> Hi all,
>>
>> In the Sahara world, we are getting ready to expose our experimental
>> v2 API to real users and not just curious devs. Therefore we need to
>> start thinking about service/version discovery of this new API.
>
>
> \o/
>
>> Earlier this year, the service types authority was created, and one of
>> the things it asserted was that different service types for each API
>> version (like Cinder and Mistral did) is bad.
>>
>> So, it would entail that we should not adopt the `data-processingv2`
>> service type.
>
>
> Yes. Please don't... the service-types data has made its way into many places 
> now.
>
>> Unfortunately it's not so easy because Sahara API v1 relies on project
>> ID in the URL, and therefore is expected to be registered with the
>> project ID template in the Keystone service catalog. But API v2 does
>> not accept project ID in the URL.
>>
>> We don't want to break existing clients' ability to discover and use
>> Sahara among all clouds. So if we changed the expectation of the
>> endpoint for the current `dataprocessing` service type to never
>> contain project ID, some clients might get spooked. (Correct me if I'm
>> wrong)
>
>
> WELL - there's totally a way to do this that works, although it's gonna be 
> somewhat annoying.
>
> First and most importantly you need to update python-saharaclient to make 
> sure it can handle it an unversioned endpoint in the catalog (by doing 
> discovery) - and that if it finds an unversioned endpoint in the catalog it 
> knows to prepend project-id to the urls is sends. The easiest/best way to do 
> this it to make sure it's delegating version discovery to keystoneauth ... I 
> will be more than happy to help you get that updated.
>
> Then, for now, recommend that *new* deployments put the unversioned endpoint 
> into their catalog, but that existing deployments keep the v1 endpoint in the 
> catalog even if they upgrade sahara to a version that has v2 as well. (The 
> full description of version discovery describes how to get to a newer version 
> even if an older version is in the catalog, so people can opt-in to v2 if 
> it's there with no trouble)
>
> That gets us to a state where:
>
> - existing deployments with users using v1 are not broken
> - existing deployments that upgrade can have user's opt-in to v2 easily
> - new deployments will have both v1 and v2 - but users who want to use v1 
> will have to do so with a client that understands actually doing discovery
>
> Then let it sit that way for a while, and we can work to make sure that other 
> clients with sahara support are also up to date with version discovery.
>
> There will eventually come a point where a deployer will decide they want to 
> change their catalog from /v1/{project_id} to / ... but by then we should 
> have all the clients able to understand discovery fully.
>
>> So, we either need to break the rules and create the
>> `data-processingv2` type anyway, or we can create a new type just
>> called, for example, `bigdata` which going forward can be used to
>> discover either v1 or v2 without any interop concerns.
>
>
> I think renaming to bigdata is less terrible than data-processing2 ... but 
> let's see if we can't get things to work the other day first - there's a lot 
> of churn otherwise.
>
>> This is not an aspect of OpenStack I know a lot about, so any guidance
>> is appreciated. Once we figure out a way forward I will make sure
>> patches get proposed to the service types authority repo.
>

Re: [openstack-dev] [openstck-dev][sahara] Proposing Shu Yingya to Sahara Core Team

[Jeremy Freudberg]

+1

Thank you Yingya for all the reasons which Telles mentioned. Well-deserved!

On Dec 7, 2017 11:05 AM, "Telles Nobrega"  wrote:

> Hi Saharans,
>
> I would like to propose the addition of Shu Yingya to the Sahara Core Team.
>
> Shu Yingya has been with us for a while now and as of it is common for all
> core he has shown a great knowledge of the Sahara code base, along with all
> other small parts of sahara (SIE, sahara-tests, python-saharaclient and
> even integration of Sahara with deployment tools). Even more, he has
> contributed with great reviews with interesting fix suggestions and has
> shown an interest in seeing sahara become a better project each day.
> Other than that, he has become the biggest Sahara advocate in China,
> bringing lots of contributors to the project and helping leading them (it
> is very hard for me to do it with all the time difference).
>
> If there is no oposition, I will adding him to the core team ASAP.
>
> Thanks all and specially Shu Yiangya for the great work.
> --
>
> TELLES NOBREGA
>
> SOFTWARE ENGINEER
>
> Red Hat Brasil  
>
> Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo
>
> tenob...@redhat.com
> 
> TRIED. TESTED. TRUSTED. 
>  Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
> pelo Great Place to Work.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [sahara] [api] [sdks] [keystone] Sahara APIv2: service discovery

[Jeremy Freudberg]

Hi all,

In the Sahara world, we are getting ready to expose our experimental
v2 API to real users and not just curious devs. Therefore we need to
start thinking about service/version discovery of this new API.

Earlier this year, the service types authority was created, and one of
the things it asserted was that different service types for each API
version (like Cinder and Mistral did) is bad.

So, it would entail that we should not adopt the `data-processingv2`
service type.

Unfortunately it's not so easy because Sahara API v1 relies on project
ID in the URL, and therefore is expected to be registered with the
project ID template in the Keystone service catalog. But API v2 does
not accept project ID in the URL.

We don't want to break existing clients' ability to discover and use
Sahara among all clouds. So if we changed the expectation of the
endpoint for the current `dataprocessing` service type to never
contain project ID, some clients might get spooked. (Correct me if I'm
wrong)

So, we either need to break the rules and create the
`data-processingv2` type anyway, or we can create a new type just
called, for example, `bigdata` which going forward can be used to
discover either v1 or v2 without any interop concerns.

This is not an aspect of OpenStack I know a lot about, so any guidance
is appreciated. Once we figure out a way forward I will make sure
patches get proposed to the service types authority repo.

Best,
Jeremy

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

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

[Jeremy Freudberg]

-1 from me.

If one is a big name in OpenStack and/or has fingers in many pies,
then moving away from the 2/3 split makes sense. That is to say, if
you have the capacity for lots of interests, and lots of people are
interested in you, then flexible scheduling allows all those interests
to get satisfied.

But not every PTG atendee is like that. For example, I myself am a
full-time undergraduate student, who's essentially only works on
OpenStack (mostly Sahara) in his free time. I was fortunate enough to
attend PTGs in Atlanta and in Denver. And one of the main reasons I
was able to attend was because the Sahara team events were laid out as
_two consecutive marathon days_. Thanks, 2/3 split. Horizontal and
"theme" stuff is fun (and important to many), but not everyone has the
luxury of tacking on two extra days of extra stuff. My assumption is
that others for whom OpenStack contributions are a hobby and not part
of one's job probably share this sentiment, that we need to get-in and
get-out as quickly as we can, and can only really devote time to our
main project.


I also share Jay's intuition that it will be harder to get focus out
of several half-days then a few whole-days. For Sahara (at least from
my own observation) certainly that would be only the way to get enough
focus that we can really regroup, reset, and take stock of what we
have moving forward to the next dev cycle. A half-day feels disjointed
enough that it might as well be remote.

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

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

Re: [openstack-dev] Gertty dashboards

[Jeremy Freudberg]

I know nothing about Gertty, but it looks like you have two typos:

- Code-Review-0 should be Code-Review=0
- openstack/shade should openstack-infra/shade


That being said, there could still be other Gertty-specific things to
discuss here. Hope you get the answers you need!

On Sun, Oct 22, 2017 at 5:56 AM, Sławek Kapłoński 
wrote:

> Hello,
>
> Recently I started using Getty and I think it’s good tool.
> I have one problem which I don’t know how to solve. On web based gerrit
> page (review.openstack.org) I have defined page with own query:
>
> "(NOT owner:self) status:open label:Code-Review-0,self label:Workflow=0
> (project:openstack/neutron OR project:openstack/neutron-lib OR
> project:openstack/shade) branch:master”
>
> And it gives me list of many patches (more than 100 I think). Problem is
> that when I configured own dashboard with exactly same query in gertty.yml
> file I had only 22 patches displayed.
> I suppose that gertty is looking only for patches which are already in
> local database. Is it true? And is there any possibility to change it?
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>
>
>
> __
> OpenStack Development Mailing 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] Do you hate the new gerrit thing where the cursor jumps all over?

[Jeremy Freudberg]

Indeed it helps. Thanks!

On Fri, Oct 20, 2017 at 1:27 PM, Clark Boylan <cboy...@sapwetik.org> wrote:

> On Fri, Oct 20, 2017, at 10:16 AM, Jeremy Freudberg wrote:
> > I don't wanna turn this into a complaint session about new Gerrit. But
> > three little notes since the upgrade:
> >
> > - I can't push the "e" key to go into editing mode anymore
> > - Cherry-picks change the gerrit topic (that's probably a feature)
> > - The patch I'm already looking at shows up under "Same Topic" (that's
> > probably a feature)
> >
> >
> > The only one that really kills me is the first one. Anyone know if the
> > keyboard shortcut changed, or if it's disabled but configurable, etc...?
>
> The help overlay on the diff screen (brought up by hitting '?') says it
> is now " +  + e : Open Inline Editor".
>
> This seems to work for me in firefox on linux.
>
> Hope this helps,
> Clark
>
> __
> OpenStack Development Mailing 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] Do you hate the new gerrit thing where the cursor jumps all over?

[Jeremy Freudberg]

I don't wanna turn this into a complaint session about new Gerrit. But
three little notes since the upgrade:

- I can't push the "e" key to go into editing mode anymore
- Cherry-picks change the gerrit topic (that's probably a feature)
- The patch I'm already looking at shows up under "Same Topic" (that's
probably a feature)


The only one that really kills me is the first one. Anyone know if the
keyboard shortcut changed, or if it's disabled but configurable, etc...?

On Fri, Oct 20, 2017 at 12:02 PM, Matt Riedemann 
wrote:

> When you're lower in a change trying to expand comments and it always
> jumps you back up to the top?
>
> Since not everyone might know about the solution, it's:
>
> 1. Go into settings
> 2. Diff Preference
> 3. Change "Render" from Fast to Slow.
> 4. Save
>
> Get back to reviewing stuff without losing your mind.
>
> --
>
> 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

Re: [openstack-dev] [sahara] PTL duties and Meeting on Sep 29th

[Jeremy Freudberg]

Enjoy the time off. You've earned it.

Quick note, the cancelled meeting date will actually be Thursday Sept
*28* not 29 (which evidently coincides with Czech Statehood Day).

On Fri, Sep 22, 2017 at 3:29 PM, Telles Nobrega  wrote:
> Hi Saharans and interested parties,
>
> Next week I will be on PTO, I don't think pointing a temporary PTL is
> necessary since we have active cores that can handle the work without a
> problem.
>
> Also, since I will on PTO and Thursday is a public holiday in Tchech
> Republic I'm canceling the meeting.
>
> Thanks all and see you in week.
>
> --
>
> TELLES NOBREGA
>
> SOFTWARE ENGINEER
>
> Red Hat I
>
> tenob...@redhat.com
>
> TRIED. TESTED. TRUSTED.
>
> __
> OpenStack Development Mailing 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] Garbage patches for simple typo fixes

[Jeremy Freudberg]

Oops hit send to early.

1) git-review shows some community guidelines
2) auto-review of known lower-quality patches

And those do relieve some reviewer burden.

On Fri, Sep 22, 2017 at 12:43 PM, Jeremy Freudberg
<jeremyfreudb...@gmail.com> wrote:
> You're right. The amount of wasted reviewer time is far more
> drastic+problematic then the amount of "wasted" CI resources.
>
> My prior email did contain these suggestions:
>
>
> On Fri, Sep 22, 2017 at 11:04 AM, Jeremy Stanley <fu...@yuggoth.org> wrote:
>> On 2017-09-22 14:50:55 + (+), Rajath Agasthya (rajagast) wrote:
>>> On 9/21/17, 10:19 PM, "Jeremy Freudberg" <jeremyfreudb...@gmail.com> wrote:
>>> > 3) Delay spin-up of resource-intensive/long-running CI jobs
>>> > until after some initial review has been added or time has
>>> > passed. Authorized contributors, not necessarily synonymous with
>>> > cores, can override the delay if there's a critical patch which
>>> > needs to get through the queue quickly.
>>>
>>> +1. This is done in Go code review process, where CI is run by an
>>> explicit Run-TryBot+1 review only after a core developer
>>> ascertains that the patch looks okay and most code review comments
>>> are addressed. This means no CI resource usage for every change
>>> and every single patchset. We could adopt a similar approach so
>>> that CI resources aren’t wasted for useless patches. This doesn’t
>>> take a whole lot of work for the reviewers than the current review
>>> process.
>>>
>>> https://github.com/golang/go/wiki/GerritAccess#trybot-access-may-start-trybots
>>
>> I'm wary of potential overengineering like this, particularly
>> without at least some analysis showing the percentage of CI
>> resources we'll save by asking our already overworked (on most teams
>> anyway) core reviewers to also take on the task of authorizing basic
>> CI jobs. The more likely outcome I foresee is that, much like
>> contributions going unreviewed sometimes for weeks or months, the
>> change authors won't even know whether their changes are suitable
>> for review for some similar period of delay.
>>
>> The CI system is there to serve reviewers and contributors, not the
>> other way around. The CI resource shortages we see from time to time
>> should not be used as an excuse to go on witch hunts so we can find
>> ways to save what probably accounts for <1% of our overall
>> utilization. That's classic premature optimization. What's important
>> in this situation is the time wasted by reviewers having to respond
>> to or find ways to ignore these patches, so let's focus on that
>> rather than getting bogged down with attractive non-problems for
>> which we can more easily engineer technical solutions.
>> --
>> Jeremy Stanley
>>
>> __
>> OpenStack Development Mailing 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] Garbage patches for simple typo fixes

[Jeremy Freudberg]

You're right. The amount of wasted reviewer time is far more
drastic+problematic then the amount of "wasted" CI resources.

My prior email did contain these suggestions:


On Fri, Sep 22, 2017 at 11:04 AM, Jeremy Stanley <fu...@yuggoth.org> wrote:
> On 2017-09-22 14:50:55 + (+), Rajath Agasthya (rajagast) wrote:
>> On 9/21/17, 10:19 PM, "Jeremy Freudberg" <jeremyfreudb...@gmail.com> wrote:
>> > 3) Delay spin-up of resource-intensive/long-running CI jobs
>> > until after some initial review has been added or time has
>> > passed. Authorized contributors, not necessarily synonymous with
>> > cores, can override the delay if there's a critical patch which
>> > needs to get through the queue quickly.
>>
>> +1. This is done in Go code review process, where CI is run by an
>> explicit Run-TryBot+1 review only after a core developer
>> ascertains that the patch looks okay and most code review comments
>> are addressed. This means no CI resource usage for every change
>> and every single patchset. We could adopt a similar approach so
>> that CI resources aren’t wasted for useless patches. This doesn’t
>> take a whole lot of work for the reviewers than the current review
>> process.
>>
>> https://github.com/golang/go/wiki/GerritAccess#trybot-access-may-start-trybots
>
> I'm wary of potential overengineering like this, particularly
> without at least some analysis showing the percentage of CI
> resources we'll save by asking our already overworked (on most teams
> anyway) core reviewers to also take on the task of authorizing basic
> CI jobs. The more likely outcome I foresee is that, much like
> contributions going unreviewed sometimes for weeks or months, the
> change authors won't even know whether their changes are suitable
> for review for some similar period of delay.
>
> The CI system is there to serve reviewers and contributors, not the
> other way around. The CI resource shortages we see from time to time
> should not be used as an excuse to go on witch hunts so we can find
> ways to save what probably accounts for <1% of our overall
> utilization. That's classic premature optimization. What's important
> in this situation is the time wasted by reviewers having to respond
> to or find ways to ignore these patches, so let's focus on that
> rather than getting bogged down with attractive non-problems for
> which we can more easily engineer technical solutions.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing 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] Garbage patches for simple typo fixes

[Jeremy Freudberg]

Thanks for being brave enough to say it publicly. Not sure how many
more times I can stomach reading such classic patches as "Optimize the
link address" or "Replace six.iteritems() with .items()".

Yes, it is still possible for us to be an open community while also
minimizing the amount of useless patches.

Messages like the sample Matt provided are part of the solution.
Resisting the urge to -2/force-abandon without explanation is part of
the solution, too. But they aren't the whole solution.

The TC's emerging Top 5 help-wanted list is a step in the right
direction towards solving this problem. Let's publicize the crap out
of that. And we can go further, with project-specific help wanted
lists. And how about a better way to identify and promote issues which
are both low-hanging fruit AND important (they aren't actually that
rare!).

Turning towards more radical solutions: 1) Bake something into
git-review which will print out some agreed-up community guidelines
for what constitutes a useful patch, as well as any
repository-specific guidelines. To keep it reasonable, only show the
message the first time a contributor submits to that repository. 2)
Register fingerprints of common unhelpful patches and have a bot
similar to Elastic Recheck automatically review and comment. 3) Delay
spin-up of resource-intensive/long-running CI jobs until after some
initial review has been added or time has passed. Authorized
contributors, not necessarily synonymous with cores, can override the
delay if there's a critical patch which needs to get through the queue
quickly.

Those are just some ideas off the top of my head, so feel free to tear me apart.

Looking forward to seeing where this conversation goes this time around.



On Thu, Sep 21, 2017 at 10:21 PM, Matt Riedemann  wrote:
> I just wanted to highlight to people that there seems to be a series of
> garbage patches in various projects [1] which are basically doing things
> like fixing a single typo in a code comment, or very narrowly changing http
> to https in links within docs.
>
> Also +1ing ones own changes.
>
> I've been trying to snuff these out in nova, but I see it's basically a
> pattern widespread across several projects.
>
> This is the boilerplate comment I give with my -1, feel free to employ it
> yourself.
>
> "Sorry but this isn't really a useful change. Fixing typos in code comments
> when the context is still clear doesn't really help us, and mostly seems
> like looking for padding stats on stackalytics. It's also a drain on our CI
> environment.
>
> If you fixed all of the typos in a single module, or in user-facing
> documentation, or error messages, or something in the logs, or something
> that actually doesn't make sense in code comments, then maybe, but this
> isn't one of those things."
>
> I'm not trying to be a jerk here, but this is annoying to the point I felt
> the need to say something publicly.
>
> [1] https://review.openstack.org/#/q/author:%255E.*inspur.*
>
> --
>
> 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

Re: [openstack-dev] [sahara] PTG Summary

[Jeremy Freudberg]

Thanks Telles - we all appreciate your leadership which was conducive to a
very productive PTG.

Another exciting point to highlight is more community visibility and
involvement regarding Sahara's plugins:
1) Plugin upgrades tied to a release milestone visible on the official
release schedule
2) Collecting community and operator feedback about what new services
Sahara should support

Again, thanks to all involved and hope to see you all at next PTG.

On Wed, Sep 20, 2017 at 10:00 AM, Telles Nobrega 
wrote:

> Hello Saharan's and interested folks, this past week we had our PTG at
> Denver and it was a very productive one, with so many discussions and too
> much to do after that. In the next lines I will describe a little of the
> main decisions made by the Sahara team.
>
> Pike Retrospective
> -
> We started our PTG with a retrospective from the previous cycle. Since
> there were only sahara members on the room and we basically walked through
> the good and bads from the cycle.
>
> On the bad side:
>  - Losing too many community members
>  - First PTL cycle was a little overwhelming
>  - We had too much errors not caught by tests
>  - We lost our third-party CI
> On the good side:
>  - Most of our priorities was finished
>  - Even with minimum hands we managed to get plugins updated and deliver a
> good product
>  - We met the documentation in project goal
>
> Documentation
> 
> Alongside the community with the goal of moving documentation into project
> tree we were able to move a lot of our documentation into tree with just
> details left for Queens cycle.
> Also, we plan to do a Documentation day in order to update and improve our
> documentation.
>
> APIv2
> 
> This feature has been around for quite some time and in Pike we had a good
> advance in its implementation. We were able to do most of the work needed
> for its release but there are a few steps left. Our plan is to finish up
> all these steps in Queens and release APIv2 as experimental (at least).
>
> Sahara-CI
> --
> During the Pike cycle we lost our third-party CI. In Queens we need to
> gather resources to deploy a new CI as well as improve our CI in infra with
> vanilla multinode jobs. We plan to introduce some nightly jobs for more
> exhaustive testing with large files.
> We are also working on automating the CI deployment with ansible.
>
> Sahara-files
> 
> Just as Sahara-CI we might be losing our sahara files hosts soon and we
> need to remove all references of it from code (which is almost done) and
> copy the files for a different source.
>
> Specs cleanup and prioritization
> ---
> We took some time to review old specs and do a little cleanup of our
> queues. On that we moved some specs into backlog and added some new as well
> as fixed some typos on older specs.
>
> New features and bugs
> ---
> We discussed new features and bugs and we have a priority list for the
> work we plan to do in Queens and possible for next two cycles. If you are
> interested in a deeper look into planned features and bugs take a look at
> [0]
>
> Community-goals
> 
> For Queens there are two community goals. The first one is related to
> Split tempest plugin and this was done in Sahara a couple cycles ago. The
> second is regarding policy in code which we already have a patch (WIP) up
> [1] and should get it done soon.
>
> Thanks all!
>
> [0] https://etherpad.openstack.org/p/sahara-queens-ptg
> [1] https://review.openstack.org/#/c/503221/
>
>
>
> --
>
> TELLES NOBREGA
>
> SOFTWARE ENGINEER
>
> Red Hat I 
>
> tenob...@redhat.com
> 
> TRIED. TESTED. TRUSTED. 
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [sahara] [ptg] [all] Sahara dinner in Denver - planned

[Jeremy Freudberg]

Hey all,

The Sahara team dinner at Denver PTG will be this Wednesday night
(Sept 13). Very likely to take place at La Sandia, whose menu is here:
http://www.richardsandoval.com/lasandiacantina/uploads/menus/lasandiacantina-dinner.pdf

Due to poor pedestrian infrastructure and scorching heat we will most
likely Uber to and from the restaurant, which is just a short distance
away from the event hotel.

All are welcome. There's a spot to RSVP on the Etherpad as well:
https://etherpad.openstack.org/p/sahara-queens-ptg

Best,
Jeremy

__
OpenStack Development Mailing 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] [sahara] [ptg] Sahara dinner in Denver

[Jeremy Freudberg]

Hey all,

Sahara team: I will attempt to organize a team dinner in Denver. Not
sure when (Tuesday, Wednesday, Thursday night) or where (the immediate
area is notoriously spread-out and not pedestrian-friendly) but please
let me know if you have any thoughts. You can let me know on
email/IRC/etherpad.

Others: Being an active contributor to Sahara is not a requirement for
having dinner with the Sahara team! If you're interested in joining
us, please let us know on email/IRC/etherpad.

Best,
Jeremy

__
OpenStack Development Mailing 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] [sahara] Sahara-CI comes alive

[Jeremy Freudberg]

Hi Evgeny,

First, it is good to know even with only 50GB RAM and 20VCPU, Sahara
CI can still be deployed.
Actually, that is just the default quota on our cloud and we might be
able to increase it more.

However, that cloud is actually having some storage/disk issues
(failed writes...), so it's probably not a good idea to rush into
deployment right now - sorry.

I am definitely in favor of refactoring and automation! Preparing for
the future is always good.

There are still some internal talks about new dedicated resources
(arising from cooperation between my university and Red Hat) for
Sahara CI. If, hopefully, we get some good news out of that
discussion, automation makes even more sense: we can work on
automation during the time that we are waiting.

On Thu, Jul 27, 2017 at 3:44 AM, Evgeny Sikachov  wrote:
> Hey, guys!
>
> Unfortunately today I need to skip the meeting. But I have a question for
> discussion.
>
> Jeremy helped me with resources for Sahara-CI(a lot of thanks again!). And
> now we have around of 50GB RAM and 20VCPUs. This is enough to implement
> basic sahara-ci.
>
> In https://github.com/openstack/sahara-ci-config we have scripts for
> deploying but these scripts not fully automated. For deployment, I will need
> around 4 hours.
>
> My questions:
> Option 1:
> Do we need to deploy sahara-ci right now or we can refactor scripts for more
> convenient deployment/migration? Refactoring task can take 2 weeks.
>
> Option 2:
> I can deploy sahara-ci now in basic configuration, but if we got a crashing
> of infrastructure I will need to redeploy it manually again
>
> __
> OpenStack Development Mailing 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